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