21:01:38 #startmeeting crossproject 21:01:39 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:42 The meeting name has been set to 'crossproject' 21:01:45 hey 21:01:45 jroll: i don't disassociate 21:01:54 how do I get on the ping list? 21:01:55 :P 21:02:12 Agenda: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting 21:02:26 nikhil_: since you proposed the quota topic? 21:02:35 nikhil_: oh sorry, I thought I grabbed everyone on the cp-spec laision list. I can also just add you :) 21:02:41 flwang: that's not the first item 21:02:43 o/ 21:02:51 o/ 21:02:53 o/ 21:02:54 thingee: me too please :) 21:02:59 oh hey. new channel 21:03:00 thingee: please do, though I should ideally be on the list 21:03:00 #topic Team announcements (horizontal, vertical, diagonal) 21:03:02 just realized. 21:03:06 o/ 21:03:08 nikhil_k: will do 21:03:21 o/ 21:03:22 what's going on people 21:03:36 with your project that others should be aware of? 21:03:44 o/ 21:03:56 o/ 21:04:14 #info Final release for non-client libraries: Feb 24 21:04:16 o/ 21:04:22 #info Final release for client libraries: Mar 2 21:04:31 #info Mitaka 3: Feb 29-Mar 4 (includes feature freeze and soft string freeze) 21:04:34 grah, echannels 21:04:46 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 Of interest to possibly nova, cinder is planning on a final os-brick release next week. 21:05:01 #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/085705.html release focuses 21:05:25 #info nova/cinder planning final os-brick release next week 21:05:34 hi 21:05:46 o/ 21:05:49 #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086152.html final release process 21:06:14 smcginnis: and, the privsep parts are integrated into it? 21:06:24 o/ 21:06:56 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 #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html The trouble with names 21:07:09 thanks sdague for that starting that 21:07:21 sdague: That's the part we're hoping to finish up in time. 21:07:25 thingee: no prob, I'll propose resolution by end of work on that 21:07:29 smcginnis: ack, great 21:07:43 sdague: Keeping my fingers crossed. ;) 21:08:02 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 feedback is much appreciated 21:08:18 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 (thingee's summaries)++ 21:08:36 elmiko, ++ 21:08:42 elmiko: yep 21:08:52 sdague: do you want to have a slot to talk about that today? 21:08:55 or next week? 21:08:57 that's what I meant by proposing resolution 21:08:59 from the reactions on that thread, it seems like the next step 21:09:08 thingee: I'll just do it on the mailing list 21:09:13 sdague: sounds good :) 21:09:27 thanks sdague 21:09:42 #topic Quotas: Cross project vs. distributed & dedicated. What are the current challenges and are there any unannounced plans? 21:09:45 nikhil_k: hi! 21:09:51 hi hi 21:10:18 So, that's me trying to get some sense out of the community of what we must do in "newton" 21:10:48 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 In glance we are trying to accomplish a nested or simple quota mechanism 21:11:30 and the dilemma persist on what's the right thing to do 21:11:45 first questions as usually were "what's the larger community want" 21:11:56 and I am hoping to get some answers here for that 21:12:11 1. Are there any other projects that are implementing quotas? 21:12:36 2. Are there any strong nested quota or simple quota implementations? 21:12:49 3. Do we need to start a guideline spec? 21:12:52 nikhil_k: Cinder is currently working on getting their quota implementations cleaned up- they are currently VERY broken 21:13:07 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 nikhil_k: swift supports quotas http://docs.openstack.org/developer/swift/api/container_quotas.html 21:13:42 diablo_rojo: I heard the transition was from simple to complex, is that some unadvised ? 21:13:44 What makes it broken? 21:13:44 nikhil_k: from what I understand, your goal is to get a consistent approach for quotas in openstack right ? 21:14:02 e.g an unique approach for nested quotas across projects 21:14:20 Right, I think we don't want to say these three projects support nested quotas, everyone else, eh maybe they do? 21:14:25 it's bad experience 21:14:44 barbican supports quotas as well http://docs.openstack.org/developer/barbican/api/reference/quotas.html 21:14:53 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 thingee: why can't 3 projects support nested quotas ? 21:15:00 redrobot, notmyname: Quotas, or nested quotas? 21:15:02 samueldmq: My approach is to try to get consistent with the community as far as possible 21:15:08 thingee: you mean a single config across projects ? 21:15:10 this = a cross project approach 21:15:15 samueldmq: but I would love some insights into nested work 21:15:16 smcginnis: what's a nested quota? 21:15:30 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 OK. :) 21:15:30 smcginnis yeah... not sure what "nested" means? 21:15:32 I should have specified nested quotas is broken in Cinder, not regular quotas 21:15:43 notmyname: it's related to how set quotas in a project hierarchy 21:15:49 glance is using config file to store the quota, and we're going to use db-based 21:15:53 could we have a quota microservice? 21:16:05 and then the question is what's the api should be looked like? 21:16:13 smcginnis: wat? 21:16:16 notmyname: where a quota of child projects depends on their parent quota 21:16:25 #link http://specs.openstack.org/openstack/cinder-specs/specs/liberty/cinder-nested-quota-driver.html nested quota 21:16:31 so there's the first problem^ 21:16:33 flwang: I think that's not it 21:16:38 since nova/cinder/neutorn/swift are using different(more or less) api format 21:16:47 designate has had quotas for quite a while as well - http://docs.openstack.org/developer/designate/rest/admin/quotas.html 21:16:49 it's only a project spec. For some reason I thought we had this in a cross-project spec 21:16:54 Glance wants quotas for data, no. images etc. A DB based approach covers everything. 21:17:27 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 I definitely think we need a cp-spec. First to make sure everyone knows what "nested quotas" means... 21:17:46 thingee: I agree, even thought we have different APIs, the behavior should be the same across projects (for nested quotas ,eg) 21:18:04 And second to make sure we implement it in an at least semi-consistent way across projects. 21:18:18 nikhil_k: I feel like I'm hijacking your topic. Was it just around nested quotas? 21:18:50 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 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 I see 21:19:16 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 thingee, If the xproject spec addresses nested quotas for all projects, I think it answers nikhil_k's questions 21:19:50 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 harlowja: ping 21:20:20 thinrichs pong 21:20:23 vilobhmm11 pong 21:20:24 penick pong 21:20:29 *just noticed this being talked about, ha 21:20:29 harlowja: is the person that worked on nested quotas around? 21:20:32 vilobhmm11 ping 21:20:33 ;) 21:20:43 they might be reading the logs to catch up 21:20:43 harlowja: I think he would have good insight in what nikhil_k is asking 21:20:46 yup 21:20:49 agreed +1 21:21:03 vilobhmm11 likely catching up 21:21:09 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 thingee : i m here 21:21:29 diablo_rojo: that would be great 21:21:43 diablo_rojo: right but you have to transition to nested quotas if users are already using quotas in your project. 21:21:50 I think that's what upgrade is meaning in this context 21:21:51 fyi: if you don't have a project hierarchy, nested quotas = regular quotas anyways 21:22:08 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 thingee: Oh okay, that makes more sense. 21:22:18 *skims log* 21:22:34 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 thingee : nested quota had a lot of push back in the past 21:23:01 even this time the nested quota feature for nova has been pushed to newton 21:23:17 vilobhmm11: yeah, I know! there are/were 5 quota BPs that I know of 21:23:24 johnthetubaguy: ^ 21:23:24 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 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 thingee : if as a community we are interested we can definately take it forward 21:23:46 said cp-spec will not be easy to pull off (since projects already have impls of quota, in various ways...) 21:24:01 nikhil_k: I just got a response from him, he should be here in a sec. 21:24:10 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 harlowja: +1 on cross-project spec 21:24:20 hey there 21:24:31 harlowja: Are there any oslo libraries for quota mgmt in existence? 21:24:39 penick so there was an attempt 21:24:39 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 (dont say boson) 21:24:47 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 from there cp-spec liaisons can carry the priority forward to their respected projects 21:24:54 it gets into a tricky gray area penick because that library needs to store data somewhere 21:24:58 and not alot of oslo libraries do this 21:25:09 because migrations of data now become library responsiblity (where is the data stored?) 21:25:10 thingee: that sounds fair 21:25:19 thingee : cinder nested quota driver https://blueprints.launchpad.net/cinder/+spec/cinder-nested-quota-driver nikhil_k 21:25:22 once upon a time we had plans for quota library penick - https://review.openstack.org/#/c/132127/ 21:25:25 has more details 21:25:26 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 dims right penick see commentary in that review 21:25:37 there's openstack.common.quota http://docs.openstack.org/developer/oslo-incubator/api/openstack.common.quota.html 21:25:58 penick quite possibly, the main objections where what to do about data migrations 21:26:04 dims: seems to make sense, not sure what the push back was. 21:26:04 penick : y, maintaining db was the thing that stopped its progress 21:26:08 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 dims: I mean, I need to read that closer :) 21:26:12 that also didn't help, ha 21:26:15 nikhil_k: IMO you should be able to implement quotas first and extend that support for nested quotas. 21:26:36 mc_nair : +1 21:26:40 thingee ack :) 21:26:43 mc_nair: I agree 21:26:46 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 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 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 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 so who is interested in copying the spec and bring it forward as a cp-spec? 21:27:38 but same objects are still going to happen ;) 21:27:38 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 *objections, not objects, lol 21:28:08 thingee: olso.quotas would be great. Would be even better if the wait wasn't of separation from nova! 21:28:10 harlowja : yep 21:28:28 so cp-spec with maybe something in oslo 21:28:29 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 thingee: I can do that if no one from cinder is interested 21:28:48 nikhil_k: check with dims on the oslo spec if one exists 21:29:00 I want to see this stuff through in newton as far as possible 21:29:01 we can promote it within this channel of people 21:29:01 nikhil_k ya, there might have been one, i can't remember, dims might remember, ha 21:29:01 nikhil_k : feel free to involve me if any help is needed 21:29:05 nikhil_k: I'm up for helping with that also 21:29:28 #action nikhil_k to look into possibly a cp-spec or oslo spec that already exists for quotas 21:29:29 we'll need someone from nova :) 21:29:40 mc_nair has been doing a lot of work on this in cinder, so yes, please include him. 21:29:43 dims and or all the projects with quota impls (future or present) 21:29:43 johnthetubaguy is my cc for this meeting, but not sure he's around 21:30:04 alright lets move on because we have some others that were kind to join to talk about their specs. 21:30:08 thanks nikhil_k 21:30:20 thanks you. 21:30:24 thank* 21:30:26 harlowja : ack 21:30:26 I'm here sort of as nova-rep, but my context on nova quota is nil so far 21:30:32 I can make sure john's aware 21:30:33 cdent : yay 21:30:38 cdent: sorry forgot about you! 21:30:43 :( 21:30:47 #topic Query Config From UI 21:31:02 ayoung: hi 21:31:29 #link https://review.openstack.org/#/c/242852/ Query Config from UI spec 21:31:46 Yo 21:31:52 quickie on last topic: https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking ln#453 Quotas subteam info 21:31:59 So, this came up in the past on a couple occasions 21:32:01 Maybe it is just me, but I feel like the actual proposal isn't really present in that spec 21:32:08 thus my comments are sort of from left field 21:32:13 the biggest one was v2 to v3 conversion 21:32:26 we had kn way of reporting what the Default domain was 21:32:28 cdent: +1, but going to hear adam out first :) 21:32:31 not a big deal, punted on it 21:32:45 but it seems to keep coming up. I was looking at this from a Keystone perspective 21:32:56 does UI mean horizon? 21:32:56 and was told others have the same problem, and we should think cross project 21:32:59 so here I am 21:33:38 so, my feelings on exposing config options in an API aside, this seems to be an incomplete spec 21:33:39 I think the origianal blueprint got decomissioned. 21:33:47 so I'm curious, what the question we want to answer in this meeting is 21:33:48 It was incomplete 21:33:55 bknudson_: I was confused by that too, but I think it's meant from the rest api. 21:33:59 I brought it up because I've been told others are pursuing this as well 21:34:02 I think from UI means coming up with cp standard for the callbacks for all the projects 21:34:07 yeah, is should be REST API. 21:34:13 hmmm 21:34:26 REST ++ 21:34:51 callbacks for what? 21:34:55 So...do other teams have this issue? 21:35:06 operators don't know how their systems are configured? 21:35:15 ++ 21:35:32 configs change. What is it *now*? 21:35:33 I disagree with the premise there should ever be a GET /config/foo API 21:35:36 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 jroll, rationale? 21:35:56 ayoung: to answer what question(s)? 21:36:14 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 "I disagree with the premise there should ever be a GET /config/foo API" 21:36:31 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 jroll, that could certainly work for my use. The question is does that cover what other people are asking for 21:37:29 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 WIth policy enforcement, we have found ways to work around it thus far 21:37:46 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 correct me if I'm wrong ayoung 21:38:00 * cdent still doesn't understand why people want to query configs 21:38:08 thingee, you are right 21:38:12 ayoung: I'm struggling to come up with a coherent reason "why not" other than "why would you" 21:38:20 ok so not really something available to users, but sservices 21:38:22 I'm not disputing that someone might, but it would help to know why? 21:38:35 anyway, to answer the question, no I don't see a need for this :) 21:38:36 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 the two reasons I've come up with both involve defaulting values for migrating forward 21:38:56 jroll, troubleshooting? 21:39:03 but they are ,as pointed out, specific values 21:39:09 rockyg: ssh? read the config management? 21:39:12 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 samueldmq: that's a good point 21:39:59 would another way to describe this be: capabilities discovery? 21:40:04 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 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 jroll, so login to service vm, cd to /etc/nnn/config, find out you want some other config option, repeat? 21:40:50 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 or yes, what cdent said in fewer words 21:41:00 so years ago LP had this concept that you'd surface *everything* to the user 21:41:01 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 fungi: right I think that's what jroll was touching on 21:41:07 it was in hindsight a terrible idea 21:41:08 thingee: however domain configs can already e stored/retrieved via API in keystone (as bknudson_ pointed above) 21:41:24 I think a good question to start is "what use cases are we trying to solve? who needs it?' 21:41:24 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 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 samueldmq: +1 21:41:52 lifeless: then everything becomes a contractual api and you can't ever change anything? 21:42:13 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 fungi: that is one of the side effects of surfacing everything without care, yes. 21:42:31 fungi: another specific problem was that internal model != external model 21:42:31 jroll, don't necessarily need to change, just get the info quickly 21:42:36 I think all this would be good feedback for people to add to the spec so that we have it there. 21:42:44 fungi: lifeless: ah yes, this also has implications for deprecating configs 21:42:46 fungi: e.g. how we configure things from a sysadmin view, vs how users are affected are very different things 21:42:47 some specific examples of need for Horizon are around policy, but fix centralized policy and that goes away 21:42:59 given the "never delete API endpoints" talk/work lately 21:43:01 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 jroll: exactly 21:43:30 effectively, your configs become an api in their entirety 21:43:34 yup 21:43:37 ayoung: not sure if this feedback was helpful. you're quiet :) 21:43:38 fungi: oh i don't like that 21:43:45 and they are, but currently on a different lifecycle, and with different audiences 21:43:47 thingee, I want input 21:43:49 * jroll quivers 21:43:50 can we not make configs an API :P 21:43:52 and who knows what random services will start depending on nuanced details of your configuration 21:43:58 fungi: exactly 21:44:02 +1 21:44:08 as I said, I have workarounds for this 21:44:26 but they don't feel any better than querying the value 21:44:32 there's also a concern of not coupling this to config _files_, especially in specific format (ini) 21:44:35 how about rather than a config api we have a capabilities discovery api? 21:44:43 ayoung: I'm not against surfacing chosen things one by one 21:44:45 bknudson_: ++ 21:44:51 bknudson_: better idea 21:45:03 ayoung: but - as bknudson_ says :) 21:45:18 (btw, we already have configs in api in keystone) 21:45:19 for example, to fix https://bugs.launchpad.net/keystone/+bug/968696 we actually added the value to the token response 21:45:20 Launchpad bug 968696 in Glance ""admin"-ness not properly scoped" [High,Triaged] 21:45:21 what is a capability we're talking about ? 21:45:22 or even GET /domains/default 21:45:38 fwiw, cinder has a concept of capabilities 21:45:39 jroll: that is not unreasonable. 21:45:39 APIs == capabilities ? 21:45:39 but not GET /configs/default_v2_domain or whatever 21:45:44 that can be asked for 21:45:58 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 jroll: also leans towards expicit specific information 21:46:08 not "the config data" 21:46:13 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 yeah 21:46:22 the fact it's a config is tangential 21:46:27 Ok so lets get some feedback back on the specs for ayoung to iterated on. we still have one more topic 21:46:33 we should get users the data they need, no matter where it comes from 21:46:51 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 jroll, ++ 21:47:06 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 for exdample if networkid = config.admin.netowkr.id or soemthing in Neutron 21:47:19 ayoung: i am fairly against that unless there realy is no good other options 21:47:51 notmorgan, well, there wasn't for policy, which is why henrynash 's example had you editing the poluicy file 21:48:04 so if you need to edit a policy file, I'd argue its config anyway 21:48:14 except it is contained in policy 21:48:25 policy and config 21:48:28 vs. set [potentially] in multiple places 21:48:33 Note that for policy it does not need to be remotely queryable 21:48:43 just locally exposed to the policy engine 21:48:53 which could be an entry in the policy file 21:48:57 contained 21:49:21 spreading this across multiple locations makes it far far more complex imo 21:50:04 10 mins left 21:50:05 i'd rather see it contained in policy DSL than cross policy and osli.config 21:50:07 if that makes sense 21:50:18 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 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 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 ayoung: we talked about last week, 21:51:00 dolphm: I believe you need more time than 10 mins? 21:51:09 definitely 21:51:18 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 ok, lets punt dolphm's topic to next week 21:51:47 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 Oh. damn 21:52:08 I would have preferred we talk about that 21:52:11 dolphm: i am already opinionated on the spec... it should be a thing! 21:52:15 :P 21:52:21 ++ 21:52:24 #link https://review.openstack.org/#/c/245629/ Homework: A Common Policy Scenario Across All Projects 21:52:25 but, yeah, that one is a big one. 21:52:42 thingee: can we prioritise that first thing next week? 21:52:44 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 it is a big topic 21:52:52 emerging conensus of too big ;) 21:52:56 so yes, that means we will be having a cross-project meeting next week! 21:53:05 notmorgan: of course. it waited through this meeting 21:53:05 YAY! 21:53:13 thingee: just making sure :) 21:53:16 ++ 21:53:24 #topic open discussion 21:53:24 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 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 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 jroll: that would be a good starting point ;) 21:54:08 dolphm: heh. good, I like 21:54:11 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 dolphm: maybe we make the per-controller stuff optional or different spec 21:55:18 dolphm: keep in mind just like the service catalog TNG, you are able to hold your own meeting in this channel 21:55:22 i don't mind if services want to do something but leave it out of the common 21:55:23 jamielennox: right, split manager roles and endpoint / capability roles into a separate spec 21:55:25 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 dolphm: I can talk to you more about that offline 21:55:54 thingee: i think this is the right audience for the initial discussion - if we need to carry on more meetings, then ++ 21:56:04 dolphm: sounds good 21:56:20 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 jamielennox: i definitely hijacked it 21:56:43 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 i think the deployers who want that level of granularity are the ones who can maintain there own policy files 21:57:25 but if we have more than a couple, my argument is that it should be upstream 21:58:16 ideally sure 21:58:28 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 thingee: ooh, that's a good question... 21:58:53 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 thingee, we could call in to the ops midcycle via telconfernece 21:59:15