| *** uzumaki has joined #airshipit | 02:23 | |
| *** uzumaki has quit IRC | 03:15 | |
| *** uzumaki has joined #airshipit | 03:15 | |
| *** uzumaki has quit IRC | 04:04 | |
| *** evrardjp has quit IRC | 05:33 | |
| *** evrardjp has joined #airshipit | 05:33 | |
| *** happyhemant has joined #airshipit | 09:05 | |
| *** SRao has joined #airshipit | 14:03 | |
| mattmceuen | Reminder: no IRC/Slack team meeting today. Happy (US) Thanksgiving! :) | 14:52 |
|---|---|---|
| *** roman_g has joined #airshipit | 14:59 | |
| airship-irc-bot | <craig.anderson> I'm not clear how airshipctl translates data from manifests into API objects | 15:56 |
| airship-irc-bot | <kk6740> what do you mean? | 15:57 |
| airship-irc-bot | <craig.anderson> `document.ToAPIObject` is the method that we use to do this? | 15:57 |
| airship-irc-bot | <kk6740> you pass your object to it and schema | 15:59 |
| airship-irc-bot | <kk6740> and it’s going to populate your object | 15:59 |
| airship-irc-bot | <craig.anderson> ok. something about the existing isogen implementation is broken as it does not seem to do this | 15:59 |
| airship-irc-bot | <kk6740> can u explain a little more? | 16:00 |
| airship-irc-bot | <craig.anderson> as I understand, the json paths are defined in the struct tags. ex: https://github.com/airshipit/airshipctl/blob/master/pkg/api/v1alpha1/imageconfiguration_types.go | 16:03 |
| airship-irc-bot | <kk6740> not json paths | 16:03 |
| airship-irc-bot | <kk6740> representation of the object in go | 16:04 |
| airship-irc-bot | <craig.anderson> but the tags are used to specify the json (yaml) path to load data from manifests? | 16:05 |
| airship-irc-bot | <craig.anderson> `json:"builder,omitempty"` | 16:05 |
| airship-irc-bot | <kk6740> thats the name of the field in json | 16:05 |
| airship-irc-bot | <kk6740> so basically if u marshal/unmrashal json ducments into this object | 16:05 |
| airship-irc-bot | <kk6740> it’s going to look for those fields | 16:05 |
| airship-irc-bot | <kk6740> u cant do json path there | 16:06 |
| airship-irc-bot | <kk6740> just plane name of the field | 16:06 |
| airship-irc-bot | <craig.anderson> I changed all of these to `json:"foobar,omitempty"` for image-builder but it did not fail any unit tests | 16:06 |
| airship-irc-bot | <kk6740> i don’t think that marshaling and unmarshaling is covered by unit tests. | 16:09 |
| airship-irc-bot | <kk6740> unit tests for isogen are quite limited probably | 16:10 |
| airship-irc-bot | <kk6740> due to the nature | 16:10 |
| airship-irc-bot | <kk6740> of this being external calls | 16:10 |
| airship-irc-bot | <craig.anderson> somehow the api object is an empty string instead of the value being set in manifests | 16:10 |
| airship-irc-bot | <kk6740> but certainly it would be beneficial to develop more unit-tests | 16:10 |
| airship-irc-bot | <kk6740> where do u read this object? | 16:11 |
| airship-irc-bot | <craig.anderson> I'm not sure that it is being read, which was the part that was confusing me since isogen includes values in manifests: https://github.com/airshipit/airshipctl/blob/master/manifests/function/ephemeral/image_configuration.yaml#L7 | 16:14 |
| airship-irc-bot | <craig.anderson> but as far as I can tell those values are never used anywhere | 16:14 |
| airship-irc-bot | <ih616h> check this function: https://github.com/airshipit/airshipctl/blob/master/pkg/bootstrap/isogen/command.go#L92 | 16:16 |
| airship-irc-bot | <craig.anderson> maybe I'm just missing the connection then, | 16:19 |
| airship-irc-bot | <kk6740> can u explain what problem u actually hitting? you are changing the values to different docker image and nothing happens? | 16:19 |
| airship-irc-bot | <craig.anderson> how does "cfg.Builder.UserDataFileName" know to populate with data from the "builder.userDataFileName" field in yaml | 16:20 |
| airship-irc-bot | <kk6740> this data is used by the container | 16:24 |
| airship-irc-bot | <kk6740> it is just passed to the container | 16:24 |
| airship-irc-bot | <kk6740> as volume | 16:24 |
| airship-irc-bot | <kk6740> https://github.com/airshipit/airshipctl/blob/c18db07043e8357f2c8698078711e904c2235c37/pkg/bootstrap/isogen/command.go#L101 | 16:24 |
| airship-irc-bot | <kk6740> i mean it writes userdata it finds in manifests to this file location | 16:26 |
| airship-irc-bot | <craig.anderson> I guess I am doing something wrong in my patchset. The api object is initializing with blank strings for these config parameters for isogen and for cowgen https://review.opendev.org/c/airship/airshipctl/+/758782 | 16:26 |
| *** roman_g has quit IRC | 16:27 | |
| airship-irc-bot | <craig.anderson> passing to container works fine. It is getting data form YAML into the api object which I have some issue with. Not understanding how the api object population knows which YAML fields to populate data from | 16:27 |
| airship-irc-bot | <kk6740> this is a huge patchset, i dont know where to look there | 16:28 |
| airship-irc-bot | <craig.anderson> If I can understand how this works with the existing code, that would help | 16:29 |
| airship-irc-bot | <craig.anderson> trying to follow how `cfg.Builder.UserDataFileName` referenced above knows to populate with data from the YAML path on Line 10 here https://github.com/airshipit/airshipctl/blob/master/manifests/function/ephemeral/image_configuration.yaml#L10 | 16:33 |
| airship-irc-bot | <kk6740> ok, with existing code we basically do: 1) kustomize build <directory_with_phase_documents> - this one should contain ur image builder configuration 2) we find a phase named like in cmd line `airshipctl phase run <phase name>` 3) We take the executor reference in the phase named specified in cmd line 4) if the phase with the name from cmd line references you image builder configuration, it will load executor interface 5) invoke Run | 16:34 |
| airship-irc-bot | method of the executor interface | 16:34 |
| airship-irc-bot | <kk6740> do u try to run image builder as phase? | 16:37 |
| *** roman_g has joined #airshipit | 16:37 | |
| -openstackstatus- NOTICE: The Gerrit service on review.opendev.org is being restarted quickly to troubleshoot an SMTP queuing backlog, downtime should be less than 5 minutes | 16:40 | |
| airship-irc-bot | <craig.anderson> yes, it runs as phases. It is locating the phase documents and running the executors from them | 16:46 |
| airship-irc-bot | <kk6740> ok, so lets limit this , remove all the phases but ur phase + executor from the bundle, and lets do `kustomize build` on it | 16:47 |
| airship-irc-bot | <kk6740> and see what’s rendering | 16:47 |
| airship-irc-bot | <craig.anderson> how does `cfg.Builder.UserDataFileName` know to populate with data from the YAML path of `builder.userDataFileName`, and not `foo.bar` ? | 16:47 |
| airship-irc-bot | <craig.anderson> ok | 16:47 |
| airship-irc-bot | <kk6740> using that `json.builder` annotation | 16:47 |
| *** roman_g has quit IRC | 16:48 | |
| airship-irc-bot | <craig.anderson> `json:"outputMetadataFileName,omitempty"` from the struct definition, yes? | 16:49 |
| airship-irc-bot | <kk6740> yes | 16:51 |
| airship-irc-bot | <ih616h> The `userDataFileName` is a member of `Builder`, which in turn is a member of `ImageConfiguration`. `ImageConfiguration` is the `runtime.Object` that is filled at https://github.com/airshipit/airshipctl/blob/master/pkg/bootstrap/isogen/executor.go#L56-L60 | 16:52 |
| airship-irc-bot | <kk6740> @craig.anderson did u generate zzz_deepcopy file changes or did them manualy? | 16:53 |
| airship-irc-bot | <ih616h> where `ToAPIObject` simply gets the yaml from the `ExecutorDocument` and passes it through the k8s json serializer | 16:53 |
| airship-irc-bot | <craig.anderson> ok, so I should be able to add some debugging to ToAPIObject to see where it's trying to pull data from | 16:55 |
| airship-irc-bot | <ih616h> that may help, sure | 16:55 |
| airship-irc-bot | <craig.anderson> @kk6740 manually | 16:56 |
| airship-irc-bot | <kk6740> so that maybe an issue | 16:56 |
| airship-irc-bot | <kk6740> we have a make file target to generate them | 16:56 |
| airship-irc-bot | <kk6740> use it to generate it | 16:56 |
| airship-irc-bot | <craig.anderson> ahh | 16:56 |
| airship-irc-bot | <kk6740> it is used during population of the object i think | 16:57 |
| airship-irc-bot | <ih616h> `make generate` is the target you need | 16:58 |
| airship-irc-bot | <craig.anderson> tyvm. trying that now. | 17:01 |
| airship-irc-bot | <craig.anderson> if that works I'll add a zuul job to -1 any patchsets that don't match the `make generate` output | 17:06 |
| airship-irc-bot | <kk6740> if that doesn’t help, and issue is somewhere else, you still need to make sure that those methods are generated with make generate :slightly_smiling_face: | 17:07 |
| airship-irc-bot | <craig.anderson> ok. so this zuul check will help either way | 17:08 |
| *** roman_g has joined #airshipit | 17:08 | |
| airship-irc-bot | <craig.anderson> I will propose this in a separate patchset | 17:09 |
| *** roman_g has quit IRC | 17:11 | |
| *** SRao has quit IRC | 17:35 | |
| *** happyhemant has quit IRC | 17:44 | |
| airship-irc-bot | <craig.anderson> no change in behavior =/ | 18:33 |
| *** mcriswell has quit IRC | 19:56 | |
| airship-irc-bot | <alexander.hughes> RE ViNO are we using kubebuilder, or ansible operator to scaffold the project? seems to be some confusion right now and it's not clear to me in the design document. seems the original POC was done via ansible operator, but I'm hearing we pivoted to kubebuilder to match SIP | 21:11 |
| airship-irc-bot | <alexander.hughes> https://hackmd.io/KSu8p4QeTc2kXIjlrso2eA#Virtual-Node-OperatorViNO is what I'm using as a reference | 21:11 |
| *** rezroo has joined #airshipit | 21:34 | |
| *** rezroo has quit IRC | 21:47 | |
| portdirect | we should update that doc is not already | 22:02 |
| portdirect | i did the poc in ansible operator | 22:02 |
| portdirect | but for the real thing, we should use kubebuilder | 22:02 |
| portdirect | so we have a consstent framework between our two operators | 22:03 |
| portdirect | just like a couple of grapes on the vine | 22:03 |
| portdirect | s/ansible operator/operator-sdk | 22:04 |
| airship-irc-bot | <dwalt> That makes sense. Thanks for clearing that up portdirect | 22:04 |
| portdirect | np | 22:04 |
| airship-irc-bot | <sudeep.batra> Hey guys, what is the expected output of sudo ./tools/deployment/35_deploy_workload.sh Is the below expected ? Any help appreciated. ```Deploy workload + airshipctl phase run workload-target --debug [airshipctl] 2020/11/18 04:11:06 opendev.org/airship/airshipctl@/pkg/k8s/applier/executor.go:129: Getting kubeconfig context name from cluster map [airshipctl] 2020/11/18 04:11:06 | 22:31 |
| airship-irc-bot | opendev.org/airship/airshipctl@/pkg/k8s/applier/executor.go:134: Getting kubeconfig file information from kubeconfig provider [airshipctl] 2020/11/18 04:11:08 opendev.org/airship/airshipctl@/pkg/k8s/applier/executor.go:139: Filtering out documents that shouldn't be applied to kubernetes from document bundle [airshipctl] 2020/11/18 04:11:08 opendev.org/airship/airshipctl@/pkg/k8s/applier/executor.go:147: Using kubeconfig at | 22:31 |
| airship-irc-bot | '/home/user/.airship/kubeconfig-524900776' and context 'target-cluster' [airshipctl] 2020/11/18 04:11:08 opendev.org/airship/airshipctl@/pkg/k8s/applier/executor.go:118: WaitTimeout: 33m20s [airshipctl] 2020/11/18 04:11:08 opendev.org/airship/airshipctl@/pkg/k8s/applier/applier.go:76: Getting infos for bundle, inventory id is workload-target [airshipctl] 2020/11/18 04:11:08 opendev.org/airship/airshipctl@/pkg/k8s/applier/applier.go:106: | 22:31 |
| airship-irc-bot | Inventory Object config Map not found, auto generating Inventory object [airshipctl] 2020/11/18 04:11:08 opendev.org/airship/airshipctl@/pkg/k8s/applier/applier.go:113: Injecting Inventory Object: {"apiVersion":"v1","kind":"ConfigMap","metadata":{"creationTimestamp":null,"labels":{"cli-utils.sigs.k8s.io/inventory-id":"workload-target"},"name":"airshipit-workload-target","namespace":"airshipit"}}{nsfx:false,beh:unspecified} into bundle | 22:31 |
| airship-irc-bot | [airshipctl] 2020/11/18 04:11:08 opendev.org/airship/airshipctl@/pkg/k8s/applier/applier.go:119: Making sure that inventory object namespace airshipit exists namespace/ingress unchanged helmrelease.helm.toolkit.fluxcd.io/ingress configured helmrepository.source.toolkit.fluxcd.io/ingress-nginx configured 3 resource(s) applied. 0 created, 1 unchanged, 2 configured namespace/ingress is Current: Resource is current | 22:31 |
| airship-irc-bot | helmrelease.helm.toolkit.fluxcd.io/ingress is Current: Resource is Ready helmrepository.source.toolkit.fluxcd.io/ingress-nginx is Current: Resource is Ready helmrelease.helm.toolkit.fluxcd.io/ingress is InProgress: reconciliation in progress helmrepository.source.toolkit.fluxcd.io/ingress-nginx is Current: Resource is Ready helmrelease.helm.toolkit.fluxcd.io/ingress is Current: Resource is Ready all resources has reached the Current status + | 22:31 |
| airship-irc-bot | echo 'Ensure we can reach ingress controller default backend' Ensure we can reach ingress controller default backend ++ curl --head --write-out '%{http_code}' --silent --output /dev/null 10.23.25.102:30000/should-404 + '[' 404 '!=' 404 ']'``` | 22:31 |
| airship-irc-bot | <sirajudeen.yasin> looks good | 22:33 |
| airship-irc-bot | <sirajudeen.yasin> in case of failure.. we will see "Failed to reach ingress controller default backend" , this seems to be success scenario | 22:34 |
| airship-irc-bot | <sirajudeen.yasin> may be we can add some message to say it is success | 22:35 |
| airship-irc-bot | <craig.anderson> do we support setting container security context with airshipctl/pkg/container? Either `--privileged` or `--cap-add=SYS_ADMIN` ? | 23:48 |
| airship-irc-bot | <craig.anderson> and if not, was it a deliberate design decision (something I should avoid adding)? | 23:51 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!