21:02:05 <thingee> #startmeeting cross-project
21:02:07 <openstack> Meeting started Tue Mar 29 21:02:05 2016 UTC and is due to finish in 60 minutes.  The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:10 <samueldmq> hi all
21:02:11 <openstack> The meeting name has been set to 'cross_project'
21:02:12 <docaedo> o/
21:02:12 <cdent> o/
21:02:13 <EmilienM> o/
21:02:13 <mriedem> o/
21:02:15 <samueldmq> o/
21:02:15 <thingee> hey everyone
21:02:19 <kencjohnston> o/
21:02:19 <diablo_rojo> Hello :)
21:02:23 <thingee> a lot to talk about today, let me tell ya
21:02:32 <dims> o/ we need to invite the incoming PTL(s)
21:02:32 <dhellmann> o/
21:02:35 <sdake> yar
21:02:40 <dtroyer> o/
21:02:41 <nikhil> o/
21:02:43 <thingee> agenda today https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda
21:02:46 <adam_g> o/
21:02:58 <thingee> #topic Team announcements (horizontal, vertical, diagonal)
21:02:59 <fungi> i feel both incoming and outgoing
21:03:01 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090737.html Changes to release ACLs for official projects in Newton
21:03:03 <thingee> hi dhellmann
21:03:09 <dhellmann> hi
21:03:10 <hongbin_> o/
21:03:13 <mtreinish> o/
21:03:20 <david-lyle> o/
21:03:20 <dhellmann> this is the next phase of the release automation work we're doing
21:03:24 <dims> fungi : ++
21:03:26 <xarses> o/
21:03:34 <dhellmann> for newton, all official project teams will use the openstack/releases repo to request and document releases
21:03:50 <dhellmann> see the email thread for details, and the README in the repo, and then let me know if you have questions
21:04:03 <thingee> dhellmann: while I have you here
21:04:06 <dhellmann> most of you have already been using it, so it won't really be a big change
21:04:10 <samueldmq> dhellmann: so release notes don't go in individual prject repos, but in a centralized repo instead
21:04:10 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090517.html Release liaisons for newton
21:04:15 <EmilienM> dhellmann: excellent. Does release tags matter?
21:04:24 <dhellmann> samueldmq : no, this is to request a tag for a release, not a release note
21:04:40 <samueldmq> dhellmann: sure, I will look at the README and the eamil threads, sorry
21:04:46 <dhellmann> ah, yeah, thanks thingee
21:04:59 <dhellmann> the other thing we're changing next cycle is we want to have only one release liaison per project team
21:05:05 <EmilienM> dhellmann: for example, Puppet OpenStack group is applying to some release tags with the goal to release our deliverables like other projects https://review.openstack.org/297382
21:05:16 <dhellmann> we had a few projects with lots of deliverables assign a different person per deliverable, and that turned out to be too much for us to keep up with
21:05:43 <dhellmann> EmilienM : release:managed will stay around for now to indicate that we work really closely with the team, but it isn't required for use of openstack/releases
21:05:56 <EmilienM> dhellmann: ack.
21:06:03 <thingee> thanks dhellmann
21:06:07 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090659.html Oh Swagger, where art thou?
21:06:08 <dhellmann> thanks, thingee
21:06:11 <thingee> annegentle: you around?
21:06:17 <annegentle> here!
21:06:57 <thingee> looks like we have some changes coming in the swagger with some new approach coming soon?
21:06:59 <annegentle> thanks for bringing it up
21:07:18 <annegentle> yes, that email and sdague's follow up give a good overview
21:07:39 <annegentle> I wanted to be sure to be available for any questions. We're making good progress with the proof of concept
21:07:52 <bknudson> is this going to apply to all projects?
21:07:56 <bknudson> or just nova?
21:08:11 <annegentle> bknudson: yes, the POC is for nova but I'd like keystone to look early and often
21:08:20 <thingee> looks like sdague is spearheading this for nova
21:08:22 <thingee> with a new approach
21:08:30 <bknudson> is there a conversion tool like fairyslipper?
21:08:36 <annegentle> bknudson: yes
21:08:39 <annegentle> wadl2rst
21:08:50 <annegentle> #link https://github.com/annegentle/wadl2rst
21:09:02 <annegentle> it does migration and only migration, fairy-slipper has a migration portion and a display/ui portion
21:09:17 <jroll> I assume the rest_* extension will be broken out to a separate project?
21:09:40 <annegentle> jroll: sdague can comment on that, he's wrangling the extensions
21:10:00 <jroll> sure
21:10:12 <thingee> speaking of sdague
21:10:22 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090754.html Service Catalog TNG work in Mitaka ... next steps
21:10:36 * thingee looks to the left and looks to the right
21:10:52 <jroll> this is super neat overall, though, thanks annegentle and sdague for pushing on it :)
21:10:56 <annegentle> might be late for sdague
21:11:11 <cdent> the sctng message struck me as accurate and a good plan
21:11:16 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090546.html Kolla Deploying the big tent
21:11:19 <thingee> sdake: ^
21:11:53 <bknudson> we sure do have a lot of openstack deploy tools
21:12:01 <sdake> moment catching up
21:12:15 <thingee> it's just your announcement on needing help with kolla
21:12:20 <thingee> to the dev ml
21:12:53 <sdake> oh
21:13:02 <sdake> ya it woudl be cool if new projects contirbuted
21:13:19 <sdake> like with the devstak plugin model
21:13:30 <sdake> i'm going to try to get kolla cogating with compute-kit projects this cycle
21:13:48 <bknudson> what's compute-kit?
21:13:51 <sdake> because nobody usess devstack in production
21:14:08 <sdake> gnarld_ glance nova neutron kesytone and its deps
21:14:08 <mriedem> and our ci system doesn't use kolla
21:14:24 <thingee> bknudson: https://www.openstack.org/software/sample-configs/
21:14:34 <thingee> "compute starter kit"
21:14:47 <jroll> I'd be surprised if most teams have people with enough free time to contribute to kolla, personally
21:14:55 <sdake> kolla is ci'ed but just barely
21:14:59 <jroll> maybe if there was a plugin model where I could have something in my tree
21:15:13 <sdake> jroll we have discussed that but technically it is difficult
21:15:16 <EmilienM> like a tempest pluging?
21:15:18 <jroll> sure
21:15:19 <mriedem> jroll: but you wouldn't know if that works unless ironic had a kolla ci job that uses it
21:15:22 <sdake> bordering on impossible
21:15:29 <jroll> mriedem: yep
21:15:35 <dims> jroll : personally i want look at rabbitmq and keystone in kolla when i get a chance. though i understand those are already taken care of
21:15:41 <mriedem> projects have devstack plugins so they can run dsvm jobs using our infra model
21:16:05 <jroll> anyway, what I'm trying to say is that (at least ironic) has plenty to do already without contributing to all of the various deployment projects
21:16:08 <dims> sdake : how would one poke at just containers running stuff that's of interest to them?
21:16:16 <EmilienM> puppet modules have one module per component, why don't you follow this model?
21:16:20 <sdake> jroll ironic is already implemented so your in the clear ;)
21:16:26 <jroll> yay.
21:16:30 <dims> lol
21:16:34 <thingee> and real quickly cause we have to move on...
21:16:37 <thingee> #link https://etherpad.openstack.org/p/newton-cross-project-sessions cross-project summit sessions
21:16:49 <thingee> sdague is asking for your sessions, get 'em in!
21:16:55 <sdake> wt session on plugins
21:17:07 <sdake> we have all kinds of plugin patterns in openstack
21:17:11 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090606.html Austin Design Summit Track Layout
21:17:19 <sdake> i know its unreasonable ot epect eveyrone to standardize on one
21:17:22 <sdake> but can we not make mroe ;)
21:17:26 <thingee> the layout for all official projects is out. review it. get back to ttx and I
21:17:39 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090422.html PTL Election Results
21:17:44 <thingee> congrats all!
21:17:45 <ttx> planning to officialize tomorrow, so last day for comments
21:17:46 <xarses> EmilienM: should we put the deployment orchestrator tool up?
21:17:52 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090421.html TC Nominations Start
21:17:53 <elmiko> dims: i found the kolla docs and install pretty approachable, and configurable. the team was awesome with questions too =)
21:18:05 <thingee> #link http://www.openstack.org/blog/2016/03/openstack-developer-mailing-list-digest-20160318-2/ Dev Digest from last week
21:18:12 <thingee> catch up on the dev list reminder^
21:18:16 <thingee> alright lets begin, whew
21:18:19 <sdake> why thank you elmiko
21:18:23 <dims> elmiko thanks!
21:18:23 <EmilienM> xarses: it was not in the agenda, but if we have time why not.
21:18:29 <xarses> EmilienM: https://etherpad.openstack.org/p/newton-cross-project-sessions
21:18:44 <harlowja> hello
21:18:47 <thingee> #topic Add centralized configuration options specification
21:18:49 <thingee> #link https://review.openstack.org/#/c/295543/ spec
21:18:55 <thingee> sigmavirus24: hi
21:18:56 <sdake> jroll just for reference my emali was directed mostly at new projects to openstack in liberty/mitaka, not projeects with a long histroy
21:19:03 <sigmavirus24> Sorry I'm late :)
21:19:09 <thingee> you're on time
21:19:12 <elmiko> this seems like a nice idea
21:19:22 <jroll> sdake: sure, just my 2c :)
21:19:38 <sdake> jroll maye its not viable,but doens't hurt to ask :)
21:20:39 <nikhil> what are we discussing on this topic?
21:21:11 <thingee> surfacing it up for more eyes. was giving the floor to sigmavirus24 to discuss
21:21:19 <mriedem> it's probably already been pointed out that there has been a team of people in nova centralizing config options and upating help text since mitaka
21:21:39 <sigmavirus24> thingee: ah, sorry, didn't realize that was my cue.
21:21:40 <bknudson> keystone has all its config options in 1 module
21:21:43 <mriedem> i see mzoeller is on the xp spec so that's good
21:22:08 <sigmavirus24> So kencjohnston johnthetubaguy rosmaita and I have been talking about this for a while as a cross-project effort. kencjohnston wrote the original user story around categorizing and centralizing configuration options
21:22:17 <thingee> #note nova has a team of people centralizing config options and updating help text since mitaka
21:22:25 <thingee> #info nova has a team of people centralizing config options and updating help text since mitaka
21:23:17 <sigmavirus24> johnthetubaguy: and I were talking earlier about making them two separate cross-project specs actually only because we think the categorization efforts that I started to outline in that spec is something we think will help operators and downstream redistributors more than the centralization which is in part more focused on helping developers
21:23:27 <bknudson> this looks like it will improve usability
21:23:30 <mriedem> #link nova spec from mitaka http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/centralize-config-options.html
21:23:46 <elmiko> i brought this up on the review, but i'd be curious to see patterns for improving config usage in libraries
21:23:54 <sigmavirus24> That said, I think aspects of the centralization (including the work on each option's help text) will benefit more than just developers for reasons I've described in the spec
21:23:57 <mriedem> sigmavirus24: sounds identical to http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/centralize-config-options.html
21:24:18 <sigmavirus24> mriedem: that was in fact the basis of the discussion that we all had ~2 weeks ago?
21:24:21 <mriedem> elmiko: that should be included given the server projects import oslo lib options
21:24:51 <mriedem> ok, just hope the wheel doesn't get re-invented
21:24:57 <bknudson> since the oslo options wind up in different projects highest impact is probably there.
21:25:13 <gordc> is this a guideline?
21:25:27 <elmiko> mriedem: ok, just wanted to voice it since we ran into issues creating the config module for castellan
21:25:52 <nikhil> didn't get a chance to look at the user story
21:25:54 <sigmavirus24> gordc: some of the people listed were going to start working on bringing this work to other services so more of a spec
21:26:08 <nikhil> is the objective to improve awareness and consumption of these options?
21:26:37 <cdent> can we use this as a chance to destroy globals ;)
21:26:55 <harlowja> ;)
21:26:57 <sigmavirus24> nikhil: there are multiple objectives: - allow operators to generate a config that represents the bare minimum of what they need to set, with very well written coments for each option
21:27:11 <gordc> sigmavirus24: kk. but the proposal is to move all conf options under <project>/conf/* location?
21:27:18 <elmiko> cdent: \o/
21:27:20 <mriedem> nikhil: http://docs-draft.openstack.org/43/295543/4/check/gate-openstack-specs-docs/9e24dc4//doc/build/html/specs/categorized-and-centralized-configuration-options.html#proposed-change
21:27:20 <sigmavirus24> gordc: that's *part* of the proposal
21:27:36 <gordc> sigmavirus24: i see. glossed over too quickly
21:27:43 <samueldmq> bknudson: ++
21:27:52 <sigmavirus24> gordc: right, this is why johnthetubaguy was recommending I split that particular bit out into a separate guideline/spec
21:28:19 <mriedem> we wrestled with that split in nova too, we just kept it in the same spec
21:28:27 <mriedem> i think people have just been updating help text as they move the options
21:28:50 <nikhil> oh well, we just moved away in glance(1 or 2 cycles back) from nicely documented configs ..
21:28:54 <dims> ETOOMANYOPTIONS
21:29:00 <nikhil> anyways, thanks sigmavirus24 mriedem
21:29:15 <nikhil> dims: == openstack ?
21:29:22 <nikhil> :)
21:29:28 <mriedem> thingee: sigmavirus24: so this is just fyi right?
21:29:34 <mriedem> or is there an action for this meeting?
21:29:54 <jroll> nikhil: wait, glance deliberately stopped nicely documenting configs? please tell me I am misunderstanding :)
21:29:59 <thingee> mriedem: well I think we want more eyes so we can move forward in some direction
21:30:09 <mriedem> jroll: i reada that the same way :)
21:30:24 <bknudson> so this has been adopted for nova already and the proposal is for other projects to also adopt it?
21:30:30 <nikhil> jroll: it was because people wanted to keep using oslo config generator instead
21:30:41 <nikhil> and trust developers to do the documentation!
21:31:03 <Rocky_g> glance gets a -1 from me
21:31:07 <sigmavirus24> nikhil: developers were doing that documentation anyway and the example config was constantly diverging from reality
21:31:11 <jroll> nikhil: oh, so glance stopped having the docs team document everything?
21:31:13 <thingee> sigmavirus24: can we reup based on johnthetubaguy and others comments and gather votes to move forward?
21:31:32 <jroll> anyway, that's a side conversation I guess, don't mean to distract here
21:31:38 <sigmavirus24> thingee: I think rosmaita or johnthetubaguy are going to take the spec over from me. I've been moved off this internally and have too much else going on IRL to do this in my free time
21:31:43 <nikhil> jroll: no, that's still there. the sample is gone, it used to have good documentation for operators.
21:31:52 <jroll> nikhil: oh yeah, got it
21:32:07 <mriedem> sigmavirus24: if not johnthetubaguy, markus_z might be willing to own it
21:32:08 <sigmavirus24> thingee: I'll make sure they get this feedback though
21:32:09 <nikhil> sigmavirus24: yeah, I get it I get it :)
21:32:11 <mriedem> he's leading the effort in nova
21:32:24 <thingee> mriedem: that would be great.
21:32:49 <mriedem> "might be willing"
21:33:00 <thingee> mriedem: will you ask, or shall I?
21:33:03 <thingee> or sigmavirus24 :)
21:33:06 <mriedem> not it
21:33:24 <sigmavirus24> hah
21:33:31 <thingee> sigmavirus24: if you can just make sure someone owns it and let me know
21:33:34 <sigmavirus24> I'll throw johnthetubaguy and marcus into an email together
21:33:37 <thingee> or indicate in the review.
21:33:37 <sigmavirus24> thingee: will do
21:33:41 <thingee> thanks
21:33:58 <thingee> #action sigmavirus24 to hand off the spec to johnthetubaguy, marcus or someone!
21:34:00 <mriedem> since johnthetubaguy is no longer PTL he probably has nothing going on anyway... :P
21:34:09 <thingee> heh
21:34:14 <dims> haha
21:34:18 <thingee> #topic Delimiter - Cross Project Quota Enforcement and Management
21:34:19 <thingee> #link https://review.openstack.org/#/c/284454/ spec
21:34:20 <jroll> he's probably sleeping til summit
21:34:23 <thingee> nikhil: hi!
21:34:26 <harlowja> oh hi
21:34:29 <nikhil> hey hey
21:34:36 <harlowja> vilobhmm11 yt
21:34:45 <vilobhmm11> hi
21:34:45 <nikhil> I think vilobhmm11 is here who wants to take on this topic
21:34:49 <thingee> our quota friends have gone off into their cross-project meeting and have been making progress. wanting to make sure the general group is liking the direction
21:34:50 <harlowja> k :)
21:34:54 * harlowja back to support-mode
21:35:08 <vilobhmm11> so in the spec
21:35:22 <vilobhmm11> as we discussed in yesterdays cp-quotas meeting
21:35:31 <vilobhmm11> would like to propose delimeter as a library
21:36:00 <vilobhmm11> which focus on transactional gurantees for quotas (including hierarchical as well as non-hierachal namespace)
21:36:14 <nikhil> #link http://eavesdrop.openstack.org/meetings/quotas_wg/2016/quotas_wg.2016-03-28-21.00.log.html
21:36:22 <vilobhmm11> the respective projects will still maintain the quotas related data
21:37:07 <vilobhmm11> what delimeter provides #1. easy apis to interact with quotas like #1. check_quota #2. assign_quota and the engine can take care of rest and provide transactionl gurantees
21:37:24 <vilobhmm11> please go through https://review.openstack.org/#/c/284454/8/specs/delimiter-cross-project-quota-enforcement.rst for details.
21:37:57 <thingee> I seem to remember someone from trove asking about cross-project transactional guarantees. I'm guessing this will not be in the scope.
21:38:22 <nikhil> thingee: it was amrith who was at the quota wg meeting yday
21:38:22 <vilobhmm11> for now any consumer who consumes resources from the IaaS layer say Trove, Magnum  etc
21:38:47 <jroll> delimiter.QuotaEngine(project_name="foo", ...) <- makes me think that the implementation for each project will be in the delimiter tree, is that true? if not, how does e.g. magnum interact with nova quotas?
21:38:48 <vilobhmm11> so thingee that still needs to be discussed
21:39:21 <vilobhmm11> jroll : the way to enforce quota will be in delimeter
21:39:27 <dims> vilobhmm11 : did you figure out the database part? who owns it. especially migrations
21:39:38 <jroll> (and if so, does that require magnum be able to use the nova db?)
21:39:41 <vilobhmm11> dims : the respective projects own the data
21:39:44 <nikhil> I think we agreed on projects doing the migrations
21:39:46 * dims should really read the spec
21:39:52 <vilobhmm11> and hence deleimiter need not worry about data migrations
21:39:53 <thingee> since we're going with services in things like headers, per direction of service catalog, we should probably be thinking service quota, not project quota.
21:39:55 <vilobhmm11> dims : %%
21:39:56 <thingee> nit pick maybe
21:39:59 <nikhil> all data goes in the project scope!
21:40:11 <vilobhmm11> dims : ^^
21:40:35 <dims> ack this will be interesting to see how that would work
21:40:53 <dims> each project implements something that the library would call back
21:40:54 <nikhil> thingee: I think it will be both (and project meaning tenant in this case)
21:40:58 <bknudson> the versioning of the database and data models will be interesting
21:41:14 <jroll> vilobhmm11: so this would be used by a project to say "does this thing have enough quota to do action? if so, reserve it?"
21:41:29 <vilobhmm11> jroll : yes
21:41:32 <jroll> ok
21:41:58 <vilobhmm11> this would gurantee if certain resource requirements can be satisfies ( considering both sequntial and concurrent requests)
21:42:03 <vilobhmm11> jroll : ^^
21:42:12 <jroll> yep
21:42:14 <thingee> I guess while we have people here, does anyone object to the current approach?
21:42:19 <jroll> just replacing the current engine
21:42:22 <thingee> or idea
21:42:28 <dims> +1 thingee
21:42:42 <bknudson> looks like keystone isn't involved yet
21:42:46 <nikhil> I'd prefer for us to settle on library approach (which is getting more of a reality now) before the summit session
21:42:58 <vilobhmm11> nikhil : +1
21:43:11 <dims> vilobhmm11 : should be easy to get started (http://docs.openstack.org/infra/manual/creators.html) ping me if you need a hand with library creation steps
21:43:12 <mriedem> is there a POC for this in any services that has quotas today, like nova or cinder?
21:43:23 <jroll> assign_quota says "Commit or rollback quota for the specified resources", which sounds like it might suffer from the same problems nova currently has, no?
21:43:26 <thingee> mriedem: the usuals
21:43:28 <thingee> heh
21:43:30 <vilobhmm11> dims : sure
21:43:32 <jroll> commit, do stuff, rollback on failure
21:43:48 <jroll> we forget to call rollback in one place, we're out of sync
21:44:02 <mriedem> honestly i'm not interested in this until someone shows a POC and why it's helpful for nova
21:44:09 <jroll> so it's unclear to me what this is solving
21:44:10 <mriedem> because we already have a house of cards for quotas
21:44:21 <thingee> mriedem: rock paper scissors with smcginnis to see which project has to do it first
21:44:22 <mriedem> but it's a house of cards that we've become slightly comfortable with
21:44:24 * jroll == mriedem, I think
21:44:37 <mriedem> thingee: has to do it?
21:44:37 <dims> lol mriedem
21:44:42 <dims> known devil
21:44:46 <nikhil> the spec is pulled out of cinder impl and then iterated upon
21:44:47 <thingee> mriedem: which project does a POC
21:44:50 <mriedem> i'd expect whoever is driving this to provide a POC
21:45:00 <mriedem> nova has other priorities for newton which aren't this
21:45:10 <vilobhmm11> nikhil : glance ?
21:45:16 * thingee was mostly having fun
21:45:28 <nikhil> there's one spec for glance, there's no impl yet
21:45:33 <nikhil> vilobhmm11: ^
21:45:51 <nikhil> oh, the ask was for a POC
21:45:54 <mriedem> neutron doesn't even have working quotas right? you can reserve but can't unreserve or some long-standing known issue?
21:46:08 <nikhil> I don't know about glance willing to do a POC, we will need to chat at the summit
21:46:28 <nikhil> I'd rather have the discussions on direction first, talk more at the CP session then the project session
21:46:34 <nikhil> it's a sequential train
21:46:37 <thingee> mriedem: wow, did not know that
21:46:44 * jroll posts his thoughts on the spec
21:46:51 <nikhil> there can't be concurrent requests for openstack-projects, unfortunately!
21:46:53 <harlowja> ya, i'd almost like to dive into why POC on a known-cp problem is so hard to get, but i'll refrain myself
21:47:02 <thingee> ok sounds like a poc then is the current requests from cp-spec liaisons?
21:47:09 <vilobhmm11> jroll : thanks..it moving too quickly here…not able to address everyone's questions
21:47:19 <jroll> np
21:47:36 <jroll> thingee: my request is in the spec - why is this better than what nova currently has?
21:47:45 <vilobhmm11> thingee : since we are talking about poc i assume the idea sounds fair to most of the members
21:47:51 <vilobhmm11> just to confirm
21:47:52 <jroll> but I don't care about this too much as ironic doesn't have quotas today
21:48:09 <jroll> poc would be a good start, though, too
21:48:15 <bknudson> does ironic have a need for quotas?
21:48:17 <nikhil> jroll: it's more to do about getting quotas right and then implenting them right across openstack
21:48:34 <jroll> bknudson: it may eventually, but I don't see anyone asking for it today
21:48:36 <nikhil> jroll: I think that was the most widely given opinion on the ML thread
21:48:46 <diablo_rojo> Cinder is just starting to have working quota support.
21:48:47 <vilobhmm11> nikhil : I agree
21:48:49 <jroll> nikhil: yep, I want to see why this is "right" :)
21:49:11 <nikhil> jroll: cool, so I think the point is take it from a project who has implemented and learnt from it
21:49:14 <jroll> because it sounds like what nova does already, which I know is not right with my ops hat on
21:49:15 <thingee> diablo_rojo: you mean for nested? it's had quotas for a while.
21:49:19 <nikhil> right now the example given to me was cinder
21:49:25 <diablo_rojo> thingee: Ha ha yes. Nested quotas
21:49:30 <nikhil> and we've 2 cinder folks contributing to the WG
21:49:31 <diablo_rojo> thingee: My bad.
21:49:46 <diablo_rojo> nikhil: Who has been helping out?
21:49:48 <mc_nair> yea, but it's still race-ee
21:49:54 <thingee> diablo_rojo: DuncanT
21:49:57 <nikhil> diablo_rojo: DuncanT and mc_nair
21:50:03 <vilobhmm11> nikhil : the problems mentioned in the spec are not particular to cinder they apply to nova as well
21:50:05 <nikhil> plus vilobhmm11 himself
21:50:10 <diablo_rojo> thingee: Got it. I assumed mc_nair. Wondered who the other was.
21:50:20 <vilobhmm11> or any other project to say
21:50:34 <DuncanT> Hi
21:50:45 <nikhil> vilobhmm11: right, I was just saying which project is this thing most ahead. nested is only in cinder, iirc
21:50:48 <thingee> DuncanT: go back to sleep
21:50:59 <vilobhmm11> nikhil : sure
21:51:00 <mc_nair> vilobhmm11: right the problems aren't specific but I think the point is they'd like to see the problem solved one place before making it common
21:51:08 <DuncanT> thingee: ok
21:51:26 <vilobhmm11> mc_nair :so thats the question; which project is willing to try the POC ?
21:51:52 <thingee> ok I'll defer to the wg discussing this. maybe on the ML
21:51:54 <nikhil> openstack-dev/sandbox (pfff) :/
21:52:11 <thingee> sound good?
21:52:18 <nikhil> yeah
21:52:21 <jroll> vilobhmm11: the WG should be doing the POC, in whichever project they feel comfortable doing it in
21:52:24 <jroll> imo
21:52:27 <mc_nair> I'm not in a place to make that call but I will help with Cinder support. I don't think people would complain if we removed the races from the quota stuff
21:52:29 <DuncanT> You could put a WIP patch up for cinder - probably won't get merged any time soon, but it gives something to test against
21:52:50 <thingee> and something for mriedem to look at
21:53:01 <thingee> nikhil: anything else?
21:53:07 <nikhil> yes, I can assure to provide some reviews if WIP exists in GLance but can't commit to this being approved
21:53:14 <diablo_rojo> DuncanT: +1
21:53:18 <nikhil> thingee: no, thank you.
21:53:29 <vilobhmm11> thingee : yes as we are still in design phase; if the problem statement and the thing this library plans to solve seeming something useful - it would be nice for community members to give there feedback so that we can have a solid foundation till summit and then decide
21:53:30 <thingee> #action nikhil and vilobhmm11 and folks to get a poc going
21:53:59 <thingee> vilobhmm11: I think you're in shape for the summit discussion on this. of course that's up for the TC to decide
21:54:16 <vilobhmm11> thingee : ok
21:54:21 <vilobhmm11> thanks!
21:54:25 <thingee> thanks
21:54:28 <thingee> #topic Clarify Specifications
21:54:29 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090156.html mailing list post
21:54:31 <thingee> #link https://review.openstack.org/#/c/295940/ review
21:54:47 <thingee> alright so I posted this and didn't get too much feedback aside from dhellmann
21:55:28 <jroll> I don't see dhellmann on that review at all
21:55:46 <thingee> jroll: errr thanks
21:55:55 <jroll> thingee: you mean https://review.openstack.org/#/c/296571/ ?
21:55:59 <thingee> #link https://review.openstack.org/#/c/296571/ spec/guideline separation
21:56:06 <thingee> jroll: thanks again :)
21:56:11 <jroll> heh
21:56:42 <cdent> thingee: I meant to and then easter showed up, but it's in my queue. When I glanced at it before seemed sane
21:56:59 <thingee> this is going back to our last cross-project meeting of there being confusion in a guideline being given for rolling upgrades
21:57:15 <thingee> sdague: dansmith ^
21:57:17 <jroll> I like what andreas said about explaining what each are
21:57:23 <jroll> otherwise seems fine
21:57:35 <thingee> what about dhellmann's comment of it still being under specs.openstack.org?
21:57:48 <thingee> it's gotta live somewhere... I think it might be fine
21:57:51 <jroll> I'm unopinionated there, personally, it seems fine
21:58:52 <thingee> to resolve with what the product working group wants, kencjohnston, I think it would be good for a follow-up on someone giving the guideline information based on the use cases that already exist in today's progress
21:58:52 <Rocky_g> Well, if it's a guideline, couldn't it live there?
21:58:55 <thingee> as dansmith requested
21:59:08 <thingee> Rocky_g: right it's about clarifying guidelines do live here
21:59:10 <thingee> too
21:59:10 <jroll> specs.o.o/guidelines seems close enough
21:59:14 <thingee> which we already have some in there.
21:59:30 <Rocky_g> Really, in many ways, mos of the guideline type stuff is really OpenStack-wide devrefs
21:59:31 <jroll> or whatever, specs.o.o/openstack/openstack-specs/guidelines
21:59:33 <thingee> 1 min
21:59:59 <thingee> #action thingee to update spec/guideline separation with descriptions of each
22:00:19 <thingee> #action thingee to send email to list of new PTLs making sure current cp-spec liaisons are accurate
22:00:22 <thingee> thanks all!
22:00:38 <thingee> #endmeeting