[08:47] <mbwe> Morning everybody
[12:52] <smoser> good morning mbwe (or afternoon for you now)
[16:57] <smoser> powersj, how'd you do the ascii video things ?
[16:57] <smoser> what'd you use?
[16:57] <smoser> ascii cinema ?
[16:58] <powersj> smoser: apt install asciinema
[16:58] <powersj> make an account
[16:58] <powersj> and run 'asciinema rec -t "title name"'
[16:58] <powersj> do whatever, then type exit or Ctrl-D
[16:58] <smoser> k
[18:12] <rharper> smoser: I think bug 1672833  is fixed-release now;   after some trial/error with getting user-data into the instance correctly (This is the file I attached in the ec2 console http://paste.ubuntu.com/25234630/)  The i3.large launched and formats/mounts the nvme device just fine.
[18:13] <rharper> I suspect the rework on the fs_setup/mount earlier this year resolved the issue
[18:15] <smoser> rharper, hm..
[18:15] <smoser> can you let me into your instance ?
[18:15] <rharper> yes
[18:15] <smoser> it is quite possible, even probabable that the funny device name/partition delimiter 'p' caused that
[18:15] <smoser> and now is fixed.
[18:15] <rharper> yes
[18:16] <rharper> I think that might have been it
[18:16] <rharper> following the code path, the nvme devices don't have a "special name" so the translator returns None, it's not a metadata disk, so it should just work as a device; my testing in the unittests showed that; so I was wondering if there was some sort of hotplug or something else going on
[18:17] <rharper> that user-data in my paste works fine in a ConfigDrive under KVM with an nvme device, so I tested the i3 and it just works as well
[18:18] <smoser> rharper, right. so that works but you had to know that the ephemeral disk was nvme
[18:18] <smoser> you can refer to devices as 'ephemeral0'
[18:19] <rharper> well, it's not clear in the bug what's not working then
[18:19] <rharper> the config in the bug works (if you append the #cloud-config when adding it via the console) on the latest images
[18:19] <rharper> smoser: are you suggesting if they replaced '/dev/nvme0' with 'ephemeral0' that should work ?
[18:19] <smoser> http://paste.ubuntu.com/25234714/
[18:20] <smoser> right
[18:20] <smoser> and iv'e wanted to add support for a user to name aliases like that.
[18:20] <smoser> so the user coudl then just declare that "ephemeral0" is "/dev/nvme0" or whatever
[18:20] <smoser> and override any thing provided by the md
[18:20] <rharper> well, the metadata says ephemeral0 is sdb (which I think this was the bug in the metadata you were alluding to)
[18:21] <smoser> thus making your example user-data more easily modified to work with sdb or nvme or whatever
[18:21] <smoser> right
[18:21] <rharper> I see, ideally, you can write a more common user-data
[18:21] <rharper> and if you launch without an nvme it would still work
[18:21] <rharper> hrm, I'd like to get clarity; it's not clear from the bug that the submitter intended that
[18:22] <smoser> yeah, definitely he submitted it with nvme
[18:22] <smoser> as the path
[18:22] <smoser> so uyeah
[20:11] <smoser> blackboxsw, were you reviewing https://code.launchpad.net/~msaikia/cloud-init/+git/cloud-init/+merge/322991 ?
[20:13] <blackboxsw> smoser: I need to close out on that. just got through the fisrt one. will wrap that and rharper's other branch up today
[21:06] <smoser> blackboxsw, http://paste.ubuntu.com/25235459/
[21:06] <smoser> awesome.
[21:06] <smoser> i failed to execute your script file, but i did *my* job, so exit value 0
[21:06] <blackboxsw> rharper: addressed most of your review comments on https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/328241 just pushed
[21:06] <rharper> k
[21:06] <smoser> i have some in flight there
[21:07] <rharper> blackboxsw: what about the find first nic with an address
[21:07] <rharper> smoser: interested in your thoughts on that one too
[21:10] <rharper> blackboxsw: smoser: also I had a question about changing the metadata date string;  what's the impact there ?  is it SRU'able?
[21:10] <rharper> I suppose it should be similar to how OpenStack has versioned metadata strings; but we keep those around IIRC
[21:10] <blackboxsw> rharper: yeah was pondering that comment. so we are naturally sorting that list of interface names before looking for a valid address.
[21:10] <rharper> blackboxsw: right, but the interface may or may not have an address
[21:11] <rharper> ideally we filter for all interface with address, then sort
[21:12] <rharper> maybe I'm being overly pedantic here; but I sortof would want similar heuristics used to select the "right" interface that we pick for fallback networking
[21:12] <blackboxsw> rharper: I don't follow how that's different?
[21:13] <blackboxsw> if only eth2 and eth4 have a mac address, how would that sort logic change if we filter out by interfaces with mac's first  or during our loop
[21:13] <blackboxsw> you are thinking a kernel might bring up a mac address mid-loop?
[21:14] <rharper> well, that's possible, but that's not waht I was thinking;  I was thinking ip address, not mac;   the mac should be stable
[21:14] <rharper> but hotplug is an edge case
[21:14] <rharper> we already have that gap in fallback networking as well (if the "right" one didn't show up till after we've tried to generate a network config)
[21:14] <blackboxsw> right. yeah I call bad sysfs filename "address" file == mac-address
[21:15] <rharper> does the fallback code which picks an interface to configure; does that achieve what you want (find me an itnerface to dhcp on)and if so? can we reuse that
[21:16] <rharper> I think it does (prefers certain names and other heuristics
[21:16] <rharper> I feel it woudl be good to pick in the same way
[21:17] <rharper> ah, it's not callback (buried in generate_fallback_config)
[21:17] <smoser> just hit 'submit' on my comments.
[21:17] <smoser> rharper, it is a *mac* address.
[21:17] <smoser> not an ip address.
[21:17] <rharper> yeah, I realize that now
[21:18] <rharper> but I'd like to reuse the interface name choice code
[21:18] <rharper> it was partially lifted from generate_fallback_config; if we made that a stand-along function, it could get reused
[21:18] <smoser> yeah, there is a lot of duplicate-ish code there
[21:18] <smoser> a function for 'mac_address(nic)' would have made it clearer too :)
[21:19] <rharper> right, 75% of generate_fallback_config is "pick the best interface"
[21:19] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/328542
[21:19] <smoser> we do have to do something about the api version though. we can't just straight up change that.
[21:20] <smoser> the thing that i had talked with blackboxsw about was to read the list of available api versions
[21:20] <smoser> and sect a newer one if we have one.
[21:20] <smoser> i think we probably have to do something like:
[21:20] <smoser>  read the old version instance-id
[21:20] <smoser>  try:
[21:21] <smoser>    see if "%s/" returns a list of YYYY-MM-DD
[21:21] <smoser>     if so, check for newer version, and set api_ver = that
[21:21] <smoser>   except E:
[21:21] <smoser>    that didnt work, use the old api_version
[21:22] <smoser> that way we use the old version unless the md tells us they have the newer version available (and amazon's does)
[21:22] <smoser> if theres a lookalike that doesnt, then they should fix their md service.
[21:23] <rharper> smoser: do we do that datestring check in openstack ?
[21:23] <smoser> we do something like it....
[21:23] <smoser> _find_workign_version
[21:23] <rharper> yeah, looking at that now
[21:23] <blackboxsw> +1 on the old/new API version support. I had forgotten about that in the mix. right so we need a fallback to 2009
[21:24] <rharper> right
[21:24] <rharper> blackboxsw: right; that was my concern
[21:24] <rharper> it's shame they can't point to the new url in the old metadata
[21:24] <rharper> that way we don't take a hit on a  possible not-present URL
[21:25] <rharper> sort of like a union of metadata with a link to the next set
[21:25] <smoser> well, they kind of do
[21:25] <smoser> they list the versions that are present
[21:25] <blackboxsw> shall we only support  a limited # of release metadata versions ?  SUPPORTED_METADATA_VERSIONS = ['2016-09-02', '2009-04-04',]
[21:26] <blackboxsw> and attempt to hit each in priority order if present?
[21:26] <rharper> smoser: oh, nice
[21:26] <smoser> you can enter into http://169.254.169.254/
[21:26] <smoser> and i think you get a list.
[21:26] <smoser> thats what openstack does.
[21:26] <rharper> ok
[21:26] <smoser> the issue is that i was saying a lookalike might not do that
[21:26] <smoser> (aws does)
[21:26] <smoser> and we've never depended on that list before.
[21:27] <blackboxsw> roger. but even if there is a list of X releases reported, should cloud-init attempt only the known MD versions that we have tested against (and skip any interim versions we may not understand)
[21:28] <rharper> smoser: oh, bummer
[21:28] <rharper> that sorta stinks;  so everyone pays for the hit to the new metadata version if it's not there
[21:29] <blackboxsw> or everyone pays to hit a list endpoint too I guess
[21:31] <blackboxsw> we could just make it Ec2Local hitting that MD version
[21:31] <blackboxsw> but, still most lookalikes I'd imagine would also allow for init-local dhclient init. hmm
[21:32] <smoser> blackboxsw, right. only hit the two that we've known to work.
[21:32] <smoser> hit/consider
[21:33] <smoser> rharper, but on amazon the metdata service is fast. the "hit" is not a big deal :)
[21:33] <smoser> and on amazon also you can always assume any version that your code knows about is there.
[21:34] <smoser> interesting that the only value in the list is to provide clients on a lookalike a way to check.
[21:34] <rharper> 'any version your code knows about is there'  how does that work ?
[21:45] <blackboxsw> approved https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/328542
[21:46] <blackboxsw> smoser: aws does provide a list from http://169.254.169.254/
[21:46] <blackboxsw> not sure if that's considered "faster" than attempting  a version dir in the metadata sevice that doesn't exist
[21:49] <blackboxsw> in dumb human testing w/ time  it looks like the list http://169.254.169.254/ plus string match is about comparable  to a 404 on version not present
[21:50] <blackboxsw> maybe a little faster to just try the known version and cope w/ the 404