Postgres version should be stated explicitly by the user. We can't auto-upgrade all apps, so we'd never change the 10.4 default. By forcing version to be explicit, we encourage users to pick the latest version when they first deploy, or to upgrade to latest from the old 10.4.
Also, non-existent storage class default is removed in favor of explicitly asking for storageClassName.
Change-Id: I715bcde6a66ca97be757abcea93c14139d61ed5a
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1791
Reviewed-by: informatic <informatic@hackerspace.pl>
This prevents authentication bypass from users on pod
network/boston-packets. Unfortunate.
Change-Id: I410dabff507b2f25298db09e99b6d628d76292b9
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1816
Reviewed-by: radex <radex@hackerspace.pl>
Rename `target_service` to `target` to mirror Service's `target`; rename `extra_paths` to `extraPaths` to follow the camelCase convention used everywhere except for a few places in kube.upstream (assumed to be a mistake)
Change-Id: Icfcb70ef889e3359bf0391c465034817f4b70cce
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1809
Reviewed-by: q3k <q3k@hackerspace.pl>
This is purely for consistency. While it's objectively more "magic" than the previous convention, newcomers may be asking themselves how come namespace is passed to kube objects using ns.Contain(), but to these custom objects via cfg.namespace.
Change-Id: I061c27c74213d5481b2c7e0afd5f316e84335786
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1808
Reviewed-by: q3k <q3k@hackerspace.pl>
Declare options when creating postgres {}, then pass env by taking from postgres's cfg and svc. This is both to reduce chance of making a mistake, and to improve copy-pasteability of jsonnets
Change-Id: Ief16a6825af64795f3b10e1e617b96c3d1c2a578
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1807
Reviewed-by: q3k <q3k@hackerspace.pl>
Introduce a convention of declaring a secretsRefs:: object below cfg:: for containing all secretKeyRefs. The goal is to self-document all secrets that need to be created in order to deploy a service
Change-Id: I3a990d54f65a288f5e748262c576d2a120efd815
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1806
Reviewed-by: q3k <q3k@hackerspace.pl>
A convention is introduced to specify `local top = self` declaration at the top of an app/service/component's jsonnet, representing the top-level object. Reasoning is as following:
- `top` is more universal/unambiguous than `app`
- `top` is usually shorter than $NAME
- a conventional `top` instead of $NAME (coupled with other conventions introduced) makes app jsonnets wonderfully copy-paste'able, aiding in learning and quickly building
Change-Id: I7ece83ce7e97021ad98a6abb3500fb9839936811
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1805
Reviewed-by: q3k <q3k@hackerspace.pl>
A convention is introduced to specify the kube.Namespace object in a deployment as a `local ns` instead of an `ns:` or a `namespace:` for these reasons:
- non-cluster admins cannot create new namespaces, and we've been moving in the direction of specifying objects that require cluster admin permissions to apply (policies, role bindings) in //cluster/kube/k0 instead of in the app jsonnet
- namespace admins CAN delete the namespace, making `kubecfg delete` unexpectedly dangerous (especially if a namespace contains more than just the contents of the file being applied - common with personal namespaces)
- `.Contain()` is a common operation, and it shows up in lines that are pretty long, so `ns.Contain()` is preferable to `app.ns.Contain()` or `service.namespace.Contain()`
Change-Id: Ie4ea825376dbf6faa175179054f3ee3de2253ae0
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1804
Reviewed-by: q3k <q3k@hackerspace.pl>
There's no difference as far as jsonnet is concerned, but it may confuse newbies, as Service and SimpleIngress use double colon for its top-level kube helpers. This also removes any ambiguity as to whether this is manifested in final JSON. So we can make that a convention.
Change-Id: I01ad4ea63f4d5d8ee6e5d41c79637ba186548c6f
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1803
Reviewed-by: q3k <q3k@hackerspace.pl>
The bootloader is *not* moved yet, machine still boots off the old disk
Change-Id: I8cc92489bb06bfe9581d68503237e08fa8082c7c
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1766
Reviewed-by: q3k <q3k@hackerspace.pl>
