Thursday, 2016-01-28

krotscheckelmiko: pong?00:05
krotscheck(Full disclosure, I'm in daycare mode)00:05
krotscheckelmiko: DOH. Sorry, I hear the munchkin00:06
* krotscheck is amazed at how inconsistent his sleep schedule is.00:06
*** salv-orl_ has quit IRC00:15
openstackgerritMerged openstack/python-openstackclient: Remove the Tuskar client
*** Qiming has quit IRC00:27
*** dims_ has quit IRC00:55
*** Yanyanhu has joined #openstack-sdks01:11
*** Qiming has joined #openstack-sdks01:22
*** Yanyan has joined #openstack-sdks01:27
*** Yanyanhu has quit IRC01:30
*** salv-orlando has joined #openstack-sdks01:47
*** shakamunyi has joined #openstack-sdks01:48
*** devth has joined #openstack-sdks01:56
*** salv-orlando has quit IRC01:57
xiexs__dtroyer,Richard: hi dean and Richard, could you please review the "crash dump" patch again if you have time. thanks.01:57
*** devth_ has quit IRC01:59
*** shakamunyi has quit IRC02:10
*** shakamunyi has joined #openstack-sdks02:10
*** dixiaoli has joined #openstack-sdks02:21
*** tobe has joined #openstack-sdks02:22
*** woodster_ has quit IRC02:26
*** e0ne has joined #openstack-sdks02:41
*** e0ne has quit IRC02:48
*** e0ne has joined #openstack-sdks02:50
*** e0ne_ has joined #openstack-sdks02:54
*** e0ne has quit IRC02:55
openstackgerritBrad Behle proposed openstack/python-openstackclient: Add availability zone support for network commands
*** amotoki has quit IRC02:59
*** dixiaoli_ has joined #openstack-sdks03:09
*** dixiaoli has quit IRC03:12
*** devth_ has joined #openstack-sdks03:21
*** devth has quit IRC03:24
*** amotoki has joined #openstack-sdks03:27
*** amotoki has quit IRC03:32
*** terrylhowe_ has joined #openstack-sdks03:41
*** terrylhowe has quit IRC03:41
*** terrylhowe_ is now known as terrylhowe03:41
*** salv-orlando has joined #openstack-sdks03:43
*** e0ne_ has quit IRC03:48
*** amotoki has joined #openstack-sdks03:49
*** salv-orlando has quit IRC03:56
*** amotoki has quit IRC04:03
*** e0ne has joined #openstack-sdks04:08
*** gouthamr has joined #openstack-sdks04:11
*** amotoki has joined #openstack-sdks04:20
*** terrylhowe has quit IRC04:31
*** gouthamr has quit IRC04:33
*** e0ne has quit IRC04:44
*** oomichi has joined #openstack-sdks04:54
*** jamielennox is now known as jamielennox|away05:05
*** Yanyan has quit IRC06:19
*** Yanyan has joined #openstack-sdks06:19
*** salv-orlando has joined #openstack-sdks06:38
*** salv-orlando has quit IRC06:49
*** boris-42 has joined #openstack-sdks07:17
*** salv-orlando has joined #openstack-sdks07:26
*** lhcheng has joined #openstack-sdks07:55
*** lhcheng has quit IRC08:00
*** amotoki has quit IRC08:07
*** salv-orlando has quit IRC08:10
*** amotoki has joined #openstack-sdks08:16
*** barra204 has joined #openstack-sdks08:16
*** amotoki has quit IRC08:18
*** shakamunyi has quit IRC08:19
*** dixiaoli_ has quit IRC08:35
openstackgerritlinwei wu proposed openstack/cliff: neutron wrong command display with unicode
*** amotoki has joined #openstack-sdks08:42
*** cdent has joined #openstack-sdks08:47
*** jaypipes has joined #openstack-sdks09:01
*** lucas-dinner is now known as lucasagomes09:04
*** salv-orlando has joined #openstack-sdks09:11
*** Yanyan has quit IRC09:42
*** Qiming has quit IRC09:54
*** salv-orl_ has joined #openstack-sdks10:06
*** salv-orlando has quit IRC10:09
openstackgerritEthan Lynn proposed openstack/python-openstacksdk: Override delete function of senlin cluster/node
*** Qiming has joined #openstack-sdks10:54
*** jaypipes has quit IRC11:06
*** dims has joined #openstack-sdks11:07
*** jaypipes has joined #openstack-sdks11:14
openstackgerritTang Chen proposed openstack/python-openstackclient: Remove marker and loop from "image list" command
*** fzdarsky has joined #openstack-sdks11:19
*** salv-orl_ has quit IRC11:34
*** tobe has quit IRC11:41
*** fzdarsky has quit IRC12:05
*** fzdarsky has joined #openstack-sdks12:06
*** e0ne has joined #openstack-sdks12:06
*** rtheis has joined #openstack-sdks12:16
*** fzdarsky has quit IRC12:18
*** salv-orlando has joined #openstack-sdks12:21
*** e0ne has quit IRC12:27
*** e0ne has joined #openstack-sdks12:27
*** tobe has joined #openstack-sdks12:41
*** amotoki_ has joined #openstack-sdks12:41
*** amotoki has quit IRC12:43
*** dims has quit IRC12:47
*** tobe has quit IRC13:09
*** devth has joined #openstack-sdks13:22
*** devth_ has quit IRC13:25
*** e0ne has quit IRC13:29
*** fzdarsky has joined #openstack-sdks13:34
*** dixiaoli_ has joined #openstack-sdks13:37
*** fzdarsky has quit IRC13:41
*** fzdarsky has joined #openstack-sdks13:42
*** gouthamr has joined #openstack-sdks13:43
*** gouthamr_ has joined #openstack-sdks13:48
elmikocdent: no hiding!13:50
* cdent tries to hide13:51
*** gouthamr has quit IRC13:51
cdentI'm getting too good at adding responsibilities to myself13:52
elmikoi know the feeling ;)13:53
*** terrylhowe has joined #openstack-sdks13:54
* cdent lets etoews do everything13:55
elmikoi can't be that mean13:58
*** terrylhowe_ has joined #openstack-sdks13:58
* cdent makes 2016 the year of being mean13:58
*** terrylhowe has quit IRC13:58
*** terrylhowe_ is now known as terrylhowe13:58
*** salv-orlando has quit IRC14:09
cdentelmiko: i've linked to my email on the summit agenda notes:
elmikocdent: ah, excellent. (in a meeting currently, but i'll check it out in a few)14:12
*** amotoki_ has quit IRC14:16
elmikoman... didn't realize that email thread had blown up14:17
*** e0ne has joined #openstack-sdks14:19
cdentyeah, there's all kinds of crazy shit in there14:20
elmikoit's good stuff, i just feel like i really stepped in it lol14:22
cdentIf that's the case you should step in it more.14:22
cdentStepping in it is what causes people to participate14:22
elmikogood point14:22
* elmiko dives on the grenade14:23
*** salv-orlando has joined #openstack-sdks14:26
*** salv-orlando has quit IRC14:29
*** salv-orlando has joined #openstack-sdks14:29
*** edleafe- has joined #openstack-sdks14:44
*** edleafe- has quit IRC14:47
*** edleafe has quit IRC14:47
*** fzdarsky has quit IRC14:48
*** fzdarsky has joined #openstack-sdks14:49
*** edleafe has joined #openstack-sdks14:53
*** edleafe has quit IRC14:53
*** edleafe has joined #openstack-sdks14:55
cdentelmiko: I'll go back through those header related specs soonish15:04
cdentmentally melted at the moment15:04
elmikocdent: thanks, i think they are all inline with what has been discussed15:04
elmikothey all use SERIVCE_TYPE somewhere in the headers, i just knew we had come to discussions about the whole issue in the past15:05
cdentI think you're right that an option needs to be open for services not in the service catalog to do whatever they like, but to keep in mind how/where the service names may matter to them some day15:05
elmikoyea, but how much of that is implicit in the idea that you can choose to ignore the guidelines if you want15:06
elmikoi like the very positive statements you made about the guidelines we are proposing and how strongly opinionated/curated they should be15:07
elmikobut i also note, that none of the detractors have, or probably will, respond to those comments15:07
*** sigmavirus24_awa is now known as sigmavirus2415:08
*** dims has joined #openstack-sdks15:08
openstackgerritDina Belova proposed openstack/python-openstackclient: Add shell --profile option to trigger osprofiler from CLI
cdentelmiko: yes, sad but true15:11
gouthamr_elmiko cdent: i have a question regarding that; the question's specific to a project i work on: Manila; its services have two endpoints in Keystone; thus exposing two service_types ... what's an ideal way for this project to abide by the said guidelines?15:11
cdentgouthamr_: It's a good question...15:12
elmikogouthamr_: great question, what are the 2 service types that get exposed?15:12
gouthamr_elmiko cdent: one of the service types will go away in the future; however, it's going through its standard deprecation process15:12
cdentthe straight answer is: use both service names where it matters15:12
cdenthowever I can see how that's a pain15:12
cdentthat part of the reason I question this idea of namespacing the headers so exentisively15:13
dtroyergouthamr_: is this a case where two SC entries point to the same endpoint?15:14
cdent"foobar-foobar-microversion: value" seems no less good or bad than "microversion: foobar-foobar/value"15:14
cdentgood question dtroyer15:14
gouthamr_dtroyer: no, different endpoints; very alike URLs..15:14
dtroyerfrom the client standpoint, I would hope to be able to assemble the correct header from what I have on hand, which will be the SC15:15
dtroyergouthamr_: ok, good.  Two SC entries to a single endpoint was the first place I thought of where just using the SC service type directly wasn't going to be clean15:15
elmikocdent: that's kinda my other issue with this topic, as it specifically pertains to headers15:15
elmikocdent: why do we need to keep some sort of consistency with the service catalog entry types if you are talking specifically to a known service controller15:16
elmikowouldn't you want to check their api docs to know the proper values?15:16
cdentwhat we want is for code written for a particular service-type to work when used against a different instance of the same service-type15:17
elmikocdent: this is going along the lines of multiple impls for a single service?15:17
cdentand we want it to be possible for people create library code which will correctly assemble requests for those two different instantiations of the service-type in a context where the end user will not ever read the docs15:18
cdentelmiko: long term, maybe, but short term it is the case that some instances of the same service implementation differ15:19
cdentthis stuff doesn't really address that problem but helps consciousness of it15:19
elmikoright, the disconnect for me is when it specifically comes to the headers for say microversions15:19
cdentI think it is more of a social than technical thing15:20
cdentwhich is lame15:20
elmikoif i am talking to the sahara controller, for data-processing service, then i might send a request with some header OpenStack-Microversion-Data-Processing-Min-Version, or some such15:20
cdentbut important15:20
elmikobut if the backend impl changes then the microversions may be vastly different15:21
cdentthat's a good question (we've had several so far)15:21
elmikoin those cases, i could see the value of saying OpenStack-Microverion-Sahara-Min-Version, as i know i am talking to a specific impl15:21
dtroyerelmiko: that sounds like the different implementations are not of the same API15:21
cdentand I think the answer should be that sahara provides a data-processing API at microversion x.y15:22
cdentit does not provide the sarah api at microversion x.y15:22
cdentthis is an intentional constraint15:22
elmikodtroyer, cdent, both good points15:22
cdentwe don't want there to be a sahara data processing api and a mojave data processing api15:22
cdenttehre is only a data processing api15:22
cdentfor people who want that reality to happen we have to start building constraints into the system _now_ to bring it about15:23
dtroyereven through there are a number who resist the 'OpenStack is APIs' notion, that is really what we have to enforce anyway15:23
elmikoi'm ok with that, i've just never seen it explicitly stated that these APIs will be the gold standard around which others can create alternative impls15:23
cdentyeah, dtroyer, that argument is exhausting, but if we want that cloud interop thing, its the foundation15:23
elmikodtroyer: right.. that gets to the heart of the question15:23
cdentelmiko: you've not heard because some people don't agree with it15:24
elmikoand i think it also make the water very murky15:24
*** Qiming has quit IRC15:24
elmikocdent: right, i can see how controversial it would be15:24
cdentbut it is sort of the only logical conclusion if (and there's not that much agreement on even this) the cloud interop thing is real15:24
*** jose4183 has joined #openstack-sdks15:24
elmikobecause right now, whether it is good for the API design or not, each project team is getting to define how an API will exist for an entire cloud interop field15:24
cdentso yeah, controvery15:25
cdentdammit typing is hard!15:25
cdentelmiko: yes, thus the need for a strong api-wg...15:25
cdentwhich isn't going to happen without some boost from...somewhere15:25
* cdent points sdague at the backlog15:26
cdent(as I reckon he might be interested)15:26
elmikoand honestly, i'm ok with working towards making the api guidelines a middle point for discussions about standardization of api15:26
dtroyerI think at some point we need to start pushing for 'new' APIs to adhere to the guidelines.  This might be the first step in working backward into shaping up the existing implementations15:26
elmikoi just find the whole topic very unclear...15:26
cdentdtroyer: yeah. We talked in tokyo about coming up with ways to test15:27
elmikodtroyer: oh man... i don't want to be in the room when *that* conversation gets floated ;)15:27
dtroyer:)  some things are never going to change, but there are now a lot of projects present that are still not tied to their history hard enough to not be nudged15:28
elmikowell that's encouraging15:29
cdentthere will be plenty of people thinking that it is yet more bureaucrats trying to get their oar in15:29
cdentbut it isn't really that15:29
elmikoand i would really hope we can get to a point where the service APIs can be used in a more public manner to create alternatives and whatnot15:29
elmikocdent: yea, i know. but if we start to talk about how the guidelines can be used to bring forth a new era of APIs that will be standard, and good, and blah. we will branded as bolsheviks for sure ;)15:30
cdentIf an API is well described then it ought to be relatively straightforward to create e.g. the go implementation of the telemetry api or something15:30
cdentI've always wanted that brand15:30
dtroyerI am not sure we are at the point that API guidelines are ready to be in the secondary list of 'one of us' criteria, but I personally want to move in that direction.15:31
openstackgerritwuhao proposed openstack/api-wg: Add description of pagination parameters
dtroyer^^^ now there's a nice calm topic ;)15:32
cdentyou're right dtroyer, there's a long way to go15:32
elmikodtroyer, cdent, many thanks for the comments on the email chain. i enjoyed reading your positions and i agree in general about taking a strong opinion about the guidelines we create. i'm gonna readjust my focus on the service type issue.15:32
elmikodtroyer: hahaha!15:32
dtroyerprogress is visible.  I haven't had my nose in API-WG directly for a while, but in my recent context-change for $DAY_JOB I get a fresh view of how it is seen, and progress really is visible15:34
*** fzdarsky has quit IRC15:35
* etoews reads15:37
*** devth_ has joined #openstack-sdks15:44
etoewsapi wg meeting in 15 min in #openstack-meeting-315:45
elmikoetoews: i added your suggestion to
*** gouthamr_ has quit IRC15:46
*** dixiaoli_ has quit IRC15:46
*** devth has quit IRC15:47
etoewselmiko: in your research into the version responses. did you notice if any projects aside from keystone uses jsonhome? ( see my comment here )15:51
elmikoetoews: yea, i thought there was another project doing json-home, but i'm blanking on it right now15:52
etoewshmmm...message service maybe?15:57
*** pratikmallya has joined #openstack-sdks15:57
*** fzdarsky has joined #openstack-sdks15:57
elmikoetoews: yea, that could be15:58
elmikoi feel like, maybe ironic too?15:59
elmikoetoews: yea, zaqar for sure.
*** agentleweb has joined #openstack-sdks16:05
*** salv-orl_ has joined #openstack-sdks16:06
*** salv-orlando has quit IRC16:09
*** amotoki has joined #openstack-sdks16:12
*** fzdarsky has quit IRC16:25
*** pratikma_ has joined #openstack-sdks16:33
*** pratikmallya has quit IRC16:34
*** gouthamr has joined #openstack-sdks16:40
*** pratikmallya has joined #openstack-sdks16:48
*** pratikma_ has quit IRC16:51
openstackgerritMerged openstack/python-openstackclient: Updated from global requirements
openstackgerritMark Vanderwiel proposed openstack/python-openstackclient: Allow wait_for_delete to work for all clients
*** scottda has joined #openstack-sdks17:00
agentlewebhi scottda17:00
cdentto repeat what I said over in meeting: : I think we should get together with various service catalog people because the suggested rule of "just use the service type" gets weird when you have volume, volumev2, compute, computev2117:00
agentlewebtell me more about what you're looking into?17:00
elmikocdent: yes17:00
edleafecdent: compute and computev21 aren't service types, are they?17:01
cdentI'm saying they should be17:01
cdentI'm saying that in some service catalogs there are:
edleafethey are versioned endpoints for the compute service type17:01
agentlewebwe talked about this17:01
cdentsorry edleafe "I'm _not_ saying they should be"17:01
scottdaAnd how about the header for Cinder microversions? OpenStack-[Volume | Block-Storage]-microversion17:01
edleafecdent: <whew!>17:02
cdentthanks agentleweb17:02
cdentso yeah, we want unversioned endpoints with unversioned types17:02
agentlewebcheck out
cdent(in the catalog)17:02
edleafecdent: +117:02
agentlewebbasically we still need extra data to allow for say, a service catalog with two compute endpoings17:02
cdentif/when we get that they we can prescribed the heade naming rule of "use the service type"17:03
agentlewebwe have this need at Rackspace for example17:03
elmikoscottda: my vote is for the governance based service type, but i think the catalog should get in line what that as well17:03
agentlewebcdent: we have the projects.yaml17:03
agentlewebis that what you mean cdent ?17:03
edleafeagentleweb: but those really aren't two *OpenStack* computes17:03
cdentelmiko: based on the conversation with dtroyer earlier, we want to be able to construct the headers from the service catalog without prior knowledge17:03
agentlewebbut we have to make a nicer user-first service catalog17:03
scottdaOK, I'm going with OpenStack-Block-Storage-microversion17:04
cdentscottda: I don't think that's right17:04
agentlewebscottda: where does that go?17:04
edleafe+1 to volume17:04
scottdaagentleweb: in the HTTP header17:04
scottdaSo, I might be missing this, but it looked like "Block Storage" in
elmikocdent: how does that square with things like volume and volumev2 though?17:06
*** jaypipes has quit IRC17:06
cdentelmiko: volume and volumev2 are artifacts of hooey, not the grand new happyt17:06
elmikoalso, i thought the service catalog entries were supposed to configurable by the installers (efforts to standardize notwithstanding)17:06
cdentsadly I have to go17:06
cdentelmiko: the goals of service catalog ng is to not allow that17:06
cdentotherwise interop goes boom17:07
cdentthe endpoints can change, but not the names17:07
edleafeyay to interop!17:07
cdenti'll join the logs later, good luck, sorry for leavig in the middle of things17:07
elmikocdent: yea, i get that. maybe i'm just out of touch with the naming proposed for SC:TNG17:07
*** cdent has quit IRC17:07
ameadelets just roll with 'block-storage' then?17:08
elmikoso, is there supposed to be any congruence between the governance "official" service type names and the service catalog type names?17:08
scottdaOK, API friends, thanks for the input. I'll be changing from "X-OpenStack-Cinder-API-microversion" to something in this review:
elmikoagentleweb, edleafe ^^17:08
scottdaIf not resolved here, it will be done there.17:08
scottdaPlease weigh in if you've consensus.17:09
openstackgerritJas Singh proposed openstack/python-openstackclient: Add 'port create' command
elmikoscottda: ack, thanks!17:11
scottdaThanks to you all!17:11
*** e0ne has quit IRC17:15
openstackgerritJas Singh proposed openstack/python-openstackclient: Add 'port create' command
*** sigmavirus24 is now known as sigmavirus24_awa17:16
*** woodster_ has joined #openstack-sdks17:19
*** gouthamr has quit IRC17:32
*** agentleweb has quit IRC17:33
*** gouthamr has joined #openstack-sdks17:39
openstackgerritDean Troyer proposed openstack/python-openstackclient: Add missing release notes
openstackgerritJas Singh proposed openstack/python-openstackclient: Add availability zone support for router commands
*** salv-orl_ has quit IRC17:48
*** bryan_att has joined #openstack-sdks17:59
*** lucasagomes is now known as lucas-away18:03
*** boris-42 has quit IRC18:13
etoewselmiko: seems nova is working towards using jsonhome?
elmikoetoews: ooh, neat!18:24
elmikostill brings me back to the question of handling versioning with respect to changing the home page18:24
stevemardtroyer: yo18:26
stevemarwhats up with your changing the release note format :O18:26
dtroyeruh, nothing?  WTF did I do?18:26
stevemardtroyer: also i won't make the osc meeting today #keystonemidcycle18:27
stevemardtroyer: no bug links!18:27
dtroyerah, right18:27
stevemardtroyer: 2 things:18:27
stevemar1) you are now using "features' instead of "fixes"18:27
stevemarand 2) add links to the initial bug report18:27
dtroyeryeah, some are new, not fixes18:27
dtroyerthe bug link I totally whiffed on18:28
stevemarsaaaawing battah battah18:28
*** e0ne has joined #openstack-sdks18:34
*** sigmavirus24_awa is now known as sigmavirus2418:42
openstackgerritDean Troyer proposed openstack/python-openstackclient: Add missing release notes
openstackgerritKaren Bradshaw proposed openstack/fairy-slipper: Publishing swagger to rst
openstackgerritJas Singh proposed openstack/python-openstackclient: Add 'port create' command
*** pratikma_ has joined #openstack-sdks19:41
*** salv-orlando has joined #openstack-sdks19:42
*** pratikmallya has quit IRC19:43
*** devth_ has quit IRC19:49
*** salv-orlando has quit IRC19:50
*** lhcheng has joined #openstack-sdks20:07
*** devth_ has joined #openstack-sdks20:08
*** lhcheng_ has joined #openstack-sdks20:09
*** lhcheng has quit IRC20:12
*** salv-orlando has joined #openstack-sdks20:17
*** bnemec has quit IRC20:18
*** bnemec has joined #openstack-sdks20:25
*** lhcheng_ has quit IRC20:26
*** salv-orlando has quit IRC20:30
*** pratikma_ has quit IRC20:33
stevemardtroyer: yo, can you review this devstack change:
*** pratikmallya has joined #openstack-sdks20:41
elmikoetoews, just a question about the api-wg session. do i need to register this as a "presentation" ?20:46
etoews1 sec...20:47
*** devth_ has quit IRC20:51
etoewselmiko: i'm not seeing any other options...where do you even see that?20:51
elmikoetoews: oh, i'm not aware of other options, just wanted to confirm20:51
elmiko(thought maybe you knew something else)20:52
etoewsnope. presentation it is. choosing the Working Groups track is the key.20:52
elmikogot it, thanks!20:52
*** devth has joined #openstack-sdks20:54
*** gildub has joined #openstack-sdks21:10
*** salv-orlando has joined #openstack-sdks21:11
openstackgerritDean Troyer proposed openstack/python-openstackclient: Add missing release notes
openstackgerritMark Vanderwiel proposed openstack/python-openstackclient: update heat object and command doc
*** pratikma_ has joined #openstack-sdks21:32
*** pratikmallya has quit IRC21:33
openstackgerritBrad Behle proposed openstack/python-openstackclient: Add availability zone support for network commands
*** salv-orl_ has joined #openstack-sdks22:06
openstackgerritAkihiro Motoki proposed openstack/python-openstackclient: Update translation setup
*** salv-orlando has quit IRC22:08
openstackgerritEverett Toews proposed openstack/python-openstacksdk: Make functional test resources configurable
*** pratikma_ has quit IRC22:17
*** rtheis has quit IRC22:20
*** devth has quit IRC22:22
*** devth has joined #openstack-sdks22:22
*** e0ne has quit IRC22:22
*** bryan_att has quit IRC22:29
*** terrylhowe has quit IRC22:39
*** jose4183 has quit IRC22:47
*** e0ne has joined #openstack-sdks22:56
*** e0ne_ has joined #openstack-sdks23:00
*** e0ne has quit IRC23:02
*** Guest94234 is now known as jgriffith23:14
openstackgerritAkihiro Motoki proposed openstack/python-openstackclient: Update translation setup
*** e0ne_ has quit IRC23:27
*** Qiming has joined #openstack-sdks23:32
*** chlong has quit IRC23:32
*** devth has quit IRC23:47
*** devth has joined #openstack-sdks23:48
*** sigmavirus24 is now known as sigmavirus24_awa23:56
*** amotoki has quit IRC23:56
*** devth has quit IRC23:59

Generated by 2.14.0 by Marius Gedminas - find it at!