Tuesday, 2016-03-22

*** salv-orl_ has joined #openstack-sdks00:01
*** outofmemory is now known as reedip00:04
*** salv-orlando has quit IRC00:04
*** salv-orl_ has quit IRC00:04
*** gildub has joined #openstack-sdks00:21
*** Qiming has quit IRC00:35
*** agentle has joined #openstack-sdks00:36
*** agentle has quit IRC00:40
*** eliqiao has quit IRC00:42
*** eliqiao has joined #openstack-sdks00:43
*** dims has joined #openstack-sdks00:57
*** Qiming has joined #openstack-sdks01:10
*** salv-orlando has joined #openstack-sdks01:10
*** thrash is now known as thrash|pt001:13
openstackgerritQiming Teng proposed openstack/python-openstacksdk: Cluster user guide - part 2  https://review.openstack.org/28976101:17
*** sigmavirus24_awa is now known as sigmavirus2401:21
*** sigmavirus24 is now known as sigmavirus24_awa01:22
*** salv-orlando has quit IRC01:26
*** salv-orlando has joined #openstack-sdks01:28
*** salv-orlando has quit IRC01:43
*** lucas-dinner has quit IRC01:55
openstackgerritReedip proposed openstack/python-openstackclient: Add Subnet add/remove support to router  https://review.openstack.org/28971601:55
*** lucasagomes has joined #openstack-sdks02:00
openstackgerritTang Chen proposed openstack/python-openstackclient: Use assert_called_once_with() instead of assert_called_with()  https://review.openstack.org/29489302:11
*** knikolla has quit IRC02:15
*** dims has quit IRC02:28
openstackgerritReedip proposed openstack/python-openstackclient: Subnet: Add "subnet set" command using SDK  https://review.openstack.org/28112902:29
*** salv-orlando has joined #openstack-sdks02:39
*** gouthamr has quit IRC02:44
openstackgerritReedip proposed openstack/python-openstackclient: Add external network options to osc network create  https://review.openstack.org/29223402:45
openstackgerritReedip proposed openstack/python-openstackclient: Subnet: Add "subnet set" command using SDK  https://review.openstack.org/28112902:46
*** salv-orlando has quit IRC02:50
*** lhcheng has quit IRC02:57
*** salv-orlando has joined #openstack-sdks03:07
*** lhcheng has joined #openstack-sdks03:14
*** salv-orlando has quit IRC03:24
*** chlong|wfh has quit IRC04:12
openstackgerritReedip proposed openstack/python-openstackclient: Add additional options to osc network create  https://review.openstack.org/29442204:21
openstackgerritReedip proposed openstack/python-openstackclient: Add external network options to osc network create  https://review.openstack.org/29223404:21
*** lhcheng has quit IRC04:22
*** salv-orlando has joined #openstack-sdks04:23
*** chlong has joined #openstack-sdks04:25
openstackgerritReedip proposed openstack/python-openstackclient: Add external network options to osc network create  https://review.openstack.org/29223404:29
*** salv-orlando has quit IRC04:30
*** salv-orlando has joined #openstack-sdks04:32
reediptangchen: ping04:34
openstackgerritReedip proposed openstack/python-openstackclient: Add additional options to osc network create  https://review.openstack.org/29442204:36
*** salv-orlando has quit IRC04:52
*** salv-orlando has joined #openstack-sdks04:59
*** salv-orl_ has joined #openstack-sdks05:04
*** salv-orl_ has quit IRC05:06
*** salv-orlando has quit IRC05:09
openstackgerritReedip proposed openstack/python-openstackclient: Subnet: Add "subnet set" command using SDK  https://review.openstack.org/28112905:11
*** lhcheng has joined #openstack-sdks05:30
*** lhcheng_ has joined #openstack-sdks05:31
*** lhcheng has quit IRC05:34
*** ankit_ag has joined #openstack-sdks06:07
*** salv-orlando has joined #openstack-sdks06:07
*** salv-orlando has quit IRC06:24
*** salv-orlando has joined #openstack-sdks06:35
*** lhcheng_ has quit IRC06:39
*** lhcheng has joined #openstack-sdks06:39
*** salv-orlando has quit IRC06:41
*** gildub has quit IRC06:54
*** lhcheng has quit IRC06:54
ankit_agHi all, where can I find the current PTL name for OpenStack SDK project?06:59
*** yanyanhu has joined #openstack-sdks07:16
*** salv-orlando has joined #openstack-sdks07:46
*** salv-orlando has quit IRC07:48
*** salv-orlando has joined #openstack-sdks07:53
*** salv-orlando has quit IRC07:59
*** salv-orlando has joined #openstack-sdks08:03
openstackgerritSheel Rana proposed openstack/python-openstackclient: Support for volume service list/enable/disable  https://review.openstack.org/29566008:10
*** salv-orlando has quit IRC08:14
*** salv-orlando has joined #openstack-sdks08:16
*** markvoelker has quit IRC08:16
*** salv-orlando has quit IRC08:25
*** openstackgerrit has quit IRC08:33
*** openstackgerrit has joined #openstack-sdks08:34
*** Qiming has quit IRC08:44
*** Qiming has joined #openstack-sdks08:49
*** _RuiChen has quit IRC08:53
*** fzdarsky has joined #openstack-sdks08:53
*** reedip is now known as reedip_away08:58
*** RuiChen has joined #openstack-sdks09:01
*** markvoelker has joined #openstack-sdks09:17
openstackgerritSheel Rana proposed openstack/python-openstackclient: Support for volume service list/enable/disable  https://review.openstack.org/29566009:19
*** salv-orlando has joined #openstack-sdks09:22
*** e0ne has joined #openstack-sdks09:22
*** salv-orlando has quit IRC09:39
*** Qiming has quit IRC09:42
*** sdague has joined #openstack-sdks09:44
*** dims has joined #openstack-sdks09:51
*** markvoelker has quit IRC09:52
*** gildub has joined #openstack-sdks09:52
*** dims has quit IRC10:04
*** dims has joined #openstack-sdks10:12
*** yanyanhu has quit IRC10:14
*** cdent has joined #openstack-sdks10:28
*** salv-orlando has joined #openstack-sdks10:33
*** yanyanhu has joined #openstack-sdks10:48
*** yanyanhu has quit IRC10:53
*** Qiming has joined #openstack-sdks11:10
*** gildub has quit IRC11:15
briancurtinankit_ag: it's not an "official" project so there's no official PTL. what do you need that for?11:23
*** cdent has quit IRC11:31
*** rtheis has joined #openstack-sdks11:38
*** fzdarsky is now known as fzdarsky|lunch11:48
*** markvoelker has joined #openstack-sdks11:48
*** cdent has joined #openstack-sdks11:58
*** salv-orl_ has joined #openstack-sdks12:01
*** salv-orlando has quit IRC12:05
ankit_agbriancurtin: thanks for the information12:06
ankit_agbriancurtin: I was looking someone responsible for approval of openstack-sdk blueprints12:06
briancurtinankit_ag: we don’t use blueprints12:07
ankit_agcurrently I am working on https://blueprints.launchpad.net/python-openstacksdk/+spec/return-request-id-to-caller12:07
ankit_agbriancurtin: in that case how should we process to implement a new feature12:07
briancurtinankit_ag: you just write the code and then we review it, or perhaps submit a bug report on launchpad12:08
ankit_agbriancurtin: Thank you :)12:08
briancurtinankit_ag: however, one thing to be aware of, i’m about to push a review that is effectively a ground-up rewrite of the Resource class, so anything you’d be doing to solve this problem will need to wait for that to be done12:09
briancurtinankit_ag: however, if there’s just a request-id header coming back, the way to solve that shouldnt be too hard12:10
ankit_agbriancurtin: Yes I am going to append request-id in the response object itself so it will not impact any existing functionality12:11
ankit_agbriancurtin: does the Resource class cleanup task requires my current patches to be hold which I have submitted to fix image member and tag APIs ?12:13
briancurtinankit_ag: no, those image ones are ok as they are. i can take a look at them today - i think i mostly finished them up12:14
ankit_agbriancurtin: Yes please. Thank you !12:14
*** purplerbot has quit IRC12:15
*** purplerbot has joined #openstack-sdks12:15
*** purplerbot has quit IRC12:15
*** purplerbot has joined #openstack-sdks12:16
*** fzdarsky|lunch is now known as fzdarsky12:18
*** fzdarsky is now known as fzdarsky|afk12:18
*** markvoelker has quit IRC12:21
*** annegentle has joined #openstack-sdks12:31
*** markvoelker has joined #openstack-sdks12:47
openstackgerritjichenjc proposed openstack/python-openstackclient: [compute] Add virtual interface list command  https://review.openstack.org/28383412:59
*** dims_ has joined #openstack-sdks13:02
*** dims has quit IRC13:02
*** lucasagomes is now known as lucas-hungry13:07
sheelHello All, stevemar, dtroyer, rtheis, tangchen ,13:19
sheelkindly find some spare time to review13:19
sheelhttps://review.openstack.org/#/c/295660/  and13:19
*** fzdarsky|afk is now known as fzdarsky13:21
*** reedip__ has joined #openstack-sdks13:22
*** knikolla has joined #openstack-sdks13:22
*** gouthamr has joined #openstack-sdks13:23
sdaguecdent: do you have a library pulled together for the parsing code for the new microversion header extraction?13:32
cdentsdague: one sec13:32
*** erlon has joined #openstack-sdks13:34
*** markvoelker_ has joined #openstack-sdks13:34
cdentthis is as far as I've gotten, not library-ized yet: https://tank.peermore.com/_/22ab9236-d0e1-49e4-8b31-8d0feece691d13:35
*** markvoelker has quit IRC13:36
sdaguecdent: ok, so after playing with the parsing in tree, I think we need a dedicated library here otherwise it's going to be frought with errors13:36
sdagueso as soon as you publish something there, I'll do the plugging into Nova of the header13:36
sdaguebut I'll wait on you for that13:37
cdentsdague: that's part of https://github.com/jaypipes/enamel/blob/master/enamel/api/version.py13:37
cdentthere are tests nearby13:37
cdenti agree that a library of some kind is a good idea13:38
*** markvoelker has joined #openstack-sdks13:38
cdentthe problem with the above is that it is somewhat flask oriented13:38
cdentI would guess that it ought to be possible to figure out a way to get it into something like oslo middleware13:39
*** ankit_ag has quit IRC13:40
sdaguehonestly, I would just cut a dedicated library for this13:40
*** markvoelker_ has quit IRC13:40
cdenti'll inquire with the oslo folks13:41
cdentdedicated is my preference13:41
*** RuiChen has quit IRC13:41
cdentbut people seem to get ... fussy about more stuff13:41
cdentsdague: I seem to recall that ironic wrote a new processor for microversions that does both forms.13:43
*** RuiChen has joined #openstack-sdks13:43
sdaguecdent: honestly, I don't even care if it's in oslo, just a library out there somewhere13:43
dims_++ sdague13:43
cdentit's not something that makes any sense for anything else13:44
cdentI wouldn't want to encourage microversion header handling in the world outside of openstack as it is an incorrect way to do versioning13:44
cdentwithin openstack it is what we're stuck with so an openstack library makes sense...13:44
dims_cdent : we can ask for a git repo in openstack/ git itself and develop a library - http://docs.openstack.org/infra/manual/creators.html13:45
* cdent nods13:45
dims_cdent : does not have to be under oslo umbrella13:45
cdentwhat, then, does oslo end up meaning?13:46
*** terrylhowe has joined #openstack-sdks13:46
*** terrylhowe has left #openstack-sdks13:47
dims_cdent : we can talk in the next weekly meeting if there's interest in oslo cores for a new library. just pointing out that it does not need to be under oslo13:48
* cdent nods13:48
dims_cdent : as long as you have some interested folks to be the cores for the new library you are good13:48
cdentI was mostly just being curious. I've never quite really understood the definition of "oslo"13:48
reedip__rtheis: ping13:49
rtheisreedip__: hi13:49
reedip__rtheis: Good morning, I have just one query13:49
reedip__Are we targetting Patch : https://review.openstack.org/#/c/289716/ After mitaka?13:50
dims_cdent : primary mission was to get rid of shared code into libraries. (oslo-incubator -> new libraries), then we started new libraries like debtcollector etc. but it's equally valid to start new libraries outside now that we have the big tent.13:50
reedip__Sorry, got my answer...13:50
reedip__rthies: I was confused with another patch... :)13:50
rtheisreedip__: ok, no problem13:51
rtheisreedip__: I wasn't sure if we should update requirements at this point in the release for a new function.13:51
dims_cdent : one project that was started outside of oslo (osprofiler) did end up in oslo as well. depends on interest amongst oslo cores, how pervasively it's used etc.13:51
cdentthanks dims_13:52
reedip__rtheis: I guess we should delay it after mitaka13:52
reedip__rtheis: avoid any last minute issues seeping in...13:52
rtheisyes, that may be best13:52
briancurtinankit_ag: no, those image ones are ok as they are. i can take a look at them today - i think i mostly finished them up13:52
dims_cdent : we'd be very happy to have new ideas, people. we do come with baggage :) (backwards compat etc)13:53
reedip__rtheis: agreed ....13:54
sheelrtheis: hey13:59
rtheissheel: hi13:59
sheelrtheis: was looking for some info14:00
sheelrtheis: are we done with mitaka or still accepting new patches?14:00
cdentetoews, elmiko, sdague: my last comment here is something we're going to have to address api-wise, eventually: https://review.openstack.org/#/c/281511/14:00
rtheissheel: you'll have to ask dtroyer about release plans for mitaka14:01
*** terrylhowe_ has joined #openstack-sdks14:01
*** terrylhowe_ has left #openstack-sdks14:02
sheelrtheis:  ok, sure14:02
sdaguecdent: the etags issue, sure14:02
sheelrtheis:  thanks14:02
sdaguecdent: but it also is going to need code examples14:02
* cdent nods14:03
* cdent has a backlog14:03
sheeldtroyer:  hi, are you around14:04
sdagueand needs implementation in the clients the servers are cross communicating iwht14:05
*** sigmavirus24_awa is now known as sigmavirus2414:05
cdentyes, no doubt it will be a pile of work14:05
sdaguewhich makes me a bit concerned about pushing a spec that says 'do it this way, which requires this other thing, that nothing does'14:05
cdentsdague: there's no spec yet14:06
cdentand thus far most of openstack fails the lost update check, but it is still working14:06
*** singhj has joined #openstack-sdks14:06
cdentbut nothing is helped by not acknowledging the presence of the problem14:07
sdaguecdent: sure14:07
sdaguejust it's a guideline to tell people to do it this way14:07
elmikocdent: good points14:07
sdaguebut if they do, and don't address the other thing, then it means that people are going to hit real issues14:08
sdagueI also get a little twitchy about guidelines that end up being "the client needs a bunch more logic"14:08
cdentsdague: that's the way the web works14:08
elmikosdague: also good points14:08
cdentyou can't avoid this problem without smarter clients14:08
cdenthowever, the problem is actually quite rare14:08
elmikoseems like the etags guideline should be added soon(TM)14:09
* cdent _wants_ people to hit issues because bugs the lubricant of progress and engagement14:09
*** bryan_att has joined #openstack-sdks14:09
dtroyercdent: (cathcing up a bit)  is that microversion lib intended for server or client-side use?  or both?14:13
dtroyersheel: we cut our Mitaka-equivalent release a couple of weeks ago, 2.2.0 is stable/mitaka branch.14:14
cdentdtroyer: server, initially14:15
sheeldtroyer: thanks for information14:15
dtroyercdent: ok.  Most of Oslo is written with server-side assumptions (dependencies mostly) in mind making it hard to use in clients also14:15
sheeldtroyer: so when are we planning to open up with newton?14:16
dtroyersheel: that is what master is.  We don't do the integrated release cycle, we just do periodic releases.  Since some things really want someting pinned to the integrated release, we pick the last one when the libs freeze and call it that.14:16
sheeldtroyer: ok14:17
sheeldtroyer: so we are open for new patches now.14:17
sheeldtroyer: thanks for update14:18
dtroyerthere should be no reason to need to go backward in time to use a current OSC (or any client really) with any of the supported OpenStack releases.  if there it, it's a bug.14:18
sdaguedtroyer: this is really a header parser for a particular header in question that gets complicated to parse correctly14:18
dtroyerthat of course ignores issues with Python dependencies when installing in the same space as an old server, say14:18
sdaguethere aren't client side implications for this I don't think14:18
dtroyersdague: ok, cool.  I just like to keep an eye on things that jump into oslo then want to be used in clients… those assumptions hurt sometimes14:19
*** dims_ has quit IRC14:19
sdaguethis should litterally have no dependencies14:19
sdagueit's a parsing library14:19
*** lucas-hungry is now known as lucasagomes14:21
cdentsdague: I'm only just now seeing your comment on the delete etags guideline14:28
cdentAre you suggesting that everywhere we indicate the PUT is used we need to now go back and mention etags. The problem is by no means specific to this new guideline14:29
cdentit is everywhere the is a PUT14:29
sdaguecdent: I think we should figure out if anything is doing the right thing today before telling everyone to build delete calls this way14:33
cdentsdague: it has _nothing_ to do with delete14:33
cdentit is every single place that does a PUT14:33
*** openstackgerrit has quit IRC14:33
sdaguecdent: ok, so I'm asking the question, what's the state of our code today14:33
*** openstackgerrit has joined #openstack-sdks14:34
cdentIt's a good question, one we need to address14:34
cdentthus my original comment [t 3nR9]14:35
purplerbot<cdent> etoews, elmiko, sdague: my last comment here is something we're going to have to address api-wise, eventually: https://review.openstack.org/#/c/281511/ [2016-03-22 14:00:46] [n 3nR9]14:35
elmiko<3 purplerbot14:36
sdaguesure, and what I'm saying is knowing the current state of actual code, like what does 'nova meta' commands actually do14:37
sdagueas I don't think osc has any of these apis plumbed14:37
cdentsure. So far I'm just setting the bit, not trying to resolve it.14:38
*** singhj has quit IRC14:40
sdagueright, I'm saying that before we move on with new recommendations here, we need to actually know the state of the world.14:40
*** e0ne has quit IRC14:41
cdentsdague: I guess my confusion stems from: how is this new recommendation any different from any of the others which have the same problem? We're not increasing the problem surface area. We already recommend that people use PUT to modify metadata (elsewhere in the same file). I agree with all the things we need to do to make this better, but I'm not clear on the timing of putting on the brakes14:44
etoewsit comes back to basic education around http apis14:46
etoews"I hadn't come across etags"14:46
*** DuncanT has joined #openstack-sdks14:46
etoewswe have to assume zero knowledge of http apis14:46
etoewsit would be nice to be able to recommend a short book that people can use to get up to speed if they're so inclined14:47
etoewsi feel like https://leanpub.com/restful-api-design could be that book but it's incomplete14:48
sdagueetoews: so that's fine in a greenfield world14:48
sdaguewe're working with code that's deployed everywhere14:48
etoewsin this particular case "Caching - Strategies & ETags" is on the TODO list14:48
etoewssdague: yes. and we do account for that in https://wiki.openstack.org/wiki/API_Working_Group/Current_Design14:49
DuncanTSome Openstack API specific guidance from somebody knowledgeable would be very useful14:49
etoewsdoens't mean we can't at least attempt to push forward where it makes sense to do so14:49
DuncanTThe cinder API currently has no etags support at all14:49
sdagueetoews: sure... except, there is nothing in here which then lets people know "hey, your client needs to do X otherwise you've created a data corruption issue"14:49
sdaguebecause we've got real clients and servers out there, and recommentations that assume they do things they don't14:50
etoewsright. assume nothing. it needs to be documented in the guidelines.14:50
sdagueso before doing more of that, at least surveying the state of the world would be good14:50
etoewsyep. that's why i encourage all guidelines to start with an addition to https://wiki.openstack.org/wiki/API_Working_Group/Current_Design14:51
etoewspush forward from a known state14:51
DuncanTDoing some (very quick and dirty) searching, the only etags mentions I can find are for swift14:51
etoewsthat's the only place i've come across them14:52
etoewsi can't recall how well they adhere to the a proper impl of etags14:52
DuncanTIs there anybody able to provide the start of some basic advice? I just tried to start a spec for adding etag generation to cinder, and I quickly found I don't understand nearly enough about the expected behaviour14:53
cdentDuncanT: I've put it on my todo list14:53
DuncanT(see my latest comment on the API doc review for an example)14:53
DuncanTcdent: Thanks14:53
cdentI suspect its on my. I've written several apis which use etags extensively14:53
DuncanTcdent: I'll keep an eye out for it, thanks14:55
cdentDuncanT: it may take some time depending on the extent to which it needs to be related to the current state of things in openstack, versus a description of what they are and how to use them in the general case14:56
DuncanTcdent: A general description would be a great start, as long as it covers the case of multiple views into the same object14:57
etoewsDuncanT: if you're looking for some reading on it, http://www.amazon.com/RESTful-Web-APIs-Leonard-Richardson/dp/1449358063 covers etags and has a (brief) section on avoiding the lost update. nothing on actually generating etags though.14:59
etoewscdent: where is this server-side microservices library?14:59
DuncanTetoews: Cheers, I'll see if I can track down a copy15:00
cdentetoews: it doesn't fully exist yet, but the poc is in this: https://github.com/jaypipes/enamel/blob/master/enamel/api/version.py which I'm going to try to extract to something generic15:00
cdentetoews: i assume you meant microversions?15:02
sdaguelet's also be specific about what we are talking about15:04
sdagueit's a parser for OpenStack-API-Version: compute 2.12; volume 2.115:04
sdaguefor that one field15:04
*** singhj has joined #openstack-sdks15:07
*** Qiming has quit IRC15:10
cdentsdague: you just want the parser15:14
cdentor you want a piece of middleware that manages versioning?15:14
sdaguehonestly, I just want a parser15:14
sdagueat least to start15:14
sdaguewe have all the logic on management in the applications right now15:14
sdaguebut the parsing gets an order of magnitude more complex15:15
sdagueOpenStack-API-Version: compute 2.1215:15
sdaguevs. OpenStack-Nova-API-Version: 2.1215:15
cdentwhat kind of assumptions do you want about the input: is it one folded header, multiple headers, or both?15:16
sdaguecdent: ideally both15:16
cdentthe different handing of headers by different frameworks throws a bit of a wrench15:17
sdaguein my ideal world I want this interface15:17
sdaguecdent: they don't all use webob underneath?15:17
sdaguewhat doesn't?15:17
cdentdo you mean in the world of openstack, or in the world at large?15:18
sdagueget_version(webob_request, service_type='compute')15:18
sdaguecdent: I mean a) in openstack, b) in openstack that is using microversions or might soon15:18
openstackgerritMerged openstack/python-openstackclient: Use assert_called_once_with() instead of assert_called_with()  https://review.openstack.org/29489315:19
cdentwould get you accept: get_version(headers, service_type='compute') # where headers is type checked for list or dict?15:20
cdentthat would be considerably more flexible with regard to callers15:20
sdaguecdent: as long as there is a straight forward way to get headers as that from webob15:20
cdentrequest.headers is a dict15:20
sdagueok, then yes, that's fin15:20
elmikocdent: +1 for more generic approach15:21
sdagueI would also like get_version(headers, service_type='compute') to support the legacy headers we know exist15:21
sdaguewith new headers taking preference15:22
cdentyeah, I kinda assumed that, but what about 'nova'15:23
sdagueservice_type='compute' should use OpenStack-Nova-API-Version if there is no OpenStack-API-Version declaration15:23
cdentthat embeds too much smarts15:23
cdenthow about service_types=['compute', 'nova'] ?15:24
cdentor service_type='compute', fallback='nova'15:24
cdentor something like that15:24
sdagueno, because that lets that be in the generic header, which we don't want to support15:24
sdaguehonestly, we've got only a couple of one offs, and you've said this is an openstack specific library15:24
sdagueI'm not sure why we can't just embed the legacy logic there15:25
cdentsdague: sure but we want the problems to be visible in the caller, not the library15:25
cdentotherwise they disappear15:25
sdagueso, for that I'd suggest a check_version(headers, service_type='compute')15:25
sdaguewhich returns some deeper information about things being odd15:26
sdagueor returning a warnings object with the actual version15:26
cdentI don't mean visibility in terms of inspection15:26
cdentI mean visibility in the code for future maintainers15:26
sdagueok, well how about we just start with a parser for that field then, and we'll keep all the rest of the logic in the applications15:26
cdenti'll poc something out, and we can talk about it around that15:26
sdagueyeh, if the simplest thing is done first, that's fine15:27
sdaguewe can figure out who is keeping the gorp logic later15:27
*** tangchen has quit IRC15:38
*** tangchen has joined #openstack-sdks15:39
*** dims has joined #openstack-sdks15:45
*** dims_ has joined #openstack-sdks15:55
*** dims has quit IRC15:55
*** lhcheng has joined #openstack-sdks16:10
*** annegentle has quit IRC16:12
sheeldtroyer:  hi16:13
sheeldtroyer: regarding "volume set --transfer [--transfer-name <name>]  <volume>"16:13
sheelwe need to show auth key and volume details once volume transfer set is completed16:13
sheelwe need command.showOne for this purpose16:13
sheelBut as we are planning to create transfer using volume set, its seems not possible as set uses command.Command.16:13
sheelAs per design it seems not feasible in current volume set command, any input on this16:13
sheeldtroyer: should be stick to "volume transfer"?16:19
*** cdent has quit IRC16:21
*** e0ne has joined #openstack-sdks16:21
*** dims_ has quit IRC16:46
*** cdent has joined #openstack-sdks16:48
*** lucasagomes is now known as lucas-afk17:02
*** dims has joined #openstack-sdks17:02
*** singhj has quit IRC17:08
*** dims has quit IRC17:13
*** singhj has joined #openstack-sdks17:26
*** Kiall has quit IRC17:31
*** singhj has quit IRC17:31
*** Kiall has joined #openstack-sdks17:33
*** lucas-afk is now known as lucasagomes17:34
*** singhj has joined #openstack-sdks17:41
*** krotscheck has quit IRC17:43
cdentsdague, elmiko, etoews: https://github.com/cdent/microversion_parse17:50
cdentproof of concept, ymmv, ianal, etc17:50
*** lucasagomes is now known as lucas-dinner17:57
*** fzdarsky is now known as fzdarsky|afk17:57
*** d0ugal has quit IRC17:58
elmikocdent: neat, i'll keep this around as we start to implement microversions in sahara17:58
elmikothat work should be underway in newton17:58
cdentelmiko: I'm assuming we'll move some form of that under the openstack umbrella after we hash it around a bit17:59
elmikomakes sense17:59
cdentnot much point if its not in line with requirements/expectations17:59
*** d0ugal has joined #openstack-sdks17:59
cdentbut if it is, then cool17:59
*** salv-orlando has joined #openstack-sdks18:02
*** salv-orl_ has quit IRC18:05
*** annegentle has joined #openstack-sdks18:05
*** fzdarsky|afk has quit IRC18:08
*** d0ugal has quit IRC18:09
etoewscdent: thanks. i know the magnum folks are interested in it too.18:09
*** lhcheng has quit IRC18:11
cdentelmiko, etoews: if you guys have a moment to check over the tests and confirm I've got the logic right. It tries to cover quite a lot of situations.18:11
elmikocdent: ack18:13
*** boris-42 has joined #openstack-sdks18:21
*** lhcheng has joined #openstack-sdks18:28
*** sigmavirus24 is now known as sigmavirus24_awa18:33
openstackgerritMerged openstack/python-openstacksdk: Fix image member apis  https://review.openstack.org/29157218:36
elmikocdent: lgtm, my only quibbles would be stylistic18:52
elmikoi do have a question,18:52
elmikoin the case of a header like "openstack-compute-api-version: 2.1, 9.2", is there a realworld case where that might happen?18:52
cdentelmiko: after we cover the actual question I'd be curious to know the stylistic quibbles, because I tend to have a pretty intentional style18:55
cdentif a client built a request and somehow  managed to send two headers with different versions, the result would be what you quote there18:55
elmikoah, ok18:56
cdentbasically: if you two different parts of the code append (rather than modifying) a header, you'd get something like that18:56
elmikoright, makes sense. i wasn't thinking about that case18:56
cdentand it is kind of easy to imagine a layered client, or a client that was a kind of proxy18:56
elmikoyea, exactly18:56
briancurtinrtheis: do you have anything to meet about?18:59
rtheisbriancurtin: nothing today18:59
elmikoas for the style quibbles, maybe i just think in a different direction with regards to things like catching an exception off a missed dictionary lookup18:59
elmikocdent: overall the code makes a good deal of sense18:59
briancurtinrtheis: pretty much same. i pushed that Resource refactor and am moving on to the Proxy part of it right now, which should be a lot quicker (i already did some of it an attempt to validate the whole idea end-to-end)19:00
cdentI'm trying to allow some, but not all, exceptions to rise to the caller, which probably causes some confusion19:00
rtheisbriancurtin: nice19:00
elmikocdent: no, i think that's a good thing19:01
cdentelmiko I was afraid you were going to tell me to add a class or something, at which point I was going to cry about the overuse of OO and sulk ;)19:01
elmikocdent: LOL19:02
* cdent burninates19:02
elmikoit was more like, when seeing https://github.com/cdent/microversion_parse/blob/master/microversion_parse/__init__.py#L8119:03
elmikofor example19:03
elmikoi find it easier to read when i see "header = headers.get(STANDARD_HEADER); if header is None: return"19:03
cdentthat probably made more sense when that block didn't have two try statements19:04
elmikobut, like i said, that's just an artifact of my style balance19:04
cdentthe inner one was added after I found a bug19:04
elmikoit makes sense, especially to those who write a lot of python.19:04
elmikoi tend to probably be overly verbose and explicit in the way i write code though19:05
sdaguecdent: as soon as there is some negative testing in there, I'm good with it19:05
elmikoand the only reason i'm mentioning this is you made me!19:05
cdentsdague: PATCHES ACCEPTED19:05
cdentsdague: and there are some already19:06
cdentbut yes, there could be some more19:06
sdaguecdent: I told you I was waiting for you... :)19:07
sdagueactually... I have a suggestion for interface change19:07
cdentah, cool, yeah?19:08
sdaguedef get_version(headers, service_type=None, legacy_headers=['X-OpenStack-Nova-API-Version'])19:08
sdagueso we only do the right thing with the new known headers, and you have to specifically give it old headers you will do parsing out of19:09
sdaguebecause https://github.com/cdent/microversion_parse/blob/master/microversion_parse/tests/test_get_version.py#L151 actually makes me nervous that that works19:09
sdagueas I can imagine stuff slipping in19:09
cdentI got the impression from the earlier discussion that we wanted it to be fairly do-it-all-for-you?19:10
cdentsdague: that _should_ work19:10
sdaguebut I don't want it to accept invalid behavior that currently doesn't exist today19:10
sdaguecdent: no, because OpenStack-Compute-API-Version is not a thing19:11
sdaguethat header has never existed in the wild19:11
sdagueI don't want to allow for it19:11
cdentah, I see what you mean19:11
sdagueI'd like to contain the damage, as you said19:11
cdentwell that should be relatively easy change19:12
sdagueso OpenStack-API-Version parsing for everyone, then projects have to be explicit about other headers they did support and only allow for those19:12
cdenti'll do that after the current run of irc meetings19:13
cdentthank you19:13
cdentsdague: I'll probably come calling your direction if I get stuck on the put-it-under-openstack stuff19:14
elmikosdague: +1, i like that notion19:16
*** sigmavirus24_awa is now known as sigmavirus2419:44
cdentsdague: adjusted, but probably still needs more tests to satisfy your desires19:45
*** david-lyle_ has joined #openstack-sdks19:56
*** david-lyle has quit IRC19:57
*** salv-orlando has quit IRC19:58
*** david-lyle_ is now known as david-lyle20:02
*** sdague has quit IRC20:31
*** jaypipes has quit IRC20:52
*** e0ne has quit IRC20:53
*** salv-orlando has joined #openstack-sdks20:56
cdentelmiko, etoews: I've must added you as a reviewer on https://review.openstack.org/#/c/296046/20:57
cdentsigh s/must/just/20:57
*** rtheis has quit IRC20:57
elmikoack, i'll take a look. but it might have to wait until after the dog walk ;)20:58
cdentelmiko: no rush20:58
cdentit's long past the end of my day20:59
elmikoyeah, seriously!20:59
*** singhj_ has joined #openstack-sdks21:00
*** singhj has quit IRC21:01
*** singhj_ has quit IRC21:05
*** gouthamr has quit IRC21:11
*** dims has joined #openstack-sdks21:11
*** singhj has joined #openstack-sdks21:14
*** singhj has quit IRC21:18
*** singhj has joined #openstack-sdks21:23
*** cdent has left #openstack-sdks21:27
*** singhj has quit IRC21:32
*** gouthamr has joined #openstack-sdks21:47
*** openstackgerrit has quit IRC21:48
*** openstackgerrit has joined #openstack-sdks21:49
*** e0ne has joined #openstack-sdks21:50
*** sigmavirus24 is now known as sigmavirus24_awa22:02
*** annegentle has quit IRC22:08
*** annegentle has joined #openstack-sdks22:17
*** e0ne has quit IRC22:21
reedip__RuiChen: ping ?22:34
*** gouthamr_ has joined #openstack-sdks22:34
reedip__tangchen: ping22:35
*** gouthamr has quit IRC22:37
*** gildub has joined #openstack-sdks22:38
*** annegentle has quit IRC22:38
*** knikolla has quit IRC22:49
*** annegentle has joined #openstack-sdks22:59
*** annegentle has quit IRC23:04
*** annegentle has joined #openstack-sdks23:09
*** annegentle has quit IRC23:10
*** dims_ has joined #openstack-sdks23:12
*** dims has quit IRC23:15
*** dims has joined #openstack-sdks23:15
*** dims_ has quit IRC23:18
*** dims_ has joined #openstack-sdks23:19
*** dims has quit IRC23:22
*** dims has joined #openstack-sdks23:23
*** dims_ has quit IRC23:25
*** Qiming has joined #openstack-sdks23:26
*** lhcheng has quit IRC23:31
*** lhcheng has joined #openstack-sdks23:32
*** lhcheng has quit IRC23:32
*** lhcheng has joined #openstack-sdks23:33
*** knikolla has joined #openstack-sdks23:39
*** markvoelker has quit IRC23:44
*** markvoelker has joined #openstack-sdks23:47

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