[00:35] <paulmey> https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/323532
[00:35] <paulmey> found and fixed a bug...
[00:36] <paulmey> bug # 1687712
[00:52] <blackboxsw> thx for that paulmey. I'm end of day now. but I'll get you a thorough review on this tomorrow if it isn't reviewed before then.
[15:23] <blackboxsw> forgot to mention powersj  I found an existing project registered over in opensuse build service https://build.opensuse.org/package/show/Cloud:Tools/cloud-init
[15:23] <blackboxsw> for when we start looking at trying to auto-gen RPMs
[15:23] <powersj> ah yes I did see this the other day. Looks like someone setup cloud-init builds for suse
[15:24] <blackboxsw> not sure how we'd coordinate w/ that (or avoid stepping on toes). But yeah it looked like it was about ~2 months old
[15:24] <powersj> +18 patches
[15:24] <blackboxsw> yeah lots of patch love
[15:24] <blackboxsw> some of those I checked against our master and saw fixes already landed
[15:41] <smoser> blackboxsw, powersj i signed up for fedora account yesterday (actually had one already, as i'm cool like that)
[15:41] <smoser> signed up for copr
[15:41] <smoser> i think copr is right for centos/fedora/rhel rpms
[15:41] <smoser> and then suse build for suse
[15:41] <smoser> thoughts?
[15:44] <blackboxsw> smoser: yeah that sounds good to me. I signed up for one end of last week as I'm not cool like that
[15:44] <blackboxsw> it's doable.
[15:45] <blackboxsw> both looked viable
[15:45] <blackboxsw> and copr is probably best in class for RHEL centos anyway (though it didn't seem to have a *ton* of projects registered if I recall)
[15:47] <blackboxsw> smoser, I've setup a digital ocean account and am spinning up a couple test instances to validate failed behavior of https://bugs.launchpad.net/cloud-init/+bug/1676908.   Will wrap up these SRU templates today I hope
[15:47] <ubot5`> Ubuntu bug 1676908 in cloud-init (Ubuntu Zesty) "DigitalOcean network improvements" [Medium,Confirmed]
[15:48] <smoser> blackboxsw, i can just bother utlemming and ask him for help on that
[15:48] <smoser> and i'm perfectly fine to have him veriy
[15:48] <smoser> this is quite reasonable. he opened bug, he mostly did work, his company benefit..
[15:48] <blackboxsw> smoser: +1 on bothering BHoward :)
[15:49]  * smoser pings utlemming
[15:51] <utlemming> smoser: here....I thought I was hanging out, but was disconnected :)
[15:52] <smoser> utlemming, thanks
[15:52] <smoser> blackboxsw, bother utlemming
[15:53] <blackboxsw> hi ben, time to bother you about https://bugs.launchpad.net/cloud-init/+bug/1676908
[15:53] <ubot5`> Ubuntu bug 1676908 in cloud-init (Ubuntu Zesty) "DigitalOcean network improvements" [Medium,Confirmed]
[15:53] <utlemming> yup
[15:53] <blackboxsw> I was going to try setting up a test config droplet in DO that'd reproduce the problem you fixed with your branch
[15:53] <smoser> utlemming, we'd like for you to do the sru template and verify fix
[15:54] <smoser> as your knowledge of digital ocean surpasses even blackboxsw's (who signed up more than 8 hours ago)
[15:54] <blackboxsw> but wanted to get some guidance on a general test config/setup that'd expose this original proble
[15:54] <utlemming> I'd be happy too...
[15:54] <utlemming> smoser: any chance that https://code.launchpad.net/~utlemming/cloud-init/+git/cloud-init-1/+merge/323273 could be included?
[15:55] <utlemming> that is the root cause on another bug....let me fetch that for you
[15:57] <utlemming> smoser: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1681531
[15:57] <ubot5`> Ubuntu bug 1681531 in cloud-init (Ubuntu) "networking.service fails on ifup if networking configured via cloud-init" [Undecided,Incomplete]
[16:02] <blackboxsw> yep, I've created my first droplet and it looks like your initial changes from #1676908 are already present http://paste.ubuntu.com/24505957/
[16:03] <blackboxsw> so DO pulls from xenial-updates
[16:03] <blackboxsw> wow spelling auto-correction by irccloud. hmm don't think I like that
[16:04] <blackboxsw> DO droplets pull from xenial-updates and I see part of ben's changes already present.
[16:07] <utlemming> blackboxsw: we're using the official images, but that is a dpkg-divert because...welp, broken
[16:10] <smoser> blackboxsw, of course they pull from -updates
[16:10] <smoser> ah.
[16:10] <smoser> hm..
[16:14] <blackboxsw> AMheh.
[16:30]  * blackboxsw steps out for an early lunch
[16:41] <ragechin> rharper: Do you have that documentation PR from yesterday handy? I seem to have lost it.
[16:41] <rharper> i do
[16:42] <rharper> https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/321397
[16:42] <rharper> ragechin: feel free to nudge smoser to land it; then it will get published on cloud-init's read-the-docs
[16:42] <ragechin> THanks.
[17:05] <smoser> utlemming, why wouldn't you fix your metadata on digital ocean?
[17:05] <smoser> essentially  https://code.launchpad.net/~utlemming/cloud-init/+git/cloud-init-1/+merge/323273 looks like the MD is provding a gateway that you're saying doesnt work.
[17:25] <utlemming> smoser: checking, on that
[17:25] <utlemming> but I would still like to ignore the second nics
[17:25] <utlemming> for the purpouses of a gateway
[17:26] <smoser> :)
[17:40] <smoser> utlemming, do you agree that the information provided to cloud-init is kind of broken ?
[17:41] <smoser> why would you have gateways on two nics?
[17:41] <ragechin> DHCP assigned addresses on both NICs
[17:41] <ragechin> see: AWS
[17:42] <utlemming> smoer: yup, I'm getting the history on that now
[17:42] <ragechin> hey smoser, any chance you can push this along please?
[17:42] <ragechin> https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/321397
[17:59] <paulmey> blackboxsw, smoser, I updated https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/323532
[18:00] <utlemming> smoser: so yeah, its wrong, but we're going to have use a different version of the json in order to fix that
[18:00] <paulmey> cleaned up tests, more specific assertions and added warnings for unused options
[18:00] <smoser> paulmey, thanks.
[18:00] <smoser> utlemming, ok, can you open a bug and provide info, then we comment in the MP on what we're doing
[18:01] <smoser> because otherwise i'm going to wonder WTH IS GOING ON in 6 months when i look at that again.
[18:01] <smoser> rharper, on https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/321397
[18:02] <smoser> hmm.
[18:02] <blackboxsw> paulmey: looking now, thanks
[18:03] <smoser> i'll just make some commits and sugest them, rharper
[18:03] <rharper> smoser: ok, more since the last time
[18:03] <rharper> I pulled your PR and fixed what you suggested
[18:04] <smoser> yeah. just some stuff i thin is confusing. its ard to type
[18:05] <rharper> sure
[18:07] <utlemming> smoser: updated the commit message to refence the bug, and updated https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1681531
[18:07] <ubot5`> Ubuntu bug 1681531 in cloud-init (Ubuntu) "DigitalOcean DS defines mutliple gateways via meta-data" [Undecided,Incomplete]
[18:18] <blackboxsw> utlemming: are you generating an SRU template for https://bugs.launchpad.net/cloud-init/+bug/1676908  too ?
[18:18] <ubot5`> Ubuntu bug 1676908 in cloud-init (Ubuntu Zesty) "DigitalOcean network improvements" [Medium,Confirmed]
[18:38] <blackboxsw> smoser: I'm not really sure what the intent of extra_opts is in fs_setup. I see no docs about it in https://cloudinit.readthedocs.io/en/latest/topics/examples.html#disk-setup and the behavior of the code seems to lead me to think any functionality could have been handled by setting fs_setup: cmd: to include everything someone wants to do.
[18:38] <utlemming> blackboxsw: fwiw, with out my other patch requested, the SRU will fail.
[18:40] <utlemming> blackboxsw: both have been SRU'ified
[18:41] <utlemming> although I seem to have been kicked out of all my LP groups, so I can't even nominate the bugs
[18:41] <blackboxsw> excellent utlemming
[18:41] <blackboxsw> or should I saw darkmuggle
[18:42] <blackboxsw> say*
[18:42] <utlemming> either :)
[19:06] <smoser> rharper, http://paste.ubuntu.com/24506946/
[19:06] <smoser> see HELPME comments ...
[19:06] <rharper> ok
[19:23] <smoser> rharper, does that stuff make sense ?
[19:23] <smoser> (the patch there)
[19:23] <smoser> utlemming, thanks.
[19:23] <smoser> paulmey, htanks
[19:23] <rharper> smoser: yes;  extra docs for helping folks
[19:24] <rharper> working them now
[19:39] <blackboxsw> paulmey: minor comments added to your proposal. thanks
[20:02] <paulmey> blackboxsw: implemented all your suggestions. Thanks for reviewing!
[20:03] <blackboxsw> np paulmey
[20:10] <rharper> smoser: merged and re-pushed to branch;
[20:28] <anticw> i have vm images i want to use on openstack, ec2 and locally ... when using them locally there is nothing for cloud-init to talk to (which is fine)
[20:28] <anticw> however, i can't seem to make cloud-init time-out promptly or reliably
[20:29] <anticw> seeing a datasource and seting timeouts, etc i still see it retrying for 120s (default which i thought i changed)
[20:43] <rharper> anticw: you may want to use the NoCloud datasource locally instead of modifying the timeouts;
[20:45] <rharper> anticw: if you want to debug the timeout, getting /var/log/cloud-init.log along with the cloud-config you seeded in the image will help us debug
[20:56] <anticw> rharper: how does cloud-init know to use NoCloud on boot?
[20:56] <rharper> fileysstem label
[20:56] <rharper> http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[20:56] <rharper> cidata is the volume label
[20:57] <anticw> cloud-drive?
[20:57] <rharper> yeah
[20:57] <anticw> but i 100% don't want that
[20:57] <anticw> why can't it just give up mucking about after 5s or so?
[20:57] <rharper> or, if you want to embed it directly in the image, you write files to /var/lib/cloud/seed/nocloud/{user-data,meta-data}
[20:57] <anticw> in ec2 it will easily get a response before then
[20:57] <anticw> no, i want the same images in all 3 envs
[20:57] <anticw> the exact same bits
[20:58] <rharper> but if you're not on ec2, the cloud-config won't apply
[20:58] <anticw> but then it delays usable boot times for 120s or more
[20:58] <anticw> VMs locally boot in about 2s or so
[20:58] <anticw> with it ... well, it's 125s+
[20:59] <anticw> (boot meaning to the point i can login)
[20:59] <rharper> right, if you use NoCloud or ConfigDrive, with the same user-data, then cloud-init will find those and run them;
[20:59] <anticw> and if it can't find them ... can i not have it timeout?
[20:59] <rharper> if you supply the same user data to an ec2 instance, it will find the ec2 metadata service and consume the same user-data and run the same paths w.r.t cloud-config
[20:59] <anticw> i mean, i could also have an init process that looks to see if it's still there after 10s and shoots it
[21:00] <anticw> i must be missing something simple sorry
[21:01] <rharper> cloud-init is attempting to find a source of data;  if you don't provide one, it currently assumes you *might* be on an ec2 instance;  historically it;s had a long timeout for various reasons;
[21:01] <rharper> I'm suggesting that you keep the same image, but provide the user-data via a config drive, so cloud-init can find it when you boot locally
[21:02] <anticw> and if i don't want config drive but would rather a timeout?
[21:02] <rharper> that will provide the same results w.r.t applying user-data (ie, set this password, import this key, etc)  as it would if you booted the image in ec2
[21:02] <rharper> the default timeout is long, as you know; changing that requires modifying the image
[21:02] <rharper> embedding some cloud-config in /etc/cloud/cloud.cfg.d/  for the EC2 datasource
[21:03] <rharper> there's a max_wait: value; I'd need to read the code a bit more to write up the details
[21:03] <rharper> even if your time out, no user-data will be applied
[21:03] <rharper> anticw: do you want the image to not run cloud-init locally ?
[21:03] <anticw> i tried setting a max_wait without success; googling i find others struggling with this too
[21:03] <anticw> rharper: locally i do NOT want cloud-init right
[21:04] <rharper> if so, you can pass a kernel parameter to disable cloud-init altogether
[21:04] <anticw> but kernel parms come from the boot loader ...
[21:04] <rharper> yes, I see your concern here
[21:04] <anticw> if i can't reduce the 120s via config i can just hack the code i guess
[21:05] <rharper> well, I'll file a bug on ec2 timeout docs;  there isn't much there
[21:05] <anticw> i could probably put a metadata server at 169.254.169.254 if there was a suitable reply that meant 'go away' but i'm not sure there is
[21:05] <anticw> rharper: there are docs/examples there but i can't get them working, likely it's me
[21:06] <rharper> anticw: in trunk cloud-init, the ds-identify feature will not run cloud-init unless it detects a local datasource; but on ec2 it woudl detect it's ec2 and enable itself
[21:06] <rharper> this is on it;s way back to previous releases (in zesty, yakkety, and eventually xenial)
[21:06] <anticw> this is ub1604 current upstream so likely not in that
[21:06] <rharper> not yet
[21:06] <rharper> you can modify it to use the strict policy now, if you like though
[21:07] <anticw> i could pattch and make a new pkg
[21:07] <rharper> you only need a new config file
[21:07] <anticw> patch even
[21:07] <anticw> oh?
[21:08] <rharper> % cat etc/cloud/ds-identify.cfg
[21:08] <rharper> policy: search,found=first,maybe=all,notfound=disabled
[21:08] <rharper> ci.datasource.ec2.strict_id=true
[21:08] <rharper> for 1604 with cloud-init version: 0.7.9-90-g61eb03fe-0ubuntu1~16.04.1
[21:08] <rharper> which is in xenial-updates
[21:08] <rharper> that policy file will force cloud-init to ensure it finds a datasource or it won't run
[21:09] <rharper> this means for a local boot, without config drive, it will skip cloud-init running altogether
[21:09] <rharper> but the same image with config drive, or booted in ec2, will run
[21:09] <rharper> does that get you what you need?
[21:10] <anticw> i think it might, waiting for it to time-out to test
[21:12] <rharper> you might be interested in mount-image-callback tool which let's you mount and modify the image without booting it
[21:12] <rharper> in the cloud-image-utils
[21:18] <anticw> i can modify images just fine
[21:18] <anticw> the goal though is to have a base images that is *not* modified
[21:19] <anticw> i've had to mount the zvol more than a couple of times locally to unfark stupid things i did
[21:25] <rharper> hehe
[21:29] <anticw> rharper: i created ds-identify.cfg as you showed above but it cloud-init still runs
[21:29] <anticw> let me check i didn't goof
[21:30] <rharper> are you running the cloud-init version I pasted above ?
[21:31] <anticw> oh, i see ... i actually assumed i was but didn't check, sorry
[21:31] <anticw> that's a git version id in there so not release tag, my guess is not
[21:32] <rharper> ok, if you apt update && apt install cloud-init, it'll upgrade to the newer version which has ds-identify available for use
[21:32] <anticw> it's in the apt-repo very recently?
[21:33] <rharper> for a few weeks or more
[21:33] <anticw> i do have it
[21:34] <rharper> ok, then we can look at /run/cloud-init/ds-identify.log
[21:35] <rharper> the default behavior without the ds-identify.cfg is to always run (as it has in the past); the policy file should direct it to not run unless it detects a local datasource (or a some other cloud identifier, for say ec2)
[21:36] <anticw> https://pastebin.com/5xdMeUE1 && https://pastebin.com/S5HMyVTW
[21:36] <anticw> maybe for ec2
[21:37] <anticw> "1 datasources returned maybe: Ec2"
[21:39] <rharper> ack, looking
[21:46] <rharper> anticw: do you have any Ec2 cloud-config in any of the /etc/cloud/* subtree ?
[21:47] <anticw> no
[21:47] <rharper> hrm, I have a plain 1604 image with that same policy loaded, but it doesn't return maybe for ec2 ... trying to figure out why yours is...
[21:48] <anticw> i did alter cloud.cfg to try and get things going and also to take out the apt modules, because with those in place source.list gets wrecked
[21:49] <anticw> i can [re]test with the stock cloud.cfg likely
[21:49] <rharper> that wouldn't affect it
[21:50] <rharper> if you're on your instance now;, you can remove /run/cloud-init/.ds-identify.result and then  sh -x /usr/lib/cloud-init/ds-identify &> ds.log;  that'll re-run ds-identify with execution tracing, and I can see how it got a maybe
[21:52] <anticw> --force?
[21:52] <anticw> otherwise cached
[21:52] <rharper> I think the dot file is the cache test
[21:52] <rharper> but you can also pass --force, won't hurt
[21:53] <anticw> so this time i got: 2 datasources returned maybe: OVF Ec2
[21:53] <anticw> pastebin ds.log for you?
[21:53] <rharper> please
[21:53] <rharper> =/
[21:53] <rharper> I think maybe OVF is expected ...   and I've been down this path before;  /me triple checks the contents of ds-identify.cfg
[21:54] <anticw> https://pastebin.com/Uz7hPdjZ
[21:55] <rharper> you need either the --force or rm /run/cloud-init/.ds-identify.result
[21:55] <rharper> the paste was from that cached run
[21:58] <anticw> oh sorry, i did it 2x and forgot to remove it the second time
[22:03] <anticw> rharper: https://pastebin.com/8jTnqpXX
[22:03] <rharper> k
[22:22] <blackboxsw> smoser: last SRU bug template for softlayer. For testing, shall I  make-configdrive-dir, but remove the dated directory from the lxd  leaving only the latest directory. Then I could run ds-identify and make sure it still finds the content?
[22:22] <blackboxsw> the bug I meant to reference: https://bugs.launchpad.net/cloud-init/+bug/1673637
[22:22] <ubot5`> Ubuntu bug 1673637 in cloud-init "cloud-init - Hosts in softlayer receiving warning" [High,Confirmed]