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