21:00:36 <vishy> #startmeeting
21:00:37 <openstack> Meeting started Thu Oct 13 21:00:36 2011 UTC.  The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:00:49 <vishy> #topic Blueprint list
21:01:14 <vishy> #link http://etherpad.openstack.org/essex
21:01:33 <vishy> i've gotten most of the blueprints added there
21:01:50 <vishy> please everyone look and see if there is anything I missed
21:02:30 <pvo> looks good Vish.
21:02:38 <pvo> I think there is a lot of work here for Essex
21:03:17 <comstud> i probably should create a XenServer ConfigDrive BP
21:03:33 <vishy> comstud: pls do
21:03:37 <comstud> no feature parity there yet
21:03:47 <bcwaldon> vishy: do you want to assign any of these today?
21:03:50 <vishy> note that the admin apis has nothing yet
21:04:19 <vishy> bcwaldon: first I want to make sure that we haven't missed any major ones
21:04:28 <PhilDay> #info you missed the two blueprints I created yesterdat for VM State Machine and Image Cache Management
21:04:41 <vishy> PhilDay: can you cpy them in pls
21:04:55 <comstud> #action comstud to create xenserver config drive BP
21:05:13 <pvo> comstud: I think there is an old one for that
21:05:19 <comstud> maybe
21:05:27 <comstud> might have been marked done with the libvirt part
21:05:29 <comstud> I'll take a look
21:06:12 <comstud> yeah
21:06:18 <comstud> #link https://blueprints.launchpad.net/nova/+spec/configuration-drive
21:06:20 <comstud> says implemented
21:06:33 <pvo> comstud: gotcha
21:06:51 <comstud> i'm supposed to create the story for our sprints anyway :)
21:06:54 <comstud> i'm slacking
21:07:08 <vishy> can someone add a blueprint for vnc console cleanup? Basically just combining the two vnc paths somehow
21:07:09 <comstud> did the research, haven't written it yet
21:07:10 <_0x44> It was implemented with the understanding/expectation that someone with access to XenServer who cared about config-drive would ensure that it worked.
21:07:22 <_0x44> I think the only thing needed is to attach it
21:07:26 <_0x44> _think_
21:07:47 <pvo> _0x44: I think there was a bit more to do. Create the VDIs and such.
21:07:55 <comstud> there's more than that
21:08:05 <comstud> but yeah
21:09:00 <sleepsonthefloor> vishy - i can add one for vnc
21:09:08 <vishy> sleepsonthefloor: thx
21:09:47 <PhilDay> vishy - added the VM state machine under ""Workflow State Machine" but not sure if that's quite the right place for it
21:10:18 <vishy> PhilDay: that is fine
21:10:34 <vishy> so we are still missing a few blueprints related to volumes
21:10:56 <vishy> other than that i think we have everything in
21:12:13 <vishy> well we are missing a few in the security session as well
21:13:09 <_0x44> vishy: Are the BP's bengrue worked on in Diablo already listed?
21:14:19 <pvo> vishy: are you going to prioritize these from your perspective as PTL?
21:14:20 <vishy> which are those?
21:14:30 <vishy> pvo: that is what I want input on
21:14:36 <pvo> ok
21:14:43 <vishy> pvo: I need to know which ones are required by teams
21:14:48 <_0x44> vishy: Bringing bengrue in here to answer that.
21:15:06 <vishy> there are definitely some missing
21:15:31 <vishy> is westmaas here?
21:15:50 <pvo> westmaaaaaaaaaaaaaaaaaaasssssssss
21:15:52 <_0x44> bengrue: What are the blueprints you were working on in Diablo around volumes?
21:16:10 <pvo> I was just chatting with him.
21:16:19 <vishy> so we have a few very big ones
21:16:31 <vishy> and we need to decide if we want to tackle them in diablo
21:16:34 <vishy> * essex
21:16:34 <bengrue> Sec.  That was a bit ago.
21:16:38 <vishy> or push to f
21:16:55 <pvo> vishy: what do you think are the biggest?
21:16:58 <pvo> top 5
21:17:03 <vishy> so the big ones as I see it are:
21:17:04 <vishy> 1) DB Cleanup and testing
21:17:07 <comstud> Do we have an overall goal for Essex?
21:17:16 <vishy> 2) Zone Aggregation
21:17:23 <pvo> stablility, performance and scalability
21:17:27 <vishy> 3) Workflow State Machine
21:17:36 <comstud> pvo: perfect
21:17:43 <vishy> 4) Secure Databases
21:17:49 <bhall_> pvo: is that all? :)
21:18:00 <pvo> bhall_: over features, I would think so
21:18:06 <pvo> I would prefer those 3, over any new features
21:18:13 <bhall_> agreed
21:18:36 <vladimir3p_> vishy: under Workflow state machine do you mean "orchestration, jobs, retries, etc..."
21:18:40 <vishy> the problem is i think all of those are required
21:18:56 <PhilDay> #agree with pvo
21:19:00 <vishy> vladimir3p_: I'm referring to sandy's proposal of actually having workflow management
21:19:10 <vladimir3p_> vishy: yep
21:19:16 <vishy> I don't thing we can hit all 4 of those
21:19:28 <vishy> and they are listed in priority as i see them
21:19:40 <vishy> #topic large blueprints
21:20:11 <vishy> #info Largest blueprints: db cleanup and testing, zone aggregation, workflow state machine, secure databases
21:20:16 <pvo> vishy: we have 4 milestones. One goal per milestone?
21:20:40 <vishy> some of them can be worked concurrently
21:20:47 <vishy> but I think all 4 of those require a team
21:21:00 <vishy> i don't think one person can handle any of them
21:21:08 <PhilDay> pvo:  I'd be worried that we'd still have big changes comming through late in Essex if we do one per milestone
21:21:13 <vishy> I'd like to push secure db / queue
21:21:25 <vishy> #info upgrades is also large
21:21:33 <bengrue> _0x44: the blueprint I was working on was https://blueprints.launchpad.net/nova/+spec/volume-cleanup
21:21:43 <vishy> bengure: that is implemented and merged
21:21:47 <vishy> * bengrue
21:22:04 <_0x44> I wasn't sure if it was merged
21:22:14 <bengrue> Yeah, Vlad I think drove it home?
21:22:17 <PhilDay> Upgrades is a v important now there are systems deployed
21:22:25 <_0x44> Ok, sorry for the confusion.
21:22:29 <bengrue> np.
21:22:47 <vishy> Yes we need a team for all 5 of those, but if we don't hit secure dbs in essex does that kill anyone
21:22:57 <vishy> PhilDay: can we push that one from your perspective?
21:23:12 <anotherjesse> vishy: secure db + zones might need to coordinate
21:23:24 <PhilDay> yep
21:23:25 <vishy> PhilDay: That one in particular requires massive changes
21:23:45 <vishy> anotherjesse: I'd like to tackle db cleanup + zones first, i think it makes secure db easier
21:24:00 <vishy> working on it concurrently will be a huge issue
21:24:14 <anotherjesse> vishy: also we might want to think of using a smaller component like the volume component for testing out the secure db
21:24:22 <pvo> vishy: ++
21:24:23 <PhilDay> Agreed, and the session in Boston showed there are more questions than answers - but if we don't hit it soon it'll just get worse
21:24:31 <vishy> #idea create subteams for the major work sections
21:24:43 <anotherjesse> vishy: teams mean launchpad teams?
21:25:19 <vishy> anotherjesse: I don't know if it needs to be that formal
21:25:41 <pvo> I think its just working groups that Vish keeps tabs on
21:25:49 <vishy> zone aggregation, i'd like to see anotherjesse, comstud, sandywalsh collaborate
21:26:19 <vishy> don't know if there is anyone else who should be involved there
21:26:50 <comstud> yeah, myself and sandy are probably a given
21:26:56 <PhilDay> We have some views, although we're not heavy into zones - yet
21:27:08 <anotherjesse> vishy: wiki page of major themes for essex with people on it (so people who aren't on it originally can join in)
21:27:24 <vishy> does anyone want to tackle the db cleanup and testing stuff
21:27:28 <vishy> anotherjesse: definitely
21:27:41 <bcwaldon> vishy: blamar would be a good one there, I'm also interested
21:27:58 <comstud> bcwaldon: funny, I was just going to nominate both of you
21:27:59 <vishy> how about upgrades?
21:28:01 <comstud> :)
21:28:01 <anotherjesse> sleepsonthefloor: do you want to help on db, statemachine or ?
21:28:08 <blamar> bcwaldon: thanks there buddy
21:28:11 <vishy> that one is a lot of theory and prototyping
21:28:14 <bcwaldon> blamar: there you are!
21:28:14 <comstud> blamar: np :)
21:28:16 <_0x44> vishy: Am interested in db=-cleanup at piston
21:28:25 <rjh> once again, we need to have a group to define what upgrades are all about
21:28:33 <vishy> I'm adding this to the etherpad
21:28:42 <rjh> We are definitely interested
21:28:42 <vishy> feel free to add yourself to a section
21:29:16 <vishy> rjh: who are you with again?
21:29:26 <pvo> I'm going to throw Dietz on the upgrades. He and I have been talking about it and whiteboarding
21:29:31 <anotherjesse> _0x44: are you guys interested in building a db backend that isn't sqlalchemy?
21:29:36 <_0x44> anotherjesse: Yes.
21:29:39 <anotherjesse> _0x44: zk?
21:29:52 <_0x44> anotherjesse: Likely
21:30:14 <PhilDay> rjh=Ray Hookway (HP)
21:30:31 <anotherjesse> _0x44: I think it is important that whoever leads the db cleanup does in order to be able to ship an alternative backend
21:30:35 <bcwaldon> thanks PhilDay, was wondering ;)
21:30:39 <_0x44> pvo:
21:30:55 <PhilDay> At least I think its Ray :-)
21:31:14 <rjh> It is
21:31:16 <jk0> if not, he was just volunteered ;)
21:31:16 <pvo> _0x44:
21:31:22 <_0x44> pvo/vishy: I'd like to add novas0x2a to upgrades also
21:31:24 <vishy> oh hai
21:31:40 <vishy> #topic subteams for major sections
21:31:50 <_0x44> Sorry, am on a terrible network right now
21:31:57 <pvo> _0x44: something didn't convert there
21:32:02 <comstud> 0x44: you still in boston?
21:32:03 <salv-orlando> Citrix would be more than happy to contribute on upgrades as well. I think the name is johngarbutt but I'm not totally sure
21:32:04 <comstud> :)
21:32:06 <_0x44> pvo: novas0x2a is mike lundy
21:32:11 <vishy> #info breaking out subteams for particular sections of the code
21:32:16 <pvo> gotcha
21:32:23 <_0x44> pvo: The nordic bearded guy at Pisotn
21:32:29 <vishy> ok we have one more subteam
21:32:34 <vishy> feature parity
21:32:47 <anotherjesse> vishy - you mean hypervisors?
21:32:49 <_0x44> I have to run now
21:32:50 <anotherjesse> or apis?
21:32:59 <vishy> anotherjesse: hypervisors
21:33:07 <pvo> all hypervisors?
21:33:23 <pvo> we focused just on KVM and XenServer at the summit
21:33:27 <pvo> is that still the majority focus?
21:33:33 <anotherjesse> pvo: probably some things will result in documenting "not supported" - for things that don't make sense
21:33:35 <vishy> no just the main two
21:33:39 <pvo> ok
21:33:45 <vishy> i don't want to get crazy
21:33:49 <pvo> just wanted to make sure
21:33:57 <vishy> so quick once over from the interested parties
21:34:17 <anotherjesse> vishy: does this include the fact that xenserver at rax vs. kvm openstack is very different from user perspective (image formats, userdata/metdata, how to auth to servers, ...)
21:34:34 <vishy> anotherjesse: it doesn't
21:34:47 <rjh> How about a security team to deal with message signing and db access?
21:34:53 <vishy> anotherjesse: we have no blueprints for those things, but they sound important
21:35:14 <vishy> rjh: yes security team is good.  I'm concerned about them being able to make much progress
21:35:16 <anotherjesse> #info jesse write up a blueprint on ux for openstack
21:35:26 <vishy> but they can at least start planning
21:35:51 <vishy> pvo, is there someone on your team who is more focused on feature parity?
21:36:23 <anotherjesse> vishy: I volunteer pvo and sleepsonthefloor
21:36:29 <vishy> :)
21:36:34 <pvo> more focused?
21:36:54 <anotherjesse> it would be nice if someone from ubuntu (kvm/lxc) & citrix (xs) could help
21:37:08 <vishy> #info db and rabbit security should be planned but the aren't targeted to be complete by essex
21:37:08 <sleepsonthefloor> yeah, I'm definitely interested in parity
21:37:23 <salv-orlando> more or less the whole Citrix team is focused on parity
21:37:24 <vishy> anotherjesse: agreed, I wonder if we could add salv-orlando
21:37:53 <salv-orlando> I'd say ewanmellor would be happy to be on this team as well
21:38:17 <sleepsonthefloor> it would be nice if someone else who has thought about nova-network and security groups with xen could be on it
21:38:31 <vishy> so does anything else seem to dangerous to be in scope for essex?
21:39:07 <anotherjesse> api 2.0 - but before zones is done … that seems scary to talk about
21:39:19 <pvo> anotherjesse: agree
21:39:22 <comstud> yeah
21:39:26 <comstud> #agree
21:39:26 <vishy> bcwaldon disappeared
21:39:49 <vishy> I don't think we need 2.0 for essex
21:39:49 <pvo> #info wait on zones to be completed before nova api 2.0
21:39:52 <anotherjesse> vishy: rbac is medium sized - mostly busy work
21:40:08 <vishy> anotherjesse: good point we need to give special attention to that one
21:40:17 <anotherjesse> (arguing over what the proper verbs are)
21:40:24 <vishy> anotherjesse: do you think we should have a team for that.  Should rcb take lead on it?
21:40:31 <anotherjesse> maybe todd?
21:40:32 <anotherjesse> xtoddx:
21:40:42 <anotherjesse> he needs that for nasa
21:40:54 <vishy> i don't mind heading that one up
21:41:06 <anotherjesse> vishy: having you on volumes would probably be better
21:41:11 <pvo> vishy: re: the top5, are there BPs for each of those?
21:41:13 <anotherjesse> since you have done a lot of that work already
21:41:34 <vishy> anotherjesse: I'm trying to offload volumes onto third parties
21:41:48 <vishy> anotherjesse: so hopefully i can move into more of a supporting role there
21:42:36 <rjh> There is a blueprint for upgrades, but it needs to be made more specific
21:43:00 <vishy> rjh: i think that one needs to be broken out into specific blueprints
21:43:13 <rjh> Secure databases is mentioned in the nova-security-updates blueprint
21:43:20 <vishy> #action upgrades team to meet and come up with specific action items and blueprints
21:43:30 <rjh> I agree - that goes for both of them
21:44:12 <vishy> #info volumes team met today and started discussing the needed pieces
21:44:26 <vishy> #info we don't have specific blueprints for the parts yet
21:45:06 <vishy> blamar: do you want to lead the db cleanup team?
21:45:37 <anotherjesse> vishy: nothing against blamar but I really think having the lead caring about an alternative backend is important
21:45:43 <anotherjesse> caring = require
21:45:48 <vishy> blamar: there is one blueprint so far, which is to make the db layer return dictionaries
21:45:58 <vishy> anotherjesse: so you think 0x44 should head it up?
21:46:04 <blamar> vishy: apologies, was on the phone..however not currently interested in leading a team; busy life
21:46:06 <vishy> does anyone here care about zookeeper?
21:46:24 <anotherjesse> vishy: supposedly _0x44 does
21:46:40 <anotherjesse> can we pencil it in - with a note that we need to verify
21:46:53 <vishy> #action vishy to verify with _0x44 that he can lead the db cleanup efforts
21:47:16 <blamar> vishy, anotherjesse: I'm an advocate for getting a couchdb backend (as per my email to the mailing list a while back on this subject) and I've used ZK in the past
21:47:23 <vishy> anotherjesse: are you heading up the zone scaling coordination?
21:47:32 <blamar> so I'd love to assist whomever leads
21:47:35 <vishy> blamar, so you're volunteering again :)
21:47:53 <blamar> negatory, I'll be a fine assistant
21:47:54 <anotherjesse> vishy: i am from our team - if sandywalsh or comstud is a better lead overall, I have no objections
21:48:00 <pvo> vishy: comstud/sandy can as well.
21:48:06 <vishy> comstud: ?
21:48:07 <pvo> Both have a pretty firm grasp of the issue
21:48:11 <comstud> hmm
21:48:29 <comstud> not sure i'm the best person
21:48:34 <vishy> we also have that big nasty Recovery/Workflow section
21:48:43 <comstud> esp. if i'll be tied up with zones
21:48:47 <vishy> which sandy seems to be very excited about
21:48:47 <anotherjesse> comstud: how about you - since you guys have to have zones to ship?
21:48:53 <sandywalsh> I'm up for zones or orchestration ... two hot topics for me
21:48:55 <comstud> oh
21:48:59 <comstud> are we talking about zones?
21:49:00 <pvo> comstud: we're talking about zones. : )
21:49:01 <vishy> comstud: zone scaling is what we're talking about
21:49:03 <comstud> lol
21:49:10 <comstud> i was chatting with sandy and not paying attention
21:49:11 <comstud> :)
21:49:14 <comstud> sure
21:49:20 <vishy> #info comstud to lead zones with help from sandy and anotherjesse
21:49:21 <comstud> I can take that
21:49:35 <vishy> #info sandy to lead orchestration with help from ...
21:49:56 <pvo> vishy: where is donabe in relation to orchestration?
21:50:22 <sandywalsh> I assumed donabe more operations oriented, not nova internal? no?
21:50:40 <salv-orlando> dendrobates?
21:50:48 <vishy> pvo, sandywalsh: It is more related to creating groups of resources i think
21:50:49 <pvo> I would think there would be some of the same retrying/requeueing in tehre as well
21:50:59 <vishy> where as this is more concerned with the state of individual resources
21:51:28 <vishy> does anyone here care particularly about Operational Support
21:51:30 <sandywalsh> resources and the workflows around them
21:51:42 <vishy> including admin apis, cli tools, etc?
21:52:01 <pvo> vishy: we do... I'm repping for our ops guys today
21:52:11 <anotherjesse> vishy: we should volunteer chmouel or others from deployment team
21:52:34 <vishy> sleepsonthefloor: are you able to lead the feature parity section?
21:52:48 <sleepsonthefloor> vishy - for sure
21:53:27 <sleepsonthefloor> salv-orlando - you interested in helping  then?
21:53:33 <vishy> ok, so i need someone to take the lead on Upgrades, Operations, Security
21:53:56 <salv-orlando> sleepsonthefloor: on feature parity? Yes.
21:53:59 <pvo> vishy: let me get back to you on the ops part.
21:54:07 <vishy> pvo: ok
21:54:14 <pvo> I'm recruiting some of our ops guys to take a more active role in the open.
21:54:16 <vishy> pvo: are you leading upgrades?
21:54:38 <pvo> me or Dietz.
21:54:38 <vishy> rjh: shall I put you on the lead for security planning?
21:54:41 <anotherjesse> vishy: I'm not sure if pvo is a good fit - as they will run an internal version - upgrades is more about shipped software?
21:55:00 <rjh> ok
21:55:04 <vishy> anotherjesse: good point
21:55:17 <anotherjesse> vishy: someone in canonical or citrix or others who ship software based on milestones / releases
21:55:25 <anotherjesse> crowbar?
21:55:28 <pvo> its more how to do upgrades is what were thinking. procedures and best practices.
21:55:41 <vishy> anotherjesse: perhaps someone from canonical will step in here
21:55:43 <pvo> you're meaning make sure upgrades work from Diablo to pre-Essex?
21:55:50 <anotherjesse> diablo to essex
21:55:54 <vishy> pvo: it is diablo to essex
21:56:11 <pvo> essex-pre release... sure. Yes, probably not the right guy there
21:56:19 <salv-orlando> vishy: we at Citrix have definitely interest in upgrades. Unfortunately our 'upgrade' men are not here tonight
21:56:26 <pvo> we won't be doing massive upgrades every 6 months
21:56:35 <vishy> ok
21:56:36 <anotherjesse> pvo: right - not that you won't be able to contribute and have lots of good feedback - but when you run a service you can do 100 upgrades between diablo and essex in stages (gradual db migrations, ...)
21:56:55 <vishy> guys, I need some suggestions for how these groups should keep in touch
21:56:56 <pvo> anotherjesse: yep. Totally valid point
21:57:07 <pvo> walkie talkies
21:57:15 <anotherjesse> pvo: you should definitely have folks on the team
21:57:18 <vishy> should we start little mailing lists for all of them like we did for the volume group?
21:57:23 <pvo> anotherjesse: absolutely will
21:57:30 <anotherjesse> vishy: does lp teams give you a mailing list?
21:57:50 <pvo> anotherjesse: I believe it does
21:57:52 <vishy> anotherjesse: yeah
21:57:58 <vishy> that is how we did it for voluems
21:58:16 <anotherjesse> teams with open enrollment (or somethign else?) seems valuable
21:58:31 <vishy> anotherjesse: ok
21:58:49 <vishy> #action vishy to create subteams for mailing list communication
21:58:56 <anotherjesse> vishy: melange integration into nova - ?  is that an essex thing?
21:59:08 <vishy> #info subteams will be open enrollment
21:59:26 <vishy> #info each team will have a poc so that vishy has someone to bug
22:00:11 <vishy> #info subteams are responsible for creating blueprints for needed work and helping vishy target them to specific milestones
22:01:14 <vishy> #action vishy to go through the registered blueprints and accept them and assign them to the subteam.
22:01:40 <vishy> #info subteam leader can reassign the blueprints to specific individuals or real teams to do the actual work
22:01:53 <vishy> Ok guys, I don't want to make this too heavyweight
22:02:12 <vishy> But there are way too many people working on the code for me to keep tabs on all of this at once, so I appreciate the help
22:03:07 <vishy> I will create open launchpad groups for all of these teams so that they can communicate
22:03:32 <vishy> i think there is already an operations team, so I might just use that one.  Although I specifically want dev help for tool and admin api createion
22:03:55 <vishy> Any other subteam that we're missing?
22:04:28 <anotherjesse> melange?
22:04:44 <anotherjesse> (integration)
22:04:44 <salv-orlando> I think there is alread a melange team
22:04:49 <salv-orlando> ah ok
22:05:40 <vishy> #topic What do we do with melange
22:05:51 <vishy> lets take a minute and plan that
22:06:20 <vishy> any input on melange?
22:06:36 <anotherjesse> right now nova-network doesn't use it - if we integrate it then we should update nova-network?
22:06:50 <anotherjesse> (melange=ipam)
22:06:50 <vishy> anotherjesse: perhaps
22:07:01 <jk0> I think it has a long ways to go before it can merge into trunk
22:07:06 <vishy> anotherjesse: why not just keep it separate
22:07:12 <salv-orlando> in QuantumManager we allow users to either use traditional nova IPAM or Melange
22:07:23 <vishy> anotherjesse: if the merge was an easy refactor inside was better
22:07:24 <salv-orlando> we could do the same in Flat & VlanManager
22:07:37 <jk0> +1 on keeping it seprate
22:07:38 <vishy> anotherjesse: just let melange support quantum
22:07:47 <anotherjesse> has anyone investigated the level of effort to make nova-net use melange?
22:07:51 <bhall_> vishy: +1
22:08:29 <vishy> anotherjesse: no, but I'm worried about the two integration points
22:08:42 <vishy> quantum is already integrating, so we save work by just using that integration
22:09:06 <salv-orlando> vishy: +1
22:09:30 <anotherjesse> salv-orlando: my goal would be to kill the nova-ipam to make things simplier - instead of making both quantum and nova-net use both
22:09:41 <anotherjesse> but I'm good with waiting - just want to make sure
22:09:45 <vishy> are any of the key melange devs here?
22:10:02 <vishy> anotherjesse: does quantum use both?
22:10:04 <jk0> they're mostly/all in India
22:10:06 <salv-orlando> I know only Troy and Rajaram
22:10:14 <bhall_> vishy: it can, currently
22:10:45 <bhall_> (by quantum I'm asuming you mean quantummanager)
22:11:08 <salv-orlando> just to be precise, quantummanager is nova-net manager for quantum
22:11:40 <vishy> salv-orlando: so there is no integration in quantum itself?
22:11:54 <bhall_> vishy: that's correct
22:12:00 <salv-orlando> vishy: no, we actually do it in nova-network!
22:12:27 <vishy> anotherjesse: in that case it sounds like the integration is fairly easy
22:12:49 <salv-orlando> I don't see it as a major hurdle. bhall_ might have more details
22:12:58 <bhall_> yeah, I don't think the integration would be that bad
22:13:10 <vishy> bhall_: but you think it should be separate?
22:13:11 <anotherjesse> vishy: it is a 10k line diff - just worry about it living in the edge too long and not getting attention
22:13:24 <vishy> anotherjesse: does it need attention?
22:13:27 <salv-orlando> (integrating, or replacing nova's IPAM as anotherjesse suggested)
22:13:52 <anotherjesse> vishy: given that we haven't looked at it outside of the quantum use case … maybe?
22:14:00 <vishy> anotherjesse: someone is going to have to spike this it sounds like
22:14:04 <anotherjesse> i'm suggesting a spike - ya
22:14:15 <pvo> we were just talking about this today
22:14:34 <pvo> I think they're going to try to figureo ut how to break it apart
22:14:39 <pvo> unknown if it can
22:15:04 <vishy> ok who can spike it?
22:15:24 <pvo> I think this is Trey or Koelker
22:15:29 <vishy> tr3buchet might be a good choice
22:15:29 <pvo> someone on my team
22:15:41 <vishy> pvo can you have the two of them look at it and come up with a plan
22:15:56 <vishy> considering a) our existing ip management sucks, what is the best path forward
22:16:09 <pvo> #action will coordinate a plan to get the network diff broken up
22:16:18 <vishy> pvo thx
22:16:21 <vishy> ok anything else
22:16:26 <anotherjesse> pvo: I feel that if we don't move to melange we will end up implementing most of the api in an os-extension
22:16:34 <vishy> #topic open discussion
22:17:52 <comstud> so
22:18:00 <comstud> reviews
22:18:13 <comstud> I've been cracking down on HACKING violations when reviewing
22:18:20 <anotherjesse> ++
22:18:34 <comstud> I dunno if this is the case or not... but it seems maybe there hasn't been a lot of attention paid to them
22:18:42 <vishy> hopefully these teams will help with the reviews
22:18:50 <comstud> Some of the stuff that annoys me in the code is general inconsistency
22:19:04 <anotherjesse> comstud: be strict but helpful?
22:19:07 <comstud> so I'm feeling like we could crack down a little more on that
22:19:08 <comstud> haha
22:19:12 <comstud> yeah
22:19:19 <anotherjesse> I kinda want a termie bot again - for the simple stuff
22:19:34 <vishy> there are a lot of cleanup related tasks needed that don't have blueprints
22:19:40 <tr3buchet> true
22:19:44 <jk0> there's a lot of stuff that isn't covered in HACKING
22:19:48 <salv-orlando> termie bot?
22:20:10 <vishy> #idea jesse suggested dedicated a couple of milestones to stabilization and cleanup
22:20:14 <salv-orlando> So it wasn't the real termie putting needs fixing for a missing linefeed on a docstring in my branch?
22:20:37 <tr3buchet> we could probably dedicate a release to it
22:22:18 <comstud> I hate making people fix little stuff like this.. for fear I'll come off like an asshole. :)  But..
22:22:33 <comstud> That's the main complaint I hear when someone new goes to look at the code
22:22:45 <comstud> A number of style differences... and then people not being sure which way they should do something
22:22:57 <pvo> comstud: +++
22:22:58 <comstud> HACKING is pretty simple to follow.. there's clear instructions there.
22:23:12 <vishy> maybe we need to add a link to hacking to how to contribute
22:23:18 <vishy> and the gerrit instructions
22:23:28 <sandywalsh> HACKING is good to enforce, sadly "pythonic" is much harder
22:23:38 <jk0> we can't really enforce something that isn't in HACKING. should we consider adding more to it?
22:23:38 <comstud> sandywalsh: Yeah, that's the thing.
22:23:39 <vishy> before typing git review: check HACKING, run tests, etc.
22:24:05 <salv-orlando> or enforce something like the termiebot as we enforce pep8
22:24:10 <anotherjesse> anyone not think it is reasonable to mark a patch "plz don't merge - needs fixing" if it has consistency issues?
22:24:26 <vishy> that is the point of code review, right?
22:24:33 <comstud> one point of it
22:24:38 <pvo> I think the question is which consistency
22:24:44 <pvo> whose consistency
22:24:46 <comstud> but 'consistency' right now doesn't mean a lot
22:24:48 <comstud> yeah
22:24:58 <tr3buchet> what else could be the point
22:25:02 <jk0> that's why I propose adding more things to HACKING
22:25:10 <comstud> tr3buchet: obvious bugs that tests don't catch
22:25:24 <anotherjesse> salv-orlando: termie bot was something justin-sb created to catch issues termie consistantly flagged
22:25:25 <tr3buchet> right right
22:25:27 <vishy> can someone add a set of instructions on running unit tests and code guidelines to the wiki
22:25:37 <jk0> indentations, single vs double quote usage, etc
22:25:45 <tr3buchet> consistency can always come in the form of refactoring
22:25:53 <bhall_> vishy: in quantum we have a "TESTING" file that talks about that.. might be good to have one in nova, too
22:26:01 <vishy> I'd like to see a nova contribution guidelines page
22:26:12 <sandywalsh> well that brings up the issue of unit tests vs. integration tests in the core test suite (nearly everything is integration currently)
22:26:17 <vishy> that we can link to from the gerrit instructions
22:26:41 <tr3buchet> it would be lovely to pare that down to unittests only
22:26:46 <vishy> sandywalsh: we need major unit test cleanup.  That is one of the large sections that doesn't ahve blueprints
22:26:56 <comstud> #agree
22:27:00 <vishy> do we need  a team for unit test cleanup?
22:27:05 <jk0> gotta admit, it was pretty nice back in the day when tests took less than a minute to run
22:27:13 <vishy> jk0: ikr
22:27:29 <tr3buchet> the good old days
22:27:42 <vishy> does anyone care about testing cleanup enough to spearhead an effort on it?
22:27:43 <sandywalsh> vishy, even if we could break it into smoke tests (pure unit tests) and "other" ... would be a great start
22:28:01 <vishy> I know ntt is adding more and more tests
22:28:05 <jk0> I think that would eventually help coverage too
22:28:20 <jk0> I'm afraid these complex "unit" tests scare people away from writing new ones
22:28:27 <comstud> vishy: Sooner rather than later would be good.
22:28:38 <sandywalsh> don't we need to unify our integration test efforts?
22:28:49 <comstud> vishy: I feel like I lose a lot of dev time with how long the tests take
22:29:01 <vishy> sandywalsh: yes but there is a team focusing on that
22:29:12 <sandywalsh> comstud, and people trying to understand the tests when something breaks
22:29:13 <vishy> comstud: I've been trying to parallelize
22:29:18 <comstud> vishy: yea
22:29:22 <tr3buchet> comstud, jk0: you can run individual modules
22:29:29 <comstud> tr3buchet: And I do
22:29:34 <jk0> well yeah
22:29:34 <tr3buchet> oh even then
22:29:40 <vishy> this seems like a big discussion
22:29:41 <sandywalsh> devstack to parallelize running the tests :D
22:29:41 <jk0> but you still have to run the entire suite before proposing merge
22:29:43 <comstud> tr3buchet: I run individual test cases sometimes as well..
22:29:51 <vishy> does anyone have a way forward on this?
22:30:00 <tr3buchet> i usually only end up running the "big test" after i'm finished and the module tests pass
22:30:18 <vishy> I'm pretty full with the blueprint and subteam stuff right now
22:30:19 <tr3buchet> i think sandywalsh had a good point
22:30:22 <comstud> right now.. i have something i'm working on..
22:30:28 <comstud> i'm not sure which tests will break exactly
22:30:31 <comstud> i have a rough idea
22:30:31 <vishy> so I don't have the brain power to come up with a plan here
22:30:32 <tr3buchet> breaking the tests into unittests and other
22:30:36 <comstud> so I run them all
22:30:43 <comstud> wait fora  breakage.. fix it by re-running the broken module
22:30:49 <comstud> then re-run the whole test suite again
22:30:51 <vishy> tr3buchet: do you want to lead that effort?
22:30:52 <comstud> wait for the next breakage
22:30:53 <comstud> repeat.
22:31:08 <vishy> I'm happy for a test cleanup team to be formed
22:31:24 <tr3buchet> vishy: if it comes down to it
22:31:50 <vishy> ok i will create the team and add tr3buchet , comstud , sandywalsh to it
22:31:51 <tr3buchet> vishy: sounds like i've got a good bit of work to do in the melange area
22:31:52 <comstud> i nominate dprince.. because he seems to not be here
22:31:54 <comstud> :)
22:31:58 <tr3buchet> +1
22:32:07 <jk0> I'd like to see bcwaldon on it too
22:32:07 <vishy> perhaps titan can take the lead on that
22:32:19 <jk0> he seems to know his way around the tests
22:32:25 <vishy> #action vishy to try to find a lead for testing cleanup team
22:32:31 <comstud> i'm mostly serious about dprince, because he seems to have use passion for tests
22:32:37 <comstud> use/huge
22:32:39 <vishy> s1rp_: seems to care a lot too
22:33:00 <tr3buchet> don't forget jaypipes
22:33:02 <jk0> agreed, s1rp_ and waldon come to mind when I think 'tests'
22:33:03 * comstud queues 'we care a lot'
22:33:10 <sandywalsh> I'm busier than a two-headed woodpecker ... don't know how valuable my contributions will be (from here)
22:33:13 <vishy> there is already a qa team
22:33:23 <tr3buchet> yea that's my thought too sandywalsh
22:33:32 <vishy> sandywalsh: I'm going to be on all of these teams, so yay me
22:33:37 <sandywalsh> heh
22:33:50 <sandywalsh> vishy, that's your lot in life though
22:33:51 <tr3buchet> hey you let them talk you into being the king of openstack
22:34:01 <vishy> tr3buchet: :(
22:34:03 <vishy> sigh
22:34:12 <vishy> ok i will create these teams
22:34:20 <vishy> and we will see how things shake out over the next week
22:34:24 <tr3buchet> are we going to have blueprints?
22:34:28 <vishy> time to finish this meeting
22:34:44 <vishy> #endmeeting