| 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? | 03:29 |
|---|---|---|
| eggbean | I suppose I should just rewrite everything in the bash script to be done in cloud-init instead? | 05:38 |
| eggbean | But is that the only way? | 05:39 |
| 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:01 |
| andras-kovacs | cloaked1: are you sure in the suid flag on the nfs mount? | 08:05 |
| === hjensas_ is now known as hjensas | ||
| === hjensas_ is now known as hjensas | ||
| robjo | blackboxsw: Odd_Bloke #160 reviewed, just a couple of comments, overall LGTM. Thanks | 12:50 |
| 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:38 |
| 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:40 |
| 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! | 13:45 |
| 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:33 |
| 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:34 |
| 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:36 |
| Odd_Bloke | :) | 14:37 |
| Odd_Bloke | Heads-up: Travis are having issues: https://www.traviscistatus.com/incidents/ntxbkxt8lrx9 | 14:39 |
| 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:43 |
| 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:46 |
| Odd_Bloke | OK, good. :) | 14:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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. ;) | 14:58 |
| 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:01 |
| 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:04 |
| 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:12 |
| Odd_Bloke | Nice! | 15:13 |
| 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:14 |
| meena | somebody please explain to me how y'all are able to focus on work | 15:17 |
| 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:24 |
| 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:31 |
| 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:35 |
| andras-kovacs | meena: :D I've chosen a job which is kind of my hobby also. | 15:41 |
| andras-kovacs | fholmes: my colleague from China told me it's 1-2 weeks from now and they will reopen their office | 15:42 |
| 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:43 |
| 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:44 |
| andras-kovacs | fholmes: you can be still that kid with 34 years of experience | 15:45 |
| 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:46 |
| andras-kovacs | I wish my colleagues would be the same as you with the attitude | 15:48 |
| 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:49 |
| 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:51 |
| 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:54 |
| 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. | 15:58 |
| fholmes | @andras-kovacs Thank you very much. I am positive he will be fine. | 17:24 |
| smoser | someone on my local user group (http://www.mug.org) just linked to https://canonical.com/careers/2075752 | 18:13 |
| 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:15 |
| 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. | 18:17 |
| Odd_Bloke | rharper: https://github.com/canonical/cloud-init/pull/275#pullrequestreview-380626877 <-- reviewed | 19:22 |
| 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:32 |
| cloaked1 | maybe one must put the individual interfaces in the right VLAN before creating the bond in the target VLAN? | 19:34 |
| cloaked1 | that's it. That error is horribly ambiguous. | 19:35 |
| 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:36 |
| 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:42 |
| 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:43 |
| 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:44 |
| * 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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 | 19:50 |
| === 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 | ||
| blackboxsw | thx for the uss-tableflip cherry-pick branch review Odd_Bloke/rharper. Wrapping those comments up now. | 19:57 |
| 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:01 |
| cloaked1 | hopefully that is worded well enough for your understanding. If it is not, let me know and I can work through it. | 20:02 |
| andras-kovacs | is there a way to use the meta data in the hosts.*.tmpl files? | 20:08 |
| 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:13 |
| blackboxsw | andras-kovacs: what tmpl file are you looking to use substitution on. I can double check quickly | 20:14 |
| 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:16 |
| 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:18 |
| 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:19 |
| andras-kovacs | blackboxsw: ok, thank you! I can go with runcmd of course but IMHO it would look more sophisticated with a template | 20:21 |
| 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:22 |
| 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:23 |
| andras-kovacs | yes i saw that but to be honest.. I was using it like: - cloud-init query region | 20:25 |
| andras-kovacs | so I should add the #cloud-config and ## template: jinja lines in the /etc/cloud/cloud.cfg also? | 20:27 |
| rharper | cloaked1: thanks | 20:28 |
| 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:29 |
| 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:30 |
| andras-kovacs | ok "and that's the story how I sold my soul to Canonical" :D | 20:31 |
| 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:33 |
| 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:34 | |
| andras-kovacs | so how people generally use it? I didn't wanted to make a special use-case here | 20:35 |
| 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 | 20:38 |
| === hjensas_ is now known as hjensas | ||
| 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:40 |
| 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:43 |
| 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:44 |
| 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:45 |
| blackboxsw | andras-kovacs: I think it's worth one bug on trying to use instance-data templates for your hosts.tmpl file | 20:46 |
| andras-kovacs | yes, I got that | 20:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| rick_h_ | lol blackboxsw way to slide that in there | 20:56 |
| blackboxsw | heh | 20:59 |
| blackboxsw | rick_h_: /me likes the instance-data and json schema drum :) | 21:00 |
| blackboxsw | it's my favorite song :) | 21:00 |
| 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:15 |
| blackboxsw | hah! | 21:16 |
| rharper | andras-kovacs: haha, awesome! | 21:22 |
| * cloaked1 loves IRC. | 21:25 | |
| cloaked1 | slack is good and all but nothing beats IRC imo. | 21:26 |
| 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:34 |
| 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:35 |
| rharper | https://github.com/canonical/cloud-init/pull/275 now has another hefty example of pytest.mark.parametrize | 21:36 |
| blackboxsw | rharper: +1 excellent, hadn't seen it yet. | 21:37 |
| 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:43 |
| 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:44 |
| andras-kovacs | (I like this word now: grok. Thanks!) | 21:46 |
| blackboxsw | grok: "understand (something) intuitively or by empathy" I'm all about empathy... :) | 21:48 |
| 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:09 |
| 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:10 |
| 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:34 |
| blackboxsw | nice andras-kovacs, excellent to hear | 22:35 |
| andras-kovacs | this way I could eliminate some custom shell scripts and systemd units | 22:35 |
| andras-kovacs | Very many thanks! I've added you on linkedin, I hope you don't mind. | 22:37 |
| 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 | 22:39 |
| andras-kovacs | blackboxsw: thanks! | 23:12 |
| 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. | 23:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!