20:03:24 <markmc> #startmeeting tc
20:03:25 <openstack> Meeting started Tue Mar 11 20:03:24 2014 UTC and is due to finish in 60 minutes.  The chair is markmc. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:28 <openstack> The meeting name has been set to 'tc'
20:03:32 <SergeyLukjanov> o/
20:03:34 <devananda> lifeless: o/
20:03:38 <markmc> tonight's agenda
20:03:38 <markmc> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:45 <DinaBelova> o/
20:03:51 <markmc> first up is DinaBelova  :)
20:03:52 <markmc> #topic Climate incubation request
20:03:59 <bauzas> o/ (Climate core dev)
20:04:00 <markmc> #link http://lists.openstack.org/pipermail/openstack-tc/2014-March/000548.html
20:04:20 <markmc> DinaBelova, maybe we could start by you summarizing the feedback you received on the thread so far?
20:04:27 <DinaBelova> ok, cool
20:04:50 <DinaBelova> so first of all, as I understood from ML this idea seems quite interesting to many people
20:04:54 <DinaBelova> but the is one moment
20:04:57 <jeblair> #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/028646.html
20:05:04 <DinaBelova> noticed by almost everyone
20:05:19 <DinaBelova> now there is no program that could accumulate CLimate idea
20:05:24 <DinaBelova> and not only climate
20:05:56 <DinaBelova> as I got from ML there is a good change that probably in future resource time management + scheduling + .. might have one program
20:06:40 <DinaBelova> so here you may see interest to create one program for climate, gantt, all other possible projects working with resources allocation/reclaiming
20:06:59 <DinaBelova> speaking about requirements, Climate fit well
20:07:16 <DinaBelova> problem is with place to set it OS - I mean gap in the program
20:07:34 <bauzas> Gantt is pretty young for standing by its own program
20:07:49 <DinaBelova> it could be Reservation program for Climate - but it looks it's wrong way looking on comments
20:07:58 <DinaBelova> bauzas, I mean possibly :)
20:08:06 <DinaBelova> as said in many comments
20:08:22 <markmc> so the summary might be that a program scope based on reservations is too narrow
20:08:37 <DinaBelova> markmc, it looks so
20:08:40 <markmc> and you should attempt to collaborate with those interested in the wider scheduling area ?
20:09:03 <bauzas> we already began collaborating with Gantt
20:09:33 <russellb> though gantt is pretty much dead right now ... the current work is back in nova
20:09:38 <bauzas> at the moment, that's draft discssions
20:09:42 <DinaBelova> well, I think that projects responsible for different scheduling types still should be different projects, but now it seems that there should be separated program for it
20:10:08 <russellb> i do think a scheduling program makes sense longer term, but we don't have a scheduler project that can fit there yet
20:10:36 <russellb> but the people in the scheduler program could just coordinating with nova to help prepare for thta
20:10:54 <bauzas> russellb: that's the idea we're following
20:10:59 <russellb> ok
20:11:14 <bauzas> russellb: we're keeping track on what's happening with Gantt
20:11:25 <bauzas> (I mean the forklift effort)
20:11:26 <DinaBelova> so If Gantt is pretty much dead, we can start resource scheduling program with only Climate in it (scheduling == reservation) with possibility to consume more scheduling projects in future
20:11:31 <sdague> I think we've been talking about the need for a cross project scheduler for a while, that we should probably assume thats the direction things end up heading
20:11:31 <markmc> if the scheduler work is going on in nova, would it make sense to add climate's idea of reservations to nova directly?
20:11:42 <russellb> markmc: i've been thinking about that
20:11:43 <jgriffith> sdague: +1
20:11:43 <dhellmann> sdague: +1
20:11:51 <sdague> markmc: that seems like a better idea than being separate
20:11:56 <dhellmann> I'd like to have our default answer stop being "add it to nova"
20:12:00 <russellb> DinaBelova: what other resources does climate aim to do reservations for?
20:12:03 <russellb> right now it just does VMs?
20:12:22 <markmc> dhellmann, let's equally not assume it's always the wrong answer, though
20:12:24 <russellb> aside from the usual "please don't add more to nova" concern, why should we *not* implement this in nova?
20:12:29 <dhellmann> markmc: sure
20:12:37 <lifeless> I see reservations and scheduling as being tightly connecteed
20:12:39 <DinaBelova> russellb, Vms and compute hosts. But in nearest future we're planning volumes and storage nodes reservation
20:12:40 <dhellmann> markmc: but instances aren't the only things we need to schedule, are they?
20:12:47 <sdague> dhellmann: I think that's fine, however it doesn't seem like we've got enough drive to get this thing stood up on it's own
20:12:48 <jgriffith> russellb: actually it seems to me that if it even belongs it likely belongs in nova
20:12:52 <markmcclain> russellb: seems that there a resources that aren't owned by nova one could reserve
20:12:59 <markmc> dhellmann, instances aren't the only thing we have e.g. quotas or scheduling for, either
20:12:59 <lifeless> you want to be able to describe a large topology and essentially schedule it across all APIs at once
20:13:06 <jgriffith> but I'm struggling to see if there's a real need here, and how you actually do it succesfully
20:13:15 <DinaBelova> dhellmann, yes, we plan more different resources to reserve
20:13:22 <lifeless> russellb: because cinder, neutron.
20:13:23 <russellb> and if there are resources elsewhere, should the reservations be a part of the API that owns those resources?
20:13:34 <annegentle> with orchestration being more prevalent, it seems useful to schedule across apis
20:13:37 <russellb> should this be a type of thing we should be implementing in each API?
20:13:39 <dhellmann> markmc: right, I said schedule :-)
20:13:50 <lifeless> holistic scheduling and holistic reservations are pretty linked, no ?
20:13:53 <jgriffith> It seems like this breaks existing limits/quota models
20:13:54 <markmc> dhellmann, sorry, I read reserve :)
20:13:55 <sdague> DinaBelova: I do think a bunch of what climate was proposing could just enhance nova today and be useful
20:14:03 <jgriffith> not that I'd be heart broken about that :)
20:14:09 <dhellmann> and not putting it directly in nova doesn't mean making its own service -- it could be some shared library code
20:14:09 <annegentle> jgriffith: heh
20:14:26 <russellb> jgriffith: right, quotas are located with the resources, so why not reservations?
20:14:36 <markmc> dhellmann, +1 on "could be library code"
20:14:36 <russellb> dhellmann: yes
20:14:43 <markmc> dhellmann, it could evolve out of nova code, though
20:14:51 <DinaBelova> sdague, idea of Climate is also to provide notifications about leases events, workflows (possibly using mistral) of how resources should be managed that time etc
20:14:52 <markmc> dhellmann, question is more about where the REST API is exposed
20:14:52 <sdague> so it seems like there are 2 different things going on
20:14:58 <dhellmann> but it sounds like DinaBelova and the rest of the climate team are working with the other interested parties, and aren't really ready for incubation yet, is that right?
20:14:59 <mikal> DinaBelova: how mature is climate? Do you have it working for any openstack project at the moment?
20:15:14 <dhellmann> markmc: evolution could work, yes
20:15:16 <DinaBelova> sdague, that's why I don't really believe that this stuff should be placed in nova
20:15:17 <sdague> 1) features that climate team wants beyond what's in nova today, which are mostly compute, which could be contributed to nova
20:15:36 <sdague> 2) and the global scheduler many of us want, that we are a ways away from
20:15:49 <DinaBelova> mikal, yes, for Nova
20:15:50 <jgriffith> Can we take a step back for a second
20:16:02 <russellb> let's not confuse this with the global scheduler either, which could quite likely be an internal only API
20:16:02 <jgriffith> There's a lot of mixed conversation about "global scheduler" here
20:16:11 <sdague> jgriffith: agreed
20:16:12 <jgriffith> I don't see anything in climate that suggests that as a goal
20:16:15 <russellb> related, but separate
20:16:23 <jgriffith> russellb: kinda
20:16:25 <jgriffith> yeah
20:16:29 <sdague> jgriffith: so that's probably true
20:16:47 <jgriffith> I'd like to focus on first does this even make sense?
20:16:54 <bauzas> there are multiple concerns here
20:16:54 <sdague> the push back was that this kind of service really needed to be done in concert with a scheduler to make sense
20:16:54 <jgriffith> time based reservations of resources
20:17:05 <jgriffith> sdague: maybe, but I see other problems
20:17:08 <sdague> sure
20:17:13 <russellb> the functionality makes sense i think
20:17:18 <jgriffith> first being whehter the idea is even sound IMO
20:17:25 <russellb> it's really just stepping back and figuring out where it actually fits and where it should live
20:17:30 <dhellmann> jgriffith: it sounds like you have reservations about the idea
20:17:32 <jgriffith> second being integration with existing quotas and limits as I mentinoed
20:17:39 <jgriffith> dhellmann: that's accurate
20:18:01 <dhellmann> jgriffith: care to elaborate?
20:18:17 <jgriffith> So firstly, I am trying to understand the value
20:18:28 <jgriffith> Is there real value in in this?
20:18:31 <bauzas> the idea is that there are possibly mixed resource types that a lease can have
20:18:54 <markmc> DinaBelova, I think I could summarize the value for jgriffith, but perhaps best if you do ?
20:18:54 <jgriffith> I mean, the whole point is our resources are meant to be elastic
20:19:02 <bauzas> like we should want to reserve a volume and boot on it
20:19:03 <DinaBelova> markmc, ok
20:19:13 <lifeless> jgriffith: elastic but exhaustible
20:19:17 <markmc> value both for users and operators
20:19:19 <jgriffith> lifeless: indeed
20:19:27 <jgriffith> but I'd argue this makes that problem even worse
20:19:27 <DinaBelova> jgriffith, idea is to potentionaly provide time based resource management to OS
20:19:31 <lifeless> jgriffith: (ask any bm cloud operator :))
20:20:04 <jgriffith> so I have tenants with time based reservations
20:20:14 <jgriffith> what happens when the "time" is up and they need resources
20:20:17 <DinaBelova> jgriffith, so user will have opportunity just to reserve some reources in future, and cloud providers will know about future load picks to manage them correctly
20:20:26 <jgriffith> how is this any different than today
20:20:30 <sdague> jgriffith: time based reservations are really useful for things like HPC on openstack
20:20:30 <annegentle> jgriffith: if your orchestration job doesn't fail until you run out of some resource that wasn't reserved, sad user
20:20:33 <jgriffith> or do you false reserve?
20:20:34 <sdague> which a lot of folks are doing
20:20:44 <sdague> when time is up, they want those things shot in the head
20:20:44 <annegentle> jgriffith: but I see it more in the quota arena really
20:20:50 <DinaBelova> jgriffith, it depends on configuration - like create snapshots for all VMs and kill them later
20:20:54 <jgriffith> sdague: no, I mean the other way around
20:21:07 <jgriffith> sdague: my understanding is they want to "reserve things for future use"
20:21:09 <mikal> DinaBelova: so, looking at the prototype nova scheduler code for this makes me wonder. Why can't this just be expressed with aggregates?
20:21:16 <lifeless> jgriffith: I think you are saying 'deploy the thing rather than reserving the right to deploy it' ?
20:21:19 <dhellmann> jgriffith: do you mean when the time at the start of the reseration period comes?
20:21:24 <DinaBelova> quota that's way to implement resource reservations, but not to manage them
20:21:24 <sdague> jgriffith: yes, sure
20:21:34 <jgriffith> lifeless: dhellmann what I'm saying is:
20:21:54 <jgriffith> one use case that was given was reserve a resource for usage at some time in the future
20:21:59 <jgriffith> so I interpretted as:
20:22:00 <DinaBelova> mikal, aggregates are only for compute reservations, but we target all types of resources
20:22:09 <jgriffith> Hey... I need a medium instance on Monday
20:22:15 <jgriffith> get ready... make sure I have it
20:22:29 <jgriffith> I see nothing but trouble there
20:22:37 <jgriffith> Having expirations on resources I get
20:22:45 <jgriffith> that's fine and easy enough IMO
20:22:52 <jgriffith> but belongs in the project owning the resource
20:22:54 <dhellmann> funny, expiration is the part I don't get :-)
20:22:59 <jgriffith> dhellmann: LOL
20:23:18 <jgriffith> just auto-delete so people don't hang on to things
20:23:21 <markmc> (time check - need to switch topic in a couple of minutes, say at 25min past the hour)
20:23:23 <jgriffith> but I wouldn't do that with Cidner
20:23:25 <jgriffith> cinder
20:23:36 <russellb> yeah the more i think about it, the more i find it very odd from the API consumer perspective to have to go to another API for this
20:23:40 <jgriffith> evaporating data isn't going to make for happy users
20:23:47 <sdague> jgriffith: it might
20:23:51 <russellb> i think we should look in more detail at what integrating this into nova itself would look like
20:23:55 <DinaBelova> we have idea to create reservations for diffrent resources types, so you'll have opportunity to prolong them all
20:23:58 <dhellmann> russellb: or heat?
20:23:59 <sdague> if they really need 20G for the next week
20:24:04 <mikal> russellb: I agree.
20:24:06 <sdague> to do some computation on
20:24:10 <markmcclain> russellb: +1
20:24:18 <sdague> russellb: yeh, I think I agree
20:24:22 <jgriffith> I'd also like to understand how it plays with the existing limit and quota modeal as I mentioned
20:24:31 <devananda> it sounds like there also needs to be a discussion about non-compute resource scheduling
20:24:32 <sdague> it should be nova enhancements until proven that it can't be
20:24:33 <jgriffith> I think there's potential for significant conflicts
20:24:35 <devananda> as DinaBelova keeps pointing out
20:24:45 <dhellmann> devananda: +1
20:24:49 <sdague> jgriffith: I also agree this raises interesting problems with quota
20:24:58 <jgriffith> devananda: ok, now we're talking scheduling again :)
20:25:01 * markmc tries to wrap up with a summary
20:25:05 <russellb> right, but i think it's just a common problem we have to solve across existing APIs
20:25:07 <lifeless> jgriffith: russellb: the thing I think we haven't (as a group) figured out is how holistic /anything/ should fit in
20:25:18 <lifeless> e.g. holistic scheduling, or holistic reservations, quotas etc.
20:25:20 <sdague> but I actually think that will become more clear with a first implementation in nova
20:25:31 <jgriffith> lifeless: I'd argue we've swung to the other extreme
20:25:33 <lifeless> right here isn't the forum to figure that out
20:25:36 <jgriffith> lifeless: service/project for EVERYTHING
20:25:37 <markmc> #agreed climate developers encouraged to pursue their reservation ideas as an API addition to nova, explore tighter integration with future global scheduler
20:25:40 <markmc> fair ?
20:25:45 <russellb> yes
20:25:46 <jgriffith> regardless of benefit
20:25:46 <sdague> markmc: +1
20:25:53 <jgriffith> markmc: yes... sorry
20:26:14 <lifeless> markmc: sounds fine for now; it doesn't make anything better or worse vis-a-vis future work AFAICT
20:26:27 <markmc> cool
20:26:31 <DinaBelova> well, it looks like we'll have further discussions here :)
20:26:36 <russellb> yep
20:26:42 <russellb> we should have a cross project session on this in atl
20:26:46 <markmc> DinaBelova, sounds like everyone is very interested to dig deeper into the details of the concept
20:26:50 <lifeless> we do need to figure out the story for big clusters with complex api deps so folk don't half-deploy 1000 machines before an error turns up
20:26:58 <DinaBelova> russellb, yes, please
20:27:01 <markmc> DinaBelova, concept of reservations, I mean
20:27:02 <lifeless> but like I say, thats orthogonal
20:27:03 <annegentle> lifeless: +1
20:27:10 <DinaBelova> I think cross project session could help here
20:27:16 <devananda> ++ to cross-project session on scheduling/reservations
20:27:30 <DinaBelova> and how that might potentially work with global scheduling idea
20:27:35 <DinaBelova> devananda, +1
20:27:45 * markmc moves on
20:27:48 <markmc> #topic Savanna graduation review
20:27:48 <markmc> #link http://lists.openstack.org/pipermail/openstack-tc/2014-February/000544.html
20:27:55 <markmc> SergeyLukjanov, you're up :)
20:27:59 <SergeyLukjanov> I'm here ;)
20:28:01 <SergeyLukjanov> #link https://etherpad.openstack.org/p/savanna-graduation-status
20:28:04 <jeblair> s/Savanna/Sahara/
20:28:06 <SergeyLukjanov> markmc, thx
20:28:06 <markmc> SergeyLukjanov, care you summarize where you're at
20:28:12 <SergeyLukjanov> jeblair, exactly
20:28:27 <markmc> what's changed during incubation, what the TC's feedback was to your original application, how you've dealt with the feedback ?
20:28:29 <SergeyLukjanov> we're in the middle of renaming process, so, we'll release Savanna as Sahara in Icehouse
20:28:57 <SergeyLukjanov> markmc, the most feedback during the incubation was about the heat usage and clustering
20:29:06 <SergeyLukjanov> heat integration was fully implemented
20:29:17 <SergeyLukjanov> and we're ready to amke it default for I release
20:29:25 <SergeyLukjanov> (I think after renaming hell...)
20:30:05 <SergeyLukjanov> re clustering it was discussed on summit with trove folks and it was decided to postpone this to the time when will have more porjects like trove and savanna
20:30:13 <SergeyLukjanov> to better see the common part
20:30:42 <SergeyLukjanov> as for about graduation requirements
20:30:55 <SergeyLukjanov> as you can see in pad https://etherpad.openstack.org/p/savanna-graduation-status we think that all of them solved
20:31:04 <SergeyLukjanov> we have a bunch of tests in tempest
20:31:20 <SergeyLukjanov> and both sahara and it's client gating using them for several month
20:31:25 <SergeyLukjanov> (voting)
20:31:44 <SergeyLukjanov> here are the logs from the mid cycle graduation review - http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-01-14-20.02.html
20:31:54 <markmc> SergeyLukjanov, on the async gate thing - how often do you see changes in other projects breaking sahara ?
20:31:54 <SergeyLukjanov> quote: Savanna is in good shape too, some concerns about lack of diversity in contributors but might be a reflection of a niche project (ttx, 20:50:17)
20:32:01 <markmc> #link http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-01-14-20.02.html
20:32:27 <SergeyLukjanov> markmc, we have jobs on devstack/tempest and d-g
20:32:40 <SergeyLukjanov> and it never breaks us for the time we're gating
20:33:16 <SergeyLukjanov> re diversity, I've make a note about this in pad
20:33:25 <SergeyLukjanov> Currently we have 52% of commits from Mirantis and this number is decreasing well (it was 65% on the mid graduation review in Jan, just 1.5 month ago!)
20:33:39 <SergeyLukjanov> and it was about 90% in time of incubating
20:33:53 <dhellmann> nice
20:34:06 <markmc> #link http://www.stackalytics.com/?release=icehouse&metric=commits&project_type=openstack&module=savanna-group&company=&user_id=
20:34:22 <markmc> seems like  a nice mix of developers and companies, and a fair amount of changes
20:34:29 <SergeyLukjanov> personally, I'm really happy that we're bringing folks from other ecosystems
20:34:36 <SergeyLukjanov> like Hortonworks folks
20:34:45 <SergeyLukjanov> to OpenStack eco
20:35:05 <annegentle> o/
20:35:40 <SergeyLukjanov> re release process - ttx manage our release starting from i1
20:35:50 <SergeyLukjanov> successfully for 3 release
20:35:57 <SergeyLukjanov> releases*
20:36:10 <markmc> all very cool
20:36:15 <markmc> any questions from tc members?
20:36:16 <russellb> you guys seem like you've really had your act together
20:36:19 <russellb> nice work
20:36:20 <annegentle> Just a question while reading the API docs, why is there an EDP doc? What's EDP? I get HDP is Hortonworks Data Platform.
20:36:29 <SergeyLukjanov> oh, the new name "Sahara" was verified and approved by Foundation lawyers
20:36:39 <SergeyLukjanov> russellb, thx
20:36:46 <SergeyLukjanov> annegentle, EDP == Elastic Data Processing
20:36:54 <sdague> yeh, agreed, the team has really stepped up
20:36:55 <aignatov> annegentle: EDP is feature of Sahara
20:37:11 <SergeyLukjanov> annegentle, it's our codename for jobs/workloads management
20:37:16 <aignatov> key component I'd say
20:37:19 <jeblair> the savanna/sahara team has been on top of gating jobs, etc
20:37:25 <russellb> elastic data processing right?
20:37:32 <SergeyLukjanov> russellb, exactly
20:37:32 <sdague> honestly, I think from a QA perspective they've done everything that they can with out infrastructure until we have some real multinode infra
20:37:36 <russellb> oh you said that sorry
20:37:39 <aignatov> russellb: yes
20:37:48 <sdague> "with our"
20:38:03 <SergeyLukjanov> annegentle, re api - our 1.1 API consists of 1.0 api + EDP stuff
20:38:12 <annegentle> SergeyLukjanov: ok it'd be great to define that - not nitpicking at all, I think you've done a good job with docs
20:38:25 <SergeyLukjanov> annegentle, that's why 1.1 doc contains only new stuff
20:38:38 <SergeyLukjanov> annegentle, thx for tip, will do
20:38:41 <jeblair> the savanna devstack jobs have indeed in place and functional for quite a while, and the team is really on board with all of our processes
20:39:06 <markmc> SergeyLukjanov, btw, you should propose a change to the openstack/governance repo to change status to integrated
20:39:13 <jgriffith> I've taken it for a spin and it went fairly well
20:39:17 <SergeyLukjanov> markmc, will do
20:39:17 <jeblair> sdague brings up a good point worth noting -- because of the poor support for multinode testing of heavy workloads, we aren't able to test all of sahara in the integrated gate at the moment
20:39:27 <jgriffith> also have a good deal of feedback from customers using it so I'm good
20:39:39 <jeblair> that's no fault of sahara's, and mirantis is filling in the gap with 3rd party ci
20:39:41 <sdague> jeblair: they have augmented that with 3rd party CI
20:39:43 <markmcclain> jeblair: but that also also applies to features of some integrated projects too
20:40:01 <mikal> jeblair: nova live migration for example
20:40:07 <SergeyLukjanov> jeblair, sdague, we're threating savanna-ci as mandatory vote
20:40:22 <sdague> markmcclain: sure, the point is from a judgement perspective they've done everything they can with our infrastructure
20:40:25 <SergeyLukjanov> jeblair, sdague, additionally we're thinking about fake plugins that could be tested in the current gate
20:40:34 <markmcclain> sdague: agreed
20:40:44 <sdague> which I'll consider sufficient, as they did everything they could
20:40:54 <sdague> plus more, by adding 3rd party ci to fill in the gap
20:40:57 <jeblair> yep, that's not a cricicism -- i'm just noting it, and agree that they've handled it well.
20:41:11 <markmc> ok, when SergeyLukjanov submits the governance review, we can vote
20:41:30 <markmc> it's probably worth ttx bringing it up again next week, just to make sure there hasn't been feedback in the interim
20:41:37 <markmc> and to give his release management feedback
20:41:45 <SergeyLukjanov> jgriffith, Hortonworks are leaders in Hadoop ecosystem, so, the fact that they are one of three contribs is a significant mark IMO
20:41:53 <markmc> but we're looking good, AFAICT
20:42:03 <jgriffith> SergeyLukjanov: I'd agree with you
20:42:05 <SergeyLukjanov> markmc, it was a very good feedback from ttx on the mid cycle review
20:42:08 <jeblair> markmc: i agree on both points
20:42:34 <markmc> nothing else on sahara for now?
20:42:38 <SergeyLukjanov> oh, one more question - should I squash renaming with graduation CRs or not?
20:42:57 <markmc> probably keep them separate
20:43:07 <dhellmann> one thing: it looks like the API is built with flask, is that right?
20:43:13 <markmc> not sure when ttx will feel it appropriate to merge the change to integrated
20:43:13 <jeblair> yeah, i'm guessing we can quickly approve (or even just have ttx approve) the renaming ones
20:43:23 <markmc> perhaps it happens early in the next cycle?
20:43:30 <markmc> i.e. sahara isn't integrated in icehouse
20:43:39 <markmc> so, get the renaming merged first
20:43:44 <annegentle> markmc: right
20:44:03 <annegentle> we are queued up with reviews in the docs repos once the infra stuff is done
20:44:04 <SergeyLukjanov> dhellmann, yup, Pecan/WSME will be used for v2 api (planned to J)
20:44:18 <dhellmann> SergeyLukjanov: great, thanks for clarifying that
20:44:32 <markmc> ok, moving on
20:44:36 <markmc> #topic Integrated projects and new requirements: Neutron
20:44:36 <markmc> #link https://etherpad.openstack.org/p/IcehouseProjectReviewNeutron
20:44:36 <SergeyLukjanov> thank you all
20:44:40 <markmc> SergeyLukjanov, thank you
20:44:45 <dhellmann> SergeyLukjanov: good work!
20:44:50 <markmc> where were we on this?
20:45:20 <dhellmann> it got bumped from the agenda last week, right?
20:45:20 <markmcclain> as requested I've proposed a mission statement
20:45:27 <markmc> AFAIR - discussing whether, nowadays, the TC would require neutron to make parity with nova it's first order of business before graduating ?
20:45:53 <markmc> #link https://review.openstack.org/79744
20:46:12 <markmcclain> markmc: yea well I think we would require the project to spin out existing code vs starting from scratch
20:46:24 <markmc> #info Neutron proposed mission - "To implement services and associated libraries to provide on-demand, scalable, and technology-agnostic network abstraction."
20:46:58 <markmc> markmcclain, hmm, well we're not saying that to ironic
20:47:16 <markmcclain> ironic is a bit of different case
20:47:26 <jgriffith> markmcclain: not sure I understand what you're saying?
20:47:49 <jgriffith> markmcclain: You mean spin out the the nova-network code somehow?
20:47:50 <russellb> i think that's an implementation detail, we'd have to consider it case by case
20:48:01 <markmcclain> if we were to start neutron today.. following the cinder approach would be the preferred path
20:48:02 <russellb> i think the answer to the question is "yes", IMO
20:48:07 <markmcclain> that way you get parity from day 1
20:48:40 <jeblair> yeah, i don't really have an opinion on whether the code should be reused or not.  i do hold the opinion that i think feature parity and compatability are important for a component that intends to deprecate an existing component.
20:48:49 <sdague> jeblair: +1
20:48:51 <russellb> i think parity has to be goal #1 before adding *anything* else
20:48:51 <markmcclain> jeblair: +1
20:48:52 <russellb> that's the key
20:48:54 <jgriffith> jeblair: +1
20:49:22 <markmcclain> but from a time to success.. spinning out code and then iterating should be our preferred stance
20:49:24 <jgriffith> so elephant in the room....  Is this going to happen in Juno?
20:49:31 <markmc> or put it another way, graduating the new project should imply deprecating the old code ?
20:49:43 <russellb> yes
20:49:44 <markmc> the issue we're having is where we have the new project, but the old code isn't deprecated yet ?
20:49:49 <russellb> yes
20:49:50 <jgriffith> markmc: that I understand and vote yes
20:50:30 <sdague> markmc: yeh, graduating a new project that should include the deprecation of what it's intended to replace, imo
20:50:41 <russellb> and i think we have graduation requirements changes in place now to explicitly avoid it from happening again
20:50:54 <sdague> agreed
20:51:01 <russellb> so that's good ... though question is, what do we do with the current case
20:51:04 <markmc> russell, want to quote the one that covers it ?
20:51:06 <dhellmann> that's the basic approach I expect we'll take with oslo libraries, too
20:51:09 <russellb> sure
20:51:37 <russellb> paste bomb ...
20:51:39 <russellb> * Scope
20:51:39 <russellb> ** Project must not duplicate functionality present in other OpenStack projects,
20:51:39 <russellb> unless the project has intentionally done so with the intent of replacing it.
20:51:39 <russellb> ** In the case that a project has intentionally duplicated functionality of
20:51:39 <russellb> another project, or portion of a project, the new project must reach a level
20:51:40 <russellb> of functionality and maturity such that we are ready to deprecate the old
20:51:41 <russellb> code and remove it after a well defined deprecation cycle.  The deprecation
20:51:43 <russellb> plan agreed to by the PTLs of each affected project, including details for
20:51:45 <russellb> how users will be able to migrate from the old to the new, must be submitted
20:51:47 <russellb> to the TC for review as a part of the graduation review.
20:51:51 <jgriffith> russellb: at least you warned us
20:51:56 <russellb> :)
20:52:07 <markmc> deprecation plan agreed in order to graduate
20:52:16 <markmc> plan might be a future one
20:52:23 <markmc> we could just tighten that up a bit
20:52:26 <markmc> but yeah, cool
20:52:34 <russellb> yeah you're right
20:52:43 <jgriffith> can we back up for a second if there's not something pressing here?
20:52:47 <russellb> certainly was my intention that it's very concrete at that point
20:53:07 <jgriffith> We've got some cool general statements and ideals but I'm more curious about reality
20:53:07 <russellb> as in, old thing is deprecated now and will be removed in X
20:53:27 <markmc> jgriffith, we've only got 7 minutes, would be good to wrap up this neutron review
20:53:34 <jgriffith> the reality is that we've all but deprecated nova-network already
20:53:38 <jgriffith> markmc: ha
20:53:39 <jgriffith> ok
20:53:43 <russellb> jgriffith: that's not accurate
20:53:44 <markmc> sounds like it's on topic
20:53:48 <markmc> carry on
20:54:07 <annegentle> jgriffith: not from a docs perspective at alll
20:54:07 <russellb> we prematurely froze it, which caused problems, and dev is open again
20:54:14 <markmc> but yeah, not accurate
20:54:18 <jgriffith> russellb: ok... if that's not accurate I'm very confused because that was a concern/complaint several meeting ago by you
20:54:21 <annegentle> jgriffith: nor from operators
20:54:22 <jgriffith> ok
20:54:23 <markmc> the perception that we have is causing massive confusion for users
20:54:24 <jgriffith> fair enough
20:54:26 <jgriffith> but...
20:54:27 <jgriffith> my point is
20:54:36 <sdague> jgriffith: I think this was sort of the point of the piece above
20:54:36 <russellb> right, we more recently clarified that it's back open because of the problems
20:54:41 <sdague> we did a very confused thing here
20:54:47 <jgriffith> do we actually have an actionable plan and a deadline to finally put this to bed in Juno?
20:54:47 <russellb> and the confusion all of this has caused is another part of the problem here
20:54:58 <sdague> and confused our users and ourselves, so we both need to make sure it never happens again
20:55:03 <dhellmann> what do we want to have happen? finish the feature parity work?
20:55:06 <russellb> jgriffith: i think that's what we need to clarify right now :)
20:55:10 * jgriffith is tired of running two stacks :)
20:55:11 <sdague> and figure out how we move forward with neutron here
20:55:16 <sdague> jgriffith: ++
20:55:18 <russellb> goal: resolve this in juno
20:55:22 <russellb> but what if that doesn't happen?
20:55:30 <dhellmann> russellb: can you restate that goal without using any pronouns?
20:55:30 <jgriffith> neutron needs to be default, nova-net deprecated
20:55:31 <markmcclain> so the biggest item left to tackle is multi-host
20:55:42 <dhellmann> russellb: what is "this"?
20:55:44 <markmcclain> we already have teams working on it for J
20:55:48 <jgriffith> done.. move on in Juno IMO
20:55:55 <sdague> markmcclain: there is also migration path
20:55:55 <russellb> goal: get to where we can deprecate nova-network and have a clear migration path to neutron by juno
20:55:57 <jgriffith> markmcclain: understood
20:56:04 <jgriffith> I just want to actually have clear goals here
20:56:11 <russellb> markmcclain: we've been saying that for several releases :(
20:56:12 <jgriffith> and agreement from TC
20:56:15 <markmcclain> sdague: so the migration path has flip-flopped over time
20:56:16 <markmc> <russellb> but what if that doesn't happen?
20:56:18 <sdague> and neutron is still in the half of integrated projects that doesn't do upgrade testing
20:56:25 <markmc> this is gonna sounds bad, but worth discussing
20:56:33 <jgriffith> markmc: I have a suggestion for that
20:56:34 <markmcclain> now that it is back we're working on how to render the current constructs onto Neutron
20:56:37 <russellb> markmc: i think we have to, yes ...
20:56:42 <sdague> which remains an issue for making that the default
20:56:43 <markmc> why wouldn't we de-graduate until it was actually ready to deprecate ?
20:56:45 <jgriffith> if it doesn't happen then we give up
20:56:55 <annegentle> there's still a FFE for migration path for ML2 plugin I think
20:56:56 <russellb> markmc: that's what i've been thinking
20:56:56 <jgriffith> nova-network is the defacto networking project
20:57:03 <markmcclain> sdague: I spoke with the owner of the grenade ticket
20:57:23 <markmcclain> he's working on tracking down why some services aren't cleanly shutting down
20:57:28 <russellb> biggest concern is honestly PR, i think
20:57:28 <SergeyLukjanov> fyi savanna renaming https://review.openstack.org/79765 and sahara graduation voting https://review.openstack.org/79766
20:57:41 <lifeless> jgriffith: ++
20:57:51 <sdague> markmcclain: I've been on that review and provided some feedback, it really looks stalled, fwiw
20:57:51 <markmcclain> annegentle: the ML2 ticket is so that the neutron team can remove OVS and LB plugins from our tree
20:58:10 <lifeless> russellb: I think its more than PR
20:58:18 <markmcclain> it did stall for a bit, but I spoke with him this morning about it
20:58:24 <lifeless> russellb: if we degraduate that means neutron goes asymmetric gating, and thats a *terrible* position to be in.
20:58:28 <annegentle> markmcclain: ok good-o
20:58:38 <russellb> lifeless: we're already in a terrible position
20:58:38 <jgriffith> lifeless: +1
20:58:44 <lifeless> russellb: you're forever in chase mode, its driving devananda batty with Ironic, and TripleO batty with everything.
20:58:45 <annegentle> markmcclain: (and that's more cross-project meeting talk really, sorry)
20:58:46 <markmc> ok, we're almost out of time
20:58:48 <russellb> but we could make an exception to the gating bit
20:58:50 <markmcclain> lifeless: we're super close to running the full job
20:58:50 <russellb> if necessary
20:58:50 <jgriffith> russellb: so why make it worse or continue to suffer?
20:58:52 <lifeless> russellb: we are, but we don't need to maek it worse.
20:58:57 <markmc> frustrating, but we're still not done here
20:58:58 <russellb> then make a gating exception
20:59:05 <markmc> anyone care to take this to a mailing list thread?
20:59:07 <lifeless> the whole gating thing needs a revisit I think
20:59:11 <markmc> or just re-schedule it for the next meeting?
20:59:21 <russellb> markmc: i can start a thread
20:59:25 <russellb> tomorrow probably
20:59:34 <markmc> russellb, thanks
20:59:37 <jgriffith> markmc: I'd vote for next meeting, but not sure which portion of the topic exactly we want to talk about :)
20:59:39 <russellb> np
20:59:42 <jeblair> gating reflects our priorities, it shouldn't drive them.
20:59:43 <jgriffith> thread it is :)
20:59:43 * markmc moves on quickly
20:59:50 <lifeless> jeblair: +1
20:59:53 <markmc> #topic Other governance changes
20:59:54 <markmc> 1) Remove gantt from Compute Program
20:59:55 <markmc> #link https://review.openstack.org/79519
20:59:55 <markmc> 2) Add os-cloud-config to tripleo
20:59:55 <markmc> #link https://review.openstack.org/79229
20:59:55 <markmc> 3) Add some REST API post-graduation requirements
20:59:55 <markmc> #link https://review.openstack.org/68258
21:00:00 <markmc> #topic Open discussion
21:00:03 <markmc> 30 seconds ?
21:00:08 <jgriffith> haha
21:00:10 <markmc> anything pressing ?
21:00:14 <jgriffith> oslo
21:00:24 <dhellmann> ?
21:00:37 <markmc> ...
21:00:38 <jgriffith> if you change things out of oslo to fix a bug please please please push a fix back to oslo
21:00:47 <jgriffith> or make sure all theother projects are aware there's an issue
21:01:01 <jgriffith> Cinder spend signficant time yesterday on a known issue in the log.py module
21:01:03 <dhellmann> yeah, I've had a couple of cases this past week where folks had critical issues I didn't know about
21:01:04 <jgriffith> spent
21:01:07 <russellb> that should be -2'd by reviewers IMO...
21:01:11 <markmc> jgriffith, "change things out of oslo" == commit to $project/openstack/common ?
21:01:14 <jgriffith> russellb: it was in Nova
21:01:17 <dhellmann> markmc: yeah
21:01:21 <russellb> >_<
21:01:21 <jgriffith> markmc: yes!
21:01:27 <markmc> bah, shouldn't happen
21:01:29 <jgriffith> which in Cinder we promptly reject
21:01:32 <russellb> yeah that was a review fail
21:01:37 <dhellmann> the default for a logging format string
21:01:38 <russellb> normally rejected
21:01:41 <sdague> ok, so we're into next meeting :)
21:01:41 <jgriffith> but it seems other projects don't follow that mantra
21:01:47 <markmc> ok, outta time
21:01:51 <russellb> nova does (usually)
21:01:51 <markmc> jgriffith, post to the list ?
21:01:52 <dhellmann> yeah, this is a good topic for the project meeting
21:01:53 <markmc> thanks
21:01:57 <markmc> #endmeeting