Tuesday, 2016-02-09

*** sdake has joined #openstack-meeting-cp02:55
*** sdake_ has joined #openstack-meeting-cp03:00
*** sdake has quit IRC03:03
*** dims has joined #openstack-meeting-cp03:27
*** dims_ has quit IRC03:28
*** dims has quit IRC03:30
*** dims has joined #openstack-meeting-cp03:43
*** dims has quit IRC03:47
*** sdake_ has quit IRC07:00
*** sdake has joined #openstack-meeting-cp07:01
*** sdake has quit IRC07:03
*** evgenyf has joined #openstack-meeting-cp07:38
*** reed_ has quit IRC07:59
*** reed_ has joined #openstack-meeting-cp08:00
*** reed_ has quit IRC08:01
*** dims has joined #openstack-meeting-cp10:45
*** dims has quit IRC10:49
*** dims has joined #openstack-meeting-cp10:50
*** evgenyf has quit IRC11:24
*** dims_ has joined #openstack-meeting-cp11:40
*** dims has quit IRC11:40
*** dims_ has quit IRC12:11
*** evgenyf has joined #openstack-meeting-cp12:17
*** dims_ has joined #openstack-meeting-cp12:19
*** sdake has joined #openstack-meeting-cp13:19
*** sdake_ has joined #openstack-meeting-cp13:21
*** sdake has quit IRC13:24
*** sdake_ is now known as sdake13:24
*** sdake has quit IRC13:40
*** sdake has joined #openstack-meeting-cp13:41
*** sdake has quit IRC13:48
*** sdake has joined #openstack-meeting-cp13:49
*** dims_ has quit IRC14:03
*** sdake has quit IRC14:10
*** dims has joined #openstack-meeting-cp14:10
*** evgenyf has quit IRC14:24
*** sdake has joined #openstack-meeting-cp14:38
nikhilflwang: hi, ping me when awake :)14:56
*** angdraug has joined #openstack-meeting-cp15:51
*** nikhil is now known as nikhil_k15:56
*** sdake has quit IRC17:11
*** sdake has joined #openstack-meeting-cp17:13
-openstackstatus- NOTICE: Gerrit is restarting now, to alleviate current performance impact and WebUI errors.17:24
*** sdake has quit IRC17:33
*** sdake has joined #openstack-meeting-cp17:33
*** angdraug has quit IRC18:02
*** angdraug has joined #openstack-meeting-cp18:53
*** dims_ has joined #openstack-meeting-cp19:17
*** dims has quit IRC19:17
*** dims_ has quit IRC19:27
*** dims has joined #openstack-meeting-cp19:30
*** dims has quit IRC19:41
*** dims has joined #openstack-meeting-cp19:42
*** dims_ has joined #openstack-meeting-cp19:46
*** dims has quit IRC19:49
*** dims_ has quit IRC19:57
*** diablo_rojo has joined #openstack-meeting-cp20:45
*** ddeja has joined #openstack-meeting-cp20:45
*** avarner__ has joined #openstack-meeting-cp20:57
*** avarner__ is now known as avarner20:57
*** samueldmq has joined #openstack-meeting-cp20:58
*** henrynash has joined #openstack-meeting-cp20:58
*** cdent has joined #openstack-meeting-cp20:59
*** lbragstad has joined #openstack-meeting-cp20:59
*** thinrichs has joined #openstack-meeting-cp20:59
thingeecourtesy ping for Qiming TravT gordc dirk mriedem SergeyLukjanov21:00
thingeecourtesy ping for daemontool jroll boris-42 redrobot flaper87 rhochmuth21:00
thingeecourtesy ping for fungi flwang dims vipul johnthetubaguy rakhmerov21:00
thingeecourtesy ping for docaedo stevemar mtreinish bswartz adam_g adrian_otto21:00
thingeecourtesy ping for zigo Piet sdake mugsie sheeprine thinrichs21:00
thingeecourtesy ping for jklare loquacities smelikyan Daisy skraynev odyssey4me21:00
thingeecourtesy ping for catherineD dhellmann dprince hyakuhei notmyname devkulkarni21:00
odyssey4meo/21:00
thingeecourtesy ping for emilienm cp16net claudiub armax david-lyle angdraug21:00
redroboto/21:00
thingeecourtesy ping for smcginnis dtroyer21:00
flwango/21:00
dolphmo/21:00
jroll\o21:00
EmilienMhello21:00
fungiahh parallel meetings!21:00
elmikoheyo/21:00
diablo_rojoo/21:00
*** ayoung has joined #openstack-meeting-cp21:00
david-lyleo/21:00
cdento/21:00
ayoungHeyo21:00
notmynamehere21:01
smcginniso/21:01
* jroll calls fork(fungi)21:01
cdentnow21:01
nikhil_ko/21:01
thingee#startmeeting crossproject21:01
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.21:01
*** openstack changes topic to " (Meeting topic: crossproject)"21:01
openstackThe meeting name has been set to 'crossproject'21:01
samueldmqhey21:01
fungijroll: i don't disassociate21:01
*** nikhil_k is now known as nikhil_21:01
nikhil_how do I get on the ping list?21:01
jroll:P21:01
thingeeAgenda: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting21:02
*** nikhil_ is now known as nikhil_k21:02
flwangnikhil_: since you proposed the quota topic?21:02
thingeenikhil_: oh sorry, I thought I grabbed everyone on the cp-spec laision list. I can also just add you :)21:02
*** rockyg has joined #openstack-meeting-cp21:02
nikhil_kflwang: that's not the first item21:02
rockygo/21:02
*** dtroyer has joined #openstack-meeting-cp21:02
*** mtreinish has joined #openstack-meeting-cp21:02
*** notmorgan has joined #openstack-meeting-cp21:02
jamielennoxo/21:02
mugsieo/21:02
samueldmqthingee: me too please :)21:02
notmorganoh hey. new channel21:02
nikhil_kthingee: please do, though I should ideally be on the list21:03
thingee#topic Team announcements (horizontal, vertical, diagonal)21:03
*** openstack changes topic to "Team announcements (horizontal, vertical, diagonal) (Meeting topic: crossproject)"21:03
notmorganjust realized.21:03
dtroyero/21:03
thingeenikhil_k: will do21:03
*** flaper87 has joined #openstack-meeting-cp21:03
adam_go/21:03
thingeewhat's going on people21:03
*** dims has joined #openstack-meeting-cp21:03
thingeewith your project that others should be aware of?21:03
odyssey4meo/21:03
angdraugo/21:03
thingee#info Final release for  non-client libraries: Feb 2421:04
dhellmanno/21:04
thingee#info Final release for client libraries: Mar 221:04
thingee#info Mitaka 3: Feb 29-Mar 4 (includes feature freeze and soft string freeze)21:04
lifelessgrah, echannels21:04
*** olaph has joined #openstack-meeting-cp21:04
thingeeread all about these release focuses from your release manager dhellmann http://lists.openstack.org/pipermail/openstack-dev/2016-February/085705.html21:04
smcginnisOf interest to possibly nova, cinder is planning on a final os-brick release next week.21:04
thingee#link http://lists.openstack.org/pipermail/openstack-dev/2016-February/085705.html release focuses21:05
*** bogdando_ has joined #openstack-meeting-cp21:05
thingee#info nova/cinder planning final os-brick release next week21:05
bogdando_hi21:05
dimso/21:05
dhellmann#link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086152.html final release process21:05
sdaguesmcginnis: and, the privsep parts are integrated into it?21:06
*** loquacities has joined #openstack-meeting-cp21:06
loquacitieso/21:06
thingeeThink 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 issue21:06
thingee#link http://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html The trouble with names21:07
thingeethanks sdague  for that starting that21:07
smcginnissdague: That's the part we're hoping to finish up in time.21:07
sdaguethingee: no prob, I'll propose resolution by end of work on that21:07
sdaguesmcginnis: ack, great21:07
smcginnissdague: Keeping my fingers crossed. ;)21:07
thingeealso 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
thingeefeedback is much appreciated21:08
elmikosdague: seems like we will still need to setup some sort of registry process, even if the api-wg is going to drive that21:08
cdent(thingee's summaries)++21:08
rockygelmiko, ++21:08
sdagueelmiko: yep21:08
thingeesdague: do you want to have a slot to talk about that today?21:08
thingeeor next week?21:08
sdaguethat's what I meant by proposing resolution21:08
elmikofrom the reactions on that thread, it seems like the next step21:08
sdaguethingee: I'll just do it on the mailing list21:09
thingeesdague: sounds good :)21:09
elmikothanks sdague21:09
thingee#topic Quotas: Cross project vs. distributed & dedicated. What are the current challenges and are there any unannounced plans?21:09
*** openstack changes topic to "Quotas: Cross project vs. distributed & dedicated. What are the current challenges and are there any unannounced plans? (Meeting topic: crossproject)"21:09
thingeenikhil_k: hi!21:09
nikhil_khi hi21:09
nikhil_kSo, that's me trying to get some sense out of the community of what we must do in "newton"21:10
*** dprince has joined #openstack-meeting-cp21:10
nikhil_kI know there has been a bit of back and forth and finally many (big) projects went ahead with dedicated quota effort in the resp proj21:10
nikhil_kIn glance we are trying to accomplish a nested or simple quota mechanism21:11
nikhil_kand the dilemma persist on what's the right thing to do21:11
nikhil_kfirst questions as usually were "what's the larger community want"21:11
nikhil_kand I am hoping to get some answers here for that21:11
nikhil_k1. Are there any other projects that are implementing quotas?21:12
nikhil_k2. Are there any strong nested quota or simple quota implementations?21:12
nikhil_k3. Do we need to start a guideline spec?21:12
diablo_rojonikhil_k: Cinder is currently working on getting their quota implementations cleaned up- they are currently VERY broken21:12
thingeeso the nested quota thing is kind of a disappointing feature at the moment unless we have a cross effort to make it available21:13
notmynamenikhil_k: swift supports quotas http://docs.openstack.org/developer/swift/api/container_quotas.html21:13
nikhil_kdiablo_rojo: I heard the transition was from simple to complex, is that some unadvised ?21:13
ayoungWhat makes it broken?21:13
samueldmqnikhil_k: from what I understand, your goal is to get a consistent approach for quotas in openstack right ?21:13
samueldmqe.g an unique approach for nested quotas across projects21:14
thingeeRight, I think we don't want to say these three projects support nested quotas, everyone else, eh maybe they do?21:14
thingeeit's bad experience21:14
redrobotbarbican supports quotas as well http://docs.openstack.org/developer/barbican/api/reference/quotas.html21:14
henrynashthis 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 domain21:14
samueldmqthingee: why can't 3 projects support nested quotas ?21:14
smcginnisredrobot, notmyname: Quotas, or nested quotas?21:15
nikhil_ksamueldmq: My approach is to try to get consistent with the community as far as possible21:15
samueldmqthingee:  you mean a single config across projects ?21:15
henrynashthis = a cross project approach21:15
nikhil_ksamueldmq: but I would love some insights into nested work21:15
notmynamesmcginnis: what's a nested quota?21:15
thingeesamueldmq: well what if you want nested quotas available in all your services? I'm just saying it's not widely available.21:15
smcginnisOK. :)21:15
redrobotsmcginnis yeah... not sure what "nested" means?21:15
diablo_rojoI should have specified nested quotas is broken in Cinder, not regular quotas21:15
samueldmqnotmyname: it's related to how set quotas in a project hierarchy21:15
flwangglance is using config file to store the quota, and we're going to use db-based21:15
bknudson_could we have a quota microservice?21:15
flwangand then the question is what's the api should be looked like?21:16
notmynamesmcginnis: wat?21:16
samueldmqnotmyname: where a quota of child projects depends on their parent quota21:16
thingee#link http://specs.openstack.org/openstack/cinder-specs/specs/liberty/cinder-nested-quota-driver.html nested quota21:16
thingeeso there's the first problem^21:16
nikhil_kflwang: I think that's not it21:16
flwangsince nova/cinder/neutorn/swift are using different(more or less) api format21:16
mugsiedesignate has had quotas for quite a while as well - http://docs.openstack.org/developer/designate/rest/admin/quotas.html21:16
thingeeit's only a project spec. For some reason I thought we had this in a cross-project spec21:16
nikhil_kGlance wants quotas for data, no. images etc. A DB based approach covers everything.21:16
nikhil_kdiablo_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
smcginnisI definitely think we need a cp-spec. First to make sure everyone knows what "nested quotas" means...21:17
samueldmqthingee: I agree, even thought we have different APIs, the behavior should be the same across projects (for nested quotas ,eg)21:17
smcginnisAnd second to make sure we implement it in an at least semi-consistent way across projects.21:18
thingeenikhil_k: I feel like I'm hijacking your topic. Was it just around nested quotas?21:18
nikhil_kthingee: 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
diablo_rojonikhil_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:18
nikhil_kI see21:19
flwangthingee: glance team also want to know the experience if it's the good way from simple to nested or just go for nested directly21:19
rockygthingee, If the xproject spec addresses nested quotas for all projects, I think it answers nikhil_k's questions21:19
*** vilobhmm11 has joined #openstack-meeting-cp21:19
*** penick has joined #openstack-meeting-cp21:19
nikhil_kdiablo_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 now21:19
thingeeharlowja: ping21:20
harlowjathinrichs pong21:20
harlowjavilobhmm11 pong21:20
harlowjapenick pong21:20
harlowja*just noticed this being talked about, ha21:20
thingeeharlowja: is the person that worked on nested quotas around?21:20
harlowjavilobhmm11 ping21:20
harlowja;)21:20
harlowjathey might be reading the logs to catch up21:20
thingeeharlowja: I think he would have good insight in what nikhil_k is asking21:20
harlowjayup21:20
harlowjaagreed +121:20
harlowjavilobhmm11 likely catching up21:21
diablo_rojonikhil_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
vilobhmm11thingee : i m here21:21
*** melwitt has joined #openstack-meeting-cp21:21
nikhil_kdiablo_rojo: that would be great21:21
thingeediablo_rojo: right but you have to transition to nested quotas if users are already using quotas in your project.21:21
thingeeI think that's what upgrade is meaning in this context21:21
samueldmqfyi: if you don't have a project hierarchy, nested quotas = regular quotas anyways21:21
harlowjathingee +1 to 'the nested quota thing is kind of a disappointing feature at the moment unless we have a cross effort'21:22
diablo_rojothingee: Oh okay, that makes more sense.21:22
penick*skims log*21:22
vilobhmm11nikhil_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 then21:22
*** sballe has joined #openstack-meeting-cp21:22
vilobhmm11thingee : nested quota had a lot of push back in the past21:22
vilobhmm11even this time the nested quota feature for nova has been pushed to newton21:23
nikhil_kvilobhmm11: yeah, I know! there are/were 5 quota BPs that I know of21:23
thingeejohnthetubaguy: ^21:23
harlowjai'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
penickI 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, etc21:23
vilobhmm11thingee : if as a community we are interested  we can definately take it forward21:23
harlowjasaid cp-spec will not be easy to pull off (since projects already have impls of quota, in various ways...)21:23
*** mc_nair has joined #openstack-meeting-cp21:24
diablo_rojonikhil_k: I just got a response from him, he should be here in a sec.21:24
thingeenikhil_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 details21:24
samueldmqharlowja: +1 on cross-project spec21:24
mc_nairhey there21:24
penickharlowja: Are there any oslo libraries for quota mgmt in existence?21:24
*** annegentle_ has joined #openstack-meeting-cp21:24
harlowjapenick so there was an attempt21:24
diablo_rojomc_nair: nikhil_k wanted to know about if it is better to implement quotas first or go right for nested quotas21:24
*** gordc has joined #openstack-meeting-cp21:24
penick(dont say boson)21:24
nikhil_kpenick: 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
thingeefrom there cp-spec liaisons can carry the priority forward to their respected projects21:24
harlowjait gets into a tricky gray area penick  because that library needs to store data somewhere21:24
harlowjaand not alot of oslo libraries do this21:24
harlowjabecause migrations of data now become library responsiblity (where is the data stored?)21:25
nikhil_kthingee: that sounds fair21:25
vilobhmm11thingee : cinder nested quota driver  https://blueprints.launchpad.net/cinder/+spec/cinder-nested-quota-driver nikhil_k21:25
dimsonce upon a time we had plans for quota library penick - https://review.openstack.org/#/c/132127/21:25
vilobhmm11has more details21:25
penickWell, 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 there21:25
harlowjadims right penick see commentary in that review21:25
dolphmthere's openstack.common.quota http://docs.openstack.org/developer/oslo-incubator/api/openstack.common.quota.html21:25
harlowjapenick quite possibly, the main objections where what to do about data migrations21:25
thingeedims: seems to make sense, not sure what the push back was.21:26
dimspenick : y, maintaining db was the thing that stopped its progress21:26
harlowjaand '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
thingeedims: I mean, I need to read that closer :)21:26
harlowjathat also didn't help, ha21:26
mc_nairnikhil_k: IMO you should be able to implement quotas first and extend that support for nested quotas.21:26
vilobhmm11mc_nair : +121:26
dimsthingee ack :)21:26
thingeemc_nair: I agree21:26
mc_nairnikhil_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 driver21:26
thingeenikhil_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
mc_nairI 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 bugs21:27
harlowjabut 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
thingeeso who is interested in copying the spec and bring it forward as a cp-spec?21:27
harlowjabut same objects are still going to happen ;)21:27
penickthe ‘wait until we rework quota’ thing does ring a bell. But, i’m not sure how far that got compared to their other priorities21:27
harlowja*objections, not objects, lol21:27
nikhil_kthingee: olso.quotas would be great. Would be even better if the wait wasn't of separation from nova!21:28
dimsharlowja : yep21:28
harlowjaso cp-spec with maybe something in oslo21:28
penickI 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
nikhil_kthingee: I can do that if no one from cinder is interested21:28
thingeenikhil_k: check with dims on the oslo spec if one exists21:28
nikhil_kI want to see this stuff through in newton as far as possible21:29
thingeewe can promote it within this channel of people21:29
harlowjanikhil_k ya, there might have been one, i can't remember, dims might remember, ha21:29
vilobhmm11nikhil_k : feel free to involve me if any help is needed21:29
mc_nairnikhil_k: I'm up for helping with that also21:29
thingee#action nikhil_k to look into possibly a cp-spec or oslo spec that already exists for quotas21:29
dimswe'll need someone from nova :)21:29
smcginnismc_nair has been doing a lot of work on this in cinder, so yes, please include him.21:29
harlowjadims and or all the projects with quota impls (future or present)21:29
thingeejohnthetubaguy is my cc for this meeting, but not sure he's around21:29
thingeealright lets move on because we have some others that were kind to join to talk about their specs.21:30
thingeethanks nikhil_k21:30
nikhil_kthanks you.21:30
nikhil_kthank*21:30
dimsharlowja : ack21:30
cdentI'm here sort of as nova-rep, but my context on nova quota is nil so far21:30
cdentI can make sure john's aware21:30
dimscdent : yay21:30
thingeecdent: sorry forgot about you!21:30
thingee:(21:30
thingee#topic Query Config From UI21:30
*** openstack changes topic to "Query Config From UI (Meeting topic: crossproject)"21:30
thingeeayoung: hi21:31
*** dprince has quit IRC21:31
thingee#link https://review.openstack.org/#/c/242852/ Query Config from UI spec21:31
ayoungYo21:31
rockygquickie on last topic:  https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking ln#453  Quotas subteam info21:31
ayoungSo, this came up in the past on a couple occasions21:31
cdentMaybe it is just me, but I feel like the actual proposal isn't really present in that spec21:32
cdentthus my comments are sort of from left field21:32
ayoungthe biggest one was v2 to v3 conversion21:32
ayoungwe had kn way of reporting what the Default domain was21:32
jrollcdent: +1, but going to hear adam out first :)21:32
ayoungnot a big deal, punted on it21:32
ayoungbut it seems to keep coming up.  I was looking at this from a Keystone perspective21:32
bknudson_does UI mean horizon?21:32
ayoungand was told others have the same problem, and we should think cross project21:32
ayoungso here I am21:32
jrollso, my feelings on exposing config options in an API aside, this seems to be an incomplete spec21:33
ayoungI think the origianal blueprint got decomissioned.21:33
jrollso I'm curious, what the question we want to answer in this meeting is21:33
ayoungIt was incomplete21:33
thingeebknudson_: I was confused by that too, but I think it's meant from the rest api.21:33
ayoungI brought it up because I've been told others are pursuing this as well21:33
rockygI think from UI means coming up with cp standard for the callbacks for all the projects21:34
ayoungyeah,  is should be REST API.21:34
ayounghmmm21:34
rockygREST ++21:34
cdentcallbacks for what?21:34
ayoungSo...do other teams have this issue?21:34
bknudson_operators don't know how their systems are configured?21:35
jroll++21:35
rockygconfigs change.  What is it *now*?21:35
jrollI disagree with the premise there should ever be a GET /config/foo API21:35
ayoungThe idea is that if there are a subset of config options (not passwords for duh reasons) that need to be remotely queryable21:35
ayoungjroll, rationale?21:35
cdentayoung: to answer what question(s)?21:35
jrollbut rather something like (for this specific case), the /domains endpoint might return a "default": "foo" that is the value of that config option21:36
ayoung"I disagree with the premise there should ever be a GET /config/foo API"21:36
fungiis this meant as a solution to the lack of end-user/app-dev discoverability for various deployment choices in different providers?21:36
ayoungjroll, that could certainly work for my use.  The question is does that cover what other people are asking for21:37
bknudson_keystone has some REST APIs for getting config -- http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#domain-configuration-management21:37
ayoungWIth policy enforcement, we have found ways to work around it thus far21:37
thingeeThe problem description lists something that keystone wants to query in configs. I think ayoung wants to know does anyone else need this?21:37
thingeecorrect me if I'm wrong ayoung21:37
* cdent still doesn't understand why people want to query configs21:38
ayoungthingee, you are right21:38
jrollayoung: I'm struggling to come up with a coherent reason "why not" other than "why would you"21:38
thingeeok so not really something available to users, but sservices21:38
cdentI'm not disputing that someone might, but it would help to know why?21:38
jrollanyway, to answer the question, no I don't see a need for this :)21:38
samueldmqexposing config via APIs might help on improving UX, e.g horizon hiding some buttons if user can't be created in the current domain21:38
ayoungthe two reasons I've come up with both involve defaulting values for migrating forward21:38
rockygjroll, troubleshooting?21:38
ayoungbut they are ,as pointed out, specific values21:39
jrollrockyg: ssh? read the config management?21:39
fungigot it, so "querying configs" is a solution for some discoverability issue in $random_service which keystone will base some behavior on21:39
thingeesamueldmq: that's a good point21:39
cdentwould another way to describe this be: capabilities discovery?21:39
thingeeso 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
jrollI 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
rockygjroll, so login to service vm, cd to /etc/nnn/config, find out you want some other config option, repeat?21:40
fungione 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
fungior yes, what cdent said in fewer words21:40
lifelessso years ago LP had this concept that you'd surface *everything* to the user21:41
elmikotend 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
thingeefungi: right I think that's what jroll was touching on21:41
lifelessit was in hindsight a terrible idea21:41
samueldmqthingee: however domain configs can already e stored/retrieved via API in keystone (as bknudson_ pointed above)21:41
samueldmqI think a good question to start is "what use cases are we trying to solve? who needs it?'21:41
jrollrockyg: 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
lifelessIn my experience you need to actually think about each thing being surfaced and decide where it belongs and how to best present it21:41
elmikosamueldmq: +121:41
fungilifeless: then everything becomes a contractual api and you can't ever change anything?21:41
thingeeOk 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 discovered21:42
lifelessfungi: that is one of the side effects of surfacing everything without care, yes.21:42
lifelessfungi: another specific problem was that internal model != external model21:42
rockygjroll, don't necessarily need to change, just get the info quickly21:42
thingeeI think all this would be good feedback for people to add to the spec so that we have it there.21:42
jrollfungi: lifeless: ah yes, this also has implications for deprecating configs21:42
lifelessfungi: e.g. how we configure things from a sysadmin view, vs how users are affected are very different things21:42
david-lylesome specific examples of need for Horizon are around policy, but fix centralized policy and that goes away21:42
jrollgiven the "never delete API endpoints" talk/work lately21:42
notmorganalso keep in mind that configs often hold sensitive data, so it's another additonal surface area to verify is safe/sane/sanatized21:43
lifelessjroll: exactly21:43
fungieffectively, your configs become an api in their entirety21:43
lifelessyup21:43
thingeeayoung: not sure if this feedback was helpful. you're quiet :)21:43
notmorganfungi: oh i don't like that21:43
lifelessand they are, but currently on a different lifecycle, and with different audiences21:43
ayoungthingee, I want input21:43
* jroll quivers21:43
notmorgancan we not make configs an API :P21:43
fungiand who knows what random services will start depending on nuanced details of your configuration21:43
notmorganfungi: exactly21:43
jroll+121:44
ayoungas I said, I have workarounds for this21:44
ayoungbut they don't feel any better than querying the value21:44
angdraugthere's also a concern of not coupling this to config _files_, especially in specific format (ini)21:44
bknudson_how about rather than a config api we have a capabilities discovery api?21:44
lifelessayoung: I'm not against surfacing chosen things one by one21:44
david-lylebknudson_: ++21:44
notmorganbknudson_: better idea21:44
lifelessayoung: but - as bknudson_ says :)21:45
*** nikhil_k is now known as nikhil21:45
breton(btw, we already have configs in api in keystone)21:45
ayoungfor example, to fix https://bugs.launchpad.net/keystone/+bug/968696  we actually added the value to the token response21:45
openstackLaunchpad bug 968696 in Glance ""admin"-ness not properly scoped" [High,Triaged]21:45
samueldmqwhat is a capability we're talking about ?21:45
jrollor even GET /domains/default21:45
thingeefwiw, cinder has a concept of capabilities21:45
notmorganjroll: that is not unreasonable.21:45
samueldmqAPIs == capabilities ?21:45
jrollbut not GET /configs/default_v2_domain or whatever21:45
thingeethat can be asked for21:45
rockygYeah.  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:45
notmorganjroll: also leans towards expicit specific information21:46
notmorgannot "the config data"21:46
jrollnotmorgan: 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
jrollyeah21:46
jrollthe fact it's a config is tangential21:46
thingeeOk so lets get some feedback back on the specs for ayoung to iterated on. we still have one more topic21:46
jrollwe should get users the data they need, no matter where it comes from21:46
ayoungso, I was origianlly thinking that we would use a config option in policy enforcement, which might also be useful beyhond Keystone21:46
rockygjroll, ++21:47
samueldmqI 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 keystone21:47
ayoungfor exdample if networkid = config.admin.netowkr.id or soemthing in Neutron21:47
notmorganayoung: i am fairly against that unless there realy is no good other options21:47
ayoungnotmorgan, well, there wasn't for policy, which is why henrynash 's example had you editing the poluicy file21:47
ayoungso if you need to edit a policy file, I'd argue its config anyway21:48
notmorganexcept it is contained in policy21:48
david-lylepolicy and config21:48
notmorganvs. set [potentially] in multiple places21:48
ayoungNote that for policy it does not need to be remotely queryable21:48
ayoungjust locally exposed to the policy engine21:48
notmorganwhich could be an entry in the policy file21:48
notmorgancontained21:48
*** sdake has quit IRC21:49
notmorganspreading this across multiple locations makes it far far more complex imo21:49
*** ninag has joined #openstack-meeting-cp21:50
samueldmq10 mins left21:50
notmorgani'd rather see it contained in policy DSL than cross policy and osli.config21:50
notmorganif that makes sense21:50
ayoungAnyway, 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
notmorganayoung: i think some of the other policy tnings can lead into a nice solution for you.. we'll chat more offline21:50
thingeeok, 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
notmorganayoung: we talked about last week,21:50
thingeedolphm: I believe you need more time than 10 mins?21:51
dolphmdefinitely21:51
dolphmit'll take 10 minutes to introduce the topic21:51
* jroll posts on the spec21:51
* notmorgan cheers for dolphm's topic21:51
thingeeok, lets punt dolphm's topic to next week21:51
dolphmin the mean time, everyone become opinionated on the spec as homework https://review.openstack.org/#/c/245629/21:51
* notmorgan is sad there isn't time today21:51
ayoungOh. damn21:51
ayoungI would have preferred we talk about that21:52
notmorgandolphm: i am already opinionated on the spec... it should be a thing!21:52
notmorgan:P21:52
david-lyle++21:52
thingee#link https://review.openstack.org/#/c/245629/ Homework: A Common Policy Scenario Across All Projects21:52
ayoungbut, yeah, that one is a big one.21:52
notmorganthingee: can we prioritise that first thing next week?21:52
rockygYou realize this is right in the middle (well end) of the ops summit, where you have *very* opinionated users who could comment?21:52
notmorganit is a big topic21:52
cdentemerging conensus of too big ;)21:52
thingeeso yes, that means we will be having a cross-project meeting next week!21:52
thingeenotmorgan: of course. it waited through this meeting21:53
diablo_rojoYAY!21:53
notmorganthingee: just making sure :)21:53
samueldmq++21:53
thingee#topic open discussion21:53
*** openstack changes topic to "open discussion (Meeting topic: crossproject)"21:53
ayoungalso, as part of the homework, note that we now have implied roles to work with which makes this easier to implement, but also has ramifications21:53
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
jrolldolphm: 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
dolphmjroll: that would be a good starting point ;)21:53
jrolldolphm: heh. good, I like21:54
dolphmi *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 it21:54
jamielennoxdolphm: maybe we make the per-controller stuff optional or different spec21:55
thingeedolphm: keep in mind just like the service catalog TNG, you are able to hold your own meeting in this channel21:55
jamielennoxi don't mind if services want to do something but leave it out of the common21:55
dolphmjamielennox: right, split manager roles and endpoint / capability roles into a separate spec21:55
ayoungdolphm, 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
thingeedolphm: I can talk to you more about that offline21:55
dolphmthingee: i think this is the right audience for the initial discussion - if we need to carry on more meetings, then ++21:55
thingeedolphm: sounds good21:56
*** gordc has left #openstack-meeting-cp21:56
jamielennoxthe 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-admin21:56
dolphmjamielennox: i definitely hijacked it21:56
jamielennoxif we want to flesh out a complete policy i'm ok, but i'd take the immediate win rather tahn debate it forever21:56
jamielennoxi think the deployers who want that level of granularity are the ones who can maintain there own policy files21:57
dolphmbut if we have more than a couple, my argument is that it should be upstream21:57
jamielennoxideally sure21:58
thingeedolphm: would it be useful for me to start promoting this to ops folks? If so, next week will be bad due to ops midcycle21:58
*** soren has joined #openstack-meeting-cp21:58
dolphmthingee: ooh, that's a good question...21:58
jamielennoxbut we put out that call for what things do you customize in your policy files and there really wasn't much21:58
ayoungthingee, we could call in to the ops midcycle via telconfernece21:59
*** bogdando_ has quit IRC21:59
dolphmlet's not21:59
jamielennoxwhich is not to say they wouldn't use it if not available, just this covered most of their needs21:59
thingeewell I think it just means people be part of the irc channel in their TZ...21:59
jrollso there's two main goals here, right? 1) get people to stop using admin, generally; 2) get something somewhat common in policy amongst the projects21:59
dolphmjroll: yes21:59
dolphmjroll: and upstream the things deployers are already doing21:59
jroll++22:00
thingeeso dolphm next week still or punt after midcycle?22:00
dolphmi'm good for next week22:00
thingeeok!22:00
thingeethanks everyone22:00
thingee#endmeeting22:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"22:00
openstackMeeting ended Tue Feb  9 22:00:33 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/crossproject/2016/crossproject.2016-02-09-21.01.html22:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/crossproject/2016/crossproject.2016-02-09-21.01.txt22:00
openstackLog:            http://eavesdrop.openstack.org/meetings/crossproject/2016/crossproject.2016-02-09-21.01.log.html22:00
elmikothanks thingee22:00
thingeewow good turn out and good participation!22:00
elmiko+122:00
jrollthanks thingee :)22:01
cdentthat was rather dense, nice22:01
elmikothingee: i wanted to say, your email reminders are spot on. nicely done ;)22:01
samueldmqthanks22:01
*** jamielennox has left #openstack-meeting-cp22:01
thingeeelmiko: Thanks. I'm hoping things like having some rep for projects to ping has helped too :)22:02
thingeeit's nice having feedback from other perspectives.22:02
elmiko+122:02
*** annegentle_ has quit IRC22:04
cdentthingee long ago and far away I did a lot of experimentation with improving mailing list communication and one of the biggest wins were summaries that exposed opinions and helped distill and move things forward. it is great that you're doing that.22:04
thingeecdent: thanks. I hope people find it useful since I don't know how many people are following it.22:05
*** thinrichs has quit IRC22:05
*** ninag has quit IRC22:08
diablo_rojothingee: I definitely find the emails helpful22:12
*** henrynash has quit IRC22:19
*** cdent has left #openstack-meeting-cp22:24
*** rockyg has quit IRC22:25
*** diablo_rojo has quit IRC22:25
*** mc_nair has left #openstack-meeting-cp22:33
*** dims_ has joined #openstack-meeting-cp22:39
*** henrynash has joined #openstack-meeting-cp22:39
*** dtroyer has left #openstack-meeting-cp22:40
*** dims has quit IRC22:40
*** henrynash has quit IRC22:53
*** penick has quit IRC23:18
*** thinrichs has joined #openstack-meeting-cp23:24

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!