21:01:25 <thingee> #startmeeting crossproject
21:01:26 <openstack> Meeting started Tue Mar 15 21:01:25 2016 UTC and is due to finish in 60 minutes.  The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:29 <openstack> The meeting name has been set to 'crossproject'
21:01:31 <nikhil> thingee: am still not on the list
21:01:55 * thingee adds nikhil now :(
21:01:58 <fhermeni> hello
21:02:02 <thingee> missed ya'll
21:02:03 <adam_g> hiya
21:02:05 <nikhil> thingee:  thx
21:02:05 <cdent> o/
21:02:11 <david-lyle> o/
21:02:14 <thingee> agenda today https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda
21:02:21 <thingee> pretty full so lets get to it!
21:02:22 <samapthP> o/
21:02:52 <thingee> #topic Compute node HA (a.k.a. automatic evacuation of instances
21:03:00 <bswartz> .o/
21:03:04 <mriedem> o/
21:03:04 <kencjohnston> o/
21:03:05 <thingee> #link http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html
21:03:10 <thingee> aspiers: hi!
21:03:13 <aspiers> hey :)
21:03:25 <EmilienM> o/
21:03:37 <aspiers> conscious that my slot doesn't have too much time
21:03:39 <angdraug> o/
21:03:51 <lifeless> \o/
21:03:54 <rockyg> Thanks thingee !
21:03:59 <aspiers> thingee: shall I kick things off?
21:04:02 <lifeless> \_/o/+
21:04:08 <thingee> aspiers: yes
21:04:08 <dtroyer> o/
21:04:09 <aspiers> ok
21:04:15 <aspiers> hi everyone :) I'm new to cross-project meetings so please bear with me :)
21:04:24 <aspiers> since Tokyo I've been moderating weekly meetings of the #openstack-ha IRC community
21:04:36 <aspiers> we've been collaborating on various approaches to implementing automatic "evacuation" of VM instances
21:04:36 <thingee> #link https://review.openstack.org/#/c/257809/ cross-project spec
21:04:54 <aspiers> "evacuation" is in quotes, because so far we've really been dealing with resurrection of dead VMs, via nova's evacuate API
21:05:14 <aspiers> however in the future, proactive evacuation of live VMs based on (say) alarms from ceilometer is certainly a possibility too
21:05:32 <EmilienM> alarms from Aodh*
21:05:39 <aspiers> right
21:05:41 <aspiers> :)
21:05:43 <aspiers> we've been trying to promote awareness of the various approaches out there
21:06:05 <aspiers> with the ultimate goal of facilitating convergence on a single implementation, if possible
21:06:23 <aspiers> you can find a summary of all known existing approaches (to resurrection) here:
21:06:32 <aspiers> #link https://etherpad.openstack.org/p/automatic-evacuation
21:06:48 <aspiers> first question from my side is: how cross-project is this, really? which projects do we expect to be affected?
21:06:58 <thingee> aspiers: do you mind telling us here and identifying in the spec the projects this involves?
21:07:00 <thingee> yes
21:07:02 <thingee> heh
21:07:12 <aspiers> sure
21:07:30 <aspiers> IMHO the answer is "probably less than 10 projects":
21:07:35 <aspiers> 1. obviously nova is involved :)
21:07:36 <mriedem> heh
21:07:58 <aspiers> 2. ceilometer
21:08:01 <aspiers> 3. aodh
21:08:11 <aspiers> 4. senlin is clearly aiming to be involved
21:08:35 <aspiers> 5. mistral - Intel have been working on a PoC where mistral orchestrates evacuation (ddeja who is here with us :)
21:08:53 <aspiers> 6. heat has been aired in the spec linked above as a possible alternative to mistral, not sure how realistic that is
21:09:06 <aspiers> 7. congress: I expect this to be needed in the future, to accommodate different recovery policies
21:09:12 <samueldmq> may the subset be defined by "any project involving quota management" + what triggers and what effectively does the ressurection ?
21:09:15 <aspiers> and maybe 8. cinder?
21:09:34 <rockyg> what about manila?
21:09:51 <jroll> I suspect someone wants this for ironic eventually, based on ideas I've seen, but this would just use nova live-migrate or something, right?
21:09:53 <aspiers> rockyg: I hadn't thought about manila yet :)
21:10:07 <aspiers> oh yeah of course: also ironic and Triple-O
21:10:10 <jroll> (so ironic, as a virt driver, would just work)
21:10:13 <elmiko> i'm curious if there are some criteria for determining if our project is affected? (something akin to what samueldmq said)
21:10:14 <jroll> (once it has migrate)
21:10:15 <aspiers> there's the whole question of fencing of compute nodes
21:10:23 <thingee> gordc, cdent ^
21:10:28 <mriedem> 25. watcher?
21:10:30 <aspiers> elmiko: not yet
21:10:39 <aspiers> yes quite possibly watcher too :)
21:10:45 <gordc> thingee: just reading spec now (missed some of earlier chatter)
21:10:51 <alaski> jroll: I think it's very likely this would use public apis in Nova, so ironic should "just work"(tm)
21:11:01 <jroll> alaski: cool, that's what I hoped
21:11:15 <aspiers> if congress is in charge of deciding what triggers workflows, then other projects don't necessarily have to be aware that data collected from them is being used in this way
21:11:17 <mriedem> yeah, nova already has the APIs for this as far as i know
21:11:22 <gordc> aspiers: have you look at the events ceilometer captures currently?
21:11:30 <thinrichs> aspiers: agreed
21:11:33 <bauzas> I don't see what Nova needs
21:11:41 <aspiers> gordc: not nearly as much as I should
21:11:56 <samueldmq> aspiers: elmiko: interesting, I'd expect that we had defined keywords to help identifying involved projects
21:11:57 <aspiers> bauzas: currently the nova evacuation process is not robust enough (I'm told)
21:12:00 <mriedem> fwiw, there is an ibm product that already does something like this, event-driven automatic evacuation, i could get names of people involved in that, they might also be invovled in this,
21:12:06 <mriedem> but they had some nova api extensions i believe
21:12:18 <mriedem> like rate limiting the migrations off the compute node
21:12:23 <mriedem> rather than just a huge batch
21:12:32 <aspiers> mriedem: yes that is one of the problems which needs tackling
21:12:38 <elmiko> samueldmq: yea, i'm very curious as i could a hypervisor dropout affecting sahara in a negative way
21:12:46 <aspiers> scalable scheduling
21:12:47 <elmiko> *i could see
21:13:04 <gordc> aspiers: i think quite a few of this is already captured in Ceilometer via messages sent from services or the polling done
21:13:22 <samueldmq> elmiko: ++
21:13:23 <shamail> aspiers: +1, the current prototype i’ve seen for Masakari specifies nova hosts for evacuation versus using the scheduler
21:13:34 <shamail> nova host*
21:13:36 <gordc> you can tell when a host or instance is up or down and provisioning failures i believe are already sent as events by nova
21:13:39 <bauzas> aspiers: well, evacuate for instance HA means that you resurrect your instance, and then impacting the users
21:13:59 <jroll> so, for the sake of time, what's the goal for this meeting? "should we pursue this" or?
21:14:06 <aspiers> there are lots of architectural considerations
21:14:07 <bauzas> jroll: ++
21:14:12 <aspiers> and jroll is right, we can't discuss them now
21:14:12 <shamail> I personally see it as instance recovery vs. availability
21:14:20 <samueldmq> jroll: ++
21:14:36 <mriedem> bauzas: also, you can't evacuate unless the compute is donw
21:14:37 <mriedem> *down
21:14:49 <aspiers> in the short time we have, I just want to understand how this relates to the cross-project team (if it's called a team, I'm not sure)
21:14:51 <mriedem> methinks anyway
21:15:04 <mriedem> aspiers: i'm not sure it does
21:15:06 <bauzas> yup, I was just explaining the problem about using evacuate for HA
21:15:11 <gordc> for those interested, comment on spec i guess? i have a feeling most of this is already covered across various projects
21:15:16 <thingee> aspiers: the spec was proposed in the repo
21:15:17 <thingee> :)
21:15:17 <mriedem> aspiers: if you have API needs in nova, then propose those as specs for nova
21:15:25 <aspiers> thingee: yeah, not by me ;-)
21:15:39 <thingee> ok, so I think we're saying, sure do this and use existing apis?
21:15:54 <cdent> thingee: that is what it sounds like
21:15:55 <thingee> and it shouldn't have been proposed spec as sdague mentioned earlier
21:15:56 <mriedem> thingee: and if there are gaps in the API, propose project-specific specs to fill those gaps
21:16:00 <_gryf> mriedem, I think all the api are in place, if we talking about nova
21:16:03 <thingee> mriedem: +1
21:16:06 <alaski> mriedem: +1
21:16:23 <aspiers> yup, I agree too
21:16:26 <jroll> mriedem: ++
21:16:28 <thingee> ok will leave a comment to have this spec abandoned
21:16:40 <aspiers> well
21:16:41 <thingee> #topic super scheduling
21:16:44 <mriedem> aspiers: hunt down jwcroppe if you haven't already
21:16:50 <aspiers> ok, thanks
21:16:52 <thingee> fhermeni: hi!
21:16:56 <fhermeni> hi there
21:16:57 <samueldmq> it'd be great to have a single bp to use cross-projects (in the topic of changes)
21:16:58 <thingee> #link https://review.openstack.org/#/c/210549/ spec
21:17:19 <fhermeni> (first OS meeting, be cool)
21:17:33 <thingee> got a lot of first timers today :)
21:18:14 <rockyg> fhermeni, we're generally a friendly bunch
21:18:22 <fhermeni> we’ll see
21:18:36 <elmiko> lol
21:18:43 <thingee> so we have no josh harlow, so I want to understand where are we going with this spec. I guess a little intro and what you need from the general cross-project team
21:19:04 <fhermeni> ok. Indeed, josh is afk (6am local time)
21:19:19 <fhermeni> so there is 2 objectives
21:19:46 <fhermeni> 1) expose a single entry for every scheduling aspect to allow to exhibit a higher perspective on scheduling expectations
21:20:07 <fhermeni> 2) abstract the scheduler a bit to decouple from existing implementation
21:20:23 <fhermeni> in that sense, you support the spec, you are suitable
21:20:52 <bswartz> I haven't read the spec yet
21:20:55 <bswartz> (but I will)
21:21:02 <fhermeni> so we designed the spec for being extensible, with a very few orthogonal concepts
21:21:09 <bswartz> does it at least acknowledge that the problem it's trying to solve is really hard?
21:21:22 <fhermeni> yes of course
21:21:37 <fhermeni> (I am writing VM placement algorithm since 10 years, I know it is hard ;))
21:21:38 <bswartz> okay
21:22:04 <bswartz> the exception cases are likely to be where it gets tangled up
21:22:07 <fhermeni> so we drafted a spec and wanted to have feedback from the involved communities
21:22:27 <thinrichs> fhermeni: I couldn't tell from the spec if you were proposing having a scheduler that makes decisions using all the state/context/data/resources of many different services, or if you were proposing an abstraction that all (local) schedulers would implement.
21:22:50 <bauzas> fhermeni: so we had kind of this discussion in the past during previous summits
21:22:57 <lifeless> every summit
21:23:00 <gordc> lol
21:23:05 <bauzas> fhermeni: that's why something popped up called Gantt
21:23:07 <lifeless> I don't think we can call it a summit without a scheduler session
21:23:18 <fhermeni> it is an abstraction. The backend may or may not fullfil all the expectation (the extensibility concern)
21:23:40 <bauzas> with the clear intent of splitting out the nova scheduler to be a separate project that others could consume
21:23:40 <fhermeni> lifeless: it is not a surprise to me
21:24:04 <bauzas> it was a dead-end for technical reasons at least, but also valid design concerns
21:24:10 <aspiers> this sounds a bit like a blog post I wrote last year http://blog.adamspiers.org/2015/05/17/cloud-rearrangement/
21:24:20 <gordc> bauzas: gnatt isn't active anymore is it?
21:24:28 <bauzas> gordc: nope, defunct
21:24:35 <gordc> kk. good to know
21:24:49 <fhermeni> as an academic, I observe there is about 50 VM placement algorithm that are proposed yearly. No one can propse or test a validation with OS because of the thigh coupling with Nova
21:25:09 <bauzas> mostly because we weren't having those stable interfaces we were needing to have
21:25:10 <fhermeni> decoupling might help
21:25:24 <gordc> fhermeni: is your scheduler completely original or does it leverage nova's scheduler?
21:25:34 <bauzas> fhermeni: see, the real problem of that is 2 words : tech debt
21:25:52 <fhermeni> bauzas: that is one of the point that require nova output
21:26:01 <fhermeni> bauzas: does the language wrap nova features
21:26:25 <thingee> so in the interest of time here, I agree with sdague and cdent that probably engagement should happen with nova here? I'm not really sure why this needs a cross-project spec.
21:26:25 <fhermeni> bauzas: and ofc I cannot reply objectively because I am out of nova and an OS newbie
21:26:31 <jroll> we keep saying vm placement, but this is about general resource placement, correct?
21:26:48 <samueldmq> thingee: ++
21:26:51 <cdent> thingee: just to be clear sdague and I have different ideas on how that engagement should happen
21:26:55 <rockyg> jroll, ++
21:26:59 <jroll> thingee: ++, I think if something like this gets pulled into nova, then it may require some cross-project work, but it needs to begin with nova
21:27:13 <bauzas> cdent: and I agree with sdake
21:27:18 <bauzas> damn
21:27:21 <bauzas> sdague
21:27:21 <thingee> cdent: sorry
21:27:29 <cdent> hoisted on your own tab key bauzas !
21:27:33 <cdent> :)
21:27:42 <bswartz> to do correct global placement is far larger than just nova
21:27:53 <rockyg> bswartz, ++
21:28:03 <bswartz> you need information about storage, networking, compute, and information that exists nowhere in openstack today
21:28:06 <rockyg> Congress would play a part
21:28:26 <fhermeni> I am ok discussing with nova ofc. The language is quite simple so I am not affraid about its suitability but it is quite different from the pending spec I read about the proposed generic api for nova
21:28:27 <rockyg> bswartz, you copied my keyboard!
21:28:30 <samueldmq> thingee: I think it could be useful to add 'keywords' in a spec, that'd identify what projects are affected
21:28:38 <nikhil> this will need to know about the placement of services too in such a case?
21:28:45 <bauzas> bswartz: that's exactly why we need stable interfaces and a correct model for describing resources
21:28:49 <thingee> samueldmq: sure
21:29:06 <samueldmq> thingee: so it will be easier to identify proposals that only relate (mostly) to a single project
21:29:13 <bauzas> both were not the case in nova a couple of months before, and that's gradually improving
21:29:19 <rockyg> bauzas, which is why this is crossproject.  More resources than just vms and compute nodes
21:29:37 <samueldmq> thingee: I will propose a change to the spec template
21:29:38 <bswartz> yeah I'm only arguing that while nova involvement is essential, this is in no-way nova-specific
21:29:42 <thingee> fhermeni: so I would say figure out what happened with gnatt, see if there is a need to revive that. I'm not really hearing much people here having an interest with global placement scheduler though
21:29:54 <bauzas> rockyg: so, see, I had this convo a lot of times before, and had no clear commitment on resource placement for others than vms
21:30:05 <fhermeni> thingee: you don’t, don’t worry we have
21:30:09 * jroll is curious how many people here know the details of the nova scheduler rework
21:30:12 <fhermeni> thingee: watcher is an example
21:30:20 <jroll> and the plans for the future
21:30:31 <bauzas> people want x-project affinity for placing instances, but I haven't seen a clear interest for placing something else but instances
21:30:33 <bswartz> thingee: I think we're all interested, but we've been burned by past failures and fear getting burned again
21:30:35 <mriedem> jroll: take jaypipes out for lunch
21:30:44 <jroll> mriedem: oh, I know the plans, but curious about others :)
21:30:57 <elmiko> jroll: i don't
21:31:02 <jroll> e.g. "is there a need to revive gaant"
21:31:12 <rockyg> I'm aware but not in deep
21:31:19 <jroll> it's too much to describe here, but I think it's good background reading for this topic
21:31:25 * jroll finds email
21:31:50 <jroll> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html
21:31:54 <rockyg> So, there are all sorts of issues in multiregion clouds that include other resources besides vm
21:31:56 <jroll> folks may want to read that for some context
21:32:00 <elmiko> jroll++
21:32:41 <rockyg> The ops community wants placement related to networking capabilities
21:32:57 <bauzas> rockyg: I'm certainly sure, I just said I haven't seen user stories yet
21:32:58 <fhermeni> indeed. For testbed for example, it is a prime feature
21:33:03 <rockyg> And HPC want placement wrt data storage
21:33:05 <jroll> so anyway, I agree that the super scheduler folks should chat more with the nova scheduler folks
21:33:19 <bauzas> rockyg: that's affinity for vms
21:33:21 <jroll> and figure out how this fits in, if at all
21:33:23 <fhermeni> HPC as well indeed. network and cache affinity
21:33:25 <elmiko> yea, i've seen some user asking question about data and compute affinity with respect to hadoop
21:33:43 <rockyg> bauzas, but global rather than local
21:33:45 <fhermeni> elmiko: indeed. VM close to the storage for data intensive workload
21:33:52 <thingee> cdent: can we get some folks interested in engaging with this spec? I think you and sdague are the only from nova that have responded to the spec
21:33:59 <elmiko> fhermeni: right, and asking for more options in sahara to control the affinity
21:34:00 <bauzas> could we stop making confusion between x-project affinity for placing vms, vs. placing things like volumes ?
21:34:16 <bauzas> thingee: I made a very clear statement too
21:34:28 <cdent> I think it is pretty clear that bauzas should be actively contributing to the discussion on the spec
21:34:44 <cdent> especially to clarify some of the thing he just clarified here
21:34:47 <rockyg> cdent, ++
21:35:00 <bauzas> I don't see the need for that being a x-project spec honestly
21:35:03 <rockyg> I'd love to see a session on this at the design summit
21:35:07 <bauzas> at least now
21:35:08 <cdent> there's a vast amount of assumptions that people make about the use cases and nobody seems to really agree
21:35:20 <thingee> ok, anyone disagree with bauzas?
21:35:22 <jroll> bauzas: ++ this needs to start in nova and expand
21:35:35 <thingee> going
21:35:35 <jroll> the nova work is making rooms for other resources like network and volumes
21:35:36 <thingee> ...
21:35:39 <thingee> going
21:35:44 <cdent> fdafda
21:35:46 <fhermeni> ok to me
21:35:57 <rockyg> gone!
21:35:59 <jroll> cdent has opinions it seems?
21:36:12 <cdent> jroll: I do, but not really on where the talk happens
21:36:13 <thingee> #agreed fhermeni and harlow to work with nova-scheduler folks to further this along to later propose cross-project
21:36:34 <jroll> cdent: right on
21:36:34 <thingee> fhermeni: thanks
21:36:44 <fhermeni> with pleasure
21:36:48 <thingee> #topic rolling upgrades
21:36:50 <thingee> kencjohnston: hi
21:36:52 <bauzas> fhermeni: http://eavesdrop.openstack.org/#Nova_Scheduler_Team_Meeting
21:36:52 <kencjohnston> howdy
21:36:55 <thingee> #link https://review.openstack.org/#/c/290977/1 spec
21:37:02 <kencjohnston> third first timer...
21:37:18 <elmiko> nice =)
21:37:42 <kencjohnston> This spec was copied from a Product Work Group developed User Story
21:38:14 <kencjohnston> with the intent of providing common problem description and use cases for upgrade improvements
21:38:29 <bknudson> we didn't get rolling schema upgrades into keystone last release.
21:38:34 <kencjohnston> realizing that work is underway in many projects on this front
21:39:01 <thingee> so I think dansmith and sdague bring up a good point that this should reflect current use cases that are already in flight and in progress.
21:39:05 <thingee> we should start there
21:39:26 <kencjohnston> thingee yeah happy to do so and I wlll incorporate their feedback
21:39:41 <kfox1111> this is similar to that ops spec.
21:39:49 <thingee> however, this spec needs ownership of someone technical that can surface the problem, and agreed concepts of a solution as well as existing shared libraries like oslo.versionobjects
21:39:50 <kfox1111> but more narrow in scope.
21:40:48 <thingee> to be clear, the product working group is trying to engage more with the community in the use cases they receive from things like the user survey.
21:40:55 <kencjohnston> thingee +1
21:41:24 <thingee> but this was received the wrong way I think. mostly because it was looked as a wish list since some of the stuff is not the current direction today.
21:41:45 <gordc> we already have a tag for this? https://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html
21:41:47 <thingee> However, I do think it would be good if the product working group was able to find someone who wants to own these repos from the technical side
21:41:52 <mriedem> gordc: yeah i was going to point that out
21:41:55 <kencjohnston> thingee Correct, and that is on me. I misunderstood some important direction thingee provided me on that front.
21:42:01 <gordc> are we trying to find owners for each project?
21:42:20 <mriedem> if a project doesn't have the rolling upgrades tag, work with each project on what it takes to add rolling upgrade support
21:42:22 <thingee> gordc: no, and I need to document this better from cross-project perspective...
21:42:38 <nikhil> is this a guideline spec?
21:43:00 <nikhil> or technical guideline spec? (first one being generic guideline)
21:43:05 <thingee> so cross-project specs I feel like should be general problem, general solutions and linking to existing libraries if they exist.
21:43:19 <nikhil> or a use these existing tools and stop adding tech debt to my prj spec?
21:43:24 <thingee> individual projects can do their own spec if they need to hash out particular details that involve their individual services.
21:43:35 <nikhil> so all three then
21:43:39 <jroll> seems like most CP specs specify an end goal and recommended solutions
21:43:49 <jroll> the end goal here is clear - the tag
21:43:56 <thingee> but we need these general ideas and solutions surfaced up somewhere, instead of what mriedem suggested of having to figure things out and dig for this information.
21:43:58 <samueldmq> what is a cross-project spec?
21:44:05 <jroll> the recommended solutions is less clear, as we can't just copy/paste code
21:44:10 <samueldmq> what does define something as a cp spec?
21:44:29 <nikhil> yes, then we'd remove the Proposed solution Heading from the spec IMHO
21:44:30 <thingee> samueldmq: I think it's something that involves more than one project.
21:44:38 <jroll> but rather should have things that get you there - if you use RPC, you should version that properly. you should do expand/contract style migrations. etc.
21:44:41 <dansmith> personally, I really don't want us to have a spec to cover all of upgrades
21:44:55 <dansmith> if we need a spec to distill best practices for versioned RPC, then we can do that
21:44:56 <nikhil> I just saw the previous 2 specs and the comment from Dan on this one and was confused
21:45:07 <dansmith> (for example)
21:45:09 <jroll> dansmith: ++
21:45:10 <gordc> dansmith: +
21:45:16 <thingee> dansmith: sure, if you want to call it that, that's fine with me
21:45:23 <jroll> there's a number of things (e.g. RPC) that projects do that make upgrades hard
21:45:24 <thingee> dansmith: that's not different from the logging spec best practice
21:45:26 <thingee> or eventlet
21:45:34 <samueldmq> thingee: I got that question after reading cdent's comment in patchset 2 at https://review.openstack.org/#/c/257809/
21:45:36 <fungi> yeah, "upgrades" seems like a blanket idea, which can mean many different facets of design to different projects
21:45:41 <jroll> we could clarify what things those are, and how a project might solve them
21:45:48 <mriedem> like log guidelines i guess? http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html
21:45:52 <jroll> (whether that's one spec or many, I'm not opinionated)
21:45:52 <dansmith> jroll: right, versioned rpc applies to a lot of projects.. versionedobjects will be picked up by fewer of those, and some will use neither
21:46:04 <thingee> mriedem: exactly what I was mentioning above :) thanks
21:46:05 <jroll> yep
21:46:06 <mriedem> thingee: ah you beat me to logging :)
21:46:20 <jroll> dansmith: there's other solutions too, like "don't change the rpc wire protocol" - crazy but it totally would work
21:46:27 <jroll> :P
21:46:39 <thingee> dansmith: I think a best practice is good.
21:46:50 <dansmith> jroll: right, which is why I kinda hesitate to do any of this, but I think of all the topics, versioned RPC best practices is probably the widest applicability
21:46:58 <gordc> jroll: that's what we use :)
21:47:11 <jroll> I do question if a spec is needed for best practices, or if this should be more like a (project guide?) docs thing
21:47:22 <rockyg> Also the upgrade tag is not the final resolution here, but the indicator that it was reached
21:47:22 <jroll> or a blog, or a wiki
21:47:23 <fungi> etching the protocol in stone without possibility of future revision encourages unsavory sorts of data serialization with nasty security vulnerability surface area though
21:47:33 <nikhil> jroll: ++
21:47:33 <jroll> fungi: I was about 10% serious :)
21:47:35 <dansmith> jroll: yeah, I've tended to put this kind of stuff in blogs
21:47:37 <fungi> heh
21:47:41 <thingee> jroll: as mriedem pointed out earlier, this isn't different from best practice of logging or eventlet which we cover today in our repo
21:47:51 <dansmith> jroll: I'd rather leave specs and TC-blessed things for required stuff
21:48:02 <jroll> thingee: okay, that's fair precedent
21:48:22 <jroll> I don't have a strong opinion, I guess. writing things down is what's important to me
21:48:24 <nikhil> Well I feel that many developers pick cp spec and just assume it to be source of truth
21:48:44 * thingee thinks if there is disagreement of what should go in this repo, he should propose what should go in this repo in the project team guide
21:48:46 <thingee> dansmith: ^
21:48:48 <nikhil> I feel we need to decouple the technical details and emphasize more on best practices
21:48:51 <fungi> i feel like a lot of the disagreements over cross-project specifications have to do with meaning people are reading into the term "specification"
21:48:52 <dansmith> nikhil: right, I'd hate for someone to read a spec, think it doesn't work for them, and decide not to pursue upgrades because that's the required solution
21:48:54 <rockyg> nikhil, if not source of truth, director to the various project sources of truth
21:48:54 <thingee> and then we can hash it out there.
21:49:23 <thingee> dansmith: I mean we have precedent of best practices, but we don't have to keep doing that.
21:49:31 <jroll> fungi: that's a good question
21:50:04 <thingee> but I think rolling upgrades is a common problem people are trying to solve
21:50:05 <dansmith> thingee: yeah, I'm not super familiar with the PTG, so I can't really say, but sounds reasonable
21:50:05 <rockyg> fungi, ++
21:50:09 <nikhil> thingee: I like CP specs, but it would be pretty good survey white paper sort of thing that has pointers to best articles or something of such sorts
21:50:23 <gordc> i don't think it's necessarily a bad thing we realised everything so far is probably overreaching. we're just confirming they are not required for everyone
21:50:30 <thingee> dansmith: what's ptg here? :P
21:50:32 <fungi> nova added specifications, then neutron, then others followed suit. then someone thought we should maybe have something like specs to coordinate stuff across multiple projects, but still called that a "specification"
21:50:42 <thingee> dansmith: oh pwg?
21:50:44 <thingee> heh
21:50:52 <dansmith> thingee: project team guide you mentioned above?
21:50:57 <samueldmq> fungi: yes, either meaning of specification or cross-project :)
21:51:10 <thingee> dansmith: oh gotcha
21:51:11 <dansmith> thingee: I think I misread,
21:51:19 <dansmith> you meant use the PTG to describe what CP specs are for?
21:51:31 <rockyg> Can't remember which project, but they have RFEs for non developers to describe their needs
21:51:34 <thingee> dansmith: yes, because there are disagreements here it seems.
21:51:45 <nikhil> rockyg: ack and I agree to what you said
21:51:47 <jroll> rockyg: neutron and ironic
21:52:21 <thingee> sean dague isn't present, I know he had disagreements here.
21:52:23 <rockyg> And this doc is pretty much an RFE.
21:52:44 <samueldmq> what does RFE stand for ?
21:52:50 <fungi> rfe is also known broadly in free software as a "wishlist item"
21:52:51 <dansmith> request for enhancement
21:52:53 <rockyg> Request for Enahancement
21:53:02 <samueldmq> thanks
21:53:19 <fungi> as in "here's something we'd like to see happen, but we don't know how it should be done or who will actually do it"
21:53:20 <samueldmq> and I agree it makes sense to have them
21:53:31 <samueldmq> if we're going to get requirements from non-dev people
21:53:36 <rockyg> and once the RFE is fleshed out with the stuff we've talked about, either individual project specs or cross project specs or both can be generated by devs
21:53:48 <thingee> #action thingee to define cross-project specs in project team guide
21:53:51 <dansmith> fungi: right, usually only happens if money is exchanged somewhere :)
21:53:58 <samueldmq> rockyg: ++
21:54:05 <thingee> kind of a bummer that we have to go back to this, but I don't want us to keep getting blocked here.
21:54:09 <samueldmq> thingee: nice! should our spec template include something as well?
21:54:24 <carolbarrett> rockyg +1
21:54:25 <kencjohnston> fungi I do want to clarify there is commitment from representatives of companies int he PWG to work on this (this being upgrades)
21:54:39 <bknudson> I think part of the problem is that as a volunteer org we need devs to be able to work on it
21:54:43 <carolbarrett> kencjohnston: +1
21:55:18 <thingee> #topic stale specs
21:55:27 <rockyg> I think we have devs, but not senior devs.  We need the cores and drivers to architect the right directions to go with this
21:55:27 <samueldmq> bknudson: agreed, starting on getting RFEs and writting specs down
21:55:28 <jroll> so nobody is arguing that we should or should not document best practices for projects that want to do upgrades, rather where it should be
21:55:30 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/089115.html
21:55:31 <carolbarrett> bknudson: I believe there are devs working on it today and we can continue to ask them to work on this
21:55:37 <fungi> kencjohnston: carolbarrett: awesome. though it's generally helpful to have the people who will be working on it write up their proposal for how they'd do it so there's more to review
21:55:52 <thingee> I've listed some stale specs here.
21:55:56 <thingee> lifeless has a bit :)
21:56:27 <thingee> jroll: I'm just going to define what the cross-project specs should be for. We can start there.
21:56:34 <jroll> thingee: cool
21:56:38 <gordc> thingee: i would abandon them and let them reopen if someone actually cares about it
21:56:47 <lifeless> thingee: I do :(
21:56:59 <thingee> so this involves the TC to abandon them. I don't have powers.
21:57:06 <thingee> but I wanted people to be aware
21:57:10 <lifeless> backwards compat is ongoing
21:57:11 <thingee> and revive whatever you care about
21:57:11 <gordc> thingee: ah i see. :(
21:57:12 <samueldmq> gordc: ++
21:57:12 <lifeless> I need to update it
21:57:22 <thingee> lifeless: ok!
21:57:23 <nikhil> thingee: you open to running the bot thing that auto-abandons if not active for 2/3 weeks?
21:57:25 <lifeless> testr isn't on the map right now, though it is still something I want to do
21:57:28 <rockyg> So, I'm willing to abandon mine if I can't update it by the summit.  I can always come back to it.
21:57:40 <nikhil> thingee: ah, nvm
21:57:49 <thingee> #topic open discussion
21:57:51 <thingee> cdent: ^
21:57:54 <fungi> are there really enough cp specs that someone can't just manually abandon them when they seem to be going nowhere any more?
21:58:00 <samueldmq> thingee: fyi I've talked to ayoung and he agrees with abandoning No global admin (Adam Young) - https://review.openstack.org/#/c/205629
21:58:12 <cdent> thanks thingee: I just wanted to point people at this thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/088658.html
21:58:23 <jroll> fungi: only the owner and the TC has abandon rights, afaik
21:58:33 <jroll> cdent: this one is so much fun
21:58:37 <kfox1111> I've got two specs that are still very important to our group, but I've not had time this cycle to follow up on, since its been a huge amount of work to try and get through.
21:58:46 <cdent> the death (or dying) of wsme impacts several projects and there's been some discussion about how to formalize or guide people in doing the a better thing
21:58:54 <kfox1111> I'm about to deliver a production system so I'm hoping I'll have time coming up to push some more.
21:58:58 <cdent> there's been some discussion of announcing that projects _must_ migrate
21:59:03 <fungi> jroll: we _can_ fix that with acls, though either way the tc needs to be involved in the discussion of who should abandon changes for the repository they control and how
21:59:04 <nikhil> heads up: We're having a discussion for quotas impl to be separate service or a lib and folks should expect a ML email from someone from the WG soonish.
21:59:05 <cdent> (in say N months)
21:59:15 <elmiko> cdent: must migrate, as in away from wsme?
21:59:17 <cdent> a thing like that seems like it would be vaguely cross-project
21:59:21 <jroll> fungi: yeah, just pointing out why thingee hasn't done it I guess :)
21:59:28 <cdent> elmiko: yes, but it is just an idea, not a decision
21:59:32 <jroll> cdent: must? yikes
21:59:41 <elmiko> cdent: ack, just trying to understand better
21:59:43 <cdent> a strawman
21:59:46 <jroll> I don't remember seeing must in that thread, rather should
21:59:57 <thingee> one minute
21:59:59 <jroll> (I agree, fwiw, I just don't want to force people to do it)
22:00:03 <fungi> if the tc wants to grant thingee the ability to abandon/restore changes on that repo, it's easy to solve in gerrit with a line in an acl
22:00:27 <fungi> i'm happy to write the change to implement it
22:00:34 <bknudson> I vote to give thingee the ability to abandon changes
22:00:35 <rockyg> Well, if no one is maintaining it, there will be bitrot.  So migration is a question of when, not if
22:00:37 <elmiko> must migrate does seem strong, but providing some nice guides on how to migrate would be awesome! (i know, more work)
22:00:46 <cdent> elmiko: well exactly
22:00:51 <thingee> ok that's time
22:00:59 <thingee> thanks everyone for attending!
22:01:01 <nikhil> thanks
22:01:04 <elmiko> thanks thingee
22:01:05 <thingee> #endmeeting