| smoser | hm.. | 00:02 |
|---|---|---|
| smoser | for virtual nics. the hotplug network item should trigger the cloud-init query to MD | 00:03 |
| smoser | and then ifup and away we go. | 00:03 |
| smoser | for physical... | 00:03 |
| smoser | i dont know | 00:03 |
| JayF | physical in our world, we'd add a vlan to a trunk, and somehow send a signal in out of band | 00:03 |
| JayF | this is still in the hand-wavy portions of planning | 00:03 |
| JayF | hence the hand waving | 00:04 |
| smoser | yeah | 00:04 |
| smoser | well, in physical world it could also be "ok, configure that nic now" | 00:04 |
| smoser | (that was previously un-configured). | 00:04 |
| JayF | how does cloud-init know to check? | 00:04 |
| JayF | you'd have to have something persistent or cron'd to check | 00:04 |
| smoser | but yours is an interesting case for thought also. essentially "hot plug vlan". | 00:04 |
| JayF | because no event to the host, like hotplugging | 00:04 |
| JayF | yup | 00:04 |
| smoser | right. i wouldn't want to do cron. we could... but | 00:04 |
| JayF | this is explicitly "I want you to do something without you having any other indication you should do it other than me telling you" | 00:05 |
| JayF | which seems out of cloud-init scope a little | 00:05 |
| smoser | we could long-poll | 00:05 |
| smoser | i'd not be completely opposed to that. | 00:05 |
| JayF | do you want a model, ever, where cloud-init runs forever? | 00:05 |
| smoser | in the past i've very much said "cloud-init is init". | 00:05 |
| JayF | yeah that was my impression as well | 00:06 |
| smoser | but it seems less of a stretch here because i *want* to be able to handle the event driven portion | 00:06 |
| JayF | smoser: btw, you should really merge the branch I pointed you at earlier. Nasty nasty bug. | 00:06 |
| smoser | udev hotplug -> cloud-init-query of MD -> ifup | 00:06 |
| JayF | smoser: something I was hunting for a while :) | 00:06 |
| smoser | which branch ? | 00:06 |
| smoser | i might have missed it. | 00:06 |
| smoser | so what i was saying is that since i want cloud-init to have code to do the hotplug based on an event , i'm not entirely opposed to somethign in cloud-init's source code being the source of the event. | 00:07 |
| smoser | or you coudl have an agent that generated the event to cloud-init. | 00:07 |
| JayF | 14:43:32 <JayF> smoser: harmw: harlowja_a*: https://code.launchpad.net/~jason-oldos/cloud-init/bug-1338614/+merge/234749 should fix 1338614. I was unable to | 00:08 |
| JayF | run tests due to local enviornment problems but will run them as soon as my VM recovers :) | 00:08 |
| JayF | If we run an agent, it'll be an agent smart enough to do everything | 00:08 |
| smoser | i thought i had fixed that | 00:08 |
| JayF | Like I said, I can't get my bzr to HEAD, so it's possible you did | 00:08 |
| JayF | but it's absolutely broken in the current release | 00:08 |
| JayF | or at least what I'm building against, which I think is current release | 00:09 |
| smoser | how can you "not get your bzr to head" | 00:09 |
| JayF | I'm at 'revno 1009' according to my cloud-init, and that's with the two commits I wrote today | 00:09 |
| JayF | I want the equivalent of 'git pull' or 'git reset --hard origin/master' | 00:10 |
| JayF | I can't get bzr to just give me a clean working copy of HEAD | 00:10 |
| smoser | well you could just : bzr branch lp:cloud-init | 00:12 |
| smoser | again | 00:12 |
| smoser | or bzr pull --overwrite | 00:12 |
| smoser | that git reset --hard | 00:12 |
| JayF | the bzr branch command didn't work | 00:12 |
| smoser | bzr branch lp:cloud-init | 00:12 |
| smoser | did not work ? | 00:12 |
| JayF | it didn't appear to do anything to my current working copy | 00:13 |
| JayF | bzr pull --overwrite is exactly what I wanted | 00:13 |
| JayF | smoser: that bug exists in HEAD :( | 00:13 |
| smoser | irght. | 00:14 |
| smoser | bzr branch lp:cloud-init | 00:14 |
| smoser | is equivalent to | 00:14 |
| smoser | git clone git://foo.git | 00:14 |
| smoser | so in a working copy, you probably got a new cloud-init/ dir underneithy | 00:15 |
| JayF | aha | 00:15 |
| JayF | that's exactly what it did | 00:15 |
| JayF | okay I understand a bit better now | 00:16 |
| JayF | I just like after I push something being able to get my working copy back to 'master' | 00:16 |
| smoser | you dont explicitly need the kwargs portion | 00:17 |
| smoser | of that MP. | 00:17 |
| smoser | right ? | 00:17 |
| JayF | Locally it didn't work until I had that | 00:18 |
| JayF | and that was suggested by someone smarter than I (comstud) | 00:18 |
| smoser | hm.. | 00:18 |
| JayF | I know that I had not-working. Apply that patch, it works. Apply that patch sans **kwargs on the function signature, and it fails | 00:19 |
| smoser | ok. pushed. | 00:28 |
| smoser | thanks | 00:28 |
| smoser | JayF, the idea of "add a vlan" is interesting as itself. | 00:31 |
| smoser | as i dont have anything that would generate such an event. | 00:31 |
| smoser | ie, for virtio ethernet . i could see getting the nic added, and cloud-init reading the config and the config saying "make a vlan" and cloud-init configuring correctly. | 00:32 |
| smoser | but the core event was the nic added. | 00:32 |
| JayF | yeah that's what I'm saying | 00:32 |
| JayF | in bare metal, no hypervisor, it takes a physical action to generate a hardware event | 00:32 |
| JayF | or much fancier bmcs than I have :) | 00:32 |
| JayF | [insert hypervisors are for the weak joke here] | 00:33 |
| smoser | ok. so i have to think about that some more. | 00:33 |
| smoser | have you ever used hackpad ? | 00:33 |
| smoser | https://hackpad.com/Cloud-init-Networking-1gtK434RgVg | 00:33 |
| smoser | that seemed like a bit more mark-uppy version of etherpad. dont know how i feel | 00:33 |
| smoser | but i put some headers in there. | 00:34 |
| smoser | i have some content too , but is all very rough | 00:34 |
| smoser | i just can't stand typing in anything other than vi | 00:34 |
| JayF | ever looked at floobits? | 00:34 |
| JayF | their vim plugin is... lacking | 00:34 |
| smoser | i'd not seen that. | 00:35 |
| smoser | no content there :) | 00:35 |
| JayF | yeah I can tell now, lol | 00:35 |
| smoser | i was trying to write how i'd want stuff to work | 00:35 |
| smoser | basically, | 00:36 |
| JayF | my answer to that, more or less, is 'well' and 'reliably' | 00:36 |
| smoser | cloud-init-local comes up, and blocks hotplug events until its done. | 00:36 |
| JayF | hehehe | 00:36 |
| smoser | once its done, it "releases" the nic that it deemed (or found in a local datasource) to be the "metadata service link" | 00:36 |
| smoser | then once that comes up | 00:37 |
| smoser | all the others are un-blocked | 00:37 |
| smoser | and they come up via getting information from the MD. | 00:37 |
| JayF | I was thinking more that | 00:37 |
| smoser | in the case of no network MD, and only provided by config-drive, the "releasing" of those blocked events would then cause read from that cached data | 00:37 |
| JayF | you'd add a new stage to cloud-init | 00:38 |
| smoser | and they'd come up too | 00:38 |
| JayF | that's possibly persistent | 00:38 |
| JayF | that handles post-boot events by re-running the relevent part of the other stage | 00:38 |
| JayF | i.e. network json changed; call that module to regenerate network from md service | 00:38 |
| smoser | i'd liek to not just have "network json changed" | 00:39 |
| smoser | but "nic AA:BB:CC:DD:EE:FF added" | 00:39 |
| smoser | rather than determining what changed. | 00:39 |
| JayF | see I think there are dragons there | 00:39 |
| JayF | because by doing it that way you *are* determining what changed | 00:39 |
| JayF | or requiring someone outside of cloud-init to give you a specific trigger | 00:40 |
| JayF | if you're doing a long poll on a md service | 00:40 |
| JayF | you'll be able to quickly know what changed | 00:40 |
| smoser | right. | 00:40 |
| smoser | unles sthe long poll is given explicit updates | 00:40 |
| smoser | ie, rather than just getting a new version of the json | 00:40 |
| JayF | but the idea of trying, on the fly, to 'diff' the old and new config in some meaningful way seems scary | 00:40 |
| smoser | it would get the element that changed. | 00:40 |
| JayF | yeah but then you've introduced a second api interface | 00:40 |
| JayF | one for init and one for ongoing | 00:40 |
| smoser | yeah. | 00:41 |
| JayF | which I personally dislike | 00:41 |
| smoser | well, only added the second api | 00:41 |
| smoser | because there was not an event | 00:41 |
| smoser | so we had to essentialy receive the event | 00:41 |
| smoser | but then i guess what happens if you miss it | 00:41 |
| smoser | so it would be good to determine what changed. | 00:41 |
| smoser | and *that* is easy enough , at least its seemingly possible. | 00:42 |
| smoser | but figuring out what that means in terms of 'ifdown X, ifup Y' is more complex. | 00:42 |
| JayF | I'd say roughly determine what changed | 00:42 |
| JayF | like in categories | 00:42 |
| JayF | like 'ssh keys changed, kickoff add_ssh_keys module' | 00:42 |
| JayF | 'network changed, kickoff network module" | 00:42 |
| JayF | etc | 00:42 |
| smoser | ah. i wasn't goign to go that far. | 00:43 |
| JayF | then you make the ability to update part of each module | 00:43 |
| smoser | i was only going to take events on network config. | 00:43 |
| JayF | they can either do everything over again or just generate a diff | 00:43 |
| JayF | why not go the whole way? | 00:43 |
| JayF | why not accept an event saying "you have a new cinder volume that wants to be mounted" | 00:43 |
| smoser | well, some are not idempotent. | 00:43 |
| JayF | assuming cloud-init would know how to react to some things | 00:43 |
| JayF | make modules opt in to being event-driven and wrk to make the modules idempotent | 00:44 |
| JayF | anything in config management (cloud init kinda is) should strive to be idempotent where possible anyway imo | 00:44 |
| smoser | i dont have strong feelings against what you're syaing. | 00:45 |
| smoser | but i'd like to have networking first :) | 00:45 |
| smoser | as i think that is where we *need* a solution | 00:45 |
| JayF | yes, I would like to have networking too | 00:45 |
| JayF | I need to get those changes written and up :x | 00:45 |
| smoser | the rest of it, i think ihave a fair argument in "let something else do that" | 00:45 |
| JayF | well, edited and up, mostly | 00:45 |
| JayF | yeah, but the thing is | 00:45 |
| smoser | but nothing else really plays in the automatically-configure-hot-plug-netowrking world. | 00:46 |
| JayF | *someone* is going to want a conduit for setting up arbitrary things via event | 00:46 |
| JayF | and if cloud-init doesn't do it, someone will | 00:46 |
| JayF | and I'm trying really hard to not be someone | 00:46 |
| smoser | well, there are lots of things that do that arlready. | 00:46 |
| JayF | lol | 00:46 |
| smoser | juju does it | 00:46 |
| smoser | puppet does it | 00:46 |
| smoser | rackspace guest agent does it/ | 00:47 |
| JayF | Nothing does it from the perspective of a provider | 00:47 |
| JayF | ugh, lets not bring nova-agent into this :( | 00:47 |
| JayF | I try to forget it exists and have success most days | 00:47 |
| smoser | so i kind of see the network stuff as cloud-init's job . | 00:47 |
| JayF | but like "mount me a network volume at boot" doesn't fit? | 00:48 |
| smoser | but beyond that, i struggle. | 00:48 |
| smoser | well at boot, that is there. | 00:48 |
| JayF | then just add general support for event-driven do stuff | 00:48 |
| JayF | and maybe a certain JayF would end up writing the event provider for cinder | 00:48 |
| smoser | how would we get an event on cinder ? | 00:48 |
| JayF | I'd presume we'd model drives to mount as an object in user_data+vendor_data | 00:49 |
| smoser | oh. duh. | 00:49 |
| smoser | sorry | 00:49 |
| smoser | well, there is a dataformat for mounts and what to do with mounts in cloud-init as it is. | 00:49 |
| JayF | so lets imagine rackspace, we'd just update vendor_data.json to add ['volumes']['my_fancy_volume'] = { 'place': '/data | 00:49 |
| JayF | you get the idea | 00:49 |
| smoser | it just only fires on those in the block-device-mapping. | 00:49 |
| smoser | so it would be very annalogus to networking solution | 00:49 |
| smoser | to have it respond to the newly attached disk | 00:49 |
| JayF | so if you saw that piece of data change, you'd trigger an event to revaluate that data | 00:49 |
| JayF | exactly | 00:50 |
| smoser | and hit the MD for "what should i do with that" | 00:50 |
| JayF | everything fits this model fairly well | 00:50 |
| smoser | so yeah | 00:50 |
| smoser | ok. you sold me there on that. | 00:50 |
| smoser | but i'm not sold on ssh keys yet :) | 00:50 |
| JayF | ssh keys is my personal #1 use case | 00:50 |
| JayF | because nova (or Rackspace Cloud, IDK the difference) only lets you inject one in the nova boot command | 00:50 |
| JayF | so the ability to trigger more keys gettting added post-boot seems nice | 00:51 |
| JayF | and I know of at least one group in Rackspace that's doing something that'd fit this workflow, but in a more gross way | 00:51 |
| harlowja_ | hmmmm, seems like a job for mr.puppet or mr.chef | 00:51 |
| JayF | again though, I'm not the owner of the node | 00:51 |
| JayF | I'm just the service provider trying to make my customer click pretty buttons in a panel and make things happen | 00:51 |
| smoser | monkeyspeere | 00:51 |
| smoser | http://web.monkeysphere.info/getting-started-ssh/ | 00:52 |
| JayF | smoser: a google of that takes me here first http://www.cracked.com/article_14990_what-monkeysphere.html | 00:52 |
| JayF | smoser: which was really perplexing, hahaha | 00:52 |
| JayF | smoser: that's amazing | 00:52 |
| JayF | This was a good chat, thanks :) I may be away mostly for a couple of days, but I'll be back | 00:54 |
| smoser | i was thinking that monkeyspehere had something to manage keys installed | 00:54 |
| smoser | but i guess not | 00:54 |
| smoser | anyway | 00:54 |
| smoser | later JayF thanks for you patch and your patience | 00:54 |
| === praneshp_ is now known as praneshp | ||
| === harlowja_ is now known as harlowja_away | ||
| === shardy_z is now known as shardy | ||
| m01 | smoser: remember my networking issue yesterday (only my first ethernet connection is setup)? I looked at the OpenStack nova sourcecode. They do have a template for the interfaces file, but it looks like it's only used for bare metal targets (e.g. PXE-booted nodes), it doesn't appear to be used in general.. | 10:28 |
| === zz_gondoi is now known as gondoi | ||
| smoser | m01, you appear to be correct. | 14:10 |
| smoser | it definitely does that in some cases. | 14:10 |
| smoser | its not only for bare metal. | 14:10 |
| smoser | harmw, https://code.launchpad.net/~smoser/cirros/buildroot-upgrade | 14:11 |
| smoser | i think that builds for i386 | 14:11 |
| smoser | running bin/bundle now | 14:11 |
| smoser | hopefully that'd get us to buildroot-2014.08 | 14:12 |
| m01 | hey | 14:15 |
| m01 | hmm | 14:16 |
| m01 | Are you saying that nova uses the /etc/network/interfaces template in environments other than baremetal? | 14:27 |
| m01 | (e.g. libvirt, kvm etc) | 14:27 |
| m01 | if cloud-init requires nova to stage that template in, then I guess I need to take it up with the openstack community? | 14:28 |
| smoser | how did you detemrine that it does not do that ? | 15:36 |
| smoser | it was not clear to me. | 15:36 |
| smoser | the interface that it uses right now is silly... it declares networking configuration in /etc/network/interfaces format. | 15:36 |
| smoser | which is very limited and guest-specific | 15:36 |
| smoser | we're wanting to do it in a more generic way. that is something that JayF is working on and pquerna also. | 15:36 |
| smoser | see https://review.openstack.org/#/c/85673/ | 15:37 |
| m01 | so I looked in the config drive, and didn't find it there (see http://pastebin.com/p3PLXjvj) | 15:37 |
| m01 | and then I went and looked at the nova code | 15:38 |
| m01 | https://github.com/openstack/nova/search?utf8=%E2%9C%93&q=net-dhcp&type=Code | 15:38 |
| m01 | that's the search for net-dhcp.ubuntu.template | 15:39 |
| m01 | which is here: https://github.com/openstack/nova/blob/master/nova/virt/baremetal/net-dhcp.ubuntu.template | 15:39 |
| m01 | I believe that's the file you're referring to, and that you're expecting in the config drive, right? | 15:39 |
| m01 | I only found that in the baremetal directory under virt, and I didn't spot anything equiavelent for the other "drivers", or whatever they're called | 15:39 |
| m01 | and yes, I agree that's a silly format.. | 15:42 |
| JayF | m01: you really shouldn't be using nova-bm at this point | 15:55 |
| JayF | m01: it's being deprecated in Juno in favor of Ironic | 15:55 |
| m01 | I'm not using it | 15:55 |
| m01 | I just noted that it's the only driver I've identified that actually stages the /etc/networks/interfaces file | 15:56 |
| m01 | and (therefore) I don't have one in my config drive | 15:56 |
| m01 | so my non-first network interfaces don't get IP addresses | 15:56 |
| m01 | (and I'm confused about how this is meant to work) | 15:56 |
| JayF | Ah, Ironic driver does too | 15:57 |
| JayF | at least it does in my install of it; but it's always possible we patched it downstream | 15:57 |
| m01 | I'm using libvirt anyway I think | 15:57 |
| smoser | well, we need to fix it. | 16:01 |
| smoser | i'm sorry for leading you on a goose hunt. but looking at code i dotn see why it would not get rendered. | 16:01 |
| smoser | dont obviously see why | 16:01 |
| m01 | smoser: which code are you looking at? | 16:02 |
| smoser | nova/api/metadata/base.py | 16:02 |
| smoser | bah. someone busted that. | 16:03 |
| m01 | CONF.injected_network_template | 16:09 |
| m01 | aha | 16:09 |
| m01 | interesting | 16:09 |
| m01 | let me see what that's set to | 16:09 |
| m01 | nova.conf:#injected_network_template=/usr/share/nova/interfaces.template | 16:10 |
| m01 | hmmmm | 16:10 |
| smoser | m01, its busted. | 16:14 |
| smoser | the metadata service (used by config drive or metadata server) | 16:14 |
| smoser | will never call netutils.get_injected_network_template | 16:14 |
| smoser | with a template | 16:14 |
| smoser | oh wait. | 16:14 |
| smoser | no.. yeah, so you were right. | 16:15 |
| smoser | see, not sure why it doenst work | 16:15 |
| m01 | I'll uncomment that setting | 16:15 |
| m01 | and try it | 16:15 |
| m01 | hmm | 16:51 |
| m01 | I uncommented that, restarted all nova services, and my config drive still doesn't have the file | 16:51 |
| === harlowja_away is now known as harlowja_ | ||
| m01 | so, I guess it is busted | 17:12 |
| harmw | smoser: cool | 17:49 |
| harmw | though I did some work in that area already | 17:49 |
| smoser | well this builds. just got the build. | 17:49 |
| smoser | it doesnt run particularly well. | 17:50 |
| smoser | noticing 2 things: | 17:50 |
| harmw | ok | 17:50 |
| smoser | a.) no lsblk or sfdisk | 17:50 |
| smoser | b.) dropbear is broken | 17:50 |
| smoser | doesnt start | 17:50 |
| harmw | ah | 17:50 |
| harmw | i fixed just that 2nd issue | 17:50 |
| harmw | and missing lsblk... sounds like some new BB knob | 17:50 |
| harmw | dropbear needs to be started with some other argument, iirc | 17:51 |
| harmw | please look at my branch, there should hopefully be something good in it :P | 17:51 |
| harlowja_ | http://online.mirantis.com/openstack-sv-live-feed if u guys interested | 17:51 |
| harlowja_ | from http://openstacksv.com | 17:51 |
| harmw | whats that? | 17:52 |
| harlowja_ | a sv openstack minidaysummit kind of thing | 17:52 |
| harlowja_ | if u interested | 17:52 |
| harlowja_ | with livestream | 17:52 |
| harmw | ok, so just what is sv :p | 17:52 |
| harmw | the rest was obvious :p | 17:52 |
| harlowja_ | *silicon valley | 17:52 |
| harmw | super vilain? | 17:52 |
| harmw | ah | 17:52 |
| harlowja_ | lol, super vilan | 17:52 |
| harmw | :> | 17:53 |
| harlowja_ | :) | 17:54 |
| harmw | smoser: https://code.launchpad.net/~harmw/cirros/cirros-buildroot-2014.02 | 17:55 |
| harmw | smoser: new c-i tag | 19:29 |
| harmw | when! :p | 19:29 |
| smoser | we're closer . | 19:30 |
| smoser | maybe i should just call it. | 19:31 |
| harmw | +1 | 19:31 |
| smoser | i was really hoping to get the network config in | 19:31 |
| harmw | nah, who needs networking | 19:31 |
| === gondoi is now known as zz_gondoi | ||
| === Guest72739 is now known as mgagne | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!