[00:10] i almost feel like the above bridge stuff would be fixed by just assuming things bridge to eth0 if not provided a port iface to bridge to [00:12] or maybe bridges in openstack are something different [13:02] dmsimard: what's the setup? the network_data.json you posted is an empty bridge (AFAICT); is that a running instance? if so, can you paste ifconfig ? I'd suspect that the openstack providing network_data.json is missing something [13:16] I must admit I don't 100% understand what apt_old_mirrors is for - doc isn't telling a lot and the code neither [13:16] I'll dig through the commit log for it, but if one knows that part as his best buddy please feel free to share :-) [13:24] dmsimard: I see what's going on; thanks for the test case; [13:26] cpaelzer, when the image is built, you can/probably-should leave apt's '/var/lib/apt/lists/' around [13:26] that way, the next time someone 'apt-get update' they dont have to pull 20M or whatever it is of data that hasnt changed (the release pocket at least). [13:26] smoser: thanks, but you are jumping to the decision - I wanted to understand what it is actually for [13:27] other than "renaming" I don't see what it really does (by my lack of apt knowlegde about that subdir) [13:27] but since cloud-init picks / writes a different mirror, then your *new* apt-get update is going to miss all that cache [13:27] ah [13:27] so it renames files from the old mirror name to the new mirror name [13:27] but you have to know the old mirror (or at least i allowed you to configure that) [13:27] that makes sense, so if old/new have lot of same content it will not pull all of it then [13:28] probably you could figure it all out and dtrt, or possibly it was more difficult to do that. [13:28] I'd drop this feature (apt_old_mirror) then [13:28] ? [13:28] oh. yeah, out of curtin. [13:28] drop [13:28] exactly - thanks for the explanation [13:28] is that waht you meant ? [13:28] it is useful for cloud-init still [13:28] yep [13:29] although i admittedly don't know if it ends up being used [13:29] oh I understand the cloud-init use case now that I understand what it really does :-) [13:29] the cloud-images may actually have apt-get clean run on them [13:29] I can tell you that the doc is rather ... nonexisting [13:29] that is pointless [13:29] it isn't even listed in examples or such [13:29] as anything in the release pocket is static so you should really never throw that away [13:29] :) [13:29] well, some things aren't really made to be configured. [13:30] clearly documentation is good. and severlely lacking. === sterfield_ is now known as sterfield [13:30] but that is'nt really something that a end user would be expected to configure. so its less important. [13:30] its just configurable rather than having a hard coded value [13:40] cpaelzer, https://code.launchpad.net/~paelzer/cloud-init/test-apt-source/+merge/294521 has merge conflicts [13:41] and did you think at all about the sucky fact that curtin and cloud-init's merging algorithms differ by default ? [13:44] smoser: I did think about the sucky fact (that sounds wrong) and decided to not overhaul any majore piece especially since it would change behaviour [13:44] smoser: but - I added it right away in the example [13:45] smoser: so that anybody that starts at doc/examples would be made aware that to get an equivalent mergeing he would need to set it [13:45] smoser: merge conflicts in bzr is the same as in git - i.e. something else got merged that now conflicts - right ? [13:46] yeah. [13:46] bzr merge ../trunk [13:46] bzr conflicts [13:46] bzr resolve foo [13:48] smoser: I'll look into it and (try to avoid) hate bzr :-) after I finished my config example for curtin [13:48] smoser: will upload updates later on then (hoepfulyl no too complex conflicts) [14:12] cpaelzer, fwiw, i just checked in a xenial container and the image *does* have /var/lib/apt/ populated, so that cloud-init's renaming those should result in not having apt-get update re-download static data. === rangerpbzzzz is now known as rangerpb [14:28] smoser: cool will look into that, but I'd expect for curtin to only hardcode the paths then (no config option) [14:30] cpaelzer, you can drop that from curtin if you'd like [14:31] it is probalby useful [14:31] but a small-ish optimization compared to installing an operating system [14:43] dmsimard: https://code.launchpad.net/~raharper/cloud-init/trunk.network-data-bridge/+merge/295591 [14:45] rharper: what do you need to know for linuxbridge ? What a network_data.json looks like with multiple networks and ports? [14:45] dmsimard: yeah [14:45] I can get you that. [14:45] and if it sets any bridge properties [14:46] under the link section [14:46] Well, the json I provided is a linuxbridge environment so I'm not sure what else could be there [14:46] currently in that patch I'll copy in any keys that start with bridge; the rackspace config I've seen had bond related stuff that I've not seen elsewhere and vlan'; but I lack a deep list of network_data.json examples from real clouds [14:47] dmsimard: you can set things like bridge_stp, bridge_fd, bridge_hello [14:47] the most interesting would be a set of interfaces to add to the bridge [14:47] Hmm, perhaps mgagne would have something for bonded networks [14:47] I've got a good bond example from rackspace a while back; but others are welcome [14:48] Yeah Rackspace tends to do things slightly differently, it's best not to rely just on them [14:48] sure [14:49] I'll get you a config drive with multiple networks and ports later [14:50] thanks! [15:56] smoser: once the conflicts are understood and fixed in the file - do I do bzr commit followed by bzr resolve - or will bzr resolve alone be what I want? [15:57] docu reads like the second [15:57] bzr resolve [15:57] and then bzr commit [15:57] smoser: thanks [15:58] ah in the log I see now how this works (hopefully) [15:59] it is not rebasing mine onto current upstream (like git) but adding a merge commit on top of mine so that they match again in that regard [15:59] at least that is how it looks like and that also explains why the diff of that last commit was so big it was the delta of the merge essentially [16:07] smoser: is there anything I can do to help with bug #1577982 ? [16:23] mgagne, i have told some people that i'll have something in yakkety by eod my friday. [16:25] cool, thanks for the follow up [16:27] mgagne, would you be able to consume a branch for me ? [16:27] if i send you a link ? [16:28] (i dont have it now, but if i point you at a bzr branch woudl you be able to test that or do you need a ppa ? or .... how can i get you to help me on this) [16:28] smoser: I don't know how to build from bzr [16:29] would a ppa build be sufficent ? [16:30] yes [16:30] ok. thanks. i'llj ust ping you here when i have somethign [16:30] sure, thanks! [17:06] rharper yt [17:43] harlowja: here [17:57] hey, so i was running dmsimard example openstack network json file through https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7 (updated) [17:58] but am wondering what your expected parts for bridges are [18:05] dmsimard was going to see about getting another example with multiple networks and such; [18:05] k [18:05] yeah I haven't got around to it yet [18:06] extinguishing some fires first [18:06] i can make the bond stuff work, just when i run that [18:06] harlowja: but what I was looking for was whether there would be additional bridge_ options set in the link [18:06] https://gist.github.com/harlowja/358358fc41685874a12f4db809504c19 [18:06] harlowja: I have a bond example from rackspace if you're interested [18:06] hmmm, bridge doesn't have the params the network_state.py stuff seems to require [18:06] maybe shouldn't be required? [18:06] harlowja: I posted a MR with the fix [18:06] MR? [18:07] mapreduce [18:07] lol [18:07] bah [18:07] MP [18:07] dmsimard: https://code.launchpad.net/~raharper/cloud-init/trunk.network-data-bridge/+merge/295591 [18:07] k [18:07] I hadn't see a network_data.json with type: bridge before [18:14] rharper: ok, getting you that network_data.json now. [18:15] rharper: eta ~40 mins or so while the environment is spawned [18:16] dmsimard: cool [18:40] smoser good to go with https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957 ? [18:42] what is usedevelop ? [18:42] and i can't use py26 by default. [18:42] as there simply isn't a py26 anywhere on ubuntu :) [18:43] that's ok :-P [18:43] other than 'deadsnakes' [18:43] usedevelop just is a time saving thing, in that it doesn't do a full pip install of cloud-init [18:43] but uses symlinks [18:43] i can remove that if needed [18:43] and you're using some magic for tox that is i think not available in 14.04 [18:43] shouldn't matter [18:43] the 'py26' magic [18:43] ?? [18:44] hm.. maybe not [18:44] http://tox.readthedocs.io/en/latest/config.html#confval-usedevelop=BOOL [18:44] odd [18:44] i can turn that off though, not that big of a deal [18:44] yeah, that doesnt' seem too bad. [18:44] but why chage 'python -m nose' to nosetests ? [18:44] i think we adtually want {basepython} -m nose [18:45] think that didn't work on 26 [18:45] let me double check [18:46] $ python -m nose [18:46] /home/jxharlow/.venv/bin/python: nose is a package and cannot be directly executed [18:46] maybe this was something special on 2.7 + ? [18:47] probably. but how did you drop the tesenv:py26 [18:47] kk, i can just add the special case for 26 [18:49] reposting in a sec [18:57] ok, reposted, and py26 still work, so goodie [18:58] and 27 it seems to, so even better [18:58] :-P [18:58] https://github.com/harlowja/remote_tox (my tool for testing these on different envs) === mfisch is now known as Guest92937 === Guest92937 is now known as mfisch [19:21] harlowja, so far in curtin we've even staye daway from xi [19:21] six [19:21] xi = 11. :) [19:24] harlowja, you dropped if PY26 ? [19:24] i'm not opposed to being *able* to run tox -e py26 [19:25] i just cant have it in the default 'tox' [19:25] as then it errors because ENOINTERPRETER and you can't distinguish that as easily from ETESTFAIL [19:26] smoser unittest2 seems to handle that all just fine for tests [19:26] oh. i see. [19:26] so no more need for crazy if PY26: [19:27] will take 26 out of default tox list [19:33] harlowja, some 'from cloudinit import in cmdline.py' [19:33] with better quoting that might make sense. [19:33] harlowja, some 'from cloudinit import' in cmdline.py [19:33] and would we not want 'from . import' ? [19:33] or is that a py27 thing too [19:34] just a thing that i guess is something i've gotten used to from openstack land [19:34] what do you mean ? [19:34] http://docs.openstack.org/developer/hacking/#imports [19:34] i've always thought releative imports a little pita, i guess openstack folks do also, so ya, idk [19:34] why? [19:35] less clear i think (in my view) [19:36] but maybe its from my java days, idk [19:36] lol [19:37] but if we want to just say meh, that's fine also [19:37] well, if we're expecting to be able to 'export' that module so that it is free of cloud-init, then 'import cloudinit' is kind of a fail path [19:38] fixed via tiny little script :-P [19:38] replace 'from cloudinit.net' --> 'from .net' [19:39] could just make that thing a lib in the first place :-P [19:39] :-P~ [19:40] * harlowja is trying to shutdown a openstack project that did this kind of copy/paste for years, lol [19:40] finally getting rid of it, lol [19:40] rharper: hai [19:40] https://gist.github.com/dmsimard/d5b14f5cba05307a3008315d11520e26 [19:40] into its own proper library ? [19:40] ya [19:40] full disk.config = https://dmsimard.com/disk.config [19:40] many proper libs [19:41] harlowja: ^ multi-network/multi-port vm [19:41] the project i'm a PTL of started off with this copy/paste junk [19:41] dmsimard nice [19:41] complex examples ftw [19:41] with bridges :-P [19:41] that was surprisingly harder to set up than I thought, the deployment we're testing only has one network, not two [19:41] so I had to do some fiddling by hand [19:41] ya, i'm hoping the sysconfig stuff i have here handles most of those [19:42] cause it gets whacky real quick, lol [19:42] smoser https://wiki.openstack.org/wiki/Oslo#Incubation [19:42] lol [19:43] I'll have that dev environment for 24 hours until it self destructs (reaped by auto reprovision) so let me know if you need anything else from it [19:43] kk [19:44] I think that gist and disk.config should have what you need [19:44] as many examples u can make would be sweet :-P [19:44] once liberty is deployed where i'm at that should help also [19:44] but the more the merrirer [19:44] that example is mitaka [19:44] k [19:53] dmsimard: thanks! [19:55] rharper: np, like I said you have 24h if you need anything else :P [19:57] dmsimard: that looks fine; the MP I posted earlier parses that just fine; I was mostly interested to see if any other bridge related parameters might get set in the "links" entries of type: bridge; they look the same here so unless you know of an Openstack that might twiddle with bridge settings like forward delay, stp or other things like that (and have a network_data.json with those values) I think we're good with th [19:57] e current MP to support things. [19:58] dmsimard: hrm, actuall, your network dump from in the guest is interesting; why doesn't the network_data.json have a the ethernet devices listed ? [19:58] ya, it almost seems like there is something missing :-P [19:59] ethernet devices, like eth0 and eth1 ? [19:59] are there ethernet devices just assumed to exist [19:59] ya [19:59] right, so I'd think we'd see bridge_interfaces = list_of_link_id's [19:59] dmsimard: right [19:59] I guess it's made agnostic through network0 and network1 [19:59] eth [19:59] but I don't know [20:00] ya, the dump of /etc/sysconfig stuff would be useful, or whatever else u got 'ifconfig' [20:00] the network describes the ip network config of the link, the link is one of 'ethernet', 'bond', 'vlan', and now 'bridge'; in the vlan and bond case, the "link" indicates if it consumes other links [20:01] harlowja: that particular VM was setup through dhcp, not with your branch of cloud init or anything [20:01] but the network_data.json and the rest of the info are relevant [20:02] http://paste.ubuntu.com/16664758/ for example this one [20:02] dmsimard: something did the bridge config there ; I think that's what's the interesting part [20:03] rharper: from what, the brctl output ? That's from the compute node, not the guest [20:03] that's handled by the neutron linuxbridge agent [20:03] ok [20:04] well, I'm somewhat confused then, what does networking look like wihtin the guest that got the network_data.json ? [20:04] let me log in to it, sec [20:04] cool [20:05] rharper: what do you want to know exactly ? which files, commands, etc [20:06] harlowja, is it appropriate to call a static method with self.methodname ? [20:06] ya [20:06] it is [20:07] ok. so you dont have to do something like self.__class__.methodname [20:07] nopers [20:07] same for class methods [20:07] smoser: in python? it's allowed in publishe documentation, i just looked this up for the importer :) [20:07] man, gonna make me cut out six :-P [20:07] dmsimard: ls -al /sys/class/net and ifconfig -a would be useful ; brctl show would be useful from within in the guest [20:08] harlowja: hehe [20:08] i knew it would work, i just didn't knwo if it was bad form [20:11] rharper: there are no bridges in the guest [20:12] :-/ [20:12] openstack is weird [20:12] lol [20:12] right, I didn't think so; but the network_data.json is supposed to be exported into the guest; it appears then like the ovs type; type bridge should be interpreted as a ethernet ... I wonder why it's emitting type bridge with it's not creating one in the gues ? [20:12] harlowja: I think the network_data/metadata is partially implemented [20:13] possible, https://github.com/openstack/nova/blob/master/nova/virt/netutils.py#L172 is the code for this [20:13] but ya, i'm unsure if its busted or missing stuff (especially for bridges?) [20:13] rharper: why are you expecting bridges inside the guest ? [20:13] the previous example, and the rackspace one which does bonds of ethernet devices and adds vlans is functional [20:13] the guest has eth0, that's it, there's no bridges to be had [20:13] dmsimard: because the linkls type is bridge, this is what the guest would get in the network_data.json [20:14] dmsimard what OS ? [20:14] the vtap is bridged on the compute node [20:14] ie, "make me a bridge" [20:14] if its rhel, i can tell u why its not implemented :-P [20:14] (cause the gist i have is that impl, lol) [20:14] the networking on that VM wasn't setup by cloud init, it was setup by dhcp [20:14] I know, I'm the one poking you about rhel/centos support ;p [20:14] dmsimard: I'm aware of how the host networking and VM networks are configured; I'm trying to understand why the network_data.json would say type: bridge when it's really just type: ethernet (aka, do dhcp on the guest ethernet device) [20:15] rharper: some guest info https://gist.github.com/dmsimard/d5b14f5cba05307a3008315d11520e26#file-guest-info-txt [20:15] dmsimard: right, network_data.json can be used to confer a network configuration into the guest [20:15] rharper: the network_data.json wasn't used by cloud-init to configure networking [20:15] ie, emit a network config dynamically in the guest, it could be , run dhcp on eth0, or configure eth0 and eth1 as a bridge, etc. [20:15] so I don't know if cloud-init would have done anything [20:15] it does now [20:15] not for centos :p [20:16] right, which we're trying to fix [20:16] harlowja 's branch and all [20:16] though, I *can* spin a ubuntu vm [20:16] with the same network config [20:16] if you'd like [20:16] it won't matter [20:16] ya, don't try centos, ha ;) [20:17] the concern is that the openstack metadata is saying the links for the guest are type bridge, which the back end of the device (bridge on the host, or tap pair) doesn't matter; the guest has a virtual nic, and it should run dhcp; so we can either assume that type: bridge means an ethernet device in the guest (likew do for type: ovs) [20:17] bah, I've got relocate bbiab [20:19] type bridge is probably where you would see type ovs ? [20:19] so it probably just stands for "this is a linuxbridge type thing, not an ovs type thing" [20:19] * dmsimard shrugs [20:21] ya, so maybe the bridge isn't what we think a bridge is, lol [20:25] pretty sure it can be safely ignored [20:26] Let me chime in: I can tell you definitely it can be ignored. The guest doesn't care if the underlying l2 infrastructure is using ovs, linuxbridge, or something else. From the perspective of the guest, it's just an interface. [20:26] more than that, the whole links part is probably not relevant [20:26] unless, I don't know, it's a baremetal use case or something like that [20:27] I don't know much of cloud-init usage beyond openstack VMs [20:27] mgagne: are ironic machines using cloud-init for the network config ? (bonding, vlan, etc) [20:28] ya, there's already code that discards the various types, but weird that it exists in the first place :-P [20:28] dmsimard, there are [20:28] not trunk cloud-init at the moment, but we do hope to have that [20:28] smoser: have what ? [20:29] rackspace baremetal use cloud-init and config-drive in bare metal systems for network [20:29] dmsimard: I think network config is via puppet. I guess mgagne can confirm... [20:29] dmsimard: yes, there is no other way around for centos7, can't read complex debian bonding config [20:29] but they use out of tree. [20:29] Oh, well, there you go. [20:29] we would like to have that functional all in cloud-init proper [20:29] ok, I wasn't sure if it was done by IPA or cloud-init, now we know :) [20:29] we don't use puppet in customer's instances [20:29] hold on [20:29] reading backlog [20:30] just to make sure I'm answering the right question [20:30] is mgagne rackspace ? [20:30] I'm Internap [20:30] or iWeb [20:30] JayF, woudl knwo more about the rackspace for sure. [20:30] You should be careful telling people I know things [20:30] we talking about baremetal delivered to customers? [20:31] You'll just lead them to disappointment :) [20:31] me and mgagne know each other already [20:31] natorious: do you have the link to our cloud-init fork for mgagne to check out? [20:31] mgagne: I guess the question is more around.. is the "links" part of the network_data.json relevant at all -- It doesn't seem to be for guest virtual machines (since it's l2 knowledge from the compute node) but we were wondering if it was relevant for bare metal. [20:31] https://github.com/jayofdoom/cloud-init-fedora-pkg ? [20:32] mgagne: i.e, referring a linuxbridge network_data.json from mitaka: https://gist.github.com/dmsimard/d5b14f5cba05307a3008315d11520e26#file-network_data-json [20:32] mgagne: no, the one we're using now is in bazaar, natorious will know where it is [20:32] :) [20:32] some day. we will be done of czr [20:32] bzr [20:32] i promise [20:32] dmsimard: what specifics of links are you referring to? [20:32] mgagne: would something like bonding be represented there, for example ? [20:32] its https://code.launchpad.net/~nathan-house-0/cloud-init/cloud-init [20:33] the pkg build scripts are all linked to the working bzr branch so you would want to fork it if your planning on doing distro builds [20:33] https://bugs.launchpad.net/cloud-init/+bug/1577982 [20:33] harlowja, https://code.launchpad.net/~harlowja/cloud-init/cloud-init-fix-test-times/+merge/294854 [20:33] http://paste.openstack.org/show/498744/ [20:33] content is here [20:33] you did not remove nose-timer [20:34] let me check [20:34] hold on [20:34] Im not sure it's the right ocntent [20:34] smoser oh, working on it :-P [20:34] nope, not the right one it seems [20:34] that's strange, I thought it was bonding [20:35] ok, let me get one [20:35] is it safe to move keys back and forth between userdata and cloud.cfg? [20:35] or if not, how can I make things that I would normally write in userdata happen regardless of userdata? [20:36] ok, issue wasn't with bonding, just ubuntu16.04, wrong bug [20:38] mgagne, if you want see what i'm thinking: http://paste.ubuntu.com/16665427/ [20:43] dmsimard: ok; I think we have two cases for when network_data.json is being used; in your case; (as with the ovs case I've seen) the network metadata refers to how the computenode has configured networking; bridge, or ovs; however, it's not currently exporting any guest configuration (though it could, for example instead of ipv4_dhcp; it could be ipv4 and emit the static ip config it wanted to assign). I'll rework th [20:43] e MP to treat the type: bridge like type:ovs, which is to say that we will not attempt to assemble a bridge in the guest, rather each link of type: bridge means we have an ethernet device [20:43] rharper: mgagne gave me http://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html#rest-api-impact [20:43] It looks like a good sample [20:44] dmsimard: yeah, and notice it doesn't have the linuxbridge example you have [20:44] and https://github.com/openstack-infra/glean/blob/master/glean/tests/fixtures/liberty/mnt/config/openstack/latest/network_info.json [20:44] but I think the right of it is as I stated above; for type: ovs and type: bridge, we merely need to translate that to ethernet interfaces in the guest (rather than attempting to assemble a device of type: X in the guest) [20:45] now that's contrasted with the other types which is somewhat in conflict if network_data.json is meant to describe the guest network [20:45] so, I'm not 100% clear on what the right thing is if in the future we wanted to describe how to configure a bridge in the guest with the ethernet devices on the VM [20:46] there is no bridge on the guest [20:46] right [20:46] I understand that; [20:46] anything related to bridge is leaked details from internal implementation on the hypervisor, not the guest [20:47] right; so I think the network_data.json you have should have type: phys instead of type: bridge in it [20:48] if we agree that network_data.json is describing guest networking [20:49] so that is actually leaking ? [20:49] copumpkin, for the fast majority of things, yes. [20:49] some things can't really take affect in the user-data but have to be in cloud.cfg.d [20:50] rharper: perhaps the nova developers are a better resource to better understand what goes where and why [20:50] smoser: like the list of modules for init/config/final? :) [20:50] I don't think the network_data.json I gave you is inherently wrong [20:50] the list of modules for config and final can, right? or are you reminding me of a bug, copumpkin [20:50] they should be able to :-( [20:50] It's just that the links portion is more than likely just not relevant for guest networking, although it could be for bare metal network (vlan, bonding, etc.) [20:50] dmsimard: well, it's ambiguous; the bridges are clearly on the host; and not part of the guest [20:50] so lets fix that. [20:50] in theory they can. in practice maybe not. [20:51] smoser ok, whenever u ready https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957 has mini six like module now, and using the imports that should be easier to 'extract that net folder out' [20:51] rharper: maybe it's a bug and shouldn't be exposed to guests, I don't know [20:51] rharper dmsimard ya, weird stuff, lol [20:51] smoser: oh, interesting, I didn't realize that. Is there some way to disable that? [20:51] not reminding you of a bug, nope! [20:52] dmsimard: yeah from my reading of the spec; it's meant to describe networking on the "machine" executing cloud-init and fed the network_data.json [20:52] if it gets host info, that's odd lol [20:52] so the generator of the json shouldn't include things that aren't meant to be configured/rendered where the json is consumed; [20:52] mgagne, http://paste.ubuntu.com/16665693/ is where i am on making those changes described in the other paste. nothing tested yet, just looking at making the changes. [20:53] take it up to the nova guys, I have no clue :( [20:53] dmsimard: sure;thanks for the help [20:53] copumpkin, disable what ? [20:54] it sure would seem both broken and wrong to tell the guest what the host's networking configuration looks like [20:54] even if only partially [20:54] harlowja: I'm leaning on bug here; mostly because it's an under consumed/tested spec. [20:54] smoser: the ability to change loaded modules on the fly. I'd like to force userdata to only use a handful of modules [20:54] https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7 (the updated next thing after that refactor branch gets merged) [20:54] rharper ya [20:54] I'm not sure I'm qualified to review those changes =) [20:55] copumpkin, i dont think you can disable it. generally the goal is that the user-data wins. [20:55] they're the ones who say waht goes. [20:55] hmm [20:55] that's unfortunate [20:55] they're the "owner" [20:55] smoser: did we get our network_data.json turned on in serverstack ? [20:55] dmsimard: there was a bug in earlier version where network_data.json wasn't available in the versioned path (only latest/) [20:55] rharper i can send out a mail to the openstack dev list, if we can't figure out wtf is going on here :P [20:55] rharper, checking [20:55] harlowja: ok; I suppose I should join that ml [20:55] (a non ambiguous network_json) [20:55] smoser: I guess I could delete the cc_* modules I'm not using? :P [20:55] rharper if u want, ha [20:56]