22:08:12 <danwent> #startmeeting
22:08:13 <troytoman> o/
22:08:14 <GheRivero> hi people
22:08:14 <openstack> Meeting started Tue Nov 29 22:08:12 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:08:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:08:16 <SumitNaiksatam> hi
22:08:19 <reed> everybody: remember to use #info more often
22:08:34 <salv-orlando> nice to talk to you again
22:08:35 <danwent> #link agenda: http://wiki.openstack.org/Network/Meetings
22:08:38 <reed> it makes minutes more readable
22:08:56 <danwent> mtaylor: you around?
22:09:01 <cdub> reed: that should be #info'd ;)
22:09:01 <markvoelker> o/
22:09:35 <danwent> before diving into melange + quantum specifically, I wanted to have mtaylor talk about his thoughts on splitting clients out of the main repo, and how that woould work for quantum + melange
22:09:41 <danwent> markvoelker: welcome back :)
22:10:08 <danwent> mtaylor: ping?
22:10:25 <cdub> danwent: as in nova/network/quantum/client.py ?
22:10:45 <mtaylor> danwent: pong
22:11:02 <danwent> cdub:  the goal is that once we have clients packaged, we can remove the nasty copy of client.py in different repos
22:11:19 <cdub> *nod* just making sure that was client we were talking about
22:11:19 <mtaylor> danwent: I would like to make the client subdir its own repo. and the common subdir its own repo
22:11:26 <danwent> cdub: yup
22:12:11 <danwent> mtaylor: i'm worried about the complexity here…
22:12:14 <mtaylor> danwent: and I would like to put both of those repos in to gerrit as projects that are managed by quantum core
22:12:29 <mtaylor> danwent: yes. however, it's a complex problem, so sometimes complexity is going to happen :)
22:12:52 <bhall> mtaylor: what about server, plugins, etc?
22:12:59 <mtaylor> danwent: the problem is that we've got projects that need to depend on this stuff (horizon being a good example)
22:13:17 <mtaylor> so we need to be able to reference the actual thing that's needed, wihtout pulling in the entire server
22:13:31 <danwent> mtaylor: definitely understand that.. we want to be able to package things separately, definitely
22:13:40 <cdub> sounds more like packagin then repo mgmt
22:13:51 <danwent> I think the question is why packaging needs to be tied to repo so tightly.
22:13:58 <cdub> e.g. simple to build multpile packages from a single repo
22:13:59 <danwent> i definitely understand that you have a lot of experience here… :)
22:14:17 <danwent> cdub: yes, in fact that is what we do already.
22:14:23 <cdub> right
22:14:25 <mtaylor> it's for a few reasons
22:14:42 <mtaylor> pip requires git lines can't reference sub directories
22:15:01 <mtaylor> so you wind up with venv installs that require actual releases to pypi to be consumable
22:15:36 <mtaylor> additionally, once you start having submodules in tree, standard tooling winds up being difficult to apply - knowing to interact with a setup.py in trunk is straight forward
22:15:50 <mtaylor> knowing that there are 4 setup.py files spread throughout the tree is less obviouos
22:16:05 <bhall> as of yesterday all setup.py's are in the root :)
22:16:24 <danwent> ok, so the trade-off here is if we want the pip files of other projects to automatically pull "trunk", we need separate repos?
22:16:41 <mtaylor> yes
22:17:21 <mtaylor> also, it's the  model we're using for the other projects, so in keeping with a consistent project-wide approach, I'd kind of want to hear a really good reason that it can't work
22:17:28 <bhall> how many repos are we talking about? client, common, server, plugins?
22:18:16 <danwent> I'm also worried about trying to keep quantum simple enough that its easy for new people to join and hack on the project
22:18:25 <mtaylor> I don't think, as of yet, that we need separate ones for plugins
22:18:55 <mtaylor> the most important one in my brain in client - as we have a python-*client project either in existence or coming in to existence for every openstack project
22:19:08 <bhall> could we go with two repos? client, common/server/plugins
22:19:11 <mtaylor> the common one is just because that's how you've organized your code - and i believe client depends on it, yeah/
22:19:18 <mtaylor> does client depend on common?
22:19:25 <danwent> I believe that was the original goal
22:19:50 <danwent> but perhaps we should revisit that… I'm not sure how much is currently shared.
22:19:58 <bhall> I think it does currently
22:20:06 <bhall> yeah, I don't think there is a lot of code that it depends on
22:20:17 <danwent> mtaylor: so the main goal here is pip install, which are mainly targetted at developers right?
22:21:05 <danwent> (I assume non-developers will get everything via packages, which should have dependencies described in terms of packages)
22:21:43 <mtaylor> danwent: yes
22:22:12 <danwent> ok, thanks for the explanations… I think I understand this better now, but still need to noodle on whether there are ways we can both be happy :)
22:22:18 <mtaylor> danwent: there is no thought that people will be doing production releases from pip :)
22:22:23 <mtaylor> danwent: awesome
22:22:50 <danwent> mtaylor: given your goal of doing this for e2, we'll follow-up with you soon.  and we'll make sure netstack list is cc'd
22:23:00 <mtaylor> danwent: sounds great!
22:23:12 <danwent> appreciate your time
22:23:18 <danwent> Ok, troy, still around?
22:23:30 <troytoman> yes
22:23:36 <danwent> #status Melange Update
22:23:43 <danwent> #topic Melange Update
22:23:49 <danwent> tired fingers :)
22:24:15 <troytoman> #info the melange repo will move to the openstack github/gerrit system tomorrow at 3PM CST
22:24:35 <troytoman> mostly been working with mtaylor and jeblair on that.
22:24:47 <troytoman> we are almost done with adding notifications as well.
22:25:05 <troytoman> once we have that done we will look to implement notifications for quantum
22:25:08 <troytoman> https://blueprints.launchpad.net/quantum/+spec/quantum-notifications
22:25:18 <troytoman> probably an e-3 type item
22:25:33 <troytoman> otherwise, trying to flesh out documentation, etc.
22:25:35 <danwent> answered the question before I could ask :)
22:25:40 <troytoman> that's about it
22:25:45 <salv-orlando> troytoman: do you think explicit plugin support would be required/adivsable for notifications?
22:25:50 <troytoman> my fingers aren't as tired
22:26:28 <troytoman> salv-orlando: you mean support for plugins within notifications?
22:26:37 <troytoman> or plugins for notifications?
22:27:05 <salv-orlando> actually, I meant to ask whether plugins should be explicitly aware of the presence of the notification mechanism
22:27:29 <salv-orlando> or if that something you can entirely handle in the API layer
22:27:40 <troytoman> that's probably a good topic to consider. since we have focused initially on Melange we haven't thought about plugins
22:28:18 <danwent> yeah, probably depends on the scope of notifications.  if they just map to API actions, I would assume plugins don't need to know about them.
22:28:18 <troytoman> but it would be a good thing to think through - initially we are focusing on basic notifications like create/delete network, ports, etc.
22:28:38 <salv-orlando> ok, cool. We'll see as soon as the spec is more defined.
22:28:42 <troytoman> i think plugins could add notifications that take advantage of the basic structure that is there
22:28:58 <troytoman> look over the blueprint and let's discuss further
22:29:02 <danwent> ok, anything else on melange?
22:29:22 <danwent> #topic Quantum Status
22:29:44 <danwent> #info we're doing pretty well on reviews: https://review.openstack.org/#q,status:open+project:openstack/quantum,n,z
22:30:07 <danwent> #info largest existing review is salvatore's patch left from e-1, but that just requires minor tweaks.
22:30:42 <danwent> Brad, can you also send a pointer to the nova-parity-nat review, as that is in nova?
22:31:00 <bhall> sure, lemme find it
22:31:01 <salv-orlando> tweaks should be in tomorrow. Apologies if I've been lazy on Quantum lately :)
22:31:25 <danwent> salv: next two topics for e-2 are you… so we'll see :)
22:31:35 <danwent> essex-2 milestone: https://launchpad.net/quantum/+milestone/essex-2
22:31:35 <bhall> #info nova-parity-nat review: https://review.openstack.org/#change,1940
22:31:56 <danwent> things are still a bit loaded for e-2, so I wanted to review the major items.
22:32:03 <danwent> salv-orlando: operational status
22:32:24 <danwent> I think this needs to be available soon if plugins are going to be able to implement the interface in time for e-2
22:32:51 <salv-orlando> This will be available for e2, definitely. The issue is what we should assume about plugins.
22:33:02 <salv-orlando> If a plugin does not support the operational status, how are we going to behave?
22:33:13 <danwent> #link operationa status still targeted for e2: https://blueprints.launchpad.net/quantum/+spec/api-operational-status
22:33:22 <salv-orlando> Return an "UNKNOWN" status, return an exception?
22:33:28 <salv-orlando> I'm for the UNKNOWN status
22:33:41 <danwent> salv: that is what I was going to suggest as well.
22:33:57 <salv-orlando> cool. Anybody against the UNKNOWN state?
22:34:14 <danwent> you're going to send out a detailed spec proposal though?
22:34:40 <salv-orlando> Still need to update the one on the wiki. My apologies for that...
22:34:48 <salv-orlando> #action Salvatore to provide updated spec
22:34:54 <danwent> Ok, please ping netstack.  yup, great
22:35:16 <salv-orlando> sure.
22:35:36 <danwent> anyone from cisco around that can comment on whether there should be a bug for doing operational status for the cisco plugin in e-2?
22:36:14 <danwent> next API topic: filters (https://blueprints.launchpad.net/quantum/+spec/api-filters)
22:36:29 <danwent> salv, this is you as well.  delivery status is "unknown"
22:36:55 <SumitNaiksatam> danwent: yeah, need to look at the spec
22:37:09 <danwent> sumit: great, thanks
22:37:33 <danwent> sumit: perhaps create a bug/bp for this and target to essex-2, just so we can track it.
22:38:05 <SumitNaiksatam> dan: ok
22:38:18 <danwent> salv-orlando: comments on status of filter?  still planning on e-2?
22:38:24 <salv-orlando> I reckon we put this spec to unknown because we did not want to create too much pressure on plugin for essex-2
22:38:48 <danwent> so sounds like e-3?
22:38:57 <salv-orlando> The code is fairly straightforward, but as any thing requires some thought. And there will possibly be plugin support required.
22:39:13 <salv-orlando> I therefore suggest to move this feature to e-3
22:39:15 <danwent> salv-orlando: yes, I suspect plugin support would be required
22:39:19 <danwent> sounds good.
22:39:43 <salv-orlando> I think that in this case it is advisable, but not strictly required (plugin can return all data, and API does filter)
22:39:56 <danwent> salv: for the filtering, would be good for us to do a quick analysis of any inefficient queries that quantummanager has to do… those are probably primary targets
22:39:59 <salv-orlando> anyway, we would still need a mechanism to understand whether the plugin is providing the filter :)
22:40:08 <danwent> yup
22:40:18 <salv-orlando> yeah, let's target the analysis in a week.
22:40:25 <danwent> ok, thanks
22:40:31 <danwent> carlp: you here?
22:40:43 <salv-orlando> #Action salvatore to publish on wiki and discuss on NetStack mailing list points where API filters might be required.
22:41:31 <danwent> #action #danwent contact #carlp about jenkins environment: https://blueprints.launchpad.net/quantum/+spec/quantum-functional-test-environment
22:42:08 <danwent> #info: plan is to have at least one simple integration test for nova + quantum in by essex-2, just so we start flushing out practical issues.  If anyone wants to contribute more, please do
22:42:25 <danwent> bhall: nova-nat parity?
22:42:57 <bhall> one review so far
22:42:59 <bhall> one more to go
22:43:06 <danwent> ok, sounds good.
22:43:15 <danwent> debo-os: any comments on the cloudpipe work?
22:43:40 <debo-os> I figured out the main changes ... writing hte BP
22:44:10 <debo-os> also we discussed pushing this to E3 due to nova changes
22:44:25 <debo-os> BP should have the flow and be done in 1-2 days
22:44:30 <danwent> debo-os: yes, makes sense.  don't want to push anything to nova team last minute
22:44:51 <danwent> ok, sounds great.  ideally we get this done early e-3, which makes for a more relaxed nova reivew process :)
22:44:54 <danwent> looks like arvind isn't around, but I know he is planning on spinning up again on the quantum + horizon work.  if you're interested in collaborating, send mail to the list.  I expect to see more BPs soon.
22:45:07 <danwent> three bugs to talk about:
22:45:14 <danwent> bug #803086
22:45:15 <uvirtbot> Launchpad bug 803086 in quantum "plugins.ini should be collapsed into quantum.conf to prevent configuraitn"sprawl"" [Medium,In progress] https://launchpad.net/bugs/803086
22:45:45 <danwent> I'm still in favor of getting this in.  we delayed it from e-1 because it was too close to the deadline.  any concerns?
22:46:09 <danwent> basically, just means that you configure the plugin in quantum.conf to avoid having too many config files.
22:46:14 <danwent> bug #897817
22:46:15 <uvirtbot> Launchpad bug 897817 in quantum "The cisco plugin extensions need to move to the cisco plugin directory" [Medium,New] https://launchpad.net/bugs/897817
22:46:34 <danwent> this is point raised on ML.  wanted to get comment from cisco team.
22:47:06 <cdub> danwent: what about this comment "Considering that we are relying on plugins.ini in several places outside of quantum, ..." (re first bug)
22:47:34 <danwent> actually, that was a concern I raised.  we have some automation scripts that do this as part of automated configuration.
22:48:28 <danwent> to me this is one of those things where the long we wait, the more things we'll break, so we might as well change it soon.
22:48:45 <salv> cdub: good point. However, keeping two conf files does not look good.
22:48:50 <cdub> as long as "places outside of quantum" is well-known, then makes sense to collapse and update the few external dependencies
22:48:59 <edgarmagana> I got kicked out from the IRC meeting!
22:48:59 <salv> We can deprecate plugins.ini but still support it in e-2 and e-3
22:49:04 <danwent> cdub: yeah, trying to get it changed while that is still the case :)
22:49:08 <salv> and then remove it completely for the final release
22:49:23 <cdub> +1 to that
22:49:30 <danwent> salv: yeah, a "soft" removal is probably best
22:49:47 <salv> cool. So, is that agreed?
22:50:05 <danwent> #agreed:  implement "soft" removal of plugins.ini, which final removal targeted in essex main release
22:50:20 <danwent> salv: patch will have to change a bit then, correct?
22:50:45 <salv> yes, but not a lot.
22:51:02 <danwent> k, great
22:51:12 <danwent> final bug of note: Bug #897837
22:51:13 <uvirtbot> Launchpad bug 897837 in quantum "The new packaging breaks find_config_file" [Critical,New] https://launchpad.net/bugs/897837
22:51:33 <bhall> that one is in already
22:51:33 <danwent> tyler just filed this today, but seems important so I upped it to critical and targeted for e-2
22:51:37 <bhall> bug maybe not updated
22:51:43 <cdub> danwent: i think that's in the repo
22:51:50 <danwent> damn, that was quick, nice work :)
22:52:00 <danwent> I will update the bug
22:52:08 <cdub> can someone explain this to me?
22:52:08 <cdub> Date:   Tue Mar 29 23:15:10 2011 -0400
22:52:32 <cdub> Tyler's commits are all from the past, but then i saw one from Brad as well
22:52:59 <danwent> as a note: people should always include bug ids in the first line of the git commit, that way jenkins automatically updates the bug to committed.
22:53:12 <bhall> one of my dev vms isn't using ntp I think
22:53:18 <cdub> commit done on workstation w/ wrong date?
22:53:18 <bhall> and is way off as far as date is concerned
22:53:44 <cdub> ok, wasn't sure if there was some other weird magic going on ;)
22:53:56 <danwent> ok, i'll ping tyler about that too.  probably just dates being off, but yeah, its confusing.
22:54:02 <danwent> Ok, anything else for e-2?
22:54:16 <danwent> remember, branch will be early on Dec 13th, for final release on Dec 15th
22:54:36 <danwent> we should now have correct repo permissions to do the branch, unlike with essex-1
22:54:57 <danwent> #topic Open Discussion
22:55:05 <danwent> anything?
22:55:25 <edgarmagana> Dan: I just created a BP for network services insertion
22:55:37 <danwent> edgarmagana: link?
22:55:59 <edgarmagana> da: #link https://blueprints.launchpad.net/quantum/+spec/services-insertion-wrapper
22:56:22 <edgarmagana> I am updating the full description but basically is what we decided during the summit
22:57:20 <danwent> Ok, from the write-up its not clear what changes will be made to quantum, so it seems a bit risky to me to target for essex-2
22:57:34 <edgarmagana> It will consist of a wrapper to insert a service "in-path" into the network
22:57:40 <danwent> what portions of the codebase are affected?
22:57:57 <danwent> "wrapper"… is this a new api extension?
22:58:06 <edgarmagana> not impact to any other code, it will be an isolated piece of code calling other methods
22:58:16 <danwent> ok, so a quantum client?
22:58:39 <edgarmagana> yes, very similar to client
22:58:54 <danwent> ok, if so, that seems pretty low risk for e-2
22:59:02 <danwent> I look forward to reading the BP.
22:59:04 <danwent> anything else?
22:59:37 <danwent> ok, have a good one folks.  one minute to spare :)
22:59:42 <danwent> #endmeeting