[03:29] <eggbean> I usually have a bash script for my aws ec2 user script. I have just confugured an instance with EFS file storage, so it has added a load of #cloud-config yaml.  How do I include my bash script to this?
[05:38] <eggbean> I suppose I should just rewrite everything in the bash script to be done in  cloud-init instead?
[05:39] <eggbean> But is that the only way?
[08:01] <andras-kovacs> <Odd_Bloke "andras-kovacs: What behaviour ar"> Hi Odd_Bloke ! If I give an immutable flag for the resolv.conf ( I know it's ugly as hell but I had to :'( ) cloud-init-local will fail whatever I set in the cloud.cfg. I want cloud-init to completely leave alone the /etc/resolv.conf. I can make it only happen by disable cloud-init completely after the first run (with a runcmd).
[08:05] <andras-kovacs> cloaked1: are you sure in the suid flag on the nfs mount?
=== hjensas_ is now known as hjensas
=== hjensas_ is now known as hjensas
[12:50] <robjo> blackboxsw: Odd_Bloke #160 reviewed, just a couple of comments, overall LGTM. Thanks
[13:38] <Odd_Bloke> eggbean: You could try moving your shell script to a runcmd stanza: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#runcmd
[13:38] <eggbean> Odd_Bloke: Thanks.  I'll have a read.
[13:40] <Odd_Bloke> Alternatively, you could investigate passing multipart user-data to cloud-init, which would allow you to leave the generated YAML completely alone.
[13:40] <Odd_Bloke> But runcmd is definitely easier if it works for you.
[13:40] <eggbean> okay, cheers
[13:45] <Odd_Bloke> andras-kovacs: Could you pastebin the traceback you (presumably) get in /var/log/cloud-init.log?  That'd hopefully give me a hint as to what is poking at resolv.conf.
[13:45] <Odd_Bloke> robjo: Thanks!
[14:33] <fholmes> Does anyone know how I can make the hostname equal the vm name in vsphere using cloud-init?  I have a template I have setup with govc guestinfo.metadata and guestinfo.userdata strings.
[14:34] <fholmes> Not sure if I need to customize those either manually or a custom script or if I can use jinja2 templates in cloud-init to pull this off.  I don't really see any queriable instance-data atttributes I can use for vsphere (esxi or whatever).
[14:36] <Odd_Bloke> fholmes: I'm not familiar with VMWare products, but you can see the available attributes by running `cloud-init query -a`.
[14:36] <fholmes> Thanks Odd_Bloke!  I will check that out and see what i can come up with then.
[14:37] <Odd_Bloke> :)
[14:39] <Odd_Bloke> Heads-up: Travis are having issues: https://www.traviscistatus.com/incidents/ntxbkxt8lrx9
[14:43] <fholmes> Well ultimately the information is not there that I need, so I guess it is a custom script then.  Thanks again Odd_Bloke, I really appreciate the assistance.
[14:46] <Odd_Bloke> fholmes: Are you aware of the runcmd: stanza, to execute the script for you as part of cloud-init's run?
[14:46] <fholmes> Yes, I definitely am
[14:54] <Odd_Bloke> OK, good. :)
[14:55] <andras-kovacs> fholmes: it sounds interesting. Which name do you want to make static?  (place in /etc/hostname)? The "local" short one or the FQDN? For me, cloud-init prints the FQDN there.
[14:56] <fholmes> @andras-kovacs I want to use the name of the vm that shows up in the vcenter client to be the local-hostname of the deployed VM.
[14:57] <fholmes> For instance govc vm.clone -vm ubuntu-1804-kube-v1.17.3 kube-master-1.   I want the hostname to be the kube-master-1 basically.
[14:57] <Odd_Bloke> meena: Last call for comments on https://github.com/canonical/cloud-init/pull/160
[14:58] <Odd_Bloke> (I'm going to land it in the next couple of hours.)
[14:58] <Odd_Bloke> (Of course if you do have any comments after that, I will still listen to you. ;)
[15:01] <andras-kovacs> <Odd_Bloke "andras-kovacs: Could you pastebi"> so I have manage_resolv_conf: 0 in my cloud.cfg, there is an immutable flag on the resolv.conf and cloud-init-local.service gets failed on every reboot. Here are the logs from /var/log/cloud-init.log https://pastebin.com/szz2QaB9
[15:04] <andras-kovacs> I'm wondering... which is better? the FQDN or the local_hostname to store in /etc/hostname? Cloud-init puts the FQDN there in my VMs.
[15:12] <Odd_Bloke> rharper: ^ sounds very familiar, but I can't find a bug report about it.
[15:12] <fholmes> Well this seems to do the trick.  https://pastebin.com/aHVJanmW
[15:13] <Odd_Bloke> Nice!
[15:14] <fholmes> Would be nice to see better support for vsphere, but beggars cant be choosers!  lol.  I know there most likely has to be a better way honestly.  This is my first real foray into cloud-init though so I still have a lot to learn here.
[15:17] <meena> somebody please explain to me how y'all are able to focus on work
[15:24] <fholmes> Very easy.  I have worked from home for the past three years at least and this is a normal day for me.  If you look at the facts instead of watching the news there is an overall death rate of ~1%.  China has stopped the spread of the virus in their country so if we all just follow some basic common sense we are going to get through this in one
[15:24] <fholmes> piece.
[15:31] <rick_h_> heh, little harder than that but someone once said something famous about accepting things I cannot control, taking care of business when I can, and such.
[15:35] <Odd_Bloke> rharper: Travis had failed to report status on #274, so I've just kicked off one of the sub-jobs again to try and get Travis to report correctly without a full re-run, FYI.
[15:41] <andras-kovacs> meena: :D I've chosen a job which is kind of my hobby also.
[15:42] <andras-kovacs> fholmes: my colleague from China told me it's 1-2 weeks from now and they will reopen their office
[15:43] <fholmes> @andras-kovac That is definitely good news!  I am truly hoping their lives can get back to normal as quickly as possible.  Along with the rest of the world.
[15:44] <fholmes> And yes, I was lucky enough to find my passion in computers at 8 years old, about 34 years ago. lol
[15:44] <andras-kovacs> but my other colleague from India told me... it's getting harder to get groceries
[15:45] <andras-kovacs> fholmes: you can be still that kid with 34 years of experience
[15:46] <fholmes> lol, I am definitely that kid in a candy store when it comes to my daily life.  :) . Learning new technologies is what I live for each day and I am blessed to be in a position where I get paid to do it and share it with others.
[15:48] <andras-kovacs> I wish my colleagues would be the same as you with the attitude
[15:49] <fholmes> Yes, there are no beans and rice anywhere here in Arizona I am sure of it.  Food is still available but the store shelves empty very quickly.  I do have three kids and one of them just finished chemo for cancer and they are concerned it might have spread.  So ultimately I have more pressing things to worry about honestly.  However, he is
[15:49] <fholmes> immunocompromised but I refuse to let the fear of him getting sick enter my mind.  Luckily the county where we live have 0 reports so hopefully everything works out.
[15:51] <fholmes> Yes, I feel you @andras-kovacs it is painful working with many people in this industry.  I was very lucky to have gotten my current job.  There are no egos to content with on my team and everyone loves what they do.  It is definitely a very refreshing change and extremely rare in this industry.
[15:51] <fholmes> s/content/contend
[15:54] <andras-kovacs> I wish the best for your kid. I hope he will get better soon! My mother had cancer also. It took time but luckily she is well now.  And I wish great power for you!
[15:58] <andras-kovacs> yes, the IT industry nowadays like... bunch of people work for the money only while they are hating it. If you are in a different environment... that can be good.
[17:24] <fholmes> @andras-kovacs Thank you very much.  I am positive he will be fine.
[18:13] <smoser> someone on my local user group (http://www.mug.org) just linked to https://canonical.com/careers/2075752
[18:15] <rick_h_> smoser:  yea, I shared it in the old ubuntu-us-mi channel
[18:15] <rick_h_> howdy smoser
[18:15] <smoser> o/ rick_h_
[18:17] <smoser> just make sure people *here* are aware. its a good company to work for and a good team to be on.
[18:17] <rick_h_> smoser:  cool yea that's awesome. Hopefully can find some awesome folks for it. Thanks for the plug in here.
[19:22] <Odd_Bloke> rharper: https://github.com/canonical/cloud-init/pull/275#pullrequestreview-380626877 <-- reviewed
[19:32] <cloaked1> I'm curious. I'm trying to set bonds up for interfaces on a couple of machines and for some reason I keep getting the error "All parents must belong to the same VLAN" which doesn't make sense. What does "parents" mean in this context?
[19:32] <cloaked1> I found the code: https://github.com/maas/maas/blob/master/src/maasserver/forms/interface.py#L574
[19:32] <cloaked1> but that still doesn't make sense. This error is senseless to me.
[19:34] <cloaked1> maybe one must put the individual interfaces in the right VLAN before creating the bond in the target VLAN?
[19:35] <cloaked1> that's it. That error is horribly ambiguous.
[19:36] <rick_h_> cloaked1:  sounds about right. Sanity checking the interfaces can both participate in the bond I'd guess
[19:36] <cloaked1> yeah, at the least the error should be better worded.
[19:36] <cloaked1> not even a google check was very helpful per se.
[19:42] <rharper> cloaked1: generally you want to vlan over a bond.  so the bond will have a list of interfaces, and then the vlan would specify the bondX as it's vlan_link,
[19:42] <cloaked1> indeed. I'm aware of that.
[19:43] <cloaked1> the issue was that I needed to preset the interfaces to the desired VLAN first and then set the bond
[19:43] <rharper> is this a MAAS ui issue then ?
[19:43] <cloaked1> that workflow was not understood.
[19:43] <rharper> as that confused me coming from the bottom  up at least
[19:44] <cloaked1> I tried setting the desired VLAN during the time of bonding; the VLAN of which was different than wat the interfaces were on in the first place.
[19:44] <powersj> hmm blackboxsw were we suppose to do a status meeting today :\ are off a week because of the sprint
[19:44] <rharper> powersj: IIRC blackboxsw set it for every day this week
[19:44] <cloaked1> rharper: not sure but it doesn't seem right.
[19:44] <rharper> so maybe it's a mystery as to which day ?
[19:45]  * blackboxsw checkes oooh right :) cloud-init status roulette now
[19:45] <rharper> cloaked1: you point to the form, so I'm guessing UI;  versus some sort of network config error coming from cloud-init or netplan, etc
[19:45] <blackboxsw> I 'fixed' the invite for status and set it today, and forgot to host it.
[19:45] <blackboxsw> sooo, shall we hold the cloud-init status meeting now?
[19:46] <rharper> I suspect there's some database relation going on, in that a bond may select any of the member interfaces at any time, so guess they want the physical interfaces to be included in the same vlan (maas internal I suspect)
[19:46] <cloaked1> yes, correct. It was UI. Should I create a bug?
[19:46] <rharper> cloaked1: yeah, confusion is confusion =/
[19:46] <cloaked1> ok. I'll create a bug report.
[19:47] <eggbean> I am putting bash script commands into #cloud-config,runcmd, but maybe some things can be done in pure cloud-init?  adding/modifying users, setting timezone, locale, hostname associating elastic IP, modifying hosts file, rebooting... which of these can be done in cloud-init?
[19:47] <powersj> blackboxsw, I think we get more folks in the US morning
[19:47] <powersj> eggbean, have you looked through some of the cloud-config examples? https://cloudinit.readthedocs.io/en/latest/topics/examples.html
[19:47] <eggbean> powersj: thanks
[19:48] <powersj> eggbean, here are the docs for every module: https://cloudinit.readthedocs.io/en/latest/topics/modules.html
[19:48] <eggbean> cheers
[19:48] <rharper> eggbean: almost all of those have explicit cloud-config
[19:48] <eggbean> cool
[19:48] <rharper> the "hostname associating with elastic IP" is new to me, so maybe not that one
[19:49] <eggbean> rharper: missed a comma after hostname
[19:49] <rharper> ah;  I don't think we have a module for the elastic ip association;  but I've not done that via command line so not sure what command to use
[19:50] <blackboxsw> powersj: rharper Odd_Bloke shall I then shift status meeting to tomorrow (my holiday), Friday or Tuesday next week?
[19:50] <eggbean> aws cli.  Looks like I'll still be using runcmd for that then
[19:50] <rharper> yeah
[19:50] <powersj> blackboxsw, let's bump to next tuesday
[19:50] <powersj> thanks
=== blackboxsw changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting March 31 16:15 UTC | 19.4 (Dec 17) drops Py2.7 : origin/stable-19.4 | 20.1 (Feb 18) | https://bugs.launchpad.net/cloud-init/+filebug
[19:57] <blackboxsw> thx for the uss-tableflip cherry-pick branch review Odd_Bloke/rharper. Wrapping those comments up now.
[20:01] <cloaked1> @here https://bugs.launchpad.net/maas/+bug/1868868
[20:01] <ubot5> Ubuntu bug 1868868 in MAAS "UI: bonding NICs on different VLAN causes ambiguous error" [Undecided,New]
[20:02] <cloaked1> hopefully that is worded well enough for your understanding. If it is not, let me know and I can work through it.
[20:08] <andras-kovacs> is there a way to use the meta data in the hosts.*.tmpl files?
[20:13] <blackboxsw> interesting questions andras-kovacs, generally with the user-data, we allow any keys from 'cloud-init query --all' using a #template: jinja header before #cloud-config and referencing variables like  {{ v1.cloud }} in your template files. Example here https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#using-instance-data
[20:14] <blackboxsw> andras-kovacs: what tmpl file are you looking to use substitution on. I can double check quickly
[20:16] <andras-kovacs> I've added to this file: /etc/cloud/templates/hosts.redhat.tmpl
[20:16] <andras-kovacs> this line: {{ds.meta_data.local_ipv4}} {{fqdn}} {{hostname}}
[20:16] <andras-kovacs> But it's not working.
[20:18] <andras-kovacs> tl;dr app team asked for a line with the ip address of eth0 with the FQDN name. cloud-init makes it like: 127.0.0.1 {{fqdn}} {{hostname}}
[20:19] <blackboxsw> andras-kovacs: it's worth a bug,  I think I may have only turned on that jinja-template handling of instance-data.json variables for cloud-config user-data. It would be worth extending that to other template rendering I think.
[20:21] <andras-kovacs> blackboxsw: ok, thank you! I can go with runcmd of course but IMHO it would look more sophisticated with a template
[20:22] <andras-kovacs> where should I raise the bug? in GitHub?
[20:22] <blackboxsw> +1 andras-kovacs right. And I assume you've grok'd that runcmd can be a jinja-template too right ?
[20:22] <blackboxsw> ## template: jinja
[20:22] <blackboxsw> #cloud-config
[20:22] <blackboxsw> runcmd:
[20:23] <blackboxsw> andras-kovacs: we track bugs in Launchpad https://bugs.launchpad.net/cloud-init/+filebug
[20:23] <blackboxsw> we don't use issue tracking in github yet
[20:25] <andras-kovacs> yes i saw that but to be honest..  I was using it like: - cloud-init query region
[20:27] <andras-kovacs> so I should add the #cloud-config and ## template: jinja lines in the /etc/cloud/cloud.cfg also?
[20:28] <rharper> cloaked1: thanks
[20:29] <blackboxsw> andras-kovacs: nope on that file, it is sources essntially cloud-config yaml anyway. But another interesting application would be to allow jinja templating /etc/cloud/cloud.cfg too on a filesystem.  I don't think that is currently handled either
[20:30] <rharper> andras-kovacs: for bugs we track them in launchpad,  https://bugs.launchpad.net/cloud-init/+filebug
[20:30] <rharper> ah, blackboxsw already mentioned that, sorry;
[20:30] <blackboxsw> I think we 'could' extend /etc/cloud/cloud.cfg and cloud.cfg.d to support jinja-template files, but I'm not sure the machinery applies there yet
[20:30] <blackboxsw> no worries rharper thx. And I think it's worth a separate bug/feature request to support jinja-templates in /etc/cloud/cloud.cfg* files
[20:31] <andras-kovacs> ok "and that's the story how I sold my soul to Canonical" :D
[20:33] <andras-kovacs> yes, probably I gave it a try but it printed my variable names so that's why I'm using the query command in cloud.cfg. Thanks, I remember now.
[20:33] <rharper> blackboxsw: hrm, well;  it's not clear to me that we can
[20:33] <rharper> we read and source system config (/etc/cloud/*) which sets up things like datasource lists and other things that are unrelated to the instance
[20:33] <rharper> so I worry that folks would jinja things that cannot be expanded
[20:34] <rharper> existing template files /etc/cloud/templates/*  I think make sense as they're consumed after we're on a ds and have an instance (including metadata)
[20:34]  * rharper gets some coffee , brb 
[20:35] <andras-kovacs> so how people generally use it? I didn't wanted to make a special use-case here
[20:38] <andras-kovacs> I mean... I know here we are using chef and ansible most of the time but I like make things easier and if cloud-init can make these things happen from the beginning, I don't want to make it more complicated
=== hjensas_ is now known as hjensas
[20:40] <andras-kovacs> If I could include the basics in my VM templates than everybody would be happy and I could evangelize cloud-init :D
[20:40] <blackboxsw> ahh right rharper, trying to render jinja template before we have instance data (like setting the original datasource_list which ds-identify consumes) would be putting the cart before the horse.
[20:43] <andras-kovacs> I got your point but when I run the runcmd commands I have everything.
[20:43] <blackboxsw> though it's possible we could support some level of templating in /etc/cloud/cloud.cfg* for certain use-cases I think, especially if the templates were not depending on specific instance-data from 'cloud-init query'.
[20:43] <blackboxsw> And right andras-kovacs at runcmd time, you have everything.
[20:44] <andras-kovacs> oh I see sg. else too!
[20:44] <blackboxsw> at any cloud-config stage after the datasource is detected you'll have instance-data (the metadata variables), (which is either cloud-init-local or cloud-init-netwok stage depending on your cloud)  https://cloudinit.readthedocs.io/en/latest/topics/boot.html
[20:45] <blackboxsw> I mean "at any cloud-init stage*"   not cloud-config stage
[20:45] <andras-kovacs> so should I need to file a bug? I don't want to waste your / anyone else's time
[20:46] <blackboxsw> andras-kovacs: I think it's worth one bug on trying to use instance-data templates for your hosts.tmpl file
[20:48] <andras-kovacs> yes, I got that
[20:49] <blackboxsw> it's not a waste if we respond and decide it's not worth it for upstream, because it will document that decision for others. but, specifically at host rendering time based on distro, I *think* we are already past accumulating and persisting instance-data
[20:49] <blackboxsw> so it might be low hanging fruit that we could provide a feature for
[20:49] <blackboxsw> or something a "cloud-init evangelist in the community" could help with ;)
[20:50] <andras-kovacs> I really like the simplicity and the way how cloud-init works I don't want to mess it up with my requests
[20:50] <blackboxsw> no worries. never a mess up to have feature requests
[20:51] <blackboxsw> gives us a stream of suggestions to prioritize
[20:51] <andras-kovacs> like... it's great you haven't forget to hit a systemctl daemon-reload before mounting with the mount module
[20:51] <rharper> andras-kovacs: I'm +1 on allowing instance metadata use in /etc/cloud/templates/*  files ;  we need to think a bit more on the general /etc/cloud/ system config files
[20:56] <rick_h_> lol blackboxsw way to slide that in there
[20:59] <blackboxsw> heh
[21:00] <blackboxsw> rick_h_: /me likes the instance-data and json schema drum :)
[21:00] <blackboxsw> it's my favorite song :)
[21:15] <andras-kovacs> I would buy that CD than warez download the mp3 version and listen to it only on spotify(on-demand).
[21:15] <powersj> lol
[21:15] <blackboxsw> Odd_Bloke: comment on https://github.com/canonical/cloud-init/pull/277
[21:16] <blackboxsw> hah!
[21:22] <rharper> andras-kovacs: haha, awesome!
[21:25]  * cloaked1 loves IRC.
[21:26] <cloaked1> slack is good and all but nothing beats IRC imo.
[21:34] <blackboxsw> Odd_Bloke: https://github.com/canonical/cloud-init/pull/272#pullrequestreview-380713598 approved, just needs rebase
[21:34] <blackboxsw> and merge
[21:34] <Odd_Bloke> Thanks!
[21:35] <blackboxsw> https://github.com/canonical/cloud-init/pull/277 approved for real too Odd_Bloke
[21:35] <Odd_Bloke> Nice, thank you.
[21:35] <blackboxsw> can circle back if needed to point folks at your existing pytest example
[21:36] <rharper> https://github.com/canonical/cloud-init/pull/275  now has another hefty example of pytest.mark.parametrize
[21:37] <blackboxsw> rharper: +1 excellent, hadn't seen it yet.
[21:43] <blackboxsw> rharper: I didn't fully grok your review comment.https://github.com/canonical/cloud-init/pull/267#discussion_r397373585 isn
[21:43] <blackboxsw> per your comment "We want to allow a local cloud-config file to set the the policy. "   isn't my branch already sourcing the merged config from the 'local cloud-config' on disk and overriding distro defaults?
[21:44] <blackboxsw> or are you suggesting we shouldn't have distros even define a preferred_renderer_priority and we only do it in distro image default /etc/cloud/config.cfg
[21:46] <andras-kovacs> (I like this word now: grok. Thanks!)
[21:48] <blackboxsw> grok: "understand (something) intuitively or by empathy"    I'm all about empathy... :)
[22:09] <blackboxsw> rharper: I'm not seeing where you mention we have a default policy set for network renderers in ubuntu. I know we set it for *bsd but the typical Ubuntu cloud-images aren't adding network: renderers to the /etc/cloud/cloud.cfg that we write in cloud-images.
[22:10] <blackboxsw> we *can* and it would make the patch simpler if we dropped the Distro.preferred_renderer_priority() if you don't think we should add it (since we prioritize merged_cfg anyway if present
[22:34] <andras-kovacs> oh before I forget here is what I've added to my runcmd:
[22:34] <andras-kovacs>  - cloud-init query -f "{{ ds.meta_data.local_ipv4 }} {{ ds.meta_data.public_hostname }} {{ v1.local_hostname }}"
[22:34] <andras-kovacs>      | tee -a /etc/hosts /etc/cloud/templates/hosts.redhat.tmpl
[22:34] <andras-kovacs> and it works just great! thank you guys!
[22:35] <blackboxsw> nice andras-kovacs, excellent to hear
[22:35] <andras-kovacs> this way I could eliminate some custom shell scripts and systemd units
[22:37] <andras-kovacs> Very many thanks! I've added you on linkedin, I hope you don't mind.
[22:39] <blackboxsw> good, good andras-kovacs. my linked in is generally stale except when we are hiring :)  per here https://www.linkedin.com/posts/chad-t-smith-b8a5b54_ubuntu-server-software-engineer-activity-6639574095736426496-u5ja
[23:12] <andras-kovacs> blackboxsw: thanks!
[23:14] <andras-kovacs> Could you tell me what "resize_rootfs_tmp: /dev" does in the cloud.cfg? I see it belongs to the resiztefs module but I can't figure out the meaning of it.