21:01:38 <thingee> #startmeeting crossproject
21:01:39 <openstack> Meeting started Tue Feb  9 21:01:38 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:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:42 <openstack> The meeting name has been set to 'crossproject'
21:01:45 <samueldmq> hey
21:01:45 <fungi> jroll: i don't disassociate
21:01:54 <nikhil_> how do I get on the ping list?
21:01:55 <jroll> :P
21:02:12 <thingee> Agenda: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
21:02:26 <flwang> nikhil_: since you proposed the quota topic?
21:02:35 <thingee> nikhil_: oh sorry, I thought I grabbed everyone on the cp-spec laision list. I can also just add you :)
21:02:41 <nikhil_k> flwang: that's not the first item
21:02:43 <rockyg> o/
21:02:51 <jamielennox> o/
21:02:53 <mugsie> o/
21:02:54 <samueldmq> thingee: me too please :)
21:02:59 <notmorgan> oh hey. new channel
21:03:00 <nikhil_k> thingee: please do, though I should ideally be on the list
21:03:00 <thingee> #topic Team announcements (horizontal, vertical, diagonal)
21:03:02 <notmorgan> just realized.
21:03:06 <dtroyer> o/
21:03:08 <thingee> nikhil_k: will do
21:03:21 <adam_g> o/
21:03:22 <thingee> what's going on people
21:03:36 <thingee> with your project that others should be aware of?
21:03:44 <odyssey4me> o/
21:03:56 <angdraug> o/
21:04:14 <thingee> #info Final release for  non-client libraries: Feb 24
21:04:16 <dhellmann> o/
21:04:22 <thingee> #info Final release for client libraries: Mar 2
21:04:31 <thingee> #info Mitaka 3: Feb 29-Mar 4 (includes feature freeze and soft string freeze)
21:04:34 <lifeless> grah, echannels
21:04:46 <thingee> read all about these release focuses from your release manager dhellmann http://lists.openstack.org/pipermail/openstack-dev/2016-February/085705.html
21:04:54 <smcginnis> Of interest to possibly nova, cinder is planning on a final os-brick release next week.
21:05:01 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/085705.html release focuses
21:05:25 <thingee> #info nova/cinder planning final os-brick release next week
21:05:34 <bogdando_> hi
21:05:46 <dims> o/
21:05:49 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086152.html final release process
21:06:14 <sdague> smcginnis: and, the privsep parts are integrated into it?
21:06:24 <loquacities> o/
21:06:56 <thingee> Think it's also good for people to be aware of a discussion started by sdague in terms of api resources and how projects overlap today. This is progress on that issue
21:07:04 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html The trouble with names
21:07:09 <thingee> thanks sdague  for that starting that
21:07:21 <smcginnis> sdague: That's the part we're hoping to finish up in time.
21:07:25 <sdague> thingee: no prob, I'll propose resolution by end of work on that
21:07:29 <sdague> smcginnis: ack, great
21:07:43 <smcginnis> sdague: Keeping my fingers crossed. ;)
21:08:02 <thingee> also there are so many discussions happening with open core, service type names versus project names. If you can't keep up, stay informed with the summaries I try to bring to people http://www.openstack.org/blog/2016/02/openstack-developer-mailing-list-digest-20160205/
21:08:07 <thingee> feedback is much appreciated
21:08:18 <elmiko> sdague: seems like we will still need to setup some sort of registry process, even if the api-wg is going to drive that
21:08:32 <cdent> (thingee's summaries)++
21:08:36 <rockyg> elmiko, ++
21:08:42 <sdague> elmiko: yep
21:08:52 <thingee> sdague: do you want to have a slot to talk about that today?
21:08:55 <thingee> or next week?
21:08:57 <sdague> that's what I meant by proposing resolution
21:08:59 <elmiko> from the reactions on that thread, it seems like the next step
21:09:08 <sdague> thingee: I'll just do it on the mailing list
21:09:13 <thingee> sdague: sounds good :)
21:09:27 <elmiko> thanks sdague
21:09:42 <thingee> #topic Quotas: Cross project vs. distributed & dedicated. What are the current challenges and are there any unannounced plans?
21:09:45 <thingee> nikhil_k: hi!
21:09:51 <nikhil_k> hi hi
21:10:18 <nikhil_k> So, that's me trying to get some sense out of the community of what we must do in "newton"
21:10:48 <nikhil_k> I know there has been a bit of back and forth and finally many (big) projects went ahead with dedicated quota effort in the resp proj
21:11:11 <nikhil_k> In glance we are trying to accomplish a nested or simple quota mechanism
21:11:30 <nikhil_k> and the dilemma persist on what's the right thing to do
21:11:45 <nikhil_k> first questions as usually were "what's the larger community want"
21:11:56 <nikhil_k> and I am hoping to get some answers here for that
21:12:11 <nikhil_k> 1. Are there any other projects that are implementing quotas?
21:12:36 <nikhil_k> 2. Are there any strong nested quota or simple quota implementations?
21:12:49 <nikhil_k> 3. Do we need to start a guideline spec?
21:12:52 <diablo_rojo> nikhil_k: Cinder is currently working on getting their quota implementations cleaned up- they are currently VERY broken
21:13:07 <thingee> so the nested quota thing is kind of a disappointing feature at the moment unless we have a cross effort to make it available
21:13:39 <notmyname> nikhil_k: swift supports quotas http://docs.openstack.org/developer/swift/api/container_quotas.html
21:13:42 <nikhil_k> diablo_rojo: I heard the transition was from simple to complex, is that some unadvised ?
21:13:44 <ayoung> What makes it broken?
21:13:44 <samueldmq> nikhil_k: from what I understand, your goal is to get a consistent approach for quotas in openstack right ?
21:14:02 <samueldmq> e.g an unique approach for nested quotas across projects
21:14:20 <thingee> Right, I think we don't want to say these three projects support nested quotas, everyone else, eh maybe they do?
21:14:25 <thingee> it's bad experience
21:14:44 <redrobot> barbican supports quotas as well http://docs.openstack.org/developer/barbican/api/reference/quotas.html
21:14:53 <henrynash> this is probably also requiedd given that keystone is making some changes where a domain is actually represented as a top level parenr project to all projects in that domain
21:14:55 <samueldmq> thingee: why can't 3 projects support nested quotas ?
21:15:00 <smcginnis> redrobot, notmyname: Quotas, or nested quotas?
21:15:02 <nikhil_k> samueldmq: My approach is to try to get consistent with the community as far as possible
21:15:08 <samueldmq> thingee:  you mean a single config across projects ?
21:15:10 <henrynash> this = a cross project approach
21:15:15 <nikhil_k> samueldmq: but I would love some insights into nested work
21:15:16 <notmyname> smcginnis: what's a nested quota?
21:15:30 <thingee> samueldmq: well what if you want nested quotas available in all your services? I'm just saying it's not widely available.
21:15:30 <smcginnis> OK. :)
21:15:30 <redrobot> smcginnis yeah... not sure what "nested" means?
21:15:32 <diablo_rojo> I should have specified nested quotas is broken in Cinder, not regular quotas
21:15:43 <samueldmq> notmyname: it's related to how set quotas in a project hierarchy
21:15:49 <flwang> glance is using config file to store the quota, and we're going to use db-based
21:15:53 <bknudson_> could we have a quota microservice?
21:16:05 <flwang> and then the question is what's the api should be looked like?
21:16:13 <notmyname> smcginnis: wat?
21:16:16 <samueldmq> notmyname: where a quota of child projects depends on their parent quota
21:16:25 <thingee> #link http://specs.openstack.org/openstack/cinder-specs/specs/liberty/cinder-nested-quota-driver.html nested quota
21:16:31 <thingee> so there's the first problem^
21:16:33 <nikhil_k> flwang: I think that's not it
21:16:38 <flwang> since nova/cinder/neutorn/swift are using different(more or less) api format
21:16:47 <mugsie> designate has had quotas for quite a while as well - http://docs.openstack.org/developer/designate/rest/admin/quotas.html
21:16:49 <thingee> it's only a project spec. For some reason I thought we had this in a cross-project spec
21:16:54 <nikhil_k> Glance wants quotas for data, no. images etc. A DB based approach covers everything.
21:17:27 <nikhil_k> diablo_rojo: I heard the transition was from simple to complex, is that some unadvised ? I mean we start with simple and then try a nested approach later?
21:17:41 <smcginnis> I definitely think we need a cp-spec. First to make sure everyone knows what "nested quotas" means...
21:17:46 <samueldmq> thingee: I agree, even thought we have different APIs, the behavior should be the same across projects (for nested quotas ,eg)
21:18:04 <smcginnis> And second to make sure we implement it in an at least semi-consistent way across projects.
21:18:18 <thingee> nikhil_k: I feel like I'm hijacking your topic. Was it just around nested quotas?
21:18:50 <nikhil_k> thingee: no, this is useful. I am taking notes and will prolly come back on this topic in a couple of weeks with more ad-hoc discussions.
21:18:55 <diablo_rojo> nikhil_k: To understand the structure of how nested quotas works it would make sense to have quotas working properly first, in my opinion anyway.
21:19:07 <nikhil_k> I see
21:19:16 <flwang> thingee: glance team also want to know the experience if it's the good way from simple to nested or just go for nested directly
21:19:17 <rockyg> thingee, If the xproject spec addresses nested quotas for all projects, I think it answers nikhil_k's questions
21:19:50 <nikhil_k> diablo_rojo: personally, I am a bit worried on the upgrades though (ie from simple to nested) and wasn't sure if any project is attempting to do that now
21:20:14 <thingee> harlowja: ping
21:20:20 <harlowja> thinrichs pong
21:20:23 <harlowja> vilobhmm11 pong
21:20:24 <harlowja> penick pong
21:20:29 <harlowja> *just noticed this being talked about, ha
21:20:29 <thingee> harlowja: is the person that worked on nested quotas around?
21:20:32 <harlowja> vilobhmm11 ping
21:20:33 <harlowja> ;)
21:20:43 <harlowja> they might be reading the logs to catch up
21:20:43 <thingee> harlowja: I think he would have good insight in what nikhil_k is asking
21:20:46 <harlowja> yup
21:20:49 <harlowja> agreed +1
21:21:03 <harlowja> vilobhmm11 likely catching up
21:21:09 <diablo_rojo> nikhil_k: I am not sure we are working on upgrading exactly, or just working on getting an implementation of nested quotas in addition to regular quotas, I just pinged the person working on it in Cinder to see if he would talk a bit, otherwise I can put you in contact with him after.
21:21:10 <vilobhmm11> thingee : i m here
21:21:29 <nikhil_k> diablo_rojo: that would be great
21:21:43 <thingee> diablo_rojo: right but you have to transition to nested quotas if users are already using quotas in your project.
21:21:50 <thingee> I think that's what upgrade is meaning in this context
21:21:51 <samueldmq> fyi: if you don't have a project hierarchy, nested quotas = regular quotas anyways
21:22:08 <harlowja> thingee +1 to 'the nested quota thing is kind of a disappointing feature at the moment unless we have a cross effort'
21:22:11 <diablo_rojo> thingee: Oh okay, that makes more sense.
21:22:18 <penick> *skims log*
21:22:34 <vilobhmm11> nikhil_k : had filed blueprint for glance as well https://blueprints.launchpad.net/glance/+spec/glance-quota-enhancements but looks like this was not a priority then
21:22:49 <vilobhmm11> thingee : nested quota had a lot of push back in the past
21:23:01 <vilobhmm11> even this time the nested quota feature for nova has been pushed to newton
21:23:17 <nikhil_k> vilobhmm11: yeah, I know! there are/were 5 quota BPs that I know of
21:23:24 <thingee> johnthetubaguy: ^
21:23:24 <harlowja> i'd like a cp-spec as smcginnis  was talking about, it'd be nice to have a agreement cp wise what to do here (because each project will get quota, as they have, and they will all vary)
21:23:26 <penick> I think the transition is fairly minimal if you’re not using hierarchical multitenancy yet, but I definitely need nested quotas in my environment across neutron, nova, glance, etc
21:23:35 <vilobhmm11> thingee : if as a community we are interested  we can definately take it forward
21:23:46 <harlowja> said cp-spec will not be easy to pull off (since projects already have impls of quota, in various ways...)
21:24:01 <diablo_rojo> nikhil_k: I just got a response from him, he should be here in a sec.
21:24:10 <thingee> nikhil_k: so I think it would be good if we could have cinder's spec be brought to a cross-project spec and start getting people familiar with the tech details
21:24:18 <samueldmq> harlowja: +1 on cross-project spec
21:24:20 <mc_nair> hey there
21:24:31 <penick> harlowja: Are there any oslo libraries for quota mgmt in existence?
21:24:39 <harlowja> penick so there was an attempt
21:24:39 <diablo_rojo> mc_nair: nikhil_k wanted to know about if it is better to implement quotas first or go right for nested quotas
21:24:46 <penick> (dont say boson)
21:24:47 <nikhil_k> penick: exactly, the clause being not using yet. I think we are getting requirement of HMT in glance and nested quotas in glance at the same time. I want it to be simplistic from ops standapoint :)
21:24:50 <thingee> from there cp-spec liaisons can carry the priority forward to their respected projects
21:24:54 <harlowja> it gets into a tricky gray area penick  because that library needs to store data somewhere
21:24:58 <harlowja> and not alot of oslo libraries do this
21:25:09 <harlowja> because migrations of data now become library responsiblity (where is the data stored?)
21:25:10 <nikhil_k> thingee: that sounds fair
21:25:19 <vilobhmm11> thingee : cinder nested quota driver  https://blueprints.launchpad.net/cinder/+spec/cinder-nested-quota-driver nikhil_k
21:25:22 <dims> once upon a time we had plans for quota library penick - https://review.openstack.org/#/c/132127/
21:25:25 <vilobhmm11> has more details
21:25:26 <penick> Well, a starting point would be a common library with a common data model, even if stored in project-specific dbs. At least we can work from there
21:25:37 <harlowja> dims right penick see commentary in that review
21:25:37 <dolphm> there's openstack.common.quota http://docs.openstack.org/developer/oslo-incubator/api/openstack.common.quota.html
21:25:58 <harlowja> penick quite possibly, the main objections where what to do about data migrations
21:26:04 <thingee> dims: seems to make sense, not sure what the push back was.
21:26:04 <dims> penick : y, maintaining db was the thing that stopped its progress
21:26:08 <harlowja> and 'We have plans to massively rework the nova quota stuff in liberty, I wonder if we want to do that first, as it might end up being quite a good base for oslo, if we get all those things done?'
21:26:11 <thingee> dims: I mean, I need to read that closer :)
21:26:12 <harlowja> that also didn't help, ha
21:26:15 <mc_nair> nikhil_k: IMO you should be able to implement quotas first and extend that support for nested quotas.
21:26:36 <vilobhmm11> mc_nair : +1
21:26:40 <dims> thingee ack :)
21:26:43 <thingee> mc_nair: I agree
21:26:46 <mc_nair> nikhil_k: I just put up a patch for https://review.openstack.org/#/c/274825/ which will split out the nested quota support into it's own driver
21:27:10 <thingee> nikhil_k: the oslo quota thing might also be interesting. Too bad cinder is already spearheading things. But it can always adopt a module later if that ends being the case.
21:27:32 <mc_nair> I like the idea of moving this effort cross-project (at least w/ collaboration) but for the time being I've just been scrambling to get the existing stuff in Cinder fixed up because we already released some stuff that's got some bugs
21:27:33 <harlowja> but dims and other oslo people (me included) are probably ok with thinking about oslo again (i'll try not to put words in dims  mouth)
21:27:36 <thingee> so who is interested in copying the spec and bring it forward as a cp-spec?
21:27:38 <harlowja> but same objects are still going to happen ;)
21:27:38 <penick> the ‘wait until we rework quota’ thing does ring a bell. But, i’m not sure how far that got compared to their other priorities
21:27:44 <harlowja> *objections, not objects, lol
21:28:08 <nikhil_k> thingee: olso.quotas would be great. Would be even better if the wait wasn't of separation from nova!
21:28:10 <dims> harlowja : yep
21:28:28 <harlowja> so cp-spec with maybe something in oslo
21:28:29 <penick> I think a cross-project spec would be better, since trying to take something project specific and make it usable for other technologies has some drawbacks. like baremetal vs VM in the compute layer.
21:28:35 <nikhil_k> thingee: I can do that if no one from cinder is interested
21:28:48 <thingee> nikhil_k: check with dims on the oslo spec if one exists
21:29:00 <nikhil_k> I want to see this stuff through in newton as far as possible
21:29:01 <thingee> we can promote it within this channel of people
21:29:01 <harlowja> nikhil_k ya, there might have been one, i can't remember, dims might remember, ha
21:29:01 <vilobhmm11> nikhil_k : feel free to involve me if any help is needed
21:29:05 <mc_nair> nikhil_k: I'm up for helping with that also
21:29:28 <thingee> #action nikhil_k to look into possibly a cp-spec or oslo spec that already exists for quotas
21:29:29 <dims> we'll need someone from nova :)
21:29:40 <smcginnis> mc_nair has been doing a lot of work on this in cinder, so yes, please include him.
21:29:43 <harlowja> dims and or all the projects with quota impls (future or present)
21:29:43 <thingee> johnthetubaguy is my cc for this meeting, but not sure he's around
21:30:04 <thingee> alright lets move on because we have some others that were kind to join to talk about their specs.
21:30:08 <thingee> thanks nikhil_k
21:30:20 <nikhil_k> thanks you.
21:30:24 <nikhil_k> thank*
21:30:26 <dims> harlowja : ack
21:30:26 <cdent> I'm here sort of as nova-rep, but my context on nova quota is nil so far
21:30:32 <cdent> I can make sure john's aware
21:30:33 <dims> cdent : yay
21:30:38 <thingee> cdent: sorry forgot about you!
21:30:43 <thingee> :(
21:30:47 <thingee> #topic Query Config From UI
21:31:02 <thingee> ayoung: hi
21:31:29 <thingee> #link https://review.openstack.org/#/c/242852/ Query Config from UI spec
21:31:46 <ayoung> Yo
21:31:52 <rockyg> quickie on last topic:  https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking ln#453  Quotas subteam info
21:31:59 <ayoung> So, this came up in the past on a couple occasions
21:32:01 <cdent> Maybe it is just me, but I feel like the actual proposal isn't really present in that spec
21:32:08 <cdent> thus my comments are sort of from left field
21:32:13 <ayoung> the biggest one was v2 to v3 conversion
21:32:26 <ayoung> we had kn way of reporting what the Default domain was
21:32:28 <jroll> cdent: +1, but going to hear adam out first :)
21:32:31 <ayoung> not a big deal, punted on it
21:32:45 <ayoung> but it seems to keep coming up.  I was looking at this from a Keystone perspective
21:32:56 <bknudson_> does UI mean horizon?
21:32:56 <ayoung> and was told others have the same problem, and we should think cross project
21:32:59 <ayoung> so here I am
21:33:38 <jroll> so, my feelings on exposing config options in an API aside, this seems to be an incomplete spec
21:33:39 <ayoung> I think the origianal blueprint got decomissioned.
21:33:47 <jroll> so I'm curious, what the question we want to answer in this meeting is
21:33:48 <ayoung> It was incomplete
21:33:55 <thingee> bknudson_: I was confused by that too, but I think it's meant from the rest api.
21:33:59 <ayoung> I brought it up because I've been told others are pursuing this as well
21:34:02 <rockyg> I think from UI means coming up with cp standard for the callbacks for all the projects
21:34:07 <ayoung> yeah,  is should be REST API.
21:34:13 <ayoung> hmmm
21:34:26 <rockyg> REST ++
21:34:51 <cdent> callbacks for what?
21:34:55 <ayoung> So...do other teams have this issue?
21:35:06 <bknudson_> operators don't know how their systems are configured?
21:35:15 <jroll> ++
21:35:32 <rockyg> configs change.  What is it *now*?
21:35:33 <jroll> I disagree with the premise there should ever be a GET /config/foo API
21:35:36 <ayoung> The idea is that if there are a subset of config options (not passwords for duh reasons) that need to be remotely queryable
21:35:49 <ayoung> jroll, rationale?
21:35:56 <cdent> ayoung: to answer what question(s)?
21:36:14 <jroll> but rather something like (for this specific case), the /domains endpoint might return a "default": "foo" that is the value of that config option
21:36:14 <ayoung> "I disagree with the premise there should ever be a GET /config/foo API"
21:36:31 <fungi> is this meant as a solution to the lack of end-user/app-dev discoverability for various deployment choices in different providers?
21:37:16 <ayoung> jroll, that could certainly work for my use.  The question is does that cover what other people are asking for
21:37:29 <bknudson_> keystone has some REST APIs for getting config -- http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#domain-configuration-management
21:37:30 <ayoung> WIth policy enforcement, we have found ways to work around it thus far
21:37:46 <thingee> The problem description lists something that keystone wants to query in configs. I think ayoung wants to know does anyone else need this?
21:37:51 <thingee> correct me if I'm wrong ayoung
21:38:00 * cdent still doesn't understand why people want to query configs
21:38:08 <ayoung> thingee, you are right
21:38:12 <jroll> ayoung: I'm struggling to come up with a coherent reason "why not" other than "why would you"
21:38:20 <thingee> ok so not really something available to users, but sservices
21:38:22 <cdent> I'm not disputing that someone might, but it would help to know why?
21:38:35 <jroll> anyway, to answer the question, no I don't see a need for this :)
21:38:36 <samueldmq> exposing config via APIs might help on improving UX, e.g horizon hiding some buttons if user can't be created in the current domain
21:38:55 <ayoung> the two reasons I've come up with both involve defaulting values for migrating forward
21:38:56 <rockyg> jroll, troubleshooting?
21:39:03 <ayoung> but they are ,as pointed out, specific values
21:39:09 <jroll> rockyg: ssh? read the config management?
21:39:12 <fungi> got it, so "querying configs" is a solution for some discoverability issue in $random_service which keystone will base some behavior on
21:39:25 <thingee> samueldmq: that's a good point
21:39:59 <cdent> would another way to describe this be: capabilities discovery?
21:40:04 <thingee> so ayoung it sounds like it could be interesting for horizon. but people who are present here don't have a need for it.
21:40:12 <jroll> I tend to think what is actually desired is "expose an API to get the value of $thing, which happens to be set by a config option"
21:40:33 <rockyg> jroll, so login to service vm, cd to /etc/nnn/config, find out you want some other config option, repeat?
21:40:50 <fungi> one possible devil's advocate question is, why not fix the discoverability issue in that service instead of just parsing its configuration somewhere that the configuration isn't actually directly applicable?
21:40:58 <fungi> or yes, what cdent said in fewer words
21:41:00 <lifeless> so years ago LP had this concept that you'd surface *everything* to the user
21:41:01 <elmiko> tend to agree with jroll, i'm having trouble coming up with a "why not". although i have not heard any rumblings about needing this capability.
21:41:04 <thingee> fungi: right I think that's what jroll was touching on
21:41:07 <lifeless> it was in hindsight a terrible idea
21:41:08 <samueldmq> thingee: however domain configs can already e stored/retrieved via API in keystone (as bknudson_ pointed above)
21:41:24 <samueldmq> I think a good question to start is "what use cases are we trying to solve? who needs it?'
21:41:24 <jroll> rockyg: yes; you'd need to ssh to change the config anyway, unless this can also change configs which is a huge can of worms :)
21:41:47 <lifeless> In my experience you need to actually think about each thing being surfaced and decide where it belongs and how to best present it
21:41:52 <elmiko> samueldmq: +1
21:41:52 <fungi> lifeless: then everything becomes a contractual api and you can't ever change anything?
21:42:13 <thingee> Ok so it sounds like we're unsure of the use case for this and also that's potentially hiding another problem os service capabilities being discovered
21:42:16 <lifeless> fungi: that is one of the side effects of surfacing everything without care, yes.
21:42:31 <lifeless> fungi: another specific problem was that internal model != external model
21:42:31 <rockyg> jroll, don't necessarily need to change, just get the info quickly
21:42:36 <thingee> I think all this would be good feedback for people to add to the spec so that we have it there.
21:42:44 <jroll> fungi: lifeless: ah yes, this also has implications for deprecating configs
21:42:46 <lifeless> fungi: e.g. how we configure things from a sysadmin view, vs how users are affected are very different things
21:42:47 <david-lyle> some specific examples of need for Horizon are around policy, but fix centralized policy and that goes away
21:42:59 <jroll> given the "never delete API endpoints" talk/work lately
21:43:01 <notmorgan> also keep in mind that configs often hold sensitive data, so it's another additonal surface area to verify is safe/sane/sanatized
21:43:05 <lifeless> jroll: exactly
21:43:30 <fungi> effectively, your configs become an api in their entirety
21:43:34 <lifeless> yup
21:43:37 <thingee> ayoung: not sure if this feedback was helpful. you're quiet :)
21:43:38 <notmorgan> fungi: oh i don't like that
21:43:45 <lifeless> and they are, but currently on a different lifecycle, and with different audiences
21:43:47 <ayoung> thingee, I want input
21:43:49 * jroll quivers
21:43:50 <notmorgan> can we not make configs an API :P
21:43:52 <fungi> and who knows what random services will start depending on nuanced details of your configuration
21:43:58 <notmorgan> fungi: exactly
21:44:02 <jroll> +1
21:44:08 <ayoung> as I said, I have workarounds for this
21:44:26 <ayoung> but they don't feel any better than querying the value
21:44:32 <angdraug> there's also a concern of not coupling this to config _files_, especially in specific format (ini)
21:44:35 <bknudson_> how about rather than a config api we have a capabilities discovery api?
21:44:43 <lifeless> ayoung: I'm not against surfacing chosen things one by one
21:44:45 <david-lyle> bknudson_: ++
21:44:51 <notmorgan> bknudson_: better idea
21:45:03 <lifeless> ayoung: but - as bknudson_ says :)
21:45:18 <breton> (btw, we already have configs in api in keystone)
21:45:19 <ayoung> for example, to fix https://bugs.launchpad.net/keystone/+bug/968696  we actually added the value to the token response
21:45:20 <openstack> Launchpad bug 968696 in Glance ""admin"-ness not properly scoped" [High,Triaged]
21:45:21 <samueldmq> what is a capability we're talking about ?
21:45:22 <jroll> or even GET /domains/default
21:45:38 <thingee> fwiw, cinder has a concept of capabilities
21:45:39 <notmorgan> jroll: that is not unreasonable.
21:45:39 <samueldmq> APIs == capabilities ?
21:45:39 <jroll> but not GET /configs/default_v2_domain or whatever
21:45:44 <thingee> that can be asked for
21:45:58 <rockyg> Yeah.  I don't think most sysadmins would want *all* the configs and values on q query.  Usually they are hunting for a specific one.
21:46:02 <notmorgan> jroll: also leans towards expicit specific information
21:46:08 <notmorgan> not "the config data"
21:46:13 <jroll> notmorgan: again this should be a "expose an API to get the value of $thing, which happens to be set by a config option"
21:46:15 <jroll> yeah
21:46:22 <jroll> the fact it's a config is tangential
21:46:27 <thingee> Ok so lets get some feedback back on the specs for ayoung to iterated on. we still have one more topic
21:46:33 <jroll> we should get users the data they need, no matter where it comes from
21:46:51 <ayoung> so, I was origianlly thinking that we would use a config option in policy enforcement, which might also be useful beyhond Keystone
21:47:04 <rockyg> jroll, ++
21:47:06 <samueldmq> I don't think we should expose every config, let's think about the use cases, and how to solve them; as we did with domain configs API in keystone
21:47:10 <ayoung> for exdample if networkid = config.admin.netowkr.id or soemthing in Neutron
21:47:19 <notmorgan> ayoung: i am fairly against that unless there realy is no good other options
21:47:51 <ayoung> notmorgan, well, there wasn't for policy, which is why henrynash 's example had you editing the poluicy file
21:48:04 <ayoung> so if you need to edit a policy file, I'd argue its config anyway
21:48:14 <notmorgan> except it is contained in policy
21:48:25 <david-lyle> policy and config
21:48:28 <notmorgan> vs. set [potentially] in multiple places
21:48:33 <ayoung> Note that for policy it does not need to be remotely queryable
21:48:43 <ayoung> just locally exposed to the policy engine
21:48:53 <notmorgan> which could be an entry in the policy file
21:48:57 <notmorgan> contained
21:49:21 <notmorgan> spreading this across multiple locations makes it far far more complex imo
21:50:04 <samueldmq> 10 mins left
21:50:05 <notmorgan> i'd rather see it contained in policy DSL than cross policy and osli.config
21:50:07 <notmorgan> if that makes sense
21:50:18 <ayoung> Anyway, that was my original reason for asking, and we have a lot of people shouiting "No" and I really am OK with letting this go.
21:50:45 <notmorgan> ayoung: i think some of the other policy tnings can lead into a nice solution for you.. we'll chat more offline
21:50:51 <thingee> ok, so like I said, seems like there are some things to be worked in the spec based on some good feedback from the group. ayoung got some input that.
21:50:53 <notmorgan> ayoung: we talked about last week,
21:51:00 <thingee> dolphm: I believe you need more time than 10 mins?
21:51:09 <dolphm> definitely
21:51:18 <dolphm> it'll take 10 minutes to introduce the topic
21:51:21 * jroll posts on the spec
21:51:39 * notmorgan cheers for dolphm's topic
21:51:45 <thingee> ok, lets punt dolphm's topic to next week
21:51:47 <dolphm> in the mean time, everyone become opinionated on the spec as homework https://review.openstack.org/#/c/245629/
21:51:51 * notmorgan is sad there isn't time today
21:51:59 <ayoung> Oh. damn
21:52:08 <ayoung> I would have preferred we talk about that
21:52:11 <notmorgan> dolphm: i am already opinionated on the spec... it should be a thing!
21:52:15 <notmorgan> :P
21:52:21 <david-lyle> ++
21:52:24 <thingee> #link https://review.openstack.org/#/c/245629/ Homework: A Common Policy Scenario Across All Projects
21:52:25 <ayoung> but, yeah, that one is a big one.
21:52:42 <notmorgan> thingee: can we prioritise that first thing next week?
21:52:44 <rockyg> You realize this is right in the middle (well end) of the ops summit, where you have *very* opinionated users who could comment?
21:52:47 <notmorgan> it is a big topic
21:52:52 <cdent> emerging conensus of too big ;)
21:52:56 <thingee> so yes, that means we will be having a cross-project meeting next week!
21:53:05 <thingee> notmorgan: of course. it waited through this meeting
21:53:05 <diablo_rojo> YAY!
21:53:13 <notmorgan> thingee: just making sure :)
21:53:16 <samueldmq> ++
21:53:24 <thingee> #topic open discussion
21:53:24 <ayoung> also, as part of the homework, note that we now have implied roles to work with which makes this easier to implement, but also has ramifications
21:53:27 <bogdando_> The spec for instances evacuation https://review.openstack.org/#/c/257809/ was updated to reflect actual initiatives (as I see it) in progress by the #ha-openstack members. Please take a look. That is related to Nova and Mistral projects mostly.
21:53:27 <jroll> dolphm: so I assume a project that is all-or-nothing policy will need to add policy entries for all the things to satisfy this? :)
21:53:46 <dolphm> jroll: that would be a good starting point ;)
21:54:08 <jroll> dolphm: heh. good, I like
21:54:11 <dolphm> i *might* break down the spec into two parts before next week - what we have an existing, strong demand for, and the logical conclusion to policy as we know it
21:55:00 <jamielennox> dolphm: maybe we make the per-controller stuff optional or different spec
21:55:18 <thingee> dolphm: keep in mind just like the service catalog TNG, you are able to hold your own meeting in this channel
21:55:22 <jamielennox> i don't mind if services want to do something but leave it out of the common
21:55:23 <dolphm> jamielennox: right, split manager roles and endpoint / capability roles into a separate spec
21:55:25 <ayoung> dolphm, the way I've started thinking of things is in 3 levels.  THe top level is "here is the job you are assigned to do"  the middle level is "here are the set of workflows you need to perform for your job" and the bottom level is "here are the permissions  on the resourcesyou need to perform the workflows"
21:55:47 <thingee> dolphm: I can talk to you more about that offline
21:55:54 <dolphm> thingee: i think this is the right audience for the initial discussion - if we need to carry on more meetings, then ++
21:56:04 <thingee> dolphm: sounds good
21:56:20 <jamielennox> the original goal of this was not to solve all problems for all deployers, just get the deployers who don't change policy files past admin/non-admin
21:56:37 <dolphm> jamielennox: i definitely hijacked it
21:56:43 <jamielennox> if we want to flesh out a complete policy i'm ok, but i'd take the immediate win rather tahn debate it forever
21:57:08 <jamielennox> i think the deployers who want that level of granularity are the ones who can maintain there own policy files
21:57:25 <dolphm> but if we have more than a couple, my argument is that it should be upstream
21:58:16 <jamielennox> ideally sure
21:58:28 <thingee> dolphm: would it be useful for me to start promoting this to ops folks? If so, next week will be bad due to ops midcycle
21:58:46 <dolphm> thingee: ooh, that's a good question...
21:58:53 <jamielennox> but we put out that call for what things do you customize in your policy files and there really wasn't much
21:59:02 <ayoung> thingee, we could call in to the ops midcycle via telconfernece
21:59:15 <dolphm> let's not
21:59:21 <jamielennox> which is not to say they wouldn't use it if not available, just this covered most of their needs
21:59:26 <thingee> well I think it just means people be part of the irc channel in their TZ...
21:59:38 <jroll> so there's two main goals here, right? 1) get people to stop using admin, generally; 2) get something somewhat common in policy amongst the projects
21:59:46 <dolphm> jroll: yes
21:59:52 <dolphm> jroll: and upstream the things deployers are already doing
22:00:03 <jroll> ++
22:00:05 <thingee> so dolphm next week still or punt after midcycle?
22:00:23 <dolphm> i'm good for next week
22:00:28 <thingee> ok!
22:00:30 <thingee> thanks everyone
22:00:33 <thingee> #endmeeting