| === benj is now known as Guest36113 | ||
| === rangerpbzzzz is now known as rangerpb | ||
| robjo | smoser: ping | 13:54 |
|---|---|---|
| smoser | hey | 13:55 |
| smoser | robjo, | 13:55 |
| robjo | smoser: Any thoughts on the e-mail I sent to the list yesterday? Have done some more digging and it appears to me that | 13:56 |
| robjo | init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL)) | 13:56 |
| robjo | i.e. stage # should be guarded such that it does not run during the -local phase | 13:56 |
| smoser | well, the specific error you point to is fixed i believe | 13:57 |
| smoser | er... hold on | 13:57 |
| smoser | https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/305882 | 13:58 |
| smoser | i belive is the one | 13:58 |
| === jgrimm-out is now known as jgrimm | ||
| robjo | smoser: 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 up | 14:03 |
| robjo | in 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 |
| smoser | ah | 14:03 |
| smoser | robjo, right. | 14:04 |
| smoser | sorry, i really, really need to write a description of all of this and what is supposed to happen. | 14:04 |
| smoser | so local should run before networking comes up | 14:04 |
| smoser | before the OS would bring up networking | 14:04 |
| smoser | as it is going to configure it. | 14:04 |
| smoser | it doesn't bring it up because the OS should on boot | 14:04 |
| smoser | as it would normally in non-cloud-init boots. | 14:04 |
| smoser | just as if cloud-init-local had run before boot and wrote the files | 14:05 |
| smoser | thats the goal | 14:05 |
| robjo | that 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 mode | 14:05 |
| robjo | Oh, I think the light just came on and I see the chicken and egg problem | 14:07 |
| robjo | in -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 file | 14:07 |
| robjo | but that is not OK at this point | 14:08 |
| robjo | so one option may be to write out configurations for every device we find whether the device is connected or not | 14:09 |
| robjo | then let the network client figure it out from there | 14:09 |
| robjo | the other option may be to delay the configuration as proposed in my e-mail | 14:10 |
| robjo | btw, I did test the delayed config approach and that worked for me | 14:11 |
| smoser | robjo, sorry. | 14:32 |
| smoser | was distracted reading. sorry. | 14:32 |
| smoser | why is it not ok to read the carrier ? | 14:33 |
| smoser | because it's not been set 'up' i guess ? | 14:33 |
| robjo | as the trace shows it may not be there, so we get EINVAL from the kernel | 14:33 |
| smoser | sure... so in that case we decide "don't know" | 14:33 |
| smoser | and assume it available i think | 14:34 |
| smoser | delaing configuration until existing configuration as found in the system (ie, readying /etc/sysconfig) | 14:34 |
| robjo | following 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 |
| smoser | would mean that that network config might come up | 14:34 |
| smoser | which might be wrong | 14:34 |
| smoser | and or detrimental | 14:34 |
| smoser | ie, if i launch 2 isntances from same captured node | 14:34 |
| smoser | then they'd both bring up networking as the old ip address | 14:34 |
| robjo | the wheels are turning, just a moment... | 14:36 |
| robjo | So, 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 |
| robjo | That also implies that we can simply write the configuration we get from the source, i.e. the config drive | 14:39 |
| robjo | there is really no need to check the carrier flag or other status of the device. | 14:39 |
| smoser | robjo, sort of. | 14:39 |
| robjo | If we simply write the configuration we promise that the instance will not come up with a duplicate IP | 14:40 |
| smoser | right. | 14:40 |
| smoser | (or if it does, not our problem) | 14:40 |
| smoser | the thing where it kind of matters is "fallback" | 14:40 |
| smoser | basically, if cloud-init does not find anything at this point | 14:40 |
| robjo | then once the config is written by -local and the network stack comes up it will sort out the interfaces that are actually in use | 14:40 |
| smoser | it generates a config that equates to old behavior "dhcp on eth0" | 14:40 |
| smoser | and writes that. | 14:40 |
| smoser | but it tries to be a bit smarter, and not dhcp on a device that is not connected | 14:41 |
| robjo | but 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 interface | 14:42 |
| robjo | now 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 |
| robjo | I am not certain there is a good answer to that question | 14:43 |
| robjo | Other than, if we try to be to clever we create problems ;) | 14:43 |
| smoser | well, if the thing isn't connected, then its pointless to try to dhcp on it. | 14:44 |
| smoser | but 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 |
| smoser | in the future, what we will be doing is like the digital ocean datasource does now. | 14:45 |
| smoser | the cloud-init local will actually be part of every datasource... | 14:45 |
| smoser | and the datasources will check to see if they are on their platform. | 14:45 |
| smoser | if they are, then they'll configure networking manually enough to get to the network metadata service | 14:46 |
| smoser | and find the real network data | 14:46 |
| smoser | and then write that. | 14:46 |
| smoser | and tear down their temporary stuff | 14:46 |
| smoser | that make sense ? its what makes us able to get networking information from a source that lives on the network | 14:46 |
| robjo | yes, makes sense | 14:48 |
| robjo | backporting the patch to 0.7.8 for my package..... | 14:48 |
| robjo | unless 0.7.9 is right around the corner ;) | 14:49 |
| smoser | well, lets get that merged. | 14:58 |
| smoser | does it work for you, robjo ? | 14:58 |
| robjo | smoser: still backporting I probably need an hour before I can test, have a meeting in a couple of minutes | 14:58 |
| smoser | robjo, ok. it did seem to fix things for others. | 15:00 |
| robjo | I'll let you know as soon as possible | 15:01 |
| hkominos | morning 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 image | 15:09 |
| hkominos | morning 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 |
| smoser | hkominos, what is "default key" ? | 15:28 |
| smoser | oh. i see. the ssh key. | 15:29 |
| hkominos | I mean a key-pair created from the openstack UI | 15:29 |
| hkominos | http://paste.openstack.org/show/585344/ | 15:30 |
| hkominos | this is the relevant cloud-init snipet | 15:31 |
| robjo | smoser: works for me with the patch applied | 15:42 |
| smoser | hkominos, i thin if you just set 'default: true' on one of those entries you'll get what you want | 15:50 |
| smoser | shoot. no that doesnt seem to work even though it should | 15:54 |
| hkominos | that 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 |
| smoser | well i think it was intended to update the exiting 'default' | 15:58 |
| smoser | just launching an lxc container, i get the user created | 15:58 |
| smoser | and no ubunt user | 15:58 |
| hkominos | you mean withou the -default user. | 15:59 |
| smoser | http://paste.ubuntu.com/23308735/ | 15:59 |
| smoser | right | 15:59 |
| smoser | all i get is /home/smoser | 15:59 |
| hkominos | http://paste.ubuntu.com/23308739/ | 16:01 |
| hkominos | so this would create 2 users. | 16:01 |
| hkominos | That is the only use of "default" tag that i know of. | 16:02 |
| prometheanfire | going to have to finish the cloud-init gentoo networkv2 stuff to get v6-only networking working I think | 18:03 |
| jgrimm | smoser, powersj: wrt cloud-init integration testing... magicalChicken has some time to help with that, interested? | 18:19 |
| smoser | sure. | 18:26 |
| jgrimm | smoser, cool i really want to get that off the ground, but wasn't sure if either of you'd started into it at all | 18:29 |
| smoser | no. other than what i'd written there. | 18:29 |
| jgrimm | smoser, what's ETA for next cloud-init release? | 18:31 |
| smoser | i hadnt targetted one. | 18:31 |
| jgrimm | ok, we probably should for the SRU waiting in the wings? | 18:32 |
| === another_larsks is now known as larsks | ||
| harlowja | prometheanfire are u the main gentoo person? | 20:36 |
| harlowja | prometheanfire if so, got any time to look at https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+ref/kill-brpm | 20:36 |
| harlowja | just preferring to use a single spec file... | 20:36 |
| harlowja | makes things a little bit simpler... | 20:37 |
| harlowja | though i can say i didn't merge in the packages/suse/cloud-init.spec.in stuff; so there might be a tiny bit of work | 20:38 |
| === nacc_ is now known as nacc | ||
| prometheanfire | harlowja: I suppose so | 20:45 |
| prometheanfire | harlowja: do you have a diff? | 20:46 |
| harlowja | ya, let me get one | 20:46 |
| prometheanfire | the files modified doesn't look like I'd care | 20:46 |
| prometheanfire | I treat it like a python package | 20:46 |
| prometheanfire | a somewhat special one (due to having to run a script iirc) | 20:47 |
| prometheanfire | https://github.com/gentoo/gentoo/blob/master/app-emulation/cloud-init/cloud-init-0.7.8-r1.ebuild#L66-L86 | 20:47 |
| prometheanfire | that's how I install | 20:48 |
| prometheanfire | someone should look at https://code.launchpad.net/~prometheanfire/cloud-init/+git/cloud-init/+merge/307969 too :P | 20:48 |
| harlowja | prometheanfire so the part that might bother u is that i dropped the suse spec file, lol | 21:08 |
| prometheanfire | harlowja: I'm not suse :P | 21:08 |
| harlowja | oh | 21:08 |
| harlowja | nm then | 21:08 |
| harlowja | lol | 21:08 |
| prometheanfire | hwoarang might | 21:09 |
| harlowja | kk | 21:09 |
| === rangerpb is now known as rangerpbzzzz | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!