[15:59] smoser: I think there is a bug in how growpart calls partx, and now partx has better error checking and blows up (see https://bugzilla.redhat.com/show_bug.cgi?id=1327337) [15:59] I am going to submit a fix on launchpad. [16:02] larsks, so partx changed interface ? [16:02] oh. i see your last comment there. [16:02] I don't think so. I think the previuos command invocation was actually incorrect, based on my reading of the man page (even for earlier versions). [16:02] I think it worked because of luck. [16:02] well, not complete luck [16:03] definitely it would have paid attention to the '1' in that call [16:03] The man page says either "partx disk" or "partx partition [disk]", neither of which is what growpart is doing. [16:03] previously, or growing growing a partition other than '1' would fail. [16:04] The examples in the man page suggest either "partx --update /dev/vda1" or "partix --update --nr 1 /dev/vda" would be correct [16:04] that is wierd. i agree. [16:04] but it definitely does work. [16:04] for lots of things [16:04] Oh yeah, totally :) [16:10] Heck, now I am extra confused... [16:10] ...because looking at the sources we appear to be calling $part $dev, which should be fine. Ugh, maybe I misread some output somewhere? [16:11] * larsks puts on his paying-attention glasses and checks again. [16:28] smoser: okay, patch submitted in lp. [16:31] link ? [16:31] larsks, i'm *that* lazy [16:32] https://bugs.launchpad.net/cloud-utils/+bug/1587971 [16:32] It's a...(counts)...5 character change. [17:09] smoser merge that stuff today righththtttttt [17:09] lol [17:10] (not joking, ha) [17:10] harlowja, bzr+ssh://bazaar.launchpad.net/~smoser/cloud-init/trunk.fix-networking/ [17:10] er.. [17:10] https://code.launchpad.net/~smoser/cloud-init/trunk.fix-networking/ [17:10] whats that [17:10] that is what i'm working on [17:10] that has to et in [17:10] u broke stuff [17:10] that fixes (soon) openstack config drive [17:11] kk [17:11] will look at [17:20] whats up with the renaming code? [17:21] does that run everytime cloud-init is ran? [17:23] that's the only part that seems to concern me :-/ [17:23] harlowja, yeah, i know. its scary [17:23] didn't think that doing `ip set ` was a permeant change [17:24] so yes. it runs every time. [17:24] :-/ [17:24] scary [17:24] it has to because of 2 things [17:25] a.) initramfs is out of date with respect to /etc/systemd/network/*.link files [17:25] this is the case in any fresh instance as the initramfs that booted is either pristine or out of date [17:25] b.) lxc container [17:26] doesn't everyone use initramfs, i didn't think say centos did and such [17:26] there are no udev events in a container, so the systemd .link files do not get applied [17:26] *does everyone [17:26] i'd suspect most things use an initramfs. [17:26] ah, just the normal initramfs, nothing special to cloudinit [17:27] its possible they do nto in cloud images (where you could feasibly have a 'virtual' kernel that had block device drivers built in for all targetted root devices [17:27] ) [17:27] but even then, that means you can't boot with UUID= [17:27] or LABEL= [17:27] as its the initramfs that figures that part out [17:27] gotcha [17:27] the reason that initramfs-out-of-date is a problem [17:28] is because systemd .link refuses to rename devices that have been renamed [17:28] lol [17:28] and the initramfs will not have any rules and rename 'eth0' to 'en1p2' or whatever the default is [17:28] its kind of obnoxious really. [17:28] ya, seems like it [17:29] smoser: please rename the device 'a' to 'b' [17:29] systemd: ok, that sounds great. device 'a' is now 'b' [17:29] smoser: please rename the device 'b' to 'c' [17:29] no soup for u [17:29] lol [17:29] systemd: sorry, smoser, you need to think ahead more or update your initramfs and reboot [17:29] ya, that's stupid [17:29] lol [17:30] harlowja, it wont run though if networking is disbled in cloud-init though [17:30] so if user wants cloud-init out of the picture, they can disable networking (via cloud-config) and get that. [17:30] on subsequent boots [17:31] ya, weird stuff, lol [17:34] i wonder if at some point we can just have the underlying system (sysconfig for example) have the right names in the first place [17:35] cause from my understanding sysconfig files have a name 'DEVICE=X' and `HWADDR` fields [17:35] so whats the point of renaming stuff if those 2 are right (but maybe i not understand something here, ha) [17:36] so in sysconfig land, is the renaming needed(?) [17:38] so the renaming is to support when the datasource declares the names [17:38] mgagne pointed out that in openstack currently they dont raelly declare the nic name. (id actually is the host nic's name :) [17:39] ya, good point, its crap like 'tap-blahblah' or ... [17:39] not eth0 or ethX [17:39] but on other systems such as smartos and possibly in the future on openstack, the datasource (or even user) would like to declare the names for their nics [17:39] internal0 [17:39] or [17:39] external0 [17:39] to mean obviously useful things. [17:40] ya [17:40] is anyone in openstack (nova) land fixing the names of these things? [17:40] * harlowja not it [17:40] lol [17:41] to not have host nic junk names [17:42] its not bad, they're just 'ids'. which is fine. they could be uuids [17:42] but conceivably a user would quite possibly want to attach a nic to a system and provide the name that they'd like that thing to appear as. [17:43] sure, i guess, i like mine called eth0-pink-bunny [17:43] lol [17:43] I'm planning on opening a bug/change for that bad behavior [17:44] cool [17:50] smoser only think i can think of is to add more informational logging about what is about to be renamed (and not just the errors that may have resulted from the act of renaming/figuring out what to rename) [17:50] harlowja, yeah, i'm working on that. [17:50] kk [17:50] it is even more fun now in container [17:50] than i thought [17:50] :-/ [17:50] https://github.com/lxc/lxd/issues/2063 [17:50] is smartos going to use cloudinit now? [17:50] you can't rename a nic that is up [17:50] now there own cloudinit [17:50] *not there own [17:51] ubuntu on smartos (guests) have cloud-init [17:51] k [17:51] since you can't rename a nic that is up [17:51] and nics in containers *start* as up [17:51] 'why is my network device 'up' when nothing in my init system has configured it so' [17:51] lol [17:52] well that shit be weird [17:52] so now i'm re-working that to allow for downing internfaces [17:52] lol [17:52] https://bugs.launchpad.net/nova/+bug/1588017 [17:52] so it will be able to down it if it does not have any "real" addresses [17:53] mgagne, interesting... [17:53] mgagne thx [17:53] from the guests perspective, it shoudl be physical always [17:53] that's not what the spec mentions [17:53] either we respect spec or we propose an amendment and wait for it to merge before changing implementation details [17:54] where do you see this ? [17:54] in the spec... [17:54] i see only a single occurance of the word 'virtual' [17:54] at http://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html#rest-api-impact [17:54] Example of VIF [17:55] otherwise I don't know what the purpose of vif would be [18:15] ya, only think i can think of is for ironic, but idk [18:15] ironic though is different [18:38] smoser i guess otherwise, now that i understand that renaming stuff that fix looks ok [18:38] i can work it into the refactor i had when u merge it [21:43] smoser in ' def update_byname(bymac): [21:43] return {data['name']: data for data in bymac.values()}' [21:43] that no worky on py26 [21:44] just fyi [21:44] dict comprhension in 2.7+ === jgrimm is now known as jgrimm-afk [23:57] harlowja, oh yeah, i forgot i had to care about py226 [23:57] er.. even py26 [23:57] :-P