#cloud-init 2014-06-18
<anotheral> is this the canonical channel for cloud-init?
<utlemming> anotheral: yup
<anotheral> i was just wondering if there's any documentation of the order of operations that happens in a cloud-config yaml?
<anotheral> i have some stuff that needs to happen before some other stuff :)
<utlemming> anotheral: /etc/cloud.cfg controls what happens when
<anotheral> beautiful
<anotheral> ta
<utlemming> anotheral: if you want to change that in user-data, you can do that too
<utlemming> anotheral: i.e. put #cloud-config into user-data
<anotheral> so the order of items in that cloud.cfg file is the order of execution?
<anotheral> not the order in my yaml
<utlemming> anotheral: yes
<anotheral> ah, looks like write_files isn't even in 12.04 cloud-init
<utlemming> anotheral: if you want to change that on boot, then define cloud_init_modules or cloud_config_modules in your #cloud-config user-data
<anotheral> oh interesting - that's good to know!
<anotheral> thanks folk!  LOOOOVE your product
<harlowja> yw!
<anotheral> if you don't mind, i do have one more question
<anotheral> i'm trying to create some files, but ubuntu 12.04 doesn't have the write_file capability
<anotheral> is there a decent workaround anyone is aware of?
<harlowja> anotheral send in a bash script that writes out the files
<harlowja> using bash syntax
<anotheral> ah right
#cloud-init 2014-06-19
<harmw> ah, with facebook offline I can finally start doing something :>
<harmw> oh, no, wait, I don't have FB
<smoser> harmw, :)
<smoser> i read that first line and was embarrased for you :)
<smoser> nice save though.
<harmw> haha
<harmw> its true, btw
<smoser> i do have a facebook account. but i spend less than 5 minutes per month.
<harmw> smoser: you happen to know a hosting company that offers /48 ipv6 ranges? perhaps even free like he.net or sixxs.net?
<smoser> no. i dont really have much hosting company experience.
<smoser> i use dreamhost. 
<smoser> is my only relationship with one
<harmw> hm hm ok
<kwadronaut> harmw: can't you sign up with ripe or similar?
<kwadronaut> i've got a /64 for ipv6 at 1 hosting company, and I believe that's what's custom/recommended (hetzner, ovh, bytemark and a bunch of others do this standard for each box)
<kwadronaut> i know bytemark gives a /48 on simple request, don't know if they're any good
<harmw> kwadronaut: this is just for at home :)
<harmw> but bytemark, lets see if there close enough to even consider :)
<kwadronaut> ripe doesn't mind, if they were to send me postcards, they'd get to my home with it's crappy dsl on the countrysideâ¦ 
<harmw> ok, ripe doesn't mind - but my wallet does :)
#cloud-init 2014-06-20
<CatKiller> Hi there! I've got a small issue with cloud-init on Ubuntu 14.04 desktop edition
<CatKiller> I've successfully installed it, but it seems that "dpkg-reconfigure cloud-init" fails with an error
<CatKiller> When ran, it opens the curses menu correctly, I can for instance pick another source
<CatKiller> but when I save, I get a few errors and the values of datasource_list remain unchangfed
<CatKiller> Here's a paste of the errors
<CatKiller> http://bpaste.net/show/nH2m5x3oKxGYP8cmrmBs/
<CatKiller> dpkg-reconfigure returns "0" on exit though
<CatKiller> Also the strange thing is that if I look in reconfigure, only the OpenStack datasource is selected.
<CatKiller> But if I look into /etc/cloud/cloud.cfg.d/90_dpkg.cfg only CloudStack appears on the datasource_list
<smoser> CatKiller, bug 1325746
<CatKiller> smoser: Thanks!
<smoser> i'm gonna upload that to proposed today
<smoser> but it will be at least 7 days till its in trusty-proposed
<CatKiller> Well I can probably compile and install cloud-init from source otherwise
<CatKiller> purge the apt installed package
<CatKiller> and just get the very latest
<CatKiller> Also another question
<CatKiller> I then changed /etc/cloud/cloud.cfg.d/90_dpkg.cfg "by hand" to include OpenStack and Ec2
<CatKiller> However when I run "cloud-init init" it doesn't seem to try to connect to the metadata server
<smoser> you can. but whenver dpkg-reconfigure cloud-init runs it screws it.
<smoser> you probably have to run 'cloud-init init --local' first
<CatKiller> Could that be that dpkg-reconfigure does more than just setting the metadata sources?
<smoser> as that will remove some state
<CatKiller> smoser: I'll try that too, thanks
<CatKiller> smoser: omg it worked. Thanks a lot. Not sure what that did though ;)
<smoser> CatKiller, sudo rm -f /var/lib/cloud/instance
<smoser> is about it really.
<smoser> since it had all ran before it found the 'None' data source. so running it again just said "already found".
<CatKiller> ahhhh ok
<CatKiller> smoser: I get it, I was wondering what all this data was about
<CatKiller> smoser: So basically, in the base image that directoy
<CatKiller> *directory should be empty
<smoser> well, its a symlink
<smoser> so it doesn't really  matter. 
<smoser> when it finds a datasource, it links that tot he current data.
<smoser> and other data is otherwise ignroed
<CatKiller> smoser: OK cool, that makes a bit of sense
<CatKiller> smoser: On a clean image, should I delete the entire contents of /var/lib/cloud then?
<CatKiller> I've noticed that this directory only gets populated the first time cloud-init runs
<CatKiller> So that I can leave cloud-init pick the "right" data source on boot?
<smoser> you can.
<smoser> you dont need to 
<smoser> but you can
<smoser> on boot, cloud-init --local gets run
<smoser> so it will always pick the right datasource
#cloud-init 2015-06-15
<openstackgerrit> Merged stackforge/cloud-init: Change the API of wait_any_url to return a tuple of url and response  https://review.openstack.org/191100
<Odd_Bloke> claudiupopa: Review of https://review.openstack.org/#/c/191137/ is blocking the other two things you reviewed from landing. :)
<Odd_Bloke> (Apologies if you were already getting to it)
<claudiupopa> ah, missed it.
<claudiupopa> thanks
<claudiupopa> This means that the documentation for windows specific modules will not be created by autodoc?
<Odd_Bloke> claudiupopa: It does; but that's unavoidable unless we make the things we want to document importable on the doc-building host.
<claudiupopa> can it be done manually at least?
<Odd_Bloke> claudiupopa: I don't know, let me have a play.
<Odd_Bloke> claudiupopa: (If you could approve that, I'll submit any progress I make as a separate change)
<claudiupopa> ok, no need to block this. We'll write them by hand.
<Odd_Bloke> smoser: I've updated https://code.launchpad.net/~daniel-thewatkins/cloud-init/lp1464253/+merge/261849 with full parameter names and no use of shell=True.
<openstackgerrit> Merged stackforge/cloud-init: Don't try to generate autodoc for Windows modules.  https://review.openstack.org/191137
<openstackgerrit> Merged stackforge/cloud-init: Fail the doc build if we have any warnings.  https://review.openstack.org/191149
<openstackgerrit> Merged stackforge/cloud-init: Add doc8 checks to docs tox target.  https://review.openstack.org/191162
<Odd_Bloke> claudiupopa: Thanks for the reviews. :)
<claudiupopa> No problem. ;-)
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Clean up stale auto-generated autodoc files.  https://review.openstack.org/191139
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Clean up stale auto-generated autodoc files.  https://review.openstack.org/191139
<Odd_Bloke> claudiupopa: http://paste.ubuntu.com/11718962/ lets us autodoc more of the Windows code, but does make the Windows code uglier as a result.
<claudiupopa> that's quite ugly.
<Odd_Bloke> Well, you chose an ugly platform. ;)
<Odd_Bloke> If we bike-shed for long enough, Windows will probably be UNIX-based, right? :p
<Odd_Bloke> claudiupopa: Yeah, it's totally ugly; but I don't think we'll do any better with autodoc.
<Odd_Bloke> I'll have a look and see if there are any tools that can do autodoc-style stuff, but with static analysis.
<Odd_Bloke> Those should work OK.
<claudiupopa> That would be cool.
<claudiupopa> We could write one if not.
<Odd_Bloke> claudiupopa: Yeah, though Sphinx plugins are fairly painful to write.
<claudiupopa> can't we hook autodoc instead?
<Odd_Bloke> claudiupopa: Having a quick look through autodoc's source, it's pretty tied up with having a Python object that it can examine.
<Odd_Bloke> Preprocessing the files to remove everything except for docstrings _might_ work...
<Odd_Bloke> But I suspect that having some scripting which does this will be a lot less painful than trying to integrate it in to the Sphinx run itself.
<claudiupopa> Yeah, I mean it doesn't need to be an autodoc extension, as long as it builds .rst files from .py, all should be good.
<Odd_Bloke> Yeah.
<claudiupopa> Let's see if Joshua doesn't already have something like this. ;-)
<Odd_Bloke> :D
<Odd_Bloke> harlowja: ^^  ^_^
<Odd_Bloke> claudiupopa: harlowja: Thinking about it, I'm not sure that our use case (for reporting) really needs a library.
<Odd_Bloke> claudiupopa: harlowja: If there was a library that would give us _handlers_ for free, that would be more interesting.
<Odd_Bloke> But the pub-sub sort of a model is overkill; we'll only have one publisher, and a constrained number of subscribers (which will all be configured in the same place at the the same time, from configuration).
<Odd_Bloke> If we want to use pub-sub more generally within cloud-init, then it would obviously make sense for the reporting framework to use that.
<Odd_Bloke> But I don't think it justifies it in and of itself.
<claudiupopa> yeah, makes sense, it's a little overkill for our use case.
<claudiupopa> Odd_Bloke: harlowja: do we actually need something heavy weight as this https://github.com/stackforge/cloud-init/blob/master/cloudinit/version.py#L9?
<claudiupopa> in certain conditions, it looks for a git repo and tries to run a git command.
<Odd_Bloke> claudiupopa: Are you hitting problems with it?
<claudiupopa> yeah.
<claudiupopa> http://paste.openstack.org/show/294140/
<claudiupopa> Not related per se (I think), but I can't stop noticing the git calls.
<claudiupopa> It's executed from a local editable installation.
<Odd_Bloke> Yeah, it doesn't look directly related.
<Odd_Bloke> But that isn't ideal.
<Odd_Bloke> On the other hand, we shouldn't hit that in a proper installation.
<Odd_Bloke> harlowja: Thoughts?
<harlowja> sup
<harlowja> just got in
<harlowja> claudiupopa i there another claudiu in your work place?
 * harlowja gets confused when i see another claudiu 
<harlowja> lol
<harlowja> Odd_Bloke u no want my pub/sub thingy, lol
<harlowja> as far as https://github.com/stackforge/cloud-init/blob/master/cloudinit/version.py#L9 up to u guys
<harlowja> i'm fine with the second way, or just a static string (that someone remembers to update)
<smoser> harlowja, there are 2 claudiu in cloudbase
<harlowja> i knew its!
<smoser> and it is very confusing
<harlowja> :-P
<smoser> i had a conversation at ODS with someone who said 'hi, i'm claudio from cloudbase'
<harlowja> ya, i had to double-check on https://review.openstack.org/#/c/191168/
<smoser> and i said... um i don't think you are
<harlowja> lol
<harlowja> did u ask for ID then?
<harlowja> lol
<smoser> i sent him a gpg encrypted email with a password that was required before i would continue the conversation
<smoser> my social skills are l33t
<harlowja> lol
<harlowja> ha
<harlowja> def
<awkwords> l
<jaksi> hi!
<jaksi> I'm playing around with cloud-init. I don't really need a "cloud", I'm using the nocloud data source with QEMU, which works great as I can attach files as disk devices on the VM
<jaksi> is there a way to do something similar with conainers?
<smoser> jaksi, yeah.
<smoser> http://ubuntu-smoser.blogspot.com/2013/08/lxc-with-fast-cloning-via-overlayfs-and.html
<smoser> essentially you just write the same files that go on that disk into /var/lib/cloud/seed/nocloud-net/d
<ByPasS> smoser : quick question, I cannot seem to get linux vms to get the random generated password by nova injected by cloud-init
<jaksi> ah, great, thanks a lot!
<ByPasS> smoser : curl 169.254.169.254/openstack/latest/password is just plain empty
<ByPasS> smoser : I've been trying alot different configs but I guess that until the nova metadata is empty it will never succeed, any idea what is wrong or a direction to verify look for ?
<smoser> ByPasS, cloud-init doesn't pay attention to that.
<smoser> use ssh keys.
<smoser> ByPasS, but that said, i really haven't ever looked at it.
<smoser> i can verify that on my cloud
<smoser> 'password' is present in curl http://169.254.169.254/openstack/latest/
<smoser> but empty at curl http://169.254.169.254/openstack/latest/password
<ByPasS> smoser : oh let me check
<ByPasS> yea thats basicly my issue, I do agree to use ssh keys but it seems the project manager wants password injection for some obsucre reasons
<smoser> echo "root:$(curl http://169.254.169.254/openstack/latest/password)" | sudo chpasswd
<smoser> ^ ByPasS something to that affect might work.
<smoser> ByPasS, i wonder, is that a one time read thing ?
<ByPasS> smoser : runcmd on first boot you mean ?
<ByPasS> smoser : could be I will test it but as far as I know, with cloudbase-init for windows the metadata is still present upon reboots etc
<smoser> yeah.
<smoser> then, yeah, its porbably not read-once
<smoser> (which you might want it to be :)
<smoser> alexpilotti, probably knows how it works. i'd have to look at code.
<ByPasS> smoser : thatd be great I will still try it just in case :) who knows
#cloud-init 2015-06-16
<anotheral> hey can anyone help me figure out why my cloud-config isn't working?
<anotheral>  /var/lib/cloud/instances/i-dca1cb75/user-data.txt has base64-encoded text
<anotheral> that decodes to a #cloud-config file
<smoser> anotheral, it shouldnt be base64 encoded there.
<Odd_Bloke> smoser: I'd like to submit a talk to LinuxCon Europe/CloudOpen Europe (they're running at the same time in the same place); I was thinking that cloud-init 2.0 would be a good topic.
<Odd_Bloke> smoser: Would you be able to help me craft a talk proposal?
<smoser> sure
<Odd_Bloke> smoser: CFP ends tomorrow; I'll try and come up with something tomorrow morning, and we can maybe discuss it on/just after the 2.0 call?
<Odd_Bloke> smoser: (I've fixed the tests on that CloudStack MP)
<smoser> ok
<smoser> Odd_Bloke, pulled
<Odd_Bloke> smoser: Thank you, sir.
<Odd_Bloke> I'll look at backporting it tomorrow also.
<Odd_Bloke> smoser: Are you able to add all the releases back to precise as targets on https://bugs.launchpad.net/cloud-init/+bug/1464253 ?
<smoser> oh. you marked that security.
<smoser> why is that different then the non-security one ?
<smoser> (i had thought it was the cpc bug or something)
<Odd_Bloke> smoser: The other bug is actually about doing it every boot (which I don't think we want to be the default).
<smoser> oh. i see.
<Odd_Bloke> smoser: Someone just noted the security issue in the comments of that bug.
<smoser> well, why idd you mark 'fixes'
<smoser> which made me mark fixes ;)
<Odd_Bloke> >.<
<Odd_Bloke> Apologies.
<Odd_Bloke> Wasn't it easier when I use git-bzr-ng and couldn't use --fixes at all. ;)
<Odd_Bloke> smoser: Do you mind if I assign doing the devel release to you?
<smoser> context ?
<Odd_Bloke> smoser: The release of that security fix in to wily.
<jgarr> I have a redhat atomic host I'm trying to run subscription-manager register on via runcmd but it doesn't appear to run and there's no output in /var/log/cloud-init.log (debug: true is set)
<jgarr> other commands in runcmd work though. Is there a way I can tell cloud-init to parse a user-data file again so I can see it run and try to debug it?
<jgarr> running the command manually after the system is booted works without issue
<ByPasS> alexpilotti : Hi there, smoser told me yesterday you might have a better idea for my issue, any chance you being around ?
<smoser> jgarr, runcmd stuff is run in 2 parts.
<smoser> jgarr, so.. the first part, writes /var/lib/cloud/instance/scripts/runcmd from what it finds in user-data
<smoser> so you can check to see that you have that file
<smoser> that part is the 'runcmd' config job. it can be regenerated by:
<smoser>  cloud-init single --name=runcmd --frequency=always
<smoser> the second part is in scripts_user
<smoser> and it actually executes (via run-parts style) all programs in /var/lib/cloud/instance/scripts/runcmd
<smoser> that can be executed:
<smoser>  cloud-init single --name=scripts_user --frequency=always
<jgarr> smoser: thanks a ton for that. I'll look at my host and see what I have
<anotheral> smoser: i removed the base64 encoding, but it still doesn't set the hostname
<jgarr> smoser: sure enough. the runcmd file doesn't exist. runing cloud-init single doesn't generate it either. Now to figure out why
<jgarr> may be helpful to say I'm also doing this on hardware with --append"ds=nocloud\;seedfrom=/var/cloud-init/" and then putting meta-data and user-data in /var/cloud-init/
#cloud-init 2015-06-17
<smoser> jgarr, seedfrom was busted recently.
<smoser> https://bugs.launchpad.net/cloud-init/+bug/1455233
<smoser> anotheral, cna you give me example of what you're p utting in there?
<openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add the data source base classes and the HTTP OpenStack implementation  https://review.openstack.org/188327
<openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add the data source base classes and the HTTP OpenStack implementation  https://review.openstack.org/188327
* Odd_Bloke changed the topic of #cloud-init to: cloud-init || 2.0 reviews: https://review.openstack.org/#/q/project:stackforge/cloud-init,n,z
<Odd_Bloke> smoser: I'm pretty much wholesale lifting your OpenStack talk abstract. :)
<smoser> imitation is the greatest form of flattery
<Odd_Bloke> /nick Odd_moser
<ByPasS> Odd_Bloke : has discussed with smoser curl http://169.254.169.254/openstack/latest/password is empty on linux VMs
<ByPasS> Odd_bloke : on windows VM there is informations...
<ByPasS> as type
<ByPasS> as typo ! :D
<Odd_Bloke> ByPasS: On the OpenStack I'm looking at, there is an admin_pass key in the config drive metadata.
<Odd_Bloke> But not in the HTTP metadata.
<Odd_Bloke> (You don't want it in the HTTP metadata; you're effectively granting anyone with access to your server root if it's available from there)
<ByPasS> Odd_Bloke : the http metadata in windows is not really the password itself since there is mix with the password and the pub key is used to hash/encrypt it and in order to do nova get-password u need the private key sent..
<ByPasS> Odd_Bloke : I will need to have a look at config drive metadata I never used it so far (yet)
<ByPasS> Odd_Bloke : thanks using metada drive and this first boot command : mount /dev/sr0 /mnt; echo "ubuntu:"`cat meta_data.json  | python -mjson.tool | grep admin | awk -F'"' '{print $4}'` | chpasswd; umount /mnt it now sets the passwd properly :)
<Odd_Bloke> ByPasS: :)
<ByPasS> well forgot the full path for the cat but basicly u get the point
<Odd_Bloke> ByPasS: We'd be happy to accept a patch in to cloud-init for this, if you wanted to try that. :)
<ByPasS> Odd_Bloke : thatd be interesting, I will brag to my project manager about the successful passwd injection and will look into it if the company gimme some time or at least I can do it in spare time
<harlowja> Odd_Bloke http://tinyurl.com/on6c32o try that sucker out
 * harlowja nicer dashboard for gerrit
<harlowja> * created from  https://review.openstack.org/192770
<Odd_Bloke> OH YOU FANCY
<harlowja> :-P
* harlowja changed the topic of #cloud-init to: cloud-init || 2.0 reviews: http://tinyurl.com/on6c32o
<harlowja> :)
* Odd_Bloke changed the topic of #cloud-init to: cloud-init || cloud-init 2.0 reviews: http://tinyurl.com/on6c32o
 * harlowja to fast, ha
<Odd_Bloke> Needs more cowbell^Wcloud-init.
<harlowja> lol
<anotheral> smoser: actually, it looks like the cloud-init part is working, but that set_hostname: does not.  So i can use a shell script as a workaround.
<harmw> harlowja: I'm not seeing very mucho reviews :p
<harlowja> harmw make some more code ;)
<harmw> that hurts :p
<harlowja> ;)
 * harlowja can't do as much as i want, got all these other code-bases to help with too
 * harmw knows that problem :>
<harlowja> and i'm not #1 so need to make that happen ( @ http://stackalytics.com/?metric=commits )
<harlowja> *see bottom loll
<harlowja> :-P
<harlowja> taking my #1 place, bums
<harlowja> lol
<jgarr> do runcmd entries run as root? or as one of the defined users?
 * jgarr is curious if that's a problem with his subscription-manager command that doesn't appear to run
<ByPasS> jgarr : yes it does run as root / UID 0
<ByPasS> jgarr : at least from my experience I can use mount with runcmd which requires root
<jgarr> ByPasS: k thanks, then I have no idea why subscription-manager doesn't work as a runcmd :-/
<jgarr> my only thought is it runs too early in the boot process and network isn't available or something
<ByPasS> are you using list method or string ?
<ByPasS> as far as I know bootcmd is executed really early in the boot process
<ByPasS> runcmd set in a string should be executed on runlevel 3 while passing the info in a string will be written to a file and ran by sh (according to the doc)
<ByPasS> I'd add a while loop checking for network connectivity right before the subscription manager cmd to validate your suspicion
<jgarr> ByPasS: I see the command is in /var/lib/cloud/instance/runcmd but the machine isn't subscribed
<jgarr> I also try catching sterr/stout via `subscription-manager register ... >> /root/cloudinit.log 2>&1` but it never shows up in the file
<jgarr> I didn't think to try a loop. I'll give it a shot. thanks
#cloud-init 2015-06-18
<Odd_Bloke> harlowja: Do you know what Sean means at https://review.openstack.org/#/c/191081/3/zuul/layout.yaml?
<Odd_Bloke> harlowja: I feel like I might be missing some OpenStack CI understanding.
<harlowja> Odd_Bloke let me see
<harlowja> Odd_Bloke seems like he wants u to put it in the post section (which runs after it merges)
<harlowja> *which i don't think u want
<harlowja> although i'm not sure why he says ' these jobs always succeed, or fail for unrelated reasons.'
<Odd_Bloke> _Unless_ the normal coverage jobs don't fail at all.
<Odd_Bloke> i.e. they only produce coverage reports
<harlowja> so what he'd want is to change 'gate:' -> 'post:'
<Odd_Bloke> (Whereas ours _do_ fail on low coverage)
<harlowja> right
<harlowja> i think u might have to explain him that
<Odd_Bloke> Yep.
<harlowja> ^ because the above isn't 'typical' for openstack
<harlowja> most of the coverage just runs in post, and nobody ever looks at it, lol
<Odd_Bloke> harlowja: Thanks for helping me understand where he was coming from. :)
<harlowja> np
 * harlowja here to serve!
<harlowja> ha
<Odd_Bloke> sudo make me a sandwich
 * harlowja sticks finger in sandwich and gives it to u
<harlowja> lol
<harlowja> eat it if u want, lol
<Odd_Bloke> I don't understand; is this a sandwich that you've stuck a finger in, or will I literally be eating a finger?
<harlowja> hahah
<harlowja> u decide
<harlowja> stick one finger in a sandwich and then stick the other finger on it, then give it to u
<Odd_Bloke> You only have two fingers? :p
<harlowja> :-P
<alexpilotti> smoser: morning!
<alexpilotti> do you already have UEFI support in cirros by any chance?
<smoser> no. would need grub2 and haven't looked.
<alexpilotti> oki, guess Iâll stick with an ubuntu image for now
<smoser> yeah. i'td take a bit of work probably.
#cloud-init 2015-06-19
<openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add the data source base classes and the HTTP OpenStack implementation  https://review.openstack.org/188327
<vassie> Hello, I was wondering if anybody could help me write a cloud init script that I can use in Foreman to provision a VMware VM from a template?
#cloud-init 2016-06-20
<harmw_> I have no idea how the current/latest fbsd stuff works out for c-i
<harmw> it's been quite a while
<smoser> harlowja, i do not remember any specs per say on updating metadata.  I'm not sure whether or not the MD gets updated if you add a device or not (in the openstack metadata service)
<smoser> but i have said before, attempting to do  dynamic interface over config drive is really just stupid, and should not be attempted.
<harlowja> smoser ya, the shitty part is that we have folks here who poll the metadata stuff to see when it changes
<harlowja> and instead if said polling turned into 'wait for event that configdrive ejected and reinserted' that'd at least avoid polling
<smoser> you can't just pull a disk from a guest
<smoser> and expect that that wont up upset something
<smoser> try it, just yank your disk from your mac. see what happens.
<smoser> its *not* a sane event mechanism.
<harlowja> k
<smoser> what would change in the md ?
<harlowja> macs don't have disks
<harlowja> lol
<harlowja> my mac runs off pixie dust
<harlowja> lol
<harlowja> obviously
<smoser> well, pry it open, get something to dissolve the glue, then rip it out
<harlowja> lol
<smoser> what would change in the md ?
<harlowja> so the guys here alter the instance users via it apparently
<harlowja> and apparently that works
<harlowja> http://lists.openstack.org/pipermail/openstack-dev/2016-June/097705.html
<harlowja> and it appears u can update said stuff, which is werid
<harlowja> not sure why nova allows updating that stuff and having it be reflected
<harlowja> (abuse waiting to happen)
<harlowja> (maybe its one of those bug-features, lol)
<harlowja> (that snuck in)
<harlowja> anyways, i'm not super-attached to that, the guys here have 'used this feature' (for better/worse), ha
<harlowja> it just does raise the question, how do things that change get reflected in the instance (long polling metadata, repeated polling ... blah blah)
<harlowja> smoser how does amazon do this, just repeated polling?
<smoser> i completely disagree with "abusing nova"
<smoser> metadata is dynamic. config drive should not be.
<harlowja> but config-drive has equivalent of metadata in it
<harlowja> aka its a mirror of metadata
<harlowja> so then its a bad equivalent of the metadata service
<smoser> yes
<smoser> web services are read/write and dynamic
<harlowja> ya, so then maybe config-drive needs to be dumber
<smoser> disks are read/write and dynamic, but i dont think you really want to deal with that.
<harlowja> and not contain a full mirror
<smoser> i really think basically config drive should provide you with networking information that is guaranteed static
<smoser> and tells you where you can get dynamic information
<smoser> wrt disks being read/write and dynamic...
<smoser> one could argue that since disks *are* read/write, then the guest should be able to modify the contents of metadata by updating a key in the json and writing the new file
<harlowja> ya, so it either is accepted that its not a full equivalent, orrr it is mutated into being that
<smoser> and the host should have to deal with that
<harlowja> right, the pull the disk solution
<smoser> but that woudl be more insane than posting events through a iso9660 filesystem
<smoser> (i was suggesting guest tells host, and host tells guest...
<smoser> ie, bi-directional
<harlowja> sounds like a qemu-metadata-agent would be better than
<harlowja> which then is pretty much the metadata service
<harlowja> lol
<smoser> right.
<smoser> except for web services do not poll well
<smoser> as you suggested
<smoser> but long-poll may be acceptable
<smoser> i hadnt thought of metadata changing
<harlowja> ya, i wasn't  really aware this was a feature, ha
<harlowja> until i tried it, lol
<smoser> but for other events such as hotplug or remove of a disk or network, you do get an event sent to the guest
<smoser> which it can respond to
<smoser> ideally the networking information in the MD woudl get updated
<harlowja> right, so its not like it would be impossible to do the eject metadata disk/cd
<harlowja> (if full parity is really wanted)
<harlowja> it might just be weird (ie for windows)
<harlowja> (and the program doing something with that disk needs to be written so that it can have the disk drop at anytime..)
<smoser> what happens if you eject while the guest is doing a read ?
<smoser> or has it mounted.
<smoser> and thus has whatever flag in that cdrom there is that says "no thank you" to the eject button
<harlowja> ya, that sucks
<harlowja> lol
<smoser> there are solutions to this, and those solutions should be used.
<smoser>  ie, etcd or zookeeper
<smoser> or fancier stuff like that.
<harlowja> ya
<harlowja> nova is weird
<harlowja> lol
<harlowja> in that this feature exists, people started using it, but it is pretty shoddy lol
<harlowja> and half-parity and half...
<harlowja> openstack is weird
<harlowja> ha
<smoser> the nova metadata service really should not be used as a replacement for zookeeper or etcd and the like.
<smoser> i do agree that that is a bit of abuse.
<smoser> i think its sane to expect metadata to change in it.
<smoser> i think its *insane* to expect config drive to change
<harlowja> k
<harlowja> ya, the feature parity of what is config-drive and what is not then i think needs to happen
<smoser> harlowja, i didn't know of pythonn -m json.tool
<smoser> thats nice
<smoser> rharper, ^ . that is easy pretty print of json
<smoser> harlowja, yeah, you need etcd or zookeeper.
<smoser> or probably one of 30 different other solutions
<harlowja> ya
<harlowja> something like that
<smoser> and then...
<smoser> in full openstack style
<smoser> you should suggest a project to run that as a service
<harlowja> :)
<rharper> smoser: nice
<smoser> harlowja, so in rhel/centos
<smoser> we're not currently writing any .link files for renaming
<smoser> but i tihnk you do write the 70-persistent-net files
<smoser> is that right ?
<harlowja> ya, i do write it
<smoser> i jsut realized that on ubuntu, we're writing those .link files, but they will [almost] never be read.
<smoser> or respected at least
<smoser> as cloud-init then reads the config drive information and renames them himself.
<harlowja> ya, i also noticed that the team here is injecting dns searchdomains into the old eni format
<harlowja> and it appears neutron doesn't put those in yet
<smoser> ?
<harlowja> it only appears to put in the nameservers, but not the searchdomains (and there is ongoing/idle/dead? work in neutron to fix this)
<smoser> oh.
<smoser> so your openstack declares networking in the old ENI format way
<harlowja> ya, which does look for search domains
<harlowja> it appears the network_data json stuff doesn't have that, lol
<harlowja> https://bugs.launchpad.net/neutron/+bug/1108644
<harlowja> not implemented (yet)
<harlowja> so ummm, ya, oops
<harlowja> and afaik the old renderers will use that if its avail
<harlowja> while the newer ones may or may not
<harlowja> ha
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-dns-sysconfig/+merge/297817 at least uses it if it exists (which in openstack case it won't, lol)
<harlowja> pretty sure the eni renderer already uses it (if it exists)
<harlowja> smoser also, something we need to cleanup is the 2 eni parsers that now exist, lol
<harlowja> pretty sure i can just use the better one and delete mine, lol
<smoser> yeah. i think so. get rid of yours. as the other is pretty good at thsi point.
<harlowja> ya
<sather> when making a custom module, why is #cloud-config needed at the top of the injected user-data to 'activate' the module?
<smoser> sather, custom module ?
<sather> smoser: cloud-init directive
<sather> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/config/cc_foo.py
<smoser> if you provide cloud-config via user-data, it must start with #cloud-config (or in a multipart archive, it must be type cloud-config)
<sather> building off of ^^
<smoser> in order for a moulde to be run, though, it has to be listed in the /etc/cloud./cloud.cfg
<smoser> they're not discovered.
<sather> hmm
<sather> Passing it as user-data though will get it to run?
<sather> (assuming it has #cloud-config as first line of the file)?
<smoser> no.
<smoser> you cannot really pass in config modules
<smoser> you *can* pass in 'handlers'
<sather> ok, that's what I'm doing
<sather> sorry for the confusion
<smoser> well, i dont knwo that you are.
<smoser>  http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/part-handler-v2.txt
<smoser> that is a part handler
<smoser> you can pass it in as user-data.
<sather> ok no
<sather> I'm passing a yaml-formatted text file
<sather> with #config-data on top
<smoser> right.
<sather> I have a custom cc_do_something.py module in my /usr/lib/python/site-packages/cloudinit/config
<sather> directory
<sather> when the user-data text has the key `do_something:` it runs that module
<sather> so it's not a part-handler
<smoser> sather, right. it doesn't work like that.
<smoser> you have to enable your module
<smoser> by adding it to one of the sections (cloud_init_modules, cloud_config_modules, or cloud_final_modules)
<smoser> then cloud-init will run it and feed it the whole config
<smoser> which you can do whatever you want with
<sather> interesting. I'm not sure how this is working then
<sather> I kind of re-implemented cc_write_files.py because I have to use a specifically formatted yaml file and can't prepend the necessary info for write_files
<sather> but it seems to work without touching /etc/cloud/cloud.cfg
<sather> (original question was escaping #cloud-config at the top of the injected user-data)
<sather> by 're-implemented' I mean I just used cc_foo.py as a base and wrote to a file using the value from cfg['key']
<sather> without using cloudinit.util
#cloud-init 2016-06-21
<smoser> bah.
<smoser> rharper, http://people.canonical.com/~rharper/curtin/topics/networking.html
<smoser> can routes be per-interface ?
<rharper> yes
<rharper> they are in cloud-init;  I've a branch to bring curtin in-line
<rharper> it was needed to support the routes from network_data.json
<rharper> smoser: http://paste.ubuntu.com/17644428/  (that's an network_config with routes per subnet)
<smoser> rharper, i think they bot lost in cloud-init
<smoser> :-(
<rharper> hrm
<rharper> I don't think so
<rharper> smoser: cloudinit/net/eni.py:Renderer:_render_route
<rharper> it's possible the logic got broken in the refactor ; I don't think we have a unittest specifically for the routes under a subnet
<smoser> rharper, yeah, i think it got busted.
 * rharper shakes fist at harlowja 
<smoser> note the coede does
<smoser>  for route in subnet.get('routes', []):
<smoser> but then later
<smoser>  for route in network_state.iter_routes():
<rharper> smoser: shall I fix it? or do we make harlowja do that ?
<smoser> well, i'm close to having it and some other cleanups
<smoser> in bzr+ssh://bazaar.launchpad.net/~smoser/cloud-init/trunk.net-improve-lo-dns/
<rharper> ok
<smoser> i'm not sure exactly how to get the per-iface routes though
<rharper> in the new fancy net refactor world... I need to look at that
<rharper> smoser: hrm, yeah I don't think that iter is actually what we'd need
<rharper> the routes in subnets were part of the subnet under the iface property
<rharper> so you really want to iface_iter
<rharper> and then get subnets under the iface
<rharper> iter_interfaces
<rharper> smoser: hrm, it looks ok from here... in _render_interfaces, we have the for iface in iter_interfaces, and then we have a for route in subnet.get('routes', []); that'll render per-interface routes; the outer iter_route is for the global routes (type: route)
<smoser> but i dont hitnk subnet.get('routes', []) ever returns anything but []
<smoser> ok. seems i was wrong.
<smoser> rharper, ^
<smoser> but in your http://people.canonical.com/~rharper/curtin/topics/networking.html
<smoser> it says gateway is CIDR netmask notation
<smoser> whichi 'dbut it seems it needs a netmask.
<rharper> that's a copy/paste error, thanks
<rharper> the gateway itself doesn't take cidr, but it can be address with cidr, or address + netmask key
<rharper> and I've not updated the curtin docs on routes per interface yet since we haven't merged in that code yet;  I have a branch but decided to wait until we moved cloud-init networking to the refactor;  after this branch of ours, I can rebase curtin net on this stuff.
<smoser> rharper, https://code.launchpad.net/~smoser/cloud-init/trunk.net-improve-lo-dns/+merge/298035
<rharper> smoser: reading
<smoser> rharper, this is where we need an equality test for *something* . whether that be network config or network state or ENI.
<smoser> its hard to test that what was rendered is right.
<rharper> there are two steps
<rharper> 1) cmp(expected_output, input -> output )
<rharper> 2) validate expected_output achieves what it says (run eni in a guest)
<blackjid> Hi! i'm having some problems with execution order on a multipart config. Please here are the details... http://serverfault.com/questions/785344/how-to-execute-some-commands-before-the-user-scripts-in-cloud-init
<blackjid> thanks
<rharper> we don;'t have a "vmtest" in cloud-init yet;  the cloud-init-tests repo is the closest we have, which would look at the input (and render it to state or yaml) we inspect an instance after cloud-init runs and extract network config and compare that to the input
<smoser> blackjid, look in /var/lib/cloud/instance/scripts/
<smoser> you'll see one file named 'runcmd'
<smoser> and the other files that are in your multipart are named by their filename
<smoser> the scripts in that directory are run in C locale sorted order (as if by runparts)
<smoser> so if you change the name of the script you've added from
<smoser>  filename="00-rancher_server_install"
<smoser> to
<smoser>  filename="zz-rancher_server_install"
<smoser> then yo'ull be good.
<smoser> rharper, yes. thats surely one way. but if i have a parser of ENI, then i should be able to render an ENI and then parse it back into network config.
<smoser> and then compare that network config to the one i started with.
<blackjid> thanks smoser!, I'll try! that.. I thought they were run in sorted order, that's why I added the 00-  but I don't quiet understand why is the other way around...
<rharper> smoser: that's step 1, but without someone putting fixed input into the expected output; I worry that if we're generating both sides, something can get missed
<smoser> blackjid, http://paste.ubuntu.com/17647782/
<smoser> blackjid, if i had it to do again, i might make runcmd be in a file called '50-runcmd' to be more fitting. but its not easily changed at this point
<blackjid> thanks again smoser!, it worked perfectly!...
<smoser> and generally speaking the ability to compare two network configs for equality without booting a system is fairly desireable.
<rharper> smoser: sure; but declaring them equal without checking if they do anything isn't super valuable, we need both.  and I argue that we we'll want both the round-trip eni -> config -> eni ; as well as hand-crafted eni vs. generated eni as a check on parser bugs
<harlowja> rharper smoser what did i break, lol
<harlowja> that code needs more tests :-P
<smoser> harlowja, it does indeed
<smoser> and i dont think you actually broke anything though
<harlowja> ah, woot
<harlowja> i never break anything
<harlowja> obviously
<harlowja> lol
<smoser> harlowja, https://code.launchpad.net/~smoser/cloud-init/trunk.net-improve-lo-dns/+merge/298035 if you want to read that, htat'd be nice.
<harlowja> kk
<harlowja> got a internal review, then that one
<harlowja> then some openstack ones
<harlowja> guess today is review day
<harlowja> lol
#cloud-init 2016-06-23
<smoser> rharper, is there something in cloud-init that says is_ipv6_addr(address)
<rharper> cloud-init/net ?
<smoser> or something like that. given a list of addresses i want to filter out the ipv4 ones and the ipv6 ones.
<smoser> yeah.
<rharper> lemme look
<rharper> smoser: I don't see anything specific, but I think ':' in addr is sufficient
<smoser> k
<harlowja> rharper https://github.com/openstack/oslo.utils/blob/master/oslo_utils/netutils.py#L84
<harlowja> https://github.com/openstack/oslo.utils/blob/master/oslo_utils/netutils.py#L99
<harlowja> if u want another way
<harlowja> but that uses netaddr ...
<rharper> harlowja: I wonder what netaddr does?
<harlowja> thou shall look at the code?
<rharper> yeah, looking now
<rharper> harlowja: looks like a fancier versision of checking for '.'  ipv4 and ":" in ipv6
<harlowja> nice, ha
<harlowja> where's the code for that
<smoser> rharper, i just pushed to bzr+ssh://bazaar.launchpad.net/~smoser/cloud-init/trunk.smartos-fabric/ with what we'd worked on.
<Nivex> Hi folks. I'm trying to boot an Ubuntu 16.04 Cloud image on an IPv6-only VLAN. I have the datasource set to local so it doesn't need to talk to the network, but it still hangs on Raise network interfaces for 5 minutes.
#cloud-init 2017-06-19
<dgarstang> I'm trying to find a way to write an arbitrary blob of json to a file with cloud-init.
<powersj> dgarstang: there is the write_files module: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#write-files
<dgarstang> hm
<dgarstang> bootstrapping instances is haaaaard
<dgarstang> can I have multiple 'write-files' headers?
<powersj> dgarstang: I don't think so, but the header can have a list below it
<dgarstang> darn
<dgarstang> Terraform has gotta write it, and it's tricky
#cloud-init 2017-06-20
<dgarstang> Trying to write a file with write_files... data in file comes out as garbage... Help
<dgarstang> Trying to write a file with write_files... data in file comes out as garbage... Help
<dgarstang> Trying to write a file with write_files... data in file comes out as garbage... Help
<powersj> dgarstang: I'm out of the day, but if you could post your cloud-config or give me something to reproduce that would be best
<dgarstang> powersj: Seems like you MUST encode b64 or gzip
<prometheanfire> security updates dontchaknow
<dgarstang> Anyone awake?
<dpb1> Zzzzzz.
<dgarstang> I'm using write_files with content: content: {"chef_org":"foo_eu","chef_run_list":"role[\"eu-base\"],role[\"bastion-host\"]","chef_server":"chef.eu-infra.local","dns_domain":"eu-infra.local","service":"bastion"} ... However in the file all the double quotes have been replaced by single quotes. :(
<powersj> dgarstang: first, it seems you figured out how to include content versus a blob or encoded text, is that correct?
<powersj> here is an example I just ran with json as content: https://paste.ubuntu.com/24908960/
<powersj> make sure you have the '|' character before your content
<rharper> dgarstang: you probably want to use the content: |  to have direct content quoting, like so:  http://paste.ubuntu.com/24908978/
<rharper> dgarstang: you can also play with cloud-init in single mode to make sure it's writing what you want (without launching a new instance)
<dgarstang> rharper: yep, worked that out... thanks. had to use |
<rharper> dgarstang: great!
<dgarstang> btw... single mode?
<rharper> that just runs a single cc_module
<rharper> I find it useful for testing out user-data that applies for various modules
<dgarstang> oic
<dgarstang> Can I split runcmd over multiple lines?
<rharper> runcmd is a list of commands, in general, for a multi-line shell, you'll need to collapse that into a single line using shell statement separators (like semi-colon)  - "if grep -q foo /bar; then echo 'wark'; else echo 'no wark'; fi"
<dgarstang> rharper: yeah but what if one of those commands between ; and ; is longer than a line?
<powersj> rharper: 1687712 - I tried that one, but was unable to fully verify it
<rharper> powersj: ok, any details or did the sru test case just fail ? paste of outputs?
<rharper> bug 1687712
<ubot5`> bug 1687712 in cloud-init "cc_disk_setup: fs_setup with cmd doesn't work" [Medium,Confirmed] https://launchpad.net/bugs/1687712
<powersj> see my last comment in the bug
<rharper> powersj: do you have the instance still up ?
<rharper> can you see if the mkfs command ran at all ? I suppose
<powersj> rharper: I do not, trying to finish LP: 1692087 before end of the day
<ubot5`> Launchpad bug 1692087 in cloud-init (Ubuntu Zesty) "check_partition_layout has false positives when partitioned with gpt" [Medium,Fix committed] https://launchpad.net/bugs/1692087
<powersj> rharper: what's best way to determine that?
<rharper> heh
<rharper> oh, well, if mkfs ran you should see a subP command output in cloud-init.log
<powersj> for example, I even tried running the command by hand and got the disk to show up under /dev/disk/by-label
<powersj> ah
<rharper> also, you can do a dumpe2fs on /dev/sdc1 to see if has a fs on it (or even blkid on it)
<rharper> I worry that /dev/sdc1 wouldn't exist for the fs_ command to do anything
<powersj> ok I'll jot that down for tomorrow, I can try again for you
<rharper> I think sdb1 might already come partitions
<rharper> ok
<powersj> in azure, sdb is that tmp disk right?
<rharper> something like that
<rharper> ephemeral storage
<powersj> I wasn't going to use that and was trying to use an attached storage disk
<rharper> you could also test with /dev/sdc
<rharper> which wouldn't require partitioning
<rharper> you can put a fs on a raw device
#cloud-init 2017-06-21
<dpb1> ah interesting.  DO is doing an object storage product
<niluje> powersj: https://github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Syntax-Reference
<niluje> just found that
<niluje> the pipeline reference for the declarative syntax
<bob_cheesey> could anyone comment on a workaround for this? https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1686338
<bob_cheesey> we're using cloud-init on our VPS platform and we don't want cloud-init to configure networkign (we have our own tool for that which cloud-init provides the data to) so network_data.json contains "{}" - would this be sufficient to run into the above bug?
<ubot5`> Ubuntu bug 1686338 in cloud-init (Ubuntu) "cloud-init fails if no network config is set" [Undecided,New]
<dpb1> bob_cheesey: I'll respond on the bug
<bob_cheesey> dpb1: thanks!
<dpb1> bob_cheesey: a patch is certainly welcom
<dpb1> e
<bob_cheesey> dpb1: I can attempt that, however I'm not sure my Python skill are sufficient to achieve this. I'll await your response first!
<dpb1> bob_cheesey: my first comment was just a general how to submit the issue, now to look at the issue
<bob_cheesey> ok, understood. thanks again
<dpb1> bob_cheesey: what cloud is this, btw?
<bob_cheesey> dpb1: it's not, it's custom images which run on our own Xen platform
<rharper> bob_cheesey: if you want to disable networking in the image, you can write out /etc/cloud/cloud.cfg.d/05-disable-network.cfg with "network: {config: disabled}"  http://cloudinit.readthedocs.io/en/latest/topics/network-config.html
<rharper> that said, if it's custom, still interested in what files in the datasource you're using are indicating that network configuration is available (I suspect this is either ConfigDrive or NoCloud);  likely some files are being included but empty;  I'd like to confirm which ones; the DataSource should handle this so cloud-init can generate a fallback network config if it's not really present
<bob_cheesey> rharper: thanks, I wasn't aware of that (I'm picking up where someone left off after developing this so I'm learning as I go). Would I need to ensure that network_data.json is completely empty or will the solution you mentioned ensure that the network_data file is ignored?
<rharper> if you disable networking entirely, then nothing will attempt to consume the network_data.json file
<bob_cheesey> rharper: we're using ConfigDrive
<rharper> on the other hand, it seems odd to include the network_data.json file if it's empty
<bob_cheesey> rharper: agreed; I'm not sure why that decision was arrived at
<rharper> further though, we should check if it's returning an empty config and propagate that back
<rharper> if you could just mention in the bz that it's COnfigDrive, and show the contents of the network_data.json file included,; we can reproduce with that and get a fix;  I do think in your case you'll likely want to just disable networking (but we'll fix the bug as well)
<bob_cheesey> rharper: certainly, i'll do that now
<bob_cheesey> thanks!
<rharper> sure; thanks for the bug
<smoser> powersj, did we have some c-i failures for cloud-init ?
<powersj> smoser: there was a LXD xenial hash mismatch that recked havoc on testing last night.
<powersj> that was resolved, so things will clean up tonight
<powersj> There have not been any commits I believe, so I didn't expect any changes in test restults.
<smoser> right. ok. i saw chad say something above in my logs about a change to 'bash' invocation
<blackboxsw_away> yeah that was bbsw barking up the wrong tree :/
<blackboxsw_away> I just saw bash in the traceback and assumed incorrectly
<smoser> blackboxsw_away, go back to away. :)
<smoser> later.
<dpb1> hi blackboxsw_away
<dpb1> :)
<powersj> dpb1: rharper: I know both of you are buried.. but FYI take a look at last comment on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1686514
<ubot5`> Ubuntu bug 1686514 in cloud-init (Ubuntu Zesty) "Azure: cloud-init does not handle reformatting GPT partition ephemeral disks" [Medium,Fix committed]
<rharper> powersj: ok
<rharper> powersj: it appears that sdb1 is getting claimed by the system; possible due to /etc/fstab having an entry from the previous boot
<rharper> that prevents the mkfs command from running
<powersj> seems odd that the other two distros didn't see this
<rharper> newer systemd
<rharper> I suspect
<rharper> powersj: ^
<rharper> we found systemd fstab/mount unit to be 'racier'
<powersj> ah
<rharper> so , not your fault but possibly indicating that we need to try harder to get that out of the way (or root cause it)
<rharper> and it's beer thirty for sure
#cloud-init 2017-06-22
<rharper> powersj: can I run ci against a cloud-init in a PPA  easily ?
<powersj> Uhh no
<rharper> bummer
<powersj> Add a card ;)
<rharper> hehe
<powersj> I'm sure it wouldn't take much
<rharper> k
<powersj> Basically pull source for it and go
 * rharper is now upgrading from azure panel to cli now; since you can;t multi-nic in the portal 
<dpb1> rharper: so you can do two nics, but not sriov ones
<rharper> yeah, panel still shows nothing advanced, but I'm testing dual nics in any case
 * dpb1 nods
<Majost> I am seeing an unexpected behavior for the chef  cloud-config where it installs chef correctly, but doesn't appear to run the chef-client
<Majost> All the docs I have seen suggest that adding a runcmd to do this is not needed
<rharper> Majost: if you can, getting /var/log/cloud-init* and your user-data together; we can look at what's going on
<rharper> dpb1: unexpectedly, adding a second nic and starting the VM back up changes the public ip the instance had ;   going to wipe cloud-init data and see what a firstboot on a dual nic setup does (not sure how they handle the double dhclient route issue)
<dpb1> rharper: but you aren't bonding
<rharper> no, just testing normal things in azure with the new code
<dpb1> k
<dpb1> that's odd indeed
<dpb1> though admitedly, I'm not sure what I have tested in azure wrt two nics before this
<rharper> testing the "don't break existing networking"
#cloud-init 2017-06-23
<Majost> rharper: I sent you a gist of the logs
<Majost> I don't think anything sensitive is in there, but just in case. ;)
<Majost> I just added a sanitized version of the user data
<Majost> These lines look the most interesting: #file-cloud-init-log-L519-L522
#cloud-init 2018-06-18
<smoser> bugger.
<smoser> i filed https://github.com/PyCQA/pylint/issues/2193
<smoser> as i was unappy with pylint and its "logging-not-lazy" (see attached python example there)
<smoser> and it got fixed... which means i think some of cloud-init logging will start getting tagged as logging-not-layz
<rharper> so this guy (smoser) on the internet just broke cloud-inits ci runs
<rharper> =P
<blackboxsw> aaaaaaand would you look at the time
<blackboxsw> #startmeeting Cloud-init bi-weekly status meeting
<meetingology> Meeting started Mon Jun 18 16:08:07 2018 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<blackboxsw> Hi folks and welcome. We've got a big week this week as we are planning on a cloud-init release.  So we will have an additional topic in today's agenda
<smoser> o/
<blackboxsw> it's been a few weeks, due to holiday schedules/travel,  our agenda will be as following: Previous Actions, Recent Changes, In-progress develepment, cloud-init release 18.3 and office hours
<blackboxsw> #topic Previous Actions
<blackboxsw> last action items are listed in our meeting minutes at the following url:
<blackboxsw> #link https://cloud-init.github.io/status-2018-05-29.html#status-2018-05-29
<blackboxsw> #ACTION blackboxsw review distro dection and empty modules list    [ DONE ]  both robjo's branches are landed as of friday of last week.
<meetingology> ACTION: blackboxsw review distro dection and empty modules list    [ DONE ]  both robjo's branches are landed as of friday of last week.
<blackboxsw> that was a carryover from the meeting before I believe.
<blackboxsw> #ACTION blackboxsw carryover network hotplug vs network maintenance on reboot-only
<meetingology> ACTION: blackboxsw carryover network hotplug vs network maintenance on reboot-only
<blackboxsw> I think this was the only other unresolved action. Our team has had mutliple followup discussions internally and with mgerts from Joyent/SmartOs as well
<blackboxsw> smoser: and rharper drew up a hackmd doc related to this work here:
<blackboxsw> #link https://hackmd.io/NUUO4nndS4CXTItl8Rs6Nw
<blackboxsw> We've come to a conclusion on a common near-term approach that will support cold-plug scenarios by allowing datasources to claim whether or not they will re-render networking on a boot event. This would allow cloud-init to react to network metadata changes across boot and enable/disable those devices accordingly
<blackboxsw> a WIP branch is available here
<blackboxsw> #link expectation is to get the foundation landed this week
<blackboxsw> and tracked in trello here
<blackboxsw> #link https://trello.com/c/Yp6VG2lP/837-eventpolicy-foundation-for-joyent-and-azure-coldplug
<robjo> Note that the metdata ins EC2 is "stale", AFIK, or at least some parts of the data are stale, i.e. they only get refreshed on instance restart
<rharper> is it instance restart or "re DHCP" ?
<rharper> ie, bounce the interface ?
<blackboxsw> #link https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+ref/feature/maintain-network-on-boot
<smoser> robjo: that is correct.
<robjo> so a re-read of the metadata on EC2 delivers no/maybe limited new information
<smoser> robjo: well, network information is updated.
<smoser> user-data is only updatable on stop -> start in ec2
<robjo> rharper: AFAIK new metadat gets pick up on instance restart
<rharper> ok
<robjo> I know the IID also only gets updated on stop-start
<blackboxsw> certainly in Azure that's the case. you have to stop the instance before changing attached network interfaces and then bring instance online again
<robjo> Yes, in Azure adding network interfaces is not dynamic
<robjo> meaning cannot happen while an instance is running
<blackboxsw> adding IPs in azure is an online thing, but even azure's network metadata is limited in that it doesn't tell you whether a network interface is static or dynamic. examples here:
<blackboxsw> https://hackmd.io/aODzXfa_TOikNtYBLt8erA
<blackboxsw> #link https://hackmd.io/aODzXfa_TOikNtYBLt8erA
<robjo> Also for Azure there exists the "problem" of accelerated networking, i.e. SR-IOV
<robjo> when accelerated networking is on the SR-IOV interface gets the same MAC address as the "Synthetic nic"
<rharper> well, they "solved" it by having the kernel auto bond =/
<robjo> the SR-IOV interface gets bound to the synthetic nic in the kernel, that was a patch that went into the kernel 6-9 months ago
<rharper> AFAICT, the sriov device just magically comes and goes as it will
<rharper> so, one shouldn't worry about the silent bonding ...  (I'm being a bit sarcastic here)
<robjo> yes, but the interface still shows up, so if output from "ip" command is read one has two devices with the same MAC address, only one of which should be configured
<rharper> we ignore any of the mlx4 driver devices
<rharper> yes they show up
<robjo> OK
<rharper> but the directive we got was to ignore them; and DHCP on the netvsc ones
<blackboxsw> ...so think that's all I had on action items from previous meeting.
<blackboxsw> shall we go to next topic?
<robjo> And that of course works until Msft gets a better HW deal from Intel or someone else for their network cards ;)
<blackboxsw> heh
<rharper> robjo: indeed
<blackboxsw> #topic Recent Changes
<blackboxsw> due to a couple vacations and some work travel it's been a slightly slower couple weeks below are the cloud-init changes that have gone in:
<blackboxsw>     - lxd: Delete default network and detach device if lxd-init created them.
<blackboxsw>       (LP: #1776958)
<blackboxsw>     - openstack: avoid unneeded metadata probe on non-openstack platforms
<blackboxsw>       [Chad Smith] (LP: #1776701)
<blackboxsw>     - stages: fix tracebacks if a module stage is undefined or empty
<blackboxsw>       [Robert Schweikert] (LP: #1770462)
<blackboxsw>     - Be more safe on string/bytes when writing multipart user-data to disk.
<ubot5> Launchpad bug 1776958 in cloud-init "error creating lxdbr0." [Medium,Fix committed] https://launchpad.net/bugs/1776958
<blackboxsw>       (LP: #1768600)
<blackboxsw>     - Fix get_proc_env for pids that have non-utf8 content in environment.
<ubot5> Launchpad bug 1776701 in cloud-init "ec2: xenial unnecessary openstack datasource probes during discovery" [High,Fix committed] https://launchpad.net/bugs/1776701
<blackboxsw>       (LP: #1775371)
<blackboxsw>     - tests: fix salt_minion integration test on bionic and later [Chad Smith]
<blackboxsw>     - tests: provide human-readable integration test summary when --verbose
<blackboxsw>       [Chad Smith]
<ubot5> Launchpad bug 1770462 in cloud-init "Allow empty stages" [Low,Fix committed] https://launchpad.net/bugs/1770462
<blackboxsw>     - tests: skip chrony integration tests on lxd running artful or older
<blackboxsw>       [Chad Smith]
<ubot5> Launchpad bug 1768600 in cloud-init "UTF-8 support in User Data (text/x-shellscript) is broken" [Medium,Fix committed] https://launchpad.net/bugs/1768600
<blackboxsw>     - test: add optional --preserve-instance arg to integraiton tests
<blackboxsw>       [Chad Smith]
<ubot5> Launchpad bug 1775371 in cloud-init "cloud-init (18.2) fails on decoding proc1 env" [Medium,Fix committed] https://launchpad.net/bugs/1775371
<blackboxsw>     - netplan: fix mtu if provided by network config for all rendered types
<blackboxsw>       [Chad Smith] (LP: #1774666)
<ubot5> Launchpad bug 1774666 in netplan.io (Ubuntu Cosmic) "Bond interfaces stuck at 1500 MTU on Bionic" [Undecided,Confirmed] https://launchpad.net/bugs/1774666
<blackboxsw>     - tests: remove pip install workarounds for pylxd, take upstream fix.
<blackboxsw>     - subp: support combine_capture argument.
<blackboxsw>     - tests: ordered tox dependencies for pylxd install [Chad Smith]
<blackboxsw>     - util: add get_linux_distro function to replace platform.dist
<blackboxsw>       [Robert Schweikert] (LP: #1745235)
<blackboxsw>     - pyflakes: fix unused variable references identified by pyflakes 2.0.0.
<ubot5> Launchpad bug 1745235 in cloud-init "distribution detection" [Medium,Fix committed] https://launchpad.net/bugs/1745235
<blackboxsw> thanks again Robert for the contributions here getting cloud-init in order :)
<blackboxsw> we've also just pushed a release of cloud-init tip into Ubuntu Cosmic.
<blackboxsw> so all latest changes are in the development series
<blackboxsw> I think that about wraps it
<blackboxsw> #topc In-progress Development
<blackboxsw> As always, we track ongoing work publicly at
<blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
<blackboxsw> we've got some cold-plug network rendering handling that will be queued for this week, mgerts is working on enabling cold-plug network rendering support on boot for SmartOS, and there is a followup for Azure to do the same
<blackboxsw> cloud-init squad is going to be setting up an SRU into Xenial, Artful and Bionic this week as well
<blackboxsw> to sync latest qualified cloud-init into those Ubuntu series
<smoser> blackboxsw: thinking out loud..
<smoser> if we're going to release 18.3 on thursday
<smoser> might as well just hold off on sru until then
<blackboxsw> (wait on 18.3 release?)
<blackboxsw> yeha
<blackboxsw> yeah even
<blackboxsw> which brings us to our next topic
<blackboxsw> #topic Cloud-init 18.3 release
<blackboxsw> I hadn't seen any responsed to your email scott to cloud-init@lists.launchpad.net.  Does anyone have any feature pressing that we'd like to get into this release
<blackboxsw> estimated release would be Thusday of this week
<blackboxsw> I'd whimsically like to include the azure cold-plug stuff, but that means getting those two branches in shape today for a thorough review/test cycle
<blackboxsw> s/whimsically/opportunitically/
<blackboxsw> heh I give up
<blackboxsw> did we want to pull this in? https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/334989
<blackboxsw> If there are any pressing bugs or features that need to be in 18.3 we'd like to see them up for review by Wednesday of this week so that we can cut our upstream release. Feel free to send an email to the list    cloud-init@lists.launchpad.net   or this channel if your branch needs to get some eyes.
<blackboxsw> we'll SRU 18.3 then into Xenial, Artful and Bionic after a complete round of testing.
<blackboxsw> #topic Office Hours (next ~30 mins)
<robjo> :D After 18.3 but before the workshop: https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904
<blackboxsw> Folks are around for further discussion on any cloud-init topics of interest
<robjo> then maybe at the workshop we can come up with a way to move SLES & openSUSE to sysconfig renderer
<blackboxsw> good topic idea
<blackboxsw> #ACTION rhaper/blackboxsw review https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904
<meetingology> ACTION: rhaper/blackboxsw review https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904
<blackboxsw> thanks again folks. catch you next time.
<blackboxsw> minutes will be published to the link below
<blackboxsw> #link https://cloud-init.github.io/
<blackboxsw> #endmeeting
<meetingology> Meeting ended Mon Jun 18 17:23:34 2018 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2018/cloud-init.2018-06-18-16.08.moin.txt
<smoser> E: Type 'curity' is not known on line 50 in source list /etc/apt/sources.list
<smoser> https://jenkins.ubuntu.com/server/job/cloud-init-integration-nocloud-kvm-b/218/console ?
<smoser> powersj: can you at some point push a delete all and README.md for things like https://github.com/canonical-server/test-scripts
<smoser> that say where the real one is ?
<blackboxsw> Umm something did a split on 'security'?
<smoser> its race condition
<smoser> in a test-scripts script
<powersj> smoser: done
<powersj> and yes seems key server issues hit at least one other test
<smoser> powersj: you'll need to update https://jenkins.ubuntu.com/server/job/cloud-init-integration-nocloud-kvm-b/218/
<smoser> it pulled from the canonical-server path
<powersj> well that is odd...
<smoser> powersj: do i have to care about precise ?
<powersj> for?
<powersj> I didn't think we were doing any precise testing
<smoser> no. i dont.
<smoser> ok
<powersj> all cloud-init jobs redeployed
<smoser> https://github.com/CanonicalLtd/server-test-scripts/pull/2
<powersj> thx will look in a sec
<smoser> hm..
#cloud-init 2018-06-19
<logan-> i'm having a hard time getting this config drive to render a bond
<logan-> here's the network_data.json: http://paste.openstack.org/raw/723775/
<logan-> and here's cloud-init.log: http://paste.openstack.org/raw/723776/
<logan-> it looks like cloud-init is failing to find a iface['bond-master']
<logan-> looks like it was fixed by https://github.com/cloud-init/cloud-init/commit/51febf7363692d7947fe17a4fbfcb85058168ccb ...now to find out how to get a more updated cloud-init into my centos images I guess
<smoser> caribou: did you get what you needed from me ?
<caribou> smoser: I just replied to your comment
<caribou> smoser: indeed, we _do_ need the possibility of changing the IP upon reboot
<caribou> smoser: now I'm not against changing the way to do it though
<smoser> ok. https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348000
<smoser> that is some of the code that blackboxsw  is doing to suggest how we would handle this.
<smoser> for "check_instance_id" we *could* just return 'True'
<smoser> but that stinks... and requires then a user to "clean" before snapshotting the image
<smoser> and starting a new one from it.
<caribou> smoser: looks like it would fit our needs quite well
<caribou> but I still need the functionality to generate the network config according to what comes from the metadata
<smoser> right.
<smoser> your changes generally seem correct.
<smoser> or at least moving in the right direction.
<caribou> smoser: so if I understand correctly, with the check_instance_id, we would only need the network_config() method w/o having to handle bringing up the network first ?
<smoser> caribou: well, what would happen if you had check_instance_id.
<smoser> you wouldnt bring up network ephemerally on every boot
<smoser> but you also wouldnt re-write it
<caribou> until your new feature comes around
<caribou> might be preferable to keep it as such until the new feature comes around
<caribou> which brings the question : is that feature expected to be present in the next upstream snapshot ? 'cause this is also when the 'fixed' DataSourceScaleway will hit the archive
<caribou> so if both become public together, it would be preferable to have the DS use the new feature and not an obsolete behavio
<caribou> behavior
<caribou> since we'll be using a PPA up until it gets SRUed, I can go either way
<smoser> caribou: we wont have the feature in the next few days.
<caribou> smoser: oh, I understand
<smoser> so i'm thinking that it might be an improvement to take your MP as it is, without the check_instance_id, which would effectively get you rendering network configuration every boot.
<smoser> thats not a great scenario, but the check would not get you the feature you're after .
<caribou> I think so too. My question was about the fact that, if the new feature is SRUed in the same snapshot as the update to the DS, might as well only do one change of the DS but you know the schedule better than me :)
<smoser> i think i'd not bother trying to manage that.
<smoser> we woudl want to avoid the check_instance_id addition until we had a solution to your "configure on boot"
<smoser> but we can just do that in trunk check_instance_id wont go in until it would do what you want.
<caribou> fine then
<blackboxsw> smoser: or rharper have a moment to chat about https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348000? I think the discussion may be faster than review comment interaction
<rharper> y
<blackboxsw> thanks
<blackboxsw> joining meet :)
<rharper> brt
<smoser> blackboxsw:
<cornfeedhobo> does cloud init run bash scripts on every startup?
<blackboxsw> rharper: or powersj doc trivial  for new sudo:false cloud-config option  that just landed https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348252
<blackboxsw> cornfeedhobo by default it does not re-run base shell script user-data.
<blackboxsw> if I provide the following userdata: it'll only get run once
<blackboxsw> #!/bin/bash
<blackboxsw> DATE=`date`
<blackboxsw> echo "I ran" $DATE
<cornfeedhobo> blackboxsw: thanks. that confirms the vague sense i got from the docs!
<blackboxsw> because of semaphores blocking re-entry in /var/lib/cloud/sem/
<blackboxsw> cornfeedhobo: if you want something run per boot it would need to live in /var/lib/cloud/scripts/per-boot/
<blackboxsw> per docs @ http://cloudinit.readthedocs.io/en/latest/topics/modules.html#scripts-per-boot
<blackboxsw> no prob
<cornfeedhobo> blackboxsw: they are at /var/lib/cloud/instance/scripts
<cornfeedhobo> no symlinks to any of the scripts/per-* directories
<blackboxsw> cornfeedhobo: sorry I didn't parse those coomments. On my bionic lxc container:
<blackboxsw> cat /var/lib/cloud/scripts/per-boot/runme.sh
<blackboxsw> #!/bin/bash
<blackboxsw> DATE=`date`
<blackboxsw> echo 'I RAN TOO! ' $DATE; grep RAN /var/log/cloud-init-output.log
<blackboxsw>  /var/log/cloud-init-output.log:I RAN TOO!  Tue Jun 19 22:22:35 UTC 2018
<blackboxsw>  /var/log/cloud-init-output.log:I RAN TOO!  Tue Jun 19 22:23:43 UTC 2018
<blackboxsw> thx for the review powersj
<powersj> that was an easy one ;)
#cloud-init 2018-06-20
<blackboxsw> smoser: rharper release 18.3 branch
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348254
<blackboxsw> then I can push an MP for cosmic
<blackboxsw> will check back in a couple hours
<smoser> blackboxsw: ah. ok. i had thought throw snapshot into cosmic
<smoser> and then tomorrow do a release.
<smoser> blackboxsw: i think if the goal is just to upload to cosmic with a 18.3, then lets wait til morning before we tag.
<smoser> that will get us a nightly c-i run on trunk also.
<smoser> blackboxsw: i went ahead and kicked off a 'Build Now' for each recipe
<smoser>  https://code.launchpad.net/~cloud-init-dev/+recipes
<smoser> so we'll have daily archive up to date shortly with master (a670eb81)
<smoser> with fingers crossed that there are no keyserver demons lurking
<smoser> alright. landing https://code.launchpad.net/~cloud-init-dev/+archive/ubuntu/daily/+packages
<smoser> and i'm going to take off on that note.
<blackboxsw> sounds good scott
<smoser> ok... as a form of version control http://paste.ubuntu.com/p/tcj3QhSmGD/
<smoser> that is skip_by_date as a decorator, i plan to try to put it into curtin soon.
<smoser> rharper: https://code.launchpad.net/~smoser/curtin/+git/curtin/+merge/348282
<smoser> oops.
<rharper> hehe
<blackboxsw> smoser: so SRU and https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348254
<blackboxsw> shall I push an 18.3 tag to upstream to get CI to work there and get that landed?
<blackboxsw> and we cut a cosmic, xenial artful bionic set of merges?
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348254
<blackboxsw> hrm ok smoser rharper , I've bungled/missed something with pushing my tags and trying to push 18.3 to origin(upstream).
<smoser> ok
<blackboxsw> I think I've pushed 18.3 tag to our common repo for cloud-init
<blackboxsw> git tags --list shows it when I have master checked out. yet git log --decorate doesn't decorate the proper commit with the tag name
<smoser> i think a rebase happened or something....
<blackboxsw> I do see the tag decorating my specific branch release/18.3
<smoser> probably in your merge review thing
<smoser> upstream/master is differant than the tag
<smoser> i can fix or you can, but essentially
<smoser> git checkout master
<smoser> git reset --hard 18.3
<smoser> git push upstream master --force
<smoser> or probalby that is just
<smoser> git push upstream 18.3:master --force
<smoser> or something
<blackboxsw> ok worked. I'll sort what review-mps did/does as it merges the branch locally (giving us a different commitish I think).
<smoser> right
<smoser> what it could do is
<smoser> git merge --ff-only
<blackboxsw> right, I think.
<smoser> if there was 1 new commit and that worked, it could do that.
<smoser> other wise, it woudl rebase and squash like it does.
<blackboxsw> yeah multicommits we'd have a problem as we are squashing
<blackboxsw> yeah
<blackboxsw> ok will add that to review-mps today. single commit --ff-only option
<smoser> i think i'd just have it do it if it could
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348300 is up
<smoser> ok. before we do that lets get the release into launchpad
<smoser> blackboxsw: can you take a quick glance at changelog for highlights ?
<smoser> ah. i knwo. hackmd link coming.
<smoser> https://hackmd.io/lIMTEWtaSpGgrleLM0pJBQ
<smoser> blackboxsw: ^
<blackboxsw> checking
<smoser> blackboxsw: just sent.
<smoser> you were too slow :)
<smoser> no big deal.
<blackboxsw> heh, nice. my coffee machine was too slow you mean
<blackboxsw> is it worth me scripting all bugs mentioned in changelog to the given milestone?
<smoser> ?
<blackboxsw> per the "35 launchpad.net issues" fixed
<smoser> oh. i did that sort of
<smoser> and updated that doc
<blackboxsw> we could target them to https://launchpad.net/cloud-init/+milestone/18.3
<blackboxsw> so they'd show there
<blackboxsw> too
<smoser> we could do that. and i guess do that in lp-bugs-released.... i dont know.
<blackboxsw> as a point of reference in the future for stuff that was fixed
<blackboxsw> yeah I was thinking lp-bugs-released extension
<smoser> i'm going to run the lp-bugs-released script now.
<smoser> is that ok ?
<blackboxsw> +1
<smoser> k
<blackboxsw> I have a tweak for specific bug series task. I think which might help as the SRU progresses
<blackboxsw> a tweak to only target the specific bug distro-series task rather.
<smoser> ?
<smoser> the lp-bugs-released only does upstream
<smoser> right?
<blackboxsw> right, but it could do individual series tasks too per something like https://launchpad.net/cloud-init/+milestone/18.3
<blackboxsw> WIP patch obviously. I was just peeking at it.
<blackboxsw> oops bad paste
<blackboxsw> http://paste.ubuntu.com/p/k6tTxnzTrN/
<smoser> i just fixed the "version "
 * blackboxsw gets merge proposals for xenial,artful, bionic together now (and filing an SRU bug)
<blackboxsw> smoser: you haven't filed an SRU bug yet have you?
<smoser> no.
<blackboxsw> ok filing
<smoser> bug mail coming in 5....
<smoser> 4, 3, 2, 1
<smoser> blackboxsw: ok. on that note, i have to run. i'll be back in later and can do uploads for sru then.
<blackboxsw> ok thanks man
<smoser> i think release is all done now.
<blackboxsw> dragging the trello card
<blackboxsw> smoser: I pushed minor changes into new-upstream-snapshot
<blackboxsw> to account for debian/changelog containing xenial-proposed instead of xenial
<blackboxsw> 3 branchs for SRU upload review tied to this card smoser https://trello.com/c/8jshO6oa/847-sru-183-to-xenial-artful-and-bionic
<blackboxsw> *branches*
 * blackboxsw needs to tweak artful and xenial branches there. we need to disable OpenstackLocal.network_config by default
<blackboxsw> as it is configurable to "apply_network_config: true" in datasource config
<blackboxsw> and we don't want to change artful/xenial behavior... maybe bionic too? WDYT rharper smoser
<rharper> right, I think we played some games with the names in the datasource class when we did this with AzureDatasource
<blackboxsw> rharper: the way I wrote DataSourceOpenstack.network_config property we now check if ds_cfg.get('apply_network_config') == False: return None. This renders fallback config (which is what xenial->bionic do today)
<blackboxsw> question I have is, should bionic continue to only render fallback config :/?
<rharper> yes
<blackboxsw> ok will apply a patch for those releases
<blackboxsw> to adjust the default behavior to fallback for all 3 series
<rharper> let me think on it a bit too;  IIUC, we could run "faster" but only render fallback config
<rharper> which wouldn't change functionality, just the speed, right ?
<rharper> where as in cosmic, we could read network_data.json over metadata service at local and render that instead of fallback
<blackboxsw> correct on all counts. we could either patch to remove DataSourceOpenstack.network_config subclassed property altogether (to run faster and retain exact current behavior).   OR -
<blackboxsw> we could patch Openstack.network_config to default to apply_network_config == False  if not provided, thereby allowing someone to override that and react to network_data.json if they want (a little slower as we check a config option value before rendering fallback config)
<blackboxsw> I think we want the 2nd choice on Xenial-Bionic as it is a useful feature to turn on if someone wants it
<blackboxsw> though I think they'd have to turn it on in their images, not user-data
<rharper> yes; I'm included to keep fallback rendering for OS metadata service in Xenial -> Bionic, but run at local if we can
<blackboxsw> ok good deal
<rharper> that produces a speedup ( \o/ ) without a change in function
<rharper> let's see if smoser agrees
<blackboxsw> yeah exactly, local timeframe == speedup
<robjo> blackboxsw: I was going to take a look at lp#1733226 and thought this may not lead too far down the rabbit hole, but turns out that dhclient stuff appears to be splattered across data sources and other parts of the code
<robjo> so I need some guidance and maybe this is too big of a project to start on late Wednesday afternoon and better wait for THursday morning
<blackboxsw> bug #1733226, yeah that's a not easy to start late Wedneday robjo : /
<ubot5> bug 1733226 in cloud-init "cloud-init-local service fails on SUSE distros" [Undecided,New] https://launchpad.net/bugs/1733226
<blackboxsw> yeah the context hander and sandboxed environment with dhclient vs wicked is potentially a bit of a dig
<robjo> OK, I'll ping you another day
<blackboxsw> hrm, so was this Openstack  robjo ?
<blackboxsw> could you cloud-init collect-logs and add the tarfile?
<robjo> I do not know, I can ask in the bug report I do not know the reporter
<blackboxsw> or Ec2/Azure maybe? those are the 3 major datasources that use it currently
<robjo> Lets see if we get an answer
<blackboxsw> it may be as simple as just replaceing dhclient with wicked, but there is lease processing etc.. and I haven't looked at how wicked stores dhcp-related conf etc. (I'm guessing that's in my immediate future)
<blackboxsw> sounds good robjo, yeah we need to fix this for SLES it seems as this EphemeralDHCPv4 context manager is the direction most datasources are oging
<blackboxsw> *are going
<robjo> Well, I'll do leg work, but the idea of having to change 3 data sources and then doing so for others potentially in the future is not very appealing, seems there should be an abstraction ;)
<blackboxsw> robjo: yeah it's all in cloudinit.net.dhcp maybe_perform_dhcp_discovery
<blackboxsw> might want to extend it to accept network_util='dhclient' default
<blackboxsw> which could be overridden with wicked I suppose
<robjo> Found that file, but also saw in the azure datasource I think (via grep) what looked like hard coded info about lease info
<blackboxsw> ohh yeah, yuck right. hardcoded dhcp lease path
<robjo> given the we're "special" :rolling_eyes: maybe this should not be distro independent, but I suspect major surgery is required to make this distro dependent
<blackboxsw> though that datasource already does a switch on util.is_FreeBSD to tweak expected lease_file path on different distros
<blackboxsw> hrm maybe distro could announce default network_cmd, we also have to solve this for a netplan-only world too, as dhclient is not really a mandatory command in newer ubuntu series.
<blackboxsw> so this is a type fix that is on our radar, just hadn't tried tackling it yet because we didn't need to... yet.
<robjo> network_cmd would probably be a dict then if we want to support the lease monitoring part we'd need at least dhcp_client_cmd,dhcp_client_options, lease_info
<robjo> and interface
<blackboxsw> could be, I'm kindof leaning toward the idea that maybe_perform_dhcp_discovery should be smart enough to detect valid dhclient commands and make a sane choice based on present of the utility so that we don't continue to bloat the Distro classes. but it'll require a bit more thought for the use-cases
<blackboxsw> *based on presence/absence of the utility*
<blackboxsw> I liked what you did w/ ifconfig vs ip stuff
<blackboxsw> it feels like it contains that logic in a single place local to where it is being used (even though it's kindof distro related)
<blackboxsw> but again, I'm not certain this EphemeralDHCPv4 solution is strictly compatible with a systemd networkd -only world.
<blackboxsw> one idea we were tossing around was to write our own tiny python dhclient which opens a socket to do the dhcp discovery
<blackboxsw> all we are attempting to do is sniff a lease on the primary nic if available.
<blackboxsw> this may be time for us to queue that work :
<blackboxsw> this may be time for us to queue that work :/
 * blackboxsw and socket programming from python. not a well used muscle. 
<robjo> The advantage of ifconfig/ip transition is that ip options are universal, but for the dhcp stuff distros, staring with SLES have clearly diverged and it appears there may be further drift, so having "smart" handling in one place may lead to lots of if-elif-elif code
<robjo> well getting a dhcp request out in and off itself is not all that difficult, what I don't know what effect that has on subsequent requests
<robjo> For example when AWS added ipv6 and wicked sent out options the dhcp server didn't understand they just didn't respond
<robjo> so no lease :(
<robjo> presumably a cloud-init implementation of get_dhcp_lease() would not send any option or only a minimal set
<robjo> but then what does the dhcp server do when the next request comes from the same origin, does it just return what it already handed out and ignore other options that might be sent along?
<robjo> I have no idea how that works
<robjo> And maybe this topic is too big for IRC and e-mail and we should beat on it during the summit
<blackboxsw> correct, cloud-init's get_dhcp_lease()  would be a dumb/simple dhcp-discovery packet without any custom options. It'd blindly return a dict of whatever lease options the response gave.   Generally the dhcp server ends up giving out the same IPs on previous discovery if the lease time hadn't expired I believe. (as it's how it's currently working in ec2/openstack.
<blackboxsw> agreed, it's a big topic. I think you are right.
<blackboxsw> I'll add it to the list of potential topics
<blackboxsw> currently I have the following:
<blackboxsw> topic ideas:
<blackboxsw>  - move SLES & openSUSE to sysconfig renderer
<blackboxsw>  - hotplug network stuff (one-shot stuff)
<blackboxsw>  - cloud-init as a daemon for repeatable calls, expedited boot runs
<blackboxsw>  - wicked support for EphemeralDCHPv4
<blackboxsw> as we get closer that list will probably grow into a hackmd doc we can all comment on that we will send to the mailinglist
<robjo> David already had a preliminary agenda, I take it you'll coordinate with that ;)
<blackboxsw> yeah if I have to ;)
<rharper> blackboxsw: another alternative that we've discussed multiple times but never dig to the bottom is replacing dhclient with cloud-init dhcp client in python itself; then Ephemeral would not have to depend on dhclient which may or maynot be present, etc
<rharper> so, in the agenda, maybe replace wicked string with 'EphermalDHCP alternatives to isc-dhcp client'
<rharper> we've the same issue in Artful/Bionic/Cosmic though we pull the dhclient in now; really that shouldn't be in there as networkd procides a dhcp client as well
<robjo> I added a short summary to bug #1733226
<ubot5> bug 1733226 in cloud-init "cloud-init-local service fails on SUSE distros" [Undecided,New] https://launchpad.net/bugs/1733226
<robjo> having a cloud-init get_dhcp_lease() is included as option 4
<smoser> blackboxsw: thanks for remembering about the datasource local in bionic.
<smoser> i think we should bite the bullet there.
<blackboxsw> yeah a quick grep of RELEASE_BLOCKER
<blackboxsw> we need to retire/remove the snap modules too :/
<blackboxsw> the old snappy etc.
<blackboxsw> but not critical
<smoser> yeah, that snot a big deal.
<smoser> hm...
 * blackboxsw is wondering how best to cherry pick the ubuntu/xenial/debian/patch/openstack* into ubuntu/artful which has no patches dir...
<blackboxsw> was trying ./debian/cherry-pick, but it falls over because there is no existing debian/patches/series file
<blackboxsw> wondering if I manually do the work in artful and then cherry pick to bionic (which also has no patches subdir/series
<smoser> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348309
<smoser> that has fail build right now
<smoser> shoot.
<blackboxsw> bah have to fix unit tests too :/
<smoser> lets think.
<smoser> one thing we generally want to do is update the ubuntu/ branches right after we land something like this
<smoser> so that our daily builds would have been doing this sense it weent in.
 * smoser shoudl have remembered that and done something then
<blackboxsw> the following would work for ubuntu/xenial I think http://paste.ubuntu.com/p/mNNQgwTPcT/
<blackboxsw> it tweaks the unit test which will fail (after debian/patch applied) to present the right ds_config setting True
<smoser> blackboxsw: i'll give this a good think tomorrow. would like to get an sru upload in, but want to think it though.
<blackboxsw> yeah I was thinking there's probably not enough time to talk through the options.
<blackboxsw> I'll fix xenial so we have a strawman on the approach, to shoot down if need be
<blackboxsw> artful/bionic are bogus, so I'll pull them,
<blackboxsw> ok pushed xenial again, will let CI run it's course
<blackboxsw> gotta take a break
<blackboxsw> ok xenial mp is at least in good enough shape for discussion about the approach for patching desired openstack behavior https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348309
<blackboxsw> rharper: do we need to change behavior of ntp/chrony on xenial->bionic with this upcoming SRU?
<blackboxsw> per bug #1749722
<ubot5> bug 1749722 in systemd (Ubuntu) "NTP: take into account systemd-timesyncd where present" [Undecided,New] https://launchpad.net/bugs/1749722
<blackboxsw> I think not, but wanted to be sure
#cloud-init 2018-06-21
<blackboxsw> http://paste.ubuntu.com/p/p5vqBxN4Rq/
<blackboxsw> on xenial translates to ENI http://paste.ubuntu.com/p/6YCv5VVv4t/
<blackboxsw> ok rharper working out --format json for package-uploads script
<blackboxsw> thanks for the thoughts there
<rharper> cool
<rharper> yeah
<blackboxsw> package-sponsor rather :/
<smoser> blackboxsw: rharper i'm back... s
<blackboxsw> ok I'm about to push prackage-uploads script changes to use json backed file.. speedup == 1 second versus 1.5 minuts
<blackboxsw> ok I'm about to push prackage-uploads script changes to use json backed file.. speedup == 1 second versus 1.5 minutes
<blackboxsw> *package-sponsor*
<blackboxsw> ok smoser I can camp in hangout
<blackboxsw> if needed
<smoser> k
<rharper> blackboxsw: \o/
<blackboxsw> smoser,  artful  and bionic now pushed. I'm trying to proposals to the trello card
<smoser> blackboxsw: ok.
<smoser>  https://github.com/CanonicalLtd/uss-tableflip/blob/master/doc/ubuntu_release_process.md
<smoser> that now odocuments --update-patches-only
<blackboxsw> +1 thank you
<smoser> blackboxsw: https://meet.google.com/bxm-azib-mtj
<smoser> i'm there
<smoser> if you have a minute
<blackboxsw> enroute
<blackboxsw> smoser: just re-pushed ubuntu/xenial per our discussion
<blackboxsw> let's see how that looks, if good I'll do artful/bionic now
<blackboxsw> new-upstream-snapshot worked for me and consolidated the two changelog entries
<blackboxsw> though my patch to new-upstream-snapshot incorrectly double-appended '-proposed' on the sed line
<smoser> blackboxsw: pribably i miscommunicated
<smoser> or you didn't p ush something
<smoser> what i think we're after is just taking f2140da2bca53cd0509e73b299e9871fba7bab3d
<blackboxsw> ohh dumb, right I did the whole thing.
<blackboxsw> sorry backing that out
<blackboxsw> I pushed too much, wasn't intending that much
<smoser> yeah. ok
<blackboxsw> yeah I was queueing the next part but forgot to leave that local
<smoser> and good to see that it will work :)
<blackboxsw> smoser: pushed xenial just the patch
<blackboxsw> will push the rest once we are sure ppa has built
<blackboxsw> will queue artful and bionic now in the same manner
<smoser> you have trailing white space on your entry in debian/changelog
<blackboxsw> ahh will fix
<smoser> other than that, yeah, that is wahte we're after.
<blackboxsw> smoser: did I fix it?
<blackboxsw> just pushed
<smoser> yeah.
<smoser> you want me to push that to upstream/ubuntu/xenial
<smoser> or you can
<smoser> and then we push 'go' on recipe builds
<blackboxsw> ok pushing artful bionix
<blackboxsw> I'll let you kick recipe builds
<blackboxsw> thanks
<smoser> did you push upstream ?
 * smoser sees not.
<smoser> i'll do that
<blackboxsw> didn't push upstream thx
<blackboxsw> artful pushed
<smoser> "in 5 minutes" https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-xenial
<blackboxsw> hold up on artful. need to fix version
<blackboxsw> bionic and artful pushed to my branch
<blackboxsw> bionic and artful pushed to my remote
<blackboxsw> smoser: diffs look good, on artful/bionic to me
<smoser> artful pushed
<smoser> bionic pushed
<blackboxsw> thanks, ok looks like xenial built
<smoser> https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-artful
<blackboxsw> so I can new-upstream-snapshot now right?
<smoser> and https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-bionic
<smoser> are going
<smoser> you can propose the merge for new-upstream-snapshot, yeah.
<blackboxsw> all artful,bionic xenial branches reposted
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348362
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348360
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348361
<blackboxsw> hrm so my debian/patch doesn't apply now  on those branches.
<blackboxsw> ok fixed artful,forgot the new-upstream-snapshot there
<blackboxsw> xenial bionic are good
#cloud-init 2018-06-22
<smoser> blackboxsw: https://jenkins.ubuntu.com/server/view/cloud-init,%20curtin,%20streams/job/cloud-init-integration-ec2-a/25/console
<smoser> thoughts ?
<smoser> powersj: https://jenkins.ubuntu.com/server/view/cloud-init,%20curtin,%20streams/job/cloud-init-integration-ec2-x/26/console ?  you have any idea on htat one ?
<smoser> Waiter InstanceRunning failed: Waiter encountered a terminal failure state
<smoser> 17 seconds after it launched the instance it encoutered a terminal failure state.
<powersj> so it was doing install deb encountered error
<powersj>     self.instance.wait_until_running()
<smoser> well, probably not
<smoser> not 17 seconds after launch of the instance
<powersj> so the instance was booting and we were waiting
<smoser> yeah
<smoser> ok. playing a bit more, http://paste.ubuntu.com/p/sFJbTP5Brn/
<smoser> that shows the "gain" of easily decorating the class.
<smoser> and explains skip_by_date decorator some.
<smoser> hope to have a mp for that tmororw.
<blackboxsw> nice, didn't realize you were still working.
<smoser> that was just still in my head
<smoser> integration test failures suck
<smoser> with that... i do need to go afk.
<smoser> have a nice night all.
<blackboxsw> I've started adding descriptions to run/failed jenkins jobs that have hit the keyserver errors.
<smoser> hm.. the name wont be right...
<smoser> :-(
<smoser> ok. later.
<blackboxsw> later. I'm kicking another integration run and will see what gives on that ec2 wait traceback
<blackboxsw> powersj: could that terminal run state be a result of maybe kicking off two ec2 intergration tests simultaneously? like a cleanup job on one wiped all live instances etc?
<blackboxsw> part of the teardown based on keys or something
<powersj> thats what i thought
<powersj> i didnt see that instance listed though
<powersj> is it still occuring?
<blackboxsw> all green now powersj
<blackboxsw> just finished. some intermittent error.
<blackboxsw> smoser: for tomorrow, looks like we hit all green on existing integrationpatchsets.
<blackboxsw> I'm outta here
<blackboxsw> rharper: on this azure instance with the renamed cirename0, it looks like netplan wasn't waiting on cirename0 per journal
<blackboxsw> emd-networkd-wait-online[743]: ignoring: cirename0
<blackboxsw> hrm
<blackboxsw> emd-networkd[722]: eth0: Interface name change detected, eth0 has been renamed to rename3.
<blackboxsw> emd-networkd[722]: rename3: Interface name change detected, rename3 has been renamed to eth0.
<blackboxsw> seems like a bit of thrashing in kernel renames of eth9
<blackboxsw> seems like a bit of thrashing in kernel renames of eth0
<smoser> the rename3 are udev
<smoser> persistent_rules i think
<cyphermox> blackboxsw: /etc/cloud.cfg.d
<cyphermox> or whatever the name of the directory is -- if you deployed the system with maas, cloud-init renames things at boot too.
<blackboxsw> cyphermox: right, there was a race w/ cloud-init trying a rename on this one azure instance but failing because a 2nd nic came up as eth0 in the meantime. I was trying to peek at the other players renaming interfaces at the same time. I just turned on systemd-networkd debug to check out what happens on next boot
<blackboxsw> end result was that the azure instance was left with a nic named 'cirename0' (which was cloud-init's doing)
<blackboxsw> yeah even after reboot, systemd-networkd-wait-online.service is camping out for 2 minutes
<blackboxsw> checking the debug journal now
<blackboxsw> just looking through this now https://github.com/systemd/systemd/issues/7143
<blackboxsw> I mean this http://paste.ubuntu.com/p/W4CT8g4Tyq/
<blackboxsw> and looking specifically at wait-online-service https://github.com/systemd/systemd/issues/7143
<blackboxsw> and looking specifically at wait-online-service http://paste.ubuntu.com/p/RMcBf6YYjN/
<blackboxsw> copy buffer fail
<blackboxsw> so it certainly isn't waiting on cirename0, just on eth0, which seems to be out to lunch for some reason. I'll poke to see if I can determine what networkd thinks eth0 actually is (like mac address etc).
<blackboxsw> cat /run/systemd/network/10-netplan-eth0.*
<blackboxsw> [Match]
<blackboxsw> MACAddress=00:0d:3a:91:bc:49
<blackboxsw> [Link]
<blackboxsw> Name=eth0
<blackboxsw> WakeOnLan=off
<blackboxsw> [Match]
<blackboxsw> MACAddress=00:0d:3a:91:bc:49
<blackboxsw> Name=eth0
<blackboxsw> [Network]
<blackboxsw> DHCP=ipv4
<blackboxsw> [DHCP]
<blackboxsw> UseMTU=true
<cyphermox> blackboxsw: sorry, I can't really keep track here; but two things jumped out in the netplan yaml you pointed out earlier
<cyphermox> I guess just one thing
<cyphermox> https://launchpad.net/ubuntu/+source/netplan.io/0.38
<blackboxsw> no worries, I'm spamming the channel anyway (not really blocked yet, but curious why networkd-online would actually be blocking for so long in this situation as cirename0 matches our optional: True netplan yaml case
<cyphermox> ^ this is a definite SRU candidate, but it's currently blocked in cosmic due to haskell.
<blackboxsw> checking now
<cyphermox> it should fix renames in general
<cyphermox> or at least greatly improve the behavior.
<blackboxsw> good to know about general netplan ip leases... though it looks like it currently Tracebacks  on all interfaces (even the ones that should be managed)
<blackboxsw> cyphermox: but maybe I'm getting that "netplan ip leases" traceback as none of the wait-online-service timed out in general and didn't persist the information for the manage interface eth0
<blackboxsw> I'll watch that 0.38 release eagerly thanks
<blackboxsw> might try it out on my broken bionic instance now to see what gives
<blackboxsw> cyphermox: is  ppa:cyphermox/netplan.io a good ppa to try 0.38?
<cyphermox> no, it's not up to date
 * blackboxsw can just play w/ cosmic to see behavior differences there
<blackboxsw> hah think I got it rharper
<blackboxsw> it's only this corner case on azure:
<blackboxsw> mac1 of original nic1 is rendered to /etc/netplan/50-cloud-init.yaml by us.
<blackboxsw> nic1 detached from instance and nic2 (new-mac) attached to instance
<blackboxsw> 90-azure-hotplug.yaml matches with our hotpluggedeth0 rule per https://paste.ubuntu.com/p/gZBWH5GKmg/
<blackboxsw> no problem on that boot either, but when you re-attached orig nic1 (it is labeled by the kernel as eth1 now on this system because nic2 is now eth0).
<blackboxsw> but that nic1 mac1 matches the original 50-cloud-init.yaml hotplug which also performs a set-name eth0. an I think that collides with the existing nic2(eth0) name on the instance as it is booted
<blackboxsw> which results in our  leaving one instance renamed as cirename0
<blackboxsw> leaving one *nic* renames ...
<blackboxsw> anyway, will try to reproduce the issue on my own instance now
<rharper> blackboxsw: hrm
<rharper> blackboxsw: that's all fine but it's not clear to me yet why we block the boot;  unless you're suggesting that networkd thinks it has two different nics (eth0 and eth1) both with the same mac value so it matches ?
<rharper> that sounds like a networkd bug w.r.t what it can "manage"
<blackboxsw> rharper: from debug logs, it looks like it's IPV6 router solicitation I think
<blackboxsw> Jun 22 18:01:18 bionic-hotplug-test systemd-networkd[744]: NDISC: Sent Router Solicitation, next solicitation in 1min 12s
<blackboxsw> keeps retrying over an over
<blackboxsw> checking your bug https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1765173 to see if related
<ubot5> Ubuntu bug 1765173 in systemd (Ubuntu) "networkd waits 10 seconds for ipv6 network discovery by default" [Undecided,Fix released]
<rharper> blackboxsw: whoa; that's not right
<blackboxsw> ok so we are on the proper systemd which should proceed without blocking on RA, systemd 237-3ubuntu10
<rharper> oh, is the image down level ?
<rharper> this was released before 18.04 GAed
<rharper> blackboxsw: what level is systemd in your image ?
 * rharper tests bionic daily to see if it's regressed
<blackboxsw> systemd	237-3ubuntu10 which matches my recent bionic lxc
<rharper>  3.036s systemd-networkd-wait-online.service
<rharper>  
<rharper> that looks like a regression
<rharper> mother
<rharper> wow, it's the same systemd =(
 * rharper adds debugging 
<blackboxsw> yeah it's as if the mentioned fix didn't work or get in.
<rharper> it went it
<rharper> in
<rharper> I verified
<rharper> so somethings different
<rharper> but I'm not sure what at this point
<blackboxsw> I'm referring to this comment https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1765173/comments/10
<ubot5> Ubuntu bug 1765173 in systemd (Ubuntu) "networkd waits 10 seconds for ipv6 network discovery by default" [Undecided,Fix released]
<blackboxsw> I'll need another pair of eyes/brain on this to correct some incorrect assumptions I have (and get a better education on this) rharper
<rharper> sure
<rharper> lemme poke at my lxd container then we can look at your instance
<blackboxsw> I'm in hangout/meet for my education by fire
<rharper> [2112600.640416] b2 systemd-networkd[149]: eth0: Gained IPv6LL
<rharper> [2112603.521339] b2 systemd-networkd[149]: eth0: DHCPv4 address 10.8.107.145/24 via 10.8.107.1
<rharper> there's my 3 seconds
<rharper> my dnsmasq is just slow
<rharper> [9271481.644265] rharper-b2 systemd[1]: Starting Wait for Network to be Configured...
<rharper> [9271484.163932] rharper-b2 systemd-networkd[151]: eth0: DHCPv4 address 10.109.225.14/24 via 10.109.225.1
<rharper> 2.5 on diglett
#cloud-init 2018-06-23
<tr3l> I am trying to get cloud-init to leave root enabled or enable it if it is disabled
<tr3l> So far, the only thing it does is ignore the directives and disable root
<tr3l> I have tried disable_root: false and disable_root: 0
<tr3l> Does anyone have any idea how I might get it to stop?
<tr3l> Is anyone available to look over my cloud.cfg for any obvious errors?
<blkadder> tr3l: What distro/is root enabled by default?
<tr3l> CentOS 7.5
<tr3l> Root should not be disabled by default on it
<tr3l> I am just using the stock ISO to install on a standard KVM VM
<tr3l> cloud-init is being used to setup the server disks on KVM VM start
<tr3l> Once it is setup, I take an image of the VM and use that image to create new VMs
<tr3l> On start, cloud-init should do nothing except resize disks as needed
<tr3l> blkadder: https://pastebin.com/UE6LHcT4
<tr3l> That is all I am trying to do
<tr3l> I am not sure what I've got wrong
<blkadder> Well you are missing #cloud-config for one.
<blkadder> If that is the complete content of the file.
<tr3l> It is the complete contents
<tr3l> What should I be adding?
<tr3l> I need zero additional functionality. I basically want it to resize the disk and leave the rest of the server alone and do absolutely nothing to it
<blkadder> You need to start the configuration file with #cloud-config as the first line.
<blkadder> https://www.digitalocean.com/community/tutorials/an-introduction-to-cloud-config-scripting
<blkadder> Also it's a stickler for spacing/indentation.
<tr3l> Is there any validator available to validate this?
<blkadder> Which has tripped me up more than once or twice (not saying you have issues there just saying you want to be careful)
<blkadder> They have something built-in.
<blkadder> It has been a while let me see if I can find it...
<blkadder> They have been working on a linter, just not sure how far they have gotten.
<tr3l> I have been struggling to find simple documentation for cloud-init
<blkadder> Yes, documentation is not the greatest. :-)
<blkadder> Many of the devs are on here, they just tend to seem to work normal business hours so this isn't the best time to find them. :-)
<tr3l> I appreciate your help
<tr3l> This cloud-init config is causing problems on production servers
<blkadder> I will refrain from any number of snarky comments.
<tr3l> If I had any other choice, it wouldn't have been used
<tr3l> It comes down to desperation and lack of any other choices. I admit that it is a cowboy solution, but I am trying my best to fix it
<blkadder> I know there is some sort of built in validator now, I am just not able to find the reference to it I had squirreled away...
<tr3l> and struggling a lot trying to get there
<tr3l> It seems like cloud-init devel schema will do something like that
<tr3l> My cloud-init doesn't support devel though
<tr3l> and I can't find any packages that install that
<blkadder> I think I installed from source.
<blkadder> Which is how I got it.
<blkadder> I thought they had moved at least some of it into a production branch but I am really not sure...
<blkadder> Sorry I can't be of more help.
<blkadder> I'm just an infrequent user.
<tr3l> The desperate are happy to have any help
<tr3l> Thank you
<blkadder> You have looked at the logs too to see what it is doing, correct?
<tr3l> I have tried, but I can't make sense of it
<blkadder> Ooh...
<blkadder> cloud-init devel schema
<tr3l> Yea
<tr3l> No devel features in my copy of cloud-init from epel
<tr3l> I also don't see any documentation anywhere about installing it or how it works even for Ubuntu
<blkadder> https://media.readthedocs.org/pdf/cloudinit/latest/cloudinit.pdf
<tr3l> That is the same type of documentation I was struggling with earlier
<tr3l> It doesn't give practical examples of structure, syntax, files, etc. I just lists what each thing does and gives you a MASSIVE overwhelming complex example file to start off
<tr3l> I'm just like.. slow down
<tr3l> Why can't we just get a file that changes the hostname and nothing else?
<tr3l> Where is the hello world of cloud-init?
<blkadder> cloud-init devel schema --config-file
<tr3l> Yeah
<tr3l> If my copy of cloud-init had devel it would be great :(
<blkadder> Best I can do for ya... Gotta run to dinner. Good luck.
<blackboxsw> thx blkadder for fielding some questiosn.
<blackboxsw> tr3l: some simple examples are here.   http://cloudinit.readthedocs.io/en/latest/topics/examples.html
<blackboxsw> as per getting latest and greatest cloud-init on your epel.... we build tip and stable over in our copr repos
<blackboxsw> https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-stable/
<blackboxsw> https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/
<blackboxsw> you can add those repos and install latest cloud-init on your instance, then a sudo cloud-init clean --logs --reboot would allow cloud-init to run as if the system were a new install
<blackboxsw> so if your image creator (or distro) doesn't have the latest cloud-init you can at least upgrade yourself
<tr3l> Thank you for the help
<blackboxsw> and cloud-init 17.1 or later would have " cloud-init devel schema --config-file <your-yaml-filename> --annotate"  which should tell you about whether the yaml you have is properly formatted and will give hints on schema validation for a few config modules
<tr3l> Should disable_root and ssh_pwauth be true/false or 1/0?
<blackboxsw> we haven't finished full schema validation for all config modules, (it's on the agenda this year). then the CLI command will be promoted to "cloud-init schema <your-yaml-file>" (dropping the "devel" param)
<blackboxsw> most of cloud-init accepts any of those options 0 ,False, false,no  as untrue  and   True, 1, true yes as "true"
<blackboxsw> TRUE_STRINGS = ('true', '1', 'on', 'yes')
<blackboxsw> FALSE_STRINGS = ('off', '0', 'no', 'false')
<blackboxsw> checking those speciically to be sure
<blackboxsw> after your instance boots with latest cloud-init  "cloud-init status --long" should quickly give you an idea if there were errors
<blackboxsw> otherwise check /var/log/cloud-init.log for a Traceback
<blackboxsw> disable_root and ssh_pwauth can both be any of those TRUE/FALSE_STRINGS I pasted
<blackboxsw> ssh_pwauth can also additionally be 'unchanged'
<tr3l> I was really hoping you would say it had to be true/false
<blackboxsw> per http://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-passwords
<tr3l> I just upgraded it from here:
<tr3l> https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-stable/
<tr3l> cloud-init: error: invalid choice: 'devel' (choose from 'init', 'modules', 'query', 'single', 'dhclient-hook', 'features')
<tr3l> Updated:
<tr3l>   cloud-init.noarch 0:0.7.9+224.g681baff-1.el7.centos
<blackboxsw> tr3l: we've had discussions a few times about being more strict on schema. I think it's a burden on the user and us to support something so flexible.... too much rope to hang oneself with. per your cloud-config yaml  .....
<blackboxsw> http://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-passwords
<blackboxsw> http://paste.ubuntu.com/p/RQ4c4hgTHX/
<blackboxsw> the rest of the file looks like valid yaml.
<tr3l> I don't mean to sound like a novice user. I've worked with everything from UML to KVM and everything in between. This software is just giving me a lot more trouble than I normally run into
<tr3l> It is a bit disconcerting if I'm honest. I usually don't have to jump into IRC
<blackboxsw> hrm, what gives with ssh_genkeytypes:  ~
<blackboxsw> syslog_fix_perms: ~?
<tr3l> Can I safely remove those?
<tr3l> I could never pin that down
<blackboxsw> yes unknown config keys are ignored
<tr3l> They were included in the default cloud.cfg for the distro as far as I remember
<blackboxsw> as per the other keys, you are mixing two things.
<tr3l> The only part I am solid on is the growroot
<tr3l> The rest is just trying to make it run without messing up the system
<tr3l> Please run without doing anything else essentially
<blackboxsw> tr3l: /etc/cloud/cloud.cfg is system configuration information.
<blackboxsw> which differs from #cloud-config user-data
<tr3l> I have no idea what any of that means
<tr3l> You lost me completely
<blackboxsw> ok sorry 'bout that
<blackboxsw> I thought you were trying originally to provide user-data to your instance which cloud-init reacts to
<tr3l> I am trying to use cloud-init to resize VM disks if they are a different size on boot
<tr3l> Nothing else
<tr3l> I've been able to do that by editing the /etc/cloud/cloud.cfg file with the contents in pastebin
<tr3l> Unfortunately, an update or something has caused it to start disabling root so now I'm trying to fix that or find why it is happening
<blackboxsw> right that minimally enables/disables various config modules
<blackboxsw> minimally for resize I think you need:
<blackboxsw>  - growpart
<blackboxsw>  - resizefs
<blackboxsw>  - disk_setup
<tr3l> growroot works as is
<tr3l> It just won't stop randomly disabling root login
<tr3l> I should note that the network portion of the config there is entirely ignored
<tr3l> I had to use this:
<tr3l> cd /etc/cloud/cloud.cfg.d/
<tr3l> [root@server3 cloud.cfg.d]# cat 99-disable-network-config.cfg
<tr3l> network: {config: disabled}
<tr3l> To make it leave the network alone
<tr3l> I am not sure why
<tr3l> Trying this now:
<tr3l> cat 97-disable-root-mods.cfg
<tr3l> disable_root: 0
<tr3l> [root@server3 cloud.cfg.d]# cat 98-disable-root-mods.cfg
<tr3l> disable_root: false
<blackboxsw> might check /var/lib/cloud/instance/user-data* or /var/lib/cloud/instance/vendor-data*
<tr3l> Both are empty
<blackboxsw> those files generally contain configuraiton that could override any config you write on disk
<blackboxsw> ok .... I do have to bail for a dinner date but hopefully http://cloudinit.readthedocs.io/en/latest/topics/modules.html can help a bit
<tr3l> says this?
<tr3l> From nobody Sat Jun 23 00:03:23 2018
<tr3l> Content-Type: multipart/mixed; boundary="===============8880678780223518493=="
<tr3l> MIME-Version: 1.0
<tr3l> Number-Attachments: 1
<tr3l> --===============8880678780223518493==
<tr3l> MIME-Version: 1.0
<tr3l> Content-Type: text/x-not-multipart
<tr3l> Content-Disposition: attachment; filename="part-001"
#cloud-init 2018-06-24
<tr3l> blackboxsw blkadder Thank you for the help. I believe it might be mitigated
<tr3l> If there is some place to donate towards the project's goals or something, please let me know
<tr3l> I appreciate it a lot
<blackboxsw> tr3l:  heh, code/doc/bug contrubutions always welcome per http://cloudinit.readthedocs.io/en/latest/topics/hacking.html#  for anything that's been a significant hurdle in better understanding things, docs or bugs about missing features are welcome. bugs can be filed here https://bugs.launchpad.net/cloud-init/+filebug
<blackboxsw> if you have any doc additions that you think would be helpful, we can help you get those reviewed and landed quickly
#cloud-init 2020-06-15
<Odd_Bloke> bswinnerton: I'm not 100% sure where that /run/network/interfaces.d file would be coming from; does it appear in /var/log/cloud-init.log at all?
<lucasmoura> Hey everyone, were exactly we should print the authorized keys fingerprints ? https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_ssh_authkey_fingerprints.py#L68
<lucasmoura> I have create a dummy userdata with an ssh_authorized_keys but I could not find the output of this function in either cloud-init-output.logs or syslog
<lucasmoura> PS: This is the PR I am trying to manually validate: https://github.com/canonical/cloud-init/pull/188/
<bswinnerton> Odd_Bloke: it doesn't, no. I suspect that it must be coming from the Debian cloud image
<smoser> bswinnerton: you're not really going to be able to use user-data to get rid of or have any effect on network config. as user-data is applied after network is up.
<smoser> i suspect you have something else running in that image that thinks it shoudl write /run/ files.
<smoser> commit a6faf3acef02bd8cd4d46ac9efeebf24b3f21d81 changed filename from /etc/network/interfaces.d/50-cloud-init.cfg to /etc/network/interfaces.d/50-cloud-init . so that is where one fix came from
<smoser> pastebin /var/log/cloud-init.log , or a tarball created with 'cloud-init collect-logs'. and i'd do so after a `clean --logs`. so that we only have one boot around. or...best case scenario on first boot of a otherwise clean image.
<blackboxsw> lucasmoura: your authorized key fingerprints should be emitted to /var/log/cloud-init-output.log ... yet look what I found :) https://github.com/canonical/cloud-init/blob/master/tests/cloud_tests/testcases/modules/TODO.md#ssh-authkey-fingerprints
<blackboxsw> lucasmoura: I'm trying to dig through to find out how we can reproduce this issue.
<blackboxsw> lucasmoura: ok I found it. util.multi_log actually logs to the console if a logger is not provided. so you can see this output in lxc by attaching to the console via: lxc console <your_container_name>    during first boot
<lucasmoura> blackboxsw, Okay, I will try doing that. Thanks for the help :)
<blackboxsw> lucasmoura: you could lxc launch ubuntu-daily:xenial sru-xenial -c user.user.data="$(cat seed_keys.yaml)" https://paste.ubuntu.com/p/5ddmcqkrVC/
<blackboxsw> lxc console sru-xenial (in another term)
<blackboxsw> upgrade cloud-init to proposed, cloud-init clean --logs --reboot
<blackboxsw> and watch for the Fingerprint (md5/sha256) table
<blackboxsw> I confirm I can see ci-info: | Keytype |                Fingerprint (md5)                | Options |    Comment    |   on xenial
<lucasmoura> Great, I work on it
<lucasmoura> Thanks blackboxsw :)
<blackboxsw> lucasmoura: I've pushed that SRU consolidation script stuff up here https://github.com/cloud-init/ubuntu-sru/pull/113 if you have any thoughts or concerns there, just let me know
<lucasmoura> blackboxsw, ack. I am just finishing the ssh PR and I will review it
<blackboxsw> good deal thanks
<taliptako> hey how can i edit the sshd_config with cloud-init
<taliptako> i need to add AuthorizedPrincipalsFile to sshd_config
<blackboxsw> taliptako: I see cloud-init updates sshd_config for values using our own helper function in https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_set_passwords.py#L123 as part of setting password. I don't see that we do that elsewhere.  So I'd say maybe with a runcmd cloud-config
<blackboxsw> taliptako: maybe like this https://pastebin.ubuntu.com/p/Hh9Dq7g2yv/
<blackboxsw> and then probably need a "- restart ssh" line too
<taliptako> blackboxsw, thank you i will try
<taliptako> interestingly AuthorizedPrincipalsFile doesnt work with Ubuntu 20
<lucasmoura> blackboxsw, just reviewed the azure refactor PR. I just have a doubt regarding the for loop that was dropped, but besides that, LGTM
<lucasmoura> blackboxsw, I have looked at some PRs that I am not sure that we should cover with manual tests: https://paste.ubuntu.com/p/FXX6RSSD84/
<lucasmoura> When you have some time to take a look and if you don't agree, just let me know
<blackboxsw> lucasmoura: I had the same thought on the first one and I had already removed it from the card an hour ago
<blackboxsw> second one is related to the CVE, so it would generally be important to verify, but none of our callsites provide pwlen, so our unittests cover that
<blackboxsw> strike that, out unittests don't cover the pwlen, but the change is so trivial that we probably don't need to validate it w/ an integration test
<blackboxsw> agreed lucasmoura, can drop those cases as they don't need validation
<blackboxsw> thanks
<lucasmoura> blackboxsw, okay, Shoul I just mark them on the list as done or remove from the card ?
<blackboxsw> lucasmoura: how about delete them
<blackboxsw> from the checklist
<blackboxsw> thanks
<lucasmoura> blackboxsw, No problem
<blackboxsw> lucasmoura: if you get a chance tomorrow plz check for errors in the attached/big logs https://github.com/cloud-init/ubuntu-sru/pull/114 :)
<lucasmoura> blackboxsw, ack
<blackboxsw> https://github.com/cloud-init/ubuntu-sru/pull/116 merged thanks lucasmoura
#cloud-init 2020-06-16
<smoser> hey. sorry if i'm off in the weeds https://github.com/canonical/cloud-init/pull/426
<smoser> i fully realize that historically vmware administrators expect that they can execute arbitrary code inside guests.
<smoser> and I also realize that cloud-init is'nt *really* going to stop that.  But cloud-init should at least allow the user to lock the door that cloud-init opened.
<Odd_Bloke> smoser: I don't think you're off in the weeds, I agree with your assessment (and line of questioning).
<meena> I've worked in companies that used VMware where creating the husk of a vm, and filling it with an actual OS where in the hands of two different teams who don't trust each other
<meena> i can imagine at least one of those teams, or their common department head, wanting to close that door
<Odd_Bloke> blackboxsw: meena: Goneri: Just replied to (I think) all the comments on https://github.com/canonical/cloud-init/pull/391 and also asked for some specific high-level input in my latest comment.
<Odd_Bloke> rharper: smoser: Your thoughts in ^ on how we should think about interface renaming conceptually would be much appreciated, as I think that's the one outstanding question I want to resolve before I'd be happy landing this PR, and I don't feel like I have the background in the details that you do.
<lucasmoura> blackboxsw, should we do a manual fix for this commit as well: https://git.launchpad.net/cloud-init/commit/?id=3e2f7356 ?
<meena> right, i got distracted reading that
<rharper> Odd_Bloke: i'll look
<Odd_Bloke> Thanks!
<blackboxsw> falcojr: here's a reference to the consolidated rc file for manually test clouds during SRU, https://github.com/cloud-init/ubuntu-sru/pull/113  this is only a meager start to consolidating some of the common config, utilities and functions.
<blackboxsw> my plan is to reflect those changes into each manual cloud template after this PR land.
<blackboxsw> lands*
<rharper> Odd_Bloke: hrm, I didn't see a specific response to how BSD handles containers (maybe that's not needed) or multi-nic instances on platforms where the nic names/macs are unstable
<rharper> Odd_Bloke: I would say lacking a response (or not having answer) I'd lean on keeping renaming Linux specific, and if/when it becomes an issue in BSD, they can provide an implementation
<smoser> it should fail though.
<smoser> if something provides a network config that includes renaming. then cloud-init needs to fail as it can't possibly do it, and the user is just going to say "where is my foonic0!"
<blackboxsw> #startmeeting cloud-init status meeting
<meetingology> Meeting started Tue Jun 16 16:21:42 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<blackboxsw> #chair smoser Odd_Bloke rharper
<meetingology> Current chairs: Odd_Bloke blackboxsw rharper smoser
<blackboxsw> Welcome to the bi-weekly cloud-init status meeting. A place to chat about upstream cloud-init activity/
<blackboxsw> his meeting is a welcome place for interruptions, questions, requests and unrelated discussions at any point.
<blackboxsw> *this*
<blackboxsw> previous meeting minutes are stored on github
<blackboxsw> #link https://cloud-init.github.io/
<blackboxsw> The topics we generally cover in this meeting are the following: Previous Actions, Recent Changes, In-progress Development, Community Charter, Office Hours (~30 mins).
<blackboxsw> From the previous meeting we captured no actions, so I'll jump into the next topic
<blackboxsw> #topic Recent Changes
<blackboxsw> the following are commits merged into cloud-init's upstream master branch: https://paste.ubuntu.com/p/WdsZXbwwWd/
<blackboxsw> found via git log --since 06-02-2020
<blackboxsw> notable changes:   util.runparts and subp out of util into subp.py,      there are a couple of branches related to improved vmware support, and resolving keyerror issues for users providing network configuration with bridges.
<blackboxsw> also upstream travis CI is now using the commercial travis-ci.com instead of travis-ci-org which should give us better throughput on test runs.
<blackboxsw> community notice: if any PRs created > 1 week ago have problems with unresolved travis ci runs marked 'in progress' those PRs will likely need to be closed and re-submitted due to the shift in travis-ci endpoints.
<blackboxsw> #topic In-progress Development
<blackboxsw> Upstream devs are currently working our way through Ubuntu StableReleaseUpdate (SRU) validation to release cloud-init version 20.2.45  to Ubuntu Xenial, Bionic, Eoan and Focal.  Thanks falcojr lucasmoura and Odd_Bloke for all the help generating test cases and reviewing SRU-related content.
<blackboxsw> We are about halfway through out testing of this release of cloud-init and expect to be able to wrap this up before next week.
<blackboxsw> To track this release, anyone can subscribe to the SRU process bug
<blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
<ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu) "sru cloud-init (19.4.33 to 20.2-45) Xenial, Bionic, Eoan and Focal" [Undecided,In progress]
<blackboxsw> that bug will go to Fix Released when our upload to <ubuntu-release>-updates apt pocket is published
<blackboxsw> Beyond SRU, there is a significant refactor of cloudinit.net* module to define a clear API and push distro-specific content into the distro modules.
<blackboxsw> #link
<blackboxsw> #link https://github.com/canonical/cloud-init/pull/391
<blackboxsw> Thanks Odd_Bloke for driving that refactor. Those interested should check out the above PR
<blackboxsw> I think that about wraps it.
<meena> during the util.subp refactor i suggested also looking into centralising service enabling and (re) starting
<meena> but we kinda glossed over that because of the net refactor
<blackboxsw> meena: good chance to bring that up: let's get that comment link
<blackboxsw> #link https://github.com/canonical/cloud-init/pull/416#issuecomment-640032968
<blackboxsw> meena: your comment was really about re-organizing the ./systemd ./upstart top-level directories and refactoring down into the distros somehow?
<blackboxsw> as that startup service construct is highly distro dependent?
<blackboxsw> If that's the suggestion you are raising for comment, I think it sounds like a reasonable thing to consider. Each distro has it's own way of handling system service management.
<meena> *nod
<blackboxsw> given the fact that all the systemd/ startup script files are all templates, it indicates that we have a lot of distro-specific uniqueness even across various flavors of linux
<blackboxsw> I think that refactor would be significantly simpler to describe in a distro-level API
<blackboxsw> meena: maybe we file a feature bug against cloud-init so we can prioritize that work.
<meena> you're right. let's do that
<blackboxsw> we could surface that bug to the mailinglist
<blackboxsw> meena: do you want to do either of those (bug or mailinglist email: subj: Refactor startup service to distro-specific Api) ?
<blackboxsw> #action file feature bug about refactoring startup services
<meetingology> ACTION: file feature bug about refactoring startup services
<blackboxsw> #action mailing list email requesting comment/concerns about a refactor of startup services
<meetingology> ACTION: mailing list email requesting comment/concerns about a refactor of startup services
<blackboxsw> I've added actions that we can track by next meeting to see if we can make progress on that discussion
<blackboxsw> ok next topic I think
<blackboxsw> #topic community charter
<blackboxsw> As always, any aspects of the cloud-init project is open for participation from community members.
<blackboxsw> We thank everyone for contributing bugs @ https://bugs.launchpad.net/cloud-init/+filebug, reviewing open 'New' bugs that are filed, and reviewing pulls requests @ https://github.com/canonical/cloud-init/pulls
<blackboxsw> all reviews are welcome on any PRs that are up. and driving feature discussions are also encouraged. Thanks meena for participating on all of those fronts
<blackboxsw> for those just wanting to join in and contribute small pull requests there is a queue of bugs or features that should be a fairly contained set of tasks in our bitesize queue:
<blackboxsw> #link https://bugs.launchpad.net/cloud-init/?field.tag=bitezise
<blackboxsw> #topic Office Hours (~next 30 minutes)
<blackboxsw> This 'section' of the meeting is a time where a couple of upstream devs will be available in channel for any discussions, questions, bug work or PR reviews.
<blackboxsw> In the absence of discussion topics, reviewing the active PRs generally occurs to scrub our queue and unblock conversations.
 * blackboxsw addresses some review comments on a CI Ubuntu daily test branch
<AnhVoMSFT> question: is there anyway to only target a particular reporting handler?
<AnhVoMSFT> Right now the Azure DS emits events to the HyperV KVP handler and they also pass through the log handler. For the most part this is fine (and useful). For some larger event message (like compressed log), it does not make sense to emit a large blob of compressed gzip + b64 to the log, is it possible to skip the log handler ?
<blackboxsw> hrm, good question AnhVoMSFT . looking
<Odd_Bloke> blackboxsw: meena: Note that the service files are selected at package generation time, not at runtime, so it's not entirely clear to me how you would integrate them into the Distro hierarchy.
<blackboxsw> nice suggestion Odd_Bloke
<blackboxsw>  AnhVoMSFT: I'm not seeing any filtering config options in reporting: config for handlers.   Are you saying you are looking to add compressed object writes to your kvp message message plane?
 * cyberpear wondering if there's any collaboration with the ignition folks
<blackboxsw> AnhVoMSFT: I think it's be reasonable to provide a named report handler to ReportEventStack
<blackboxsw> and let ReportEventStack limit what handlers it can emit publish_event to
<meena> https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_puppet.py#L106 could this be entirely puppet specific, and no other module does this dance?
<blackboxsw> AnhVoMSFT: that'd mean I suppose that report_event would need to accept a new param to limit which handler it calls handler.publish_event  for
<blackboxsw> https://github.com/canonical/cloud-init/blob/master/cloudinit/reporting/events.py#L84
<meena> https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_rsyslog.py#L210 one more
<blackboxsw> or maybe you are suggesting that we add the ability for an existing handler to define a set of data types that it accepts (and will silently ignore others)?
<blackboxsw> and here meena https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_fan.py#L55-L83
<blackboxsw> ok I've got to run.   time to close the meeting for today. Thanks all for joining in!
<blackboxsw> #endmeeting
<meetingology> Meeting ended Tue Jun 16 17:58:32 2020 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-06-16-16.21.moin.txt
<AnhVoMSFT> @blackboxsw I think we will look into adding a new param to report_event
<AnhVoMSFT> so that it can emit only to a certain handler and does not go through all the available_hanlder
<AnhVoMSFT> (probably adding a new param indicating a new filter list)
<blackboxsw> AnhVoMSFT: that makes sense to me. So, you'd avoid using the ReportEventStack context manager with  that as well?
<blackboxsw> or do you plan to also use the context manager?
<AnhVoMSFT> I have not looked that far to be honest. Will take a look later this week and start some POC
<AnhVoMSFT> @blackboxsw @rharper @Odd_Bloke: is there any way to create an image with an existing user-data (#cloud-config) and provisions the VM with cloud-init using  the user-data that was prepared inside the VM
<meena> does the meetingology text exist in formated?
<rharper> AnhVoMSFT: hrm, sort of;  you can put additional user-data config in an /etc/cloud/cloud.cfg.d/NN-my-user-data.yaml  ... however, if there are namespace overlaps then you have to deal with merging
<rharper> AnhVoMSFT: If the user-data blob coming from IMDS is empty; then that would work out fine;
<AnhVoMSFT> thanks @rharper
<blackboxsw> meena: http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-06-16-16.21.log.html  or our rendering of it here: https://cloud-init.github.io/
<blackboxsw> AnhVoMSFT: and some cloud datasources have grown vendor-data which would act like pre-defined userdata for an instance which users can augment/extend/override with their own user-data
<blackboxsw> see NoCloud/OpenStack/IBMCloud/Oracle datasources I think
<blackboxsw> which could allow your platform to expose some pre-defined configuration
<meena> blackboxsw: aah!thank you
<blackboxsw> Odd_Bloke: for tomorrow I fixed my daily build branch https://github.com/canonical/cloud-init/pull/435   had to run new-upstream-snapshot --skip-release instead of --update-patches on ubuntu/daily/xenial
#cloud-init 2020-06-17
<Odd_Bloke> blackboxsw: I've approved and landed the xenial daily branch fix; it did require configuring the xenial recipe build to use the daily branch (which I'm about to do for bionic and eoan too; this is just FYI), but it's building successfully now. \o/
<Odd_Bloke> blackboxsw: And now the same for the bionic daily branch fix. \o/
<ananke> since we've been using cloud-init to manage our automated AMI build pipelines, I am looking for something similar to it in the windows world. it appears there's cloudbase-init project that attempts to do something similar, do any of you have other recommendations?
<Odd_Bloke> blackboxsw: I have a high-level approach Q on https://github.com/cloud-init/ubuntu-sru/pull/113#pullrequestreview-431851557, so I've posted that and will defer further review until we've discussed it. :)
<Odd_Bloke> ananke: I don't (but I wouldn't really expect to, I don't use Windows for anything other than gaming ;).
<ananke> Odd_Bloke: it's certainly a very new territory for me too, after managing unix/linux systems for 25 years :)
<blackboxsw> ananke: cloudbase-init is the only alternative I was aware of, though it's feature support level seems to pale in comparison :/
<blackboxsw> Odd_Bloke: responded and push commits for discussion https://github.com/cloud-init/ubuntu-sru/pull/113#discussion_r441665171
<blackboxsw> *pushed commits*
<Odd_Bloke> blackboxsw: Ack, thanks!
<blackboxsw> Odd_Bloke: I missed it at standup but, I see you've already updated https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-bionic and https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-xenial to use daily
<blackboxsw> thanks
<Odd_Bloke> :)
<robjo> blackboxsw: Have a few some time? https://bugs.launchpad.net/cloud-init/+bug/1883907
<ubot5> Ubuntu bug 1883907 in cloud-init "EC2 data source does not properly return the instance ID when cached data exists" [Undecided,New]
<blackboxsw> robjo: will glance over that today
<blackboxsw> Odd_Bloke: if you get a chance today I'd like to merge this iteration of consolidated sru-vars if we can so I can push two cloud verifications up (azure and openstack) which rely on this branch https://github.com/cloud-init/ubuntu-sru/pull/113
<Odd_Bloke> blackboxsw: Looking now.  Do those rely on the supplemental test support?
<robjo> blackboxsw: OK, thanks, I am a bit confused as to what happens when and why. So based on debug we load the pickled object with the wrong instance data, but then we recover at some point (I have not found the place in the code where that happens) and the data source gets the data fro the new instance. And the user data is executed as expected, in my test
<robjo> Is there a possibility that a user data script could access the data source data directly and end up with the wrong data, i.e. the data loaded from the cache?
<robjo> I do not have access to the user data script that supposedly hangs in this context
<Odd_Bloke> blackboxsw: I have responded.
<blackboxsw> Odd_Bloke: thanks I've force pushed https://github.com/cloud-init/ubuntu-sru/pull/113
<blackboxsw> dropping the changes and moving azure-sru and sru-vars.template into sru-scripts/
<Odd_Bloke> blackboxsw: Thanks!  Reviewed again.
<falcojr> in this sru verification, I just discovered a legitimate issue
<falcojr> it's not technically a regression, because the old behavior failed too...but it hasn't been fixed either
<falcojr> do we try to fix it right away and then get it into the SRU? Or do we pull this particular feature out? Or do we file a bug and backport it anyway since it was already broken?
<falcojr> creating a swapfile still doesn't work even with dd on btrfs
<falcojr> following these instructions I was able to make it work
<falcojr> https://wiki.archlinux.org/index.php/Swap#Swap_file
<Odd_Bloke> falcojr: As it isn't a regression, we don't _need_ to restart the process with a fix.  And, given how far through the process we are at this point, I think it makes sense to file a bug for it and move on.
<Odd_Bloke> Oh, no blackboxsw, I'd also like his opinion.
<blackboxsw> thanks Odd_Bloke renamed necessary files https://github.com/cloud-init/ubuntu-sru/pull/113 and resolved comments
#cloud-init 2020-06-18
<Odd_Bloke> blackboxsw: I'm not seeing those changes on #113, did you push?
<mock> Hello. I have searched online yet I cannot find any reference to having the write_files module not add extra line feeds into the files it produces. Can it write the files without those extra line feeds? Is there a trick to it?
<meena> mock: can you show us an example of what your input and output look like?
<mock> Yes, wait one...
<meena> online, in some pastebinâ¦
<mock> https://paste.centos.org/view/f990169d
<mock> I have several different files my file is writing. All of them are like that.
<meena> what's the line endings in your input look like?
<mock> I'm using vim on Fedora Linux, so just \n chars.
<rharper> mock: what version of cloud-init ?
<mock> Cloud-init v. 19.3-2.amzn2
<rharper> are you running this on ec2 ? how are you getting your user-data into the instance ?
<rharper> do you paste in the user-data ?  or upload a file?
<rharper> mock: ^
<mock> Oh, I think it might how I'm reading the file via Python. Let me try to adjust that and see what I get.
<mock> Nevermind. That's what it is.
<rharper> cool, glad it was easy
<mock> Me too, but I wish I had thought to check that earlier.
<rharper> np, glad we could help
<mock> Thanks for the cold bucket of water.
<rharper> heh
<mock> :)
<mock> It's all good now. Thanks again!
<robjo> blackboxsw: Maybe a brief chat about https://bugs.launchpad.net/cloud-init/+bug/1883907 this afternoon? Or anyone else from the core team that matter
<ubot5> Ubuntu bug 1883907 in cloud-init "EC2 data source does not properly return the instance ID when cached data exists" [Undecided,New]
<Odd_Bloke> the r in rharper stand for rubber duck. ;)
<rharper> ...
<Odd_Bloke> https://en.wikipedia.org/wiki/Rubber_duck_debugging
<rharper> nice, TIL
<rharper> I was sort of doing that in the vmware discussion on PR #229 (fallback datasource)
<rharper> robjo: will there be a complete cloud-init.log of the failure scenario ?
<Odd_Bloke> I have one of these sitting on my desk, so the expression is always top-of-mind for me: https://codewith.mu/img/en/howto/debug_duck.png
<robjo> rharper: No, I can request one but based on my understanding of the context I have done all the digging and more or less am looking for confirmation that I didn't miss anything
<rharper> the log file would help; but; it it seems plausible;  looking closer at the instance_id check in stages
<rharper> robjo: what version of cloud-init ?
<robjo> As far as I can interpret what I received in a bug is 1.) Start instance 2.) Create AMI from Instance 3.) Start instance from new AMI
<robjo> that's 19.4
<robjo> but that code hasn't change since so master shold have the same behavior
<robjo> In the instance from the new AMI initially we load the cahced data source and thus get_instance_id() returns the incorrect value
<robjo> but I added some debug code and have proof that get_instance_id() eventually returns the new instance data
<robjo> and that the user data script gets executed
<rharper> just checking;  looking at stages.py:_restore_from_checked_cache();  I would expect us to throw away the cache file at local time;   we do restore the object, then we check /run/cloud-init/.instance_id  to ds.get_instance_id();  this fails as run isn't present on new image;  ec2 does not have a check_instance_id() method; so invalidate the datasource cache
<rharper> the log file should confirm that for local stage, we'll see a 'cache invalid in datasource'
<rharper> then we should try _get_data() on ec2, which will bring up ephemeral dhcp and crawl things; and all should be fine.
<robjo> That's what I found in my test, i.e. the initial incorrect information get's discarded and things fix themselves
<rharper> robjo: ok, so what's the bug then ?  this happens early in local, so all of the module stages run like new instance; (because it is)  ?
<robjo> I think we're OK and would tend to close the bug
<rharper> OK.
<rharper> I can paste this discussin in the bug and mark it invalid?
<robjo> As said I wanted confirmation that I didn't miss anything and a bug appeared the natural place for me to capture my data
<robjo> Yes you can close it as invalid, or I can
<rharper> Sure, let me respond there and answer your questions
<robjo> OK, thanks
#cloud-init 2020-06-19
<Erikjan> So anyone here ever had issues where you have nfs entry's that are not yet ready on startup, but say 20 seconds later, where cloud-init would just hang? Have this on rhel images only though, ubuntu works fine. Any idea on how to go about this?
<meena> which versions of those two OSes, Erikjan ?
<meena> well, my first thought is that something in the init scripts is blocking, but on second thought, i have no idea
<Erikjan> latest rhel 7.7 up to 8.1 (have not tested 8.2) and ubuntu the latest LTS
<Erikjan> on a cold boot in the cloud it takes some time before hte netapp is attached, it needs to wait, which it doesn't do correctly
<Odd_Bloke> smoser: Given that you were reviewing the previous iteration of it (thank you again!), do you also want to review https://github.com/canonical/cloud-init/pull/441?
<Odd_Bloke> If I could get a committer's +1 on https://github.com/canonical/cloud-init/pull/440 (paride has reviewed), that'd be much appreciated.
<Odd_Bloke> blackboxsw: ^ if you have a minute?
<blackboxsw> Odd_Bloke: reading
<Odd_Bloke> Thanks!
<Odd_Bloke> falcojr: Scott did approve that PR, so you're off the hook. ;)
<falcojr> heh, gtk
<blackboxsw> approved: Odd_Bloke awaiting CI
<Odd_Bloke> Thanks!
<Odd_Bloke> smoser: https://github.com/canonical/cloud-init/pull/444 <-- that's the fix for the `instance`-is-a-directory issue (which presumably you saw coming given the earlier PR ;)
<falcojr> what are cloud-initramfs-copymods and cloud-initramfs-dyn-netconf ?
<falcojr> just noticed them when I did a dpkg -l | grep cloud-init
<falcojr> are they related or just have an unfortunate similar name?
<falcojr> some kind of cloud specific initramfs thing or something?
<meena> falcojr: what's the "Source"? of those packages? apt show should tell you
<powersj> https://packages.ubuntu.com/source/focal/cloud-initramfs-tools
<Odd_Bloke> OK, take two on that earlier PR: https://github.com/canonical/cloud-init/pull/445
<blackboxsw> Odd_Bloke: if you get a chance today, I think https://github.com/cloud-init/ubuntu-sru/pull/113 is ready
<Odd_Bloke> blackboxsw: I'll consider it if you send me the bug creation automation you promised earlier. ;)
<blackboxsw> hah a trade. I love to barter
<blackboxsw> good pt. getting that now
<blackboxsw> Odd_Bloke: here's what I did for the schema bugs so I think
<blackboxsw> s/so I think/ https://paste.ubuntu.com/p/Dc3dbkDTSs/
<blackboxsw> lp-create-bug is in uss-tableflip
<blackboxsw> I think something comparable would work for the net refactor
<Odd_Bloke> blackboxsw: Nice, thanks!
<Odd_Bloke> blackboxsw: Still one outstanding issue on that ubuntu-sru PR. :)
<blackboxsw> Odd_Bloke: thanks and pushed https://github.com/cloud-init/ubuntu-sru/pull/113
<Odd_Bloke> blackboxsw: I think we now have the opposite problem: the remaining _templates_ will no longer be rendered per-SRU.
<blackboxsw> Odd_Bloke: I'm hoping with the next PR to place all the remaining scripts under sru-scripts/manual.
<blackboxsw> at the moment only azure-sru.*.txt would be created
<blackboxsw> I have a followup to move all remaining scripts into sru-scripts and out of sru-templates
<blackboxsw> which will then remedy that gap
<Odd_Bloke> blackboxsw: OK, cool.
<blackboxsw> I'll post that PR next (and can also post the azure and openstack SRU verification results as well)
<Odd_Bloke> blackboxsw: +1, will leave you to merge. :)
<blackboxsw> thanks Odd_Bloke
<blackboxsw> thanks will merge, and the azure and openstack prs will move those two sru-templates/manual/* scripts under sru-scripts.
<lucasmoura> hi everyone, is there a way to manually test this outside a oracle instance ? https://git.launchpad.net/cloud-init/commit/?id=2bedc440
<lucasmoura> Reading through the code it seems that only the oracle datasource use this to set network config, but I may be missing something
<blackboxsw> lucasmoura: https://github.com/cloud-init/ubuntu-sru/pull/126/files for azure sru verification results review
<blackboxsw> I'll check that commit
<lucasmoura> blackboxsw, okay
<blackboxsw> lucasmoura: I think that commit is already tested as well as you can w/ the unit test that seeds the PROTO='none' @ https://github.com/canonical/cloud-init/blob/master/tests/unittests/test_net.py#L84-L108
<blackboxsw> which confirms that a 'none' value gets converted to 'static'
<blackboxsw> so I think  we don't need integration test coverage of that
<lucasmoura> Okay, I will drop it from the list
<lucasmoura> Also, regarding this commit as well https://git.launchpad.net/cloud-init/commit/?id=d5dbbd1c, should we cover it too ? And if yes, does anyone have a good idea for an url we can use to test this more easily ?
<blackboxsw> openstack sru verification results and refactor up for review https://github.com/cloud-init/ubuntu-sru/pull/127
#cloud-init 2020-06-20
<MICROburst> is cloud-init intended to replace things like kickstart?
<meena> MICROburst: depending on your work flow, you'd use kick-start to build your images, and then you'd use cloud-init to finalise it on boot
<MICROburst> meena: build an image with RedHat's kickstart? - Odd perspective. Are there any good tutorials? I would like to PXE boot the machine and have a per machine config. What can I hand over to cloud-init? Some examples, I have seen seem to use grub instead of iPXE.
<meena> MICROburst: packer â iso or pxe boot (https://www.packer.io/docs/provisioners) â kickstart for install â export the finished product as your VM Host image: https://www.packer.io/docs/builders / https://www.packer.io/docs/post-processors )
<meena> MICROburst: so, are we talking about VMs or hardware, btw?
<MICROburst> meena: bare metal as well as VMs. Currently iPXE and kickstart. No more kickstart due to migration to ubuntu.
<meena> MICROburst: aah, yeah, that Debian seed thing is something else
<meena> imagine kickstart invented by people after they had managed to rule
<meena> flee the cult of chtulu
#cloud-init 2020-06-21
<mruffell> Hi, just wondering when the cloud-init Ubuntu SRU for 20.2-45 will be released to -updates?
