22:02:01 <danwent> #startmeeting
22:02:03 <openstack> Meeting started Tue Jan 24 22:02:01 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:02:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:02:13 <danwent> ok, netstack meeting'
22:02:15 <salv-orlando_> hello!
22:02:19 <carlp> hey!
22:02:20 <davlap> hi folks!
22:02:20 <edgarmagana> Hi Folks!
22:02:24 <danwent> agenda: http://wiki.openstack.org/Network/Meetings
22:02:25 <markvoelker> o/
22:02:25 <wwkeyboard> 'ello
22:02:29 <somik> hi folks!
22:02:30 <ttx> danwent: make that your first item :)
22:02:32 <danwent> first topic is talking with ttx + monty
22:02:33 <mestery_> 'sup guys!
22:02:40 <danwent> ttx: already one… see agenda :)
22:02:55 <ttx> danwent: damn, you're fast
22:02:58 <cdub> heh, convenient
22:03:07 <danwent> Ok, problem is that there is no automated tarball job for python-quantumclient
22:03:17 <danwent> so its hard to release it for E-3?
22:03:29 <ttx> danwent: it's also that I didn't plan to have quantumclient /melangeclient done for E3, tbh
22:03:32 <danwent> I really wanted to get it into E-3, so we could make sure distro packagers had time to adjust
22:03:47 <ttx> danwent: ok, let's see what we can do
22:04:09 <ttx> mtaylor: what's the status ? repo is up ?
22:04:20 <danwent> ttx: ok.  don't want to cause more work for you.  is this just a matter of mtaylor writing a script?
22:04:24 <danwent> ttx: yes, repo is up
22:04:33 <ttx> mtaylor: I'd need the repo set up, and tarball jobs for master and milestone-proposed... today
22:04:43 <danwent> oops, just kidding
22:04:51 <danwent> code is at: https://github.com/openstack/python-quantumclient
22:04:57 <mtaylor> and it's in gerrit, etc
22:04:58 <danwent> but ttx, you're talking about a different repo?
22:05:00 <ttx> if not, we can do an out-of-band quantumclient/E3 thing
22:05:13 <ttx> danwent: no, that one
22:05:35 <danwent> ok, i'll stop talking :)
22:05:54 <mtaylor> ttx: I think we should be able to get tarball job up asap - quantumclient is using the same version setting code as quantum and others
22:06:10 <mtaylor> ttx: I didn't set one up already because I wasn't sure if we should yet
22:06:18 <ttx> mtaylor: if the tarball job is up, I'll pick up quantumclient as part of the E3 regular process
22:06:30 <ttx> starting tomorrow morning
22:06:31 <mtaylor> cool
22:06:39 <danwent> mtaylor, can you give you the TODO?
22:06:43 <ttx> if not, we can upload a tarball for E3 out of band
22:06:54 <danwent> or rather, can I give you the TODO :)
22:06:56 <ttx> so that packagers are happy to play
22:07:01 <danwent> (too many late nights recently)
22:07:09 <danwent> thanks ttx
22:07:10 <ttx> danwent: would that work for you ?
22:07:13 <danwent> yup
22:07:15 <danwent> appreciate it
22:07:15 <ttx> ok, deal.
22:07:40 <danwent> #TODO #mtaylor try to setup a tarball job for python-quantumclient
22:08:26 <mtaylor> ++
22:08:29 <danwent> I'll just assume mtaylor is off working on it already :)
22:08:33 <danwent> thanks mtaylor
22:08:39 * mtaylor is eating a sandwich, but yeah
22:09:07 <danwent> https://review.openstack.org/#q,status:open+project:openstack/quantum,n,z
22:09:12 <danwent> here are the open reviews.
22:09:32 <danwent> with respect to python-quantumclient, we still need to approve the change-set to split out the client code.
22:09:46 <danwent> salv, I believe you had some input on how exceptions are handled?
22:09:48 * mtaylor is working on that one
22:10:01 <mtaylor> not the exceptions - waiting for salv feedback on exception
22:10:16 <salv-orlando_> feedback is on the review page
22:10:19 <danwent> right now, we get away with not duplicating, because server depends on client, but its a bit odd that some server-only exceptions are included in the client.
22:11:00 <danwent> (reading)
22:11:21 <danwent> so can I take that as saying you're fine with the exceptions as is, for now?
22:11:22 <salv-orlando_> I think we can easily keep this odd thing and proceed with the split, as long as we file a bug for tidying up exceptions
22:11:45 <salv-orlando_> well, not really as it is on the changeset, as it is going to be deleted from the server package...
22:12:02 <salv-orlando_> are we creating a repository for quantum.common as well?
22:12:03 <danwent> ok, sounds good.  such a large change makes me nervous, so i'd lke to get it in ASAP.  I think there's a fair amount of testing that still needs to be done around packaging with the split.
22:12:50 <danwent> I think mtaylors approach was to take things that might go in a "common" and put them in "client".
22:13:01 <danwent> as the server depends on "client", and thus pulls the "common" code in.
22:13:07 <danwent> is that right mtaylor?
22:13:50 <danwent> apparently he's still eating his sandwich :)
22:13:52 <salv-orlando_> In that case we will probably need exceptions to stay in the server repository, too. Otherwise Quantum API would be unable to raise faults, I'm afraid.
22:14:08 <danwent> no, it works correctly, i believe
22:14:28 <danwent> the exceptions code is available to the server, because the server depends on the client.
22:14:43 <salv-orlando_> ah... that's the bit I was missing :)
22:14:53 <danwent> yeah… took me a while as well :)
22:15:01 <salv-orlando_> In that case we should be all right
22:15:15 <danwent> Ok, I still think we need to do a fair amount of testing + reviewing with this patch.
22:15:17 <cdub> and do we expect client -> common to happen before E4?
22:15:30 <danwent> cdub: I don't think we'll create a common
22:15:34 <cdub> or F+
22:15:47 <cdub> danwent: ever?
22:15:48 <danwent> we may rework the exception code a bit so that there is no longer any "common"
22:15:54 <danwent> code
22:16:00 <danwent> which would probably be less confusing
22:16:27 <danwent> cdub: that is my guess.  long-term, both packages should be able to depend on something like openstack-common.
22:16:36 <danwent> I don't think nova + novaclient have a shared library
22:16:40 <cdub> danwent: right, ultimately we'd like to be able to install server and client separately (not on same box)
22:16:42 <mtaylor> danwent: yes. sorry - multi-tasking kills me
22:16:44 <danwent> or most of the other openstack projects.
22:16:52 <danwent> cdub: you can do that already
22:17:04 <danwent> you can install and run client with independently
22:17:08 <danwent> no need for server.
22:17:20 <danwent> its just that when you install the server, you have to install the client as well.
22:17:23 <cdub> with server needing excpetion code provided by client?
22:17:25 <danwent> which you probably want for testing as well.
22:17:48 <salv-orlando_> mtaylor: danwent clarified that actually quantum-server will depend on quantum-client. I was afraid the exceptions module was not anymore available to the server. In this case, we can go ahead with the merge.
22:17:52 <danwent> That's the part we'd like to clean up, but its more of a style thing that a correctness thing.
22:18:24 <danwent> salv-orlando: OK, there are other things that need to be fixed in the patchset, but we will note that you have withdrawn your concern about the exceptions.
22:18:40 <mtaylor> salv-orlando_: ok. cool.
22:18:46 <danwent> cdub: can you explain your concern in more detail?  or comment on the review?
22:18:48 <mtaylor> yes - need to sort the namespace pacakge issue
22:19:13 <mtaylor> which means we need to land a patch in horizon, right?
22:19:30 <danwent> dave, can you comments?
22:19:43 <davlap> mtaylor: so there's a pip requires we need to add to horizon
22:19:50 <davlap> and also need to make a mod to devstack.sh
22:19:54 <davlap> sorry.. stack.sh
22:20:09 <danwent> davlap: is horizon change required, or just suggested?
22:20:11 <mtaylor> davlap: cool. also, you were pointing to my old emonty repo and not the openstack repo
22:20:12 <davlap> stack.sh was creating fake quantum/client module in its tree which was imported before the client..
22:20:16 <danwent> wasn't clear on that
22:20:29 <davlap> we need horizon change to capture the dep for installation of horizon
22:20:44 <davlap> ok.. great.. i'll take a look at the new one..
22:20:45 <danwent> davlap: ok.  its the right change anyway.
22:20:45 <cdub> danwent: sure, i'll comment in review, shouldn't effect merge ;)
22:20:51 <mtaylor> awesome
22:21:02 <mtaylor> should we poke heckj or someone about the horizon thing?
22:21:18 <danwent> mtaylor: i already pinged devmancar and you in an email.
22:21:22 <mtaylor> awesome
22:21:25 <heckj> huh?
22:21:30 <mtaylor> oh hey! there it is
22:21:32 <danwent> looping in heckj would be good
22:21:51 <heckj> I'm here and officially loopy
22:21:53 <mtaylor> heckj: we have a quantum.client package now, so we want horizon to use it
22:22:20 <mtaylor> heckj: -e git+https://review.openstack.org/p/openstack/python-quantumclient#egg=python-quantumclient-dev
22:22:47 <heckj> sounds good - pretty much a straight up deps change I think. Is it pushed to pypi now? (i.e. easy to get) or do we have to wrangle a git based PIP install for it?
22:22:57 <heckj> git, eh?
22:23:39 <heckj> dan - same API setup, or are there code changes to use this that will be needed as well?
22:23:51 <heckj> danwent^^
22:24:09 <danwent> heckj: should just be a dependency issue
22:24:29 <danwent> there is stuff broken with horizon + quantum, but that's another discussion (for another day, but hopefully soon!)
22:24:43 <danwent> this dep change should get us to status quo
22:24:54 <debo-os> danwent: :)
22:25:14 <debo-os> I guess you meant creating networks etc
22:25:42 <danwent> debo-os: yeah, and integration with IPAM.
22:25:49 <danwent> essentially what we talked about at Essex summit
22:26:05 <danwent> ok, heckj, does that sound reasonablee?
22:26:27 <heckj> danwent: quite. I was just getting the latest code to make that change right now, see that it worked OK.
22:26:51 <danwent> ok, thanks.  definitely ping us if you see problems.  we will test it all with devstack as well once it is in.
22:27:29 <danwent> ok, so my final question with the repo split stuff is whether people have been testing generating packages from the repos.
22:27:56 <mtaylor> danwent: _hopefully_ zul and friends will start building us offical debs of these bad boys, right zul?
22:28:15 <zul> of what?
22:28:48 <danwent> mtaylor: yes, but some people build packages themselves with the setup scripts, so I want to make sure everything's happy before we drop E-3
22:29:04 <danwent> just want to make sure we're safe before we approve :)
22:29:24 <danwent> zul: quantum and python-quantumclient
22:29:44 <heckj> danwent: I've seen some packages generated from the managedIT guys too
22:29:55 <zul> danwent: quantum is already packaged in ubuntu/debian python-quantumclient not so much
22:29:58 * heckj is currently stealing zul's hard work there
22:30:18 <mtaylor> zul: it's just a split of the client libs from the quantum core
22:30:19 <zul> heckj: meh :)
22:30:30 <mtaylor> zul: you can blame me for that one
22:30:42 <zul> nnnnnngnnnnh
22:31:07 <heckj> how very…. articulate!
22:31:19 <danwent> Ok…. so are we good talking about the client repo split?
22:31:42 <danwent> anything else to bring up?  This is a pretty big change, so we'll need everyone to pitch in on testing.
22:32:04 <danwent> thanks for your help mtaylor, heckj, zul
22:32:11 <heckj> np
22:32:13 <danwent> Ok, next up:  API patches
22:32:17 <ohnoimdead> danwent: any idea on when the horizon + quantum discussion can happen? :)
22:32:25 <mtaylor> thanks everybody!
22:32:37 <danwent> ohnoimdead: definitely want to chat
22:32:49 <danwent> perhaps late this week?
22:32:51 <ohnoimdead> cool cuz we'd like to get that stuff working again
22:32:56 <danwent> once we get E-3 under controller
22:32:58 <danwent> control
22:33:04 <danwent> sweet, I would too :)
22:33:21 <danwent> ohnoimdead: please ping netstack list.
22:33:30 <ohnoimdead> doing now
22:33:41 <danwent> Ok, salv-orlando?
22:34:05 <danwent> salv-orlando_
22:34:17 <danwent> probably asleep from coding all night
22:34:25 <salv-orlando_> nope
22:34:26 <salv-orlando_> not yet
22:34:45 <salv-orlando_> a possibly final changeset for api-error-codes has been pushed
22:35:06 <danwent> ok, so its pretty late and we have the repo split… minimizing other churn at this point is good.
22:35:26 <danwent> the filters seem like the most important other thing, as we want nova to start using the filters in E-4, if possible.
22:35:42 <danwent> error-codes is about good to go though, right?
22:35:49 <salv-orlando_> I'm happy with deferring pagination.
22:36:01 <salv-orlando_> error-codes is good to go. Feedback has been addressed.
22:36:18 <salv-orlando_> For api-filters it seems that we managed to agree on the plugin behaviour.
22:36:26 <danwent> ok, so let's try to get people to review error codes.
22:36:38 <danwent> should be a quick re-review
22:36:53 <salv-orlando_> Summarizing: a plugin might or might not implement the filters. For the filters it does not implement, the API layer would perform the filtering.
22:37:08 <salv-orlando_> This keeps the code in the API layer pretty simple and gives client a consistent experience.
22:37:11 <danwent> filters is more complex.  Do we have two core reveiwers on that yet (I think it was just Aaron and I, last I checked)
22:37:42 <salv-orlando_> Yes, just the two of you. A contribution from somebody knowledgeable with the UCS plugin would be greast.
22:37:55 <danwent> volunteer?
22:38:27 <edgarmagana> dan: I take it
22:38:32 <danwent> this is mostly already reviewed, so it shouldn't be too bad.
22:38:37 <salv-orlando_> edgarmagana: thanks!
22:38:41 <danwent> great.
22:38:42 <SumitNaiksatam> yeah, I am looking at it too
22:38:54 <edgarmagana> I already reviewed but I was not sure about the plugin implementing or not the filters
22:39:01 <salv-orlando_> cool. So I will be able to address previous feedback in the next hour or so.
22:39:03 <danwent> ah, sorry, missed that edgar
22:39:24 <danwent> salv: hope you can stay up that late… we're all running on fumes :)
22:39:42 <danwent> ok, and so we'll defer the pagination?  I think that's a good call.
22:39:43 <salv-orlando_> I have plenty of coffee
22:40:04 <salv-orlando_> and in case I should run out there's a supermarket open 24/7 near my home
22:40:29 <danwent> ok, so we also have reviews for linux-bridge plugin and ryu controller plugin.
22:40:57 <danwent> ryu we've already decided to bump.  i personally think its pretty late to squeeze in linux-bridge given all the churn.
22:41:08 <danwent> sumit: is there a problem with just doing this first thing in e-4?
22:41:16 <debo-os> folks,  for the new plugins: it would be good to try with devstack
22:41:49 <danwent> debo-os: yes, we'll definitely want to do full system testing for new plugins.
22:42:02 <debo-os> danwent: cool
22:42:03 <danwent> (ideally with your new system test framework :)
22:42:03 <SumitNaiksatam> yeah, I am fine
22:42:11 <SumitNaiksatam> we have one review from edgar
22:42:12 <edgarmagana> dan: I have an end-to-end testbed with devstack and the linux-bridge code, It is working very well so far!
22:42:20 <danwent> Ok.  but it will be important that we don't let this go to late in E-4
22:42:20 <SumitNaiksatam> need one more for the linux bridge
22:42:55 <cdub> i think risk is low
22:43:01 <debo-os> edgar: did you get it automated in devstack.sh
22:43:01 <cdub> for linux-bridge e3, since it's a plug in
22:43:14 <debo-os> I can do the 2nd one
22:43:16 <danwent> Sumit: yeah, with a big chunk of new code, we definitely want to review it carefully.
22:43:27 <edgarmagana> debo: no, i had to do some manual confguration
22:43:33 <danwent> is there a big deal if we just do it next week?
22:43:50 <danwent> we're really overloaded already with code to review + test
22:44:00 <debo-os> edgar: by devstack we meant push button ... spec linuxbridge in the localrc and voila
22:44:05 <danwent> I'd much rather have those cycles go to making sure e-3 is not busted
22:44:29 <cdub> probably not, considering we'll probably going to spend more time w/ packaging anyway
22:44:40 <edgarmagana> debo: we need to modify the script and i am not working on that
22:44:51 <rkukura> linux-bridge would allow end-to-end testing of packages on fedora 16, which doesn't have OVS yet
22:44:56 <danwent> cdub: that would be my preference.  we've already had a couple late nights
22:45:13 <edgarmagana> debo: I just wanted to have a full functional end-to-end testbed with two or more cloud computes
22:45:16 <cdub> yeah, it's a balance between testable (no ovs in fedora) and testable (busted)
22:45:21 <danwent> rkukura: definitely can get this in E-4
22:45:35 <danwent> is e-3 important in particular?
22:46:00 <debo-os> edgar: understand ... but we would want to get it automated soon
22:46:21 <debo-os> thats why danwent mentioned the test framework
22:46:23 <debo-os> :)
22:46:29 <cdub> rkukura: when's fedora OS testday?  before E4?
22:46:34 <danwent> debo-os: you want to get this working in devstack, then testing it should be easy.
22:47:03 <debo-os> danwent: +!
22:47:19 <cdub> rkukura: oh, not until march8
22:47:40 <danwent> Ok, so next week is reasonable?
22:47:51 <cdub> wfm
22:47:57 <rkukura> could update packages to git snapshot after E3
22:48:31 <danwent> Ok, that way salv and I can review as well.  which I would prefer.  we're both out of cycles for e-3
22:48:50 <rkukura> understood
22:49:18 * cdub will give it proper review as well, and could use the extra time too
22:49:27 <danwent> debo, we could make testing this be part of the bug-squashing system test day as well
22:49:38 <danwent> that is Feb 2nd.  would be cool if we coudl do some testing on RHEL
22:50:22 <danwent> ok, sounds good.
22:50:49 <danwent> wanted to talk about system test more general, but debo-os said he has to bail (meeting is running long)
22:51:02 <debo-os> danwent: sure
22:51:04 <danwent> #TODO: #debo-os will update system test BP with info about his tempest work.
22:51:37 <danwent> reminder: we are hosting bug-squashing day @ Nicira on Feb 2nd.
22:51:54 <danwent> will send out an invite with details after the release madness, but expect afternoon and early evening.
22:52:25 <danwent> emphasis will be on code quality + system test.  Debo will hopefully be giving an overview of using devstack with quantum, and using tempest to create interesting test environments.
22:52:30 <edgarmagana> free pizza?
22:52:39 <danwent> you bet :)
22:52:40 <edgarmagana> and beers?
22:52:45 <danwent> maybe even free beer
22:53:01 <edgarmagana> ++
22:53:20 <danwent> ok, any open discussion?
22:53:26 <debo-os> danwent: +1 for beer and devstack+quantum test env
22:53:32 <danwent> before we end this marathon meeting and get back to testing + reviewing
22:53:33 <danwent> ?
22:54:25 <debo-os> ciao!
22:54:25 <danwent> Ok, thanks folks.  Please keep an eye on the netstack list in case critical bugs pop-up.
22:54:28 <carlp> danwent: you know there is an OpenStack meetup in SF that day as well?
22:54:32 <edgarmagana> adeu!
22:54:37 <danwent> carlp: yes
22:54:44 <carlp> danwent: OK, just checking :)
22:54:52 <danwent> enough people voiced a desire for closer location
22:55:02 <danwent> you know us bay area folks are so environmentally friends (or lazy)
22:55:03 <carlp> Fair enough
22:55:06 <danwent> :P
22:55:10 <danwent> ok, later folks!
22:55:16 <salv-orlando_> or the US-101 is alway so packed with traffic...
22:55:22 <danwent> indeed
22:55:24 <danwent> #endmeeting