/srv/irclogs.ubuntu.com/2016/10/11/#cloud-init.txt

=== benj is now known as Guest36113
=== rangerpbzzzz is now known as rangerpb
robjosmoser: ping13:54
smoserhey13:55
smoserrobjo,13:55
robjosmoser: Any thoughts on the e-mail I sent to the list yesterday? Have done some more digging and it appears to me that13:56
robjoinit.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))13:56
robjoi.e. stage # should be guarded such that it does not run during the -local phase13:56
smoserwell, the specific error you point to is fixed i believe13:57
smoserer... hold on13:57
smoserhttps://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/30588213:58
smoseri belive is the one13:58
=== jgrimm-out is now known as jgrimm
robjosmoser: I can try this, but it still appears to be opposing the definition of the intent, cloud-init-local is set to run prior to network-pre, thus there is no guarantee that the device is up14:03
robjoin this case why do we even try to read the device state? Should we no simply forgoe this whole network stuff in -local?14:03
smoserah14:03
smoserrobjo, right.14:04
smosersorry, i really, really need to write a description of all of this and what is supposed to happen.14:04
smoserso local should run before networking comes up14:04
smoserbefore the OS would bring up networking14:04
smoseras it is going to configure it.14:04
smoserit doesn't bring it up because the OS should on boot14:04
smoseras it would normally in non-cloud-init boots.14:04
smoserjust as if cloud-init-local had run before boot and wrote the files14:05
smoserthats the goal14:05
robjothat at least is my interpretation based on what's in the unit file. thus stage#6 should be guarded and should not execute the network call at all if in local mode14:05
robjoOh, I think the light just came on and I see the chicken and egg problem14:07
robjoin -local we want to write the config for the network interface, but in order to write the config we check if the device is actually online, thus we read the carrier file14:07
robjobut that is not OK at this point14:08
robjoso one option may be to write out configurations for every device we find whether the device is connected or not14:09
robjothen let the network client figure it out from there14:09
robjothe other option may be to delay the configuration as proposed in my e-mail14:10
robjobtw, I did test the delayed config approach and that worked for me14:11
smoserrobjo, sorry.14:32
smoserwas distracted reading. sorry.14:32
smoserwhy is it not ok to read the carrier ?14:33
smoserbecause it's not been set 'up' i guess ?14:33
robjoas the trace shows it may not be there, so we get EINVAL from the kernel14:33
smosersure... so in that case we decide "don't know"14:33
smoserand assume it available i think14:34
smoserdelaing configuration until existing configuration as found in the system (ie, readying /etc/sysconfig)14:34
robjofollowing the way I currently understand the logic that would imply that we will not write the config, so why bother to begin with?14:34
smoserwould mean that that network config might come up14:34
smoserwhich might be wrong14:34
smoserand or detrimental14:34
smoserie, if i launch 2 isntances from same captured node14:34
smoserthen they'd both bring up networking as the old ip address14:34
robjothe wheels are turning, just a moment...14:36
robjoSo, at this point the configuration can only come from a config drive or the config file, as there is no network cannot pull any data from a server, correct?14:38
robjoThat also implies that we can simply write the configuration we get from the source, i.e. the config drive14:39
robjothere is really no need to check the carrier flag or other status of the device.14:39
smoserrobjo, sort of.14:39
robjoIf we simply write the configuration we promise that the instance will not come up with a duplicate IP14:40
smoserright.14:40
smoser(or if it does, not our problem)14:40
smoserthe thing where it kind of matters is "fallback"14:40
smoserbasically, if cloud-init does not find anything at this point14:40
robjothen once the config is written by -local and the network stack comes up it will sort out the interfaces that are actually in use14:40
smoserit generates a config that equates to old behavior "dhcp on eth0"14:40
smoserand writes that.14:40
smoserbut it tries to be a bit smarter, and not dhcp on a device that is not connected14:41
robjobut the network client will figure that out, so if cloud-init always writes "dhcp" on "eth0" but eth0 is not there then dhcp-client, or in our case wicked will just drop that interface14:42
robjonow of course we can argue whether it is better to generate the EINVAL error form the kernel or let the network client figure out that the interface isn't really there ;)14:43
robjoI am not certain there is a good answer to that question14:43
robjoOther than, if we try to be to clever we create problems ;)14:43
smoserwell, if the thing isn't connected, then its pointless to try to dhcp on it.14:44
smoserbut if we just go on , as i think the branch i pointed at does.... then we end up with "dhcp on eth0" and eth0 not being connected, but not much else we can really do.14:45
smoserin the future, what we will be doing is like the digital ocean datasource does now.14:45
smoserthe cloud-init local will actually be part of every datasource...14:45
smoserand the datasources will check to see if they are on their platform.14:45
smoserif they are, then they'll configure networking manually enough to get to the network metadata service14:46
smoserand find the real network data14:46
smoserand then write that.14:46
smoserand tear down their temporary stuff14:46
smoserthat make sense ? its what makes us able to get networking information from a source that lives on the network14:46
robjoyes, makes sense14:48
robjobackporting the patch to 0.7.8 for my package.....14:48
robjounless 0.7.9 is right around the corner ;)14:49
smoserwell, lets get that merged.14:58
smoserdoes it work for you, robjo ?14:58
robjosmoser: still backporting I probably need an hour before I can test, have a meeting in a couple of minutes14:58
smoserrobjo, ok. it did seem to fix things for others.15:00
robjoI'll let you know as soon as possible15:01
hkominosmorning everyone. I would like to ask quick question if you dont mind. I am using a small openstack installation and i am passing cloud-init to configure the VM. I am using the cloud images from ubuntu for now. In those image15:09
hkominosmorning everyone. I would like to ask quick question if you dont mind. I am using a small openstack installation and i am passing cloud-init to configure the VM. I am using the cloud images from ubuntu for now. In those images the default user is Ubuntu. I dont want that created so I make a new one. However the default key which is passed from openstack never reaches the user[0] name created. Is that default behaviour?]15:11
smoserhkominos, what is "default key" ?15:28
smoseroh. i see. the ssh key.15:29
hkominosI mean a key-pair created from the openstack UI15:29
hkominoshttp://paste.openstack.org/show/585344/15:30
hkominosthis is the relevant cloud-init snipet15:31
robjosmoser: works for me with the patch applied15:42
smoserhkominos, i thin if you just set 'default: true' on one of those entries you'll get what you want15:50
smosershoot. no that doesnt seem to work even though it should15:54
hkominosthat is a good idea. +I think that the -default attribute would create a user named ubuntu thought. Not the one that i want to create. (i think)15:56
smoserwell i think it was intended to update the exiting 'default'15:58
smoserjust launching an lxc container, i get the user created15:58
smoserand no ubunt user15:58
hkominosyou mean withou the -default user.15:59
smoserhttp://paste.ubuntu.com/23308735/15:59
smoserright15:59
smoserall i get is /home/smoser15:59
hkominoshttp://paste.ubuntu.com/23308739/16:01
hkominosso this would create 2 users.16:01
hkominosThat is the only use of "default" tag that i know of.16:02
prometheanfiregoing to have to finish the cloud-init gentoo networkv2 stuff to get v6-only networking working I think18:03
jgrimmsmoser, powersj:  wrt cloud-init integration testing... magicalChicken has some time to help with that, interested?18:19
smosersure.18:26
jgrimmsmoser, cool  i really want to get that off the ground, but wasn't sure if either of you'd started into it at all18:29
smoserno. other than what i'd written there.18:29
jgrimmsmoser, what's ETA for next cloud-init release?18:31
smoseri hadnt targetted one.18:31
jgrimmok, we probably should for the SRU waiting in the wings?18:32
=== another_larsks is now known as larsks
harlowjaprometheanfire are u the main gentoo person?20:36
harlowjaprometheanfire  if so, got any time to look at https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+ref/kill-brpm20:36
harlowjajust preferring to use a single spec file...20:36
harlowjamakes things a little bit simpler...20:37
harlowjathough i  can say i didn't merge in the packages/suse/cloud-init.spec.in stuff; so there might be a tiny bit of work20:38
=== nacc_ is now known as nacc
prometheanfireharlowja: I suppose so20:45
prometheanfireharlowja: do you have a diff?20:46
harlowjaya, let me get one20:46
prometheanfirethe files modified doesn't look like I'd care20:46
prometheanfireI treat it like a python package20:46
prometheanfirea somewhat special one (due to having to run a script iirc)20:47
prometheanfirehttps://github.com/gentoo/gentoo/blob/master/app-emulation/cloud-init/cloud-init-0.7.8-r1.ebuild#L66-L8620:47
prometheanfirethat's how I install20:48
prometheanfiresomeone should look at https://code.launchpad.net/~prometheanfire/cloud-init/+git/cloud-init/+merge/307969 too :P20:48
harlowjaprometheanfire so the part that might bother u is that i dropped the suse spec file, lol21:08
prometheanfireharlowja: I'm not suse :P21:08
harlowjaoh21:08
harlowjanm then21:08
harlowjalol21:08
prometheanfirehwoarang might21:09
harlowjakk21:09
=== rangerpb is now known as rangerpbzzzz

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!