[00:02] <smoser> hm.. 
[00:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:12] <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:13] <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:14] <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:15] <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:16] <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:17] <smoser> you dont explicitly need the kwargs portion
[00:17] <smoser> of that MP.
[00:17] <smoser> right ?
[00:18] <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:19] <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:28] <smoser> ok. pushed.
[00:28] <smoser> thanks 
[00:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:54] <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
[10:28] <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..
[14:10] <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:11] <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:12] <smoser> hopefully that'd get us to buildroot-2014.08
[14:15] <m01> hey
[14:16] <m01> hmm
[14:27] <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:28] <m01> if cloud-init requires nova to stage that template in, then I guess I need to take it up with the openstack community?
[15:36] <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:37] <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:38] <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:39] <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:42] <m01> and yes, I agree that's a silly format..
[15:55] <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:56] <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:57] <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
[16:01] <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:02] <m01> smoser: which code are you looking at?
[16:02] <smoser> nova/api/metadata/base.py
[16:03] <smoser> bah. someone busted that.
[16:09] <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:10] <m01> nova.conf:#injected_network_template=/usr/share/nova/interfaces.template
[16:10] <m01> hmmmm
[16:14] <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:15] <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:51] <m01> hmm
[16:51] <m01> I uncommented that, restarted all nova services, and my config drive still doesn't have the file
[17:12] <m01> so, I guess it is busted
[17:49] <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:50] <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:51] <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:52] <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:53] <harmw> :>
[17:54] <harlowja_> :)
[17:55] <harmw> smoser: https://code.launchpad.net/~harmw/cirros/cirros-buildroot-2014.02 
[19:29] <harmw> smoser: new c-i tag
[19:29] <harmw> when! :p
[19:30] <smoser> we're closer .
[19:31] <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