Tuesday, 2017-05-16

*** prg3 has joined #openstack-sdks00:00
*** reedip_ has quit IRC00:03
*** annegentle has quit IRC00:15
*** annegentle has joined #openstack-sdks00:41
*** annegentle has quit IRC00:41
*** sdague has quit IRC00:49
*** elmiko has quit IRC01:05
*** elmiko has joined #openstack-sdks01:06
*** fzdarsky_ has joined #openstack-sdks01:55
*** annp has joined #openstack-sdks01:58
*** fzdarsky has quit IRC01:58
openstackgerritMerged openstack/keystoneauth master: Updated from global requirements  https://review.openstack.org/46439202:08
*** annp_ has joined #openstack-sdks02:21
chenyb4med_, please help me review https://review.openstack.org/#/c/462818/ this patch, thaks02:30
openstackgerritMerged openstack/keystoneauth master: Fix V3ADFSPassword retrieval of scoped token  https://review.openstack.org/46321202:31
openstackgerritTakashi NATSUME proposed openstack/python-openstackclient master: List/show all server migration types  https://review.openstack.org/45011902:46
*** gouthamr has joined #openstack-sdks02:51
*** yuanying has quit IRC02:51
*** dfflanders has joined #openstack-sdks03:13
chenyb4Qiming, please help me review https://review.openstack.org/#/c/462818/ this patch about 'senlin service list', thaks03:14
*** shu-mutou has joined #openstack-sdks03:24
*** salv-orlando has joined #openstack-sdks03:38
*** gildub has quit IRC03:42
*** gildub has joined #openstack-sdks03:55
*** yuanying has joined #openstack-sdks03:58
*** gouthamr has quit IRC04:05
*** yuanying has quit IRC04:23
*** yuanying has joined #openstack-sdks04:23
*** dfflanders has quit IRC04:34
*** jamielennox is now known as jamielennox|away05:10
Qimingchenyb4, done.05:13
*** yuanying has quit IRC05:18
*** yuanying has joined #openstack-sdks05:19
*** yuanying has quit IRC05:19
*** yuanying has joined #openstack-sdks05:20
*** jamielennox|away is now known as jamielennox05:30
openstackgerritDivya K Konoor proposed openstack/keystoneauth master: Re-use token passed in for v3 Token  https://review.openstack.org/46493405:40
*** Serlex has joined #openstack-sdks05:58
*** yuanying has quit IRC06:06
*** ralonsoh has joined #openstack-sdks06:45
*** dtantsur|afk is now known as dtantsur06:54
*** adriant has quit IRC06:57
*** yuanying has joined #openstack-sdks06:59
*** jamielennox is now known as jamielennox|away07:07
*** gildub has quit IRC07:19
*** jamielennox|away is now known as jamielennox07:34
*** aarefiev_afk is now known as aarefiev07:48
*** jpich has joined #openstack-sdks07:53
*** gildub has joined #openstack-sdks07:56
*** salv-orlando has quit IRC08:00
*** chenyb has joined #openstack-sdks08:32
*** LuigiOpenstack has joined #openstack-sdks08:36
LuigiOpenstackHi..is this the right IRC for development practice of Openstack and Luigi workflows?08:36
*** shu-mutou is now known as shu-mutou-AWAY08:44
LuigiOpenstackanybody has an idea of how to leverage luigi with Openstack ?08:45
*** Serlex has quit IRC08:47
*** e0ne has joined #openstack-sdks09:13
*** Serlex has joined #openstack-sdks09:23
openstackgerritDivya K Konoor proposed openstack/keystoneauth master: Re-use token passed in for v3 Token  https://review.openstack.org/46493409:48
*** gildub has quit IRC10:05
*** sdague has joined #openstack-sdks10:05
*** gildub has joined #openstack-sdks10:07
*** annp_ has quit IRC10:14
*** annp has quit IRC10:14
*** chenyb has quit IRC10:16
*** chenyb has joined #openstack-sdks10:33
*** jkilpatr has quit IRC10:41
*** sfinucan has quit IRC10:42
*** sfinucan has joined #openstack-sdks10:43
*** gildub has quit IRC10:50
*** jkilpatr has joined #openstack-sdks10:59
*** cdent has joined #openstack-sdks11:06
*** dtantsur is now known as dtantsur|brb11:09
*** reedip_ has joined #openstack-sdks11:09
*** prg3 has quit IRC11:21
*** prg3 has joined #openstack-sdks11:24
*** chenyb has quit IRC11:27
*** eliqiao has joined #openstack-sdks12:00
*** chenyb has joined #openstack-sdks12:09
*** dtantsur|brb is now known as dtantsur12:14
*** dave-mccowan has joined #openstack-sdks12:21
*** eliqiao has quit IRC12:27
*** eliqiao has joined #openstack-sdks12:28
*** eliqiao has quit IRC12:30
*** eliqiao has joined #openstack-sdks12:34
*** eliqiao has quit IRC12:45
*** eliqiao has joined #openstack-sdks12:47
*** eliqiao has quit IRC12:47
LuigiOpenstackCan anyone assist me with Python code ?12:48
*** eliqiao has joined #openstack-sdks12:48
*** salv-orlando has joined #openstack-sdks12:49
*** chenyb has quit IRC12:54
*** salv-orlando has quit IRC13:25
*** gouthamr has joined #openstack-sdks13:29
mordredLuigiOpenstack: hi! I'm not sure what a luigi is. this is the right channel to discuss OpenStack SDKs though13:49
*** prg3 has quit IRC14:21
*** fguillot has joined #openstack-sdks14:22
*** prg3 has joined #openstack-sdks14:28
edleafemordred: it's a module to handle plumbing a series of tasks together. Mario Bros. reference14:41
elmikoedleafe: lol14:48
*** hongbin has joined #openstack-sdks14:48
elmikoor were you referring to the actual luigi package14:48
* elmiko is so confused14:48
*** bobh has joined #openstack-sdks14:49
cdentelmiko: how doing after two solid weeks of conferencing?14:49
elmikocdent: almost fully recovered =)14:49
elmikofinishing the last of my expense reports now lol14:49
cdentI got home yesterday around 11am and just want to sleep14:50
elmikohope you're feeling rested now =)14:50
edleafeelmiko: both14:53
edleafecdent: go to sleep.14:53
*** aarefiev is now known as aarefiev_afk14:53
edleafecdent: elmiko: btw, I'll be in Portland on Thursday for the start of PyCon, so I won't be at the meeting14:54
cdenti slept most of yesterday, but it hasn't helped yet14:54
* cdent makes plans to assign actions to edleafe 14:54
* edleafe wouldn't expect anything else14:54
elmikoedleafe: ack, also enjoy pycon! =)15:00
edleafeelmiko: oh, I will!15:03
cdentedleafe: make sure you come back with lots of ideas to change everything15:03
edleafecdent: yeah, that always goes over well in this community.15:04
cdentexactly why it is critical15:04
elmikore-write all services in ruby after visiting pycon? XD15:05
edleafeelmiko: bite your tongue!15:07
openstackgerritBlake Covarrubias proposed openstack/keystoneauth master: Allow setting EndpointReference in ADFSPassword  https://review.openstack.org/46343215:07
*** reedip_ has quit IRC15:17
*** reedip_ has joined #openstack-sdks15:18
*** reedip_ has quit IRC15:19
*** cbsterrett has joined #openstack-sdks15:23
*** reedip_ has joined #openstack-sdks15:25
*** salv-orlando has joined #openstack-sdks15:32
*** reedip_ has quit IRC15:32
*** Serlex has quit IRC15:35
mordrededleafe: somehow last week - several sessions ended up with the outcome "mordred will write a spec" ...15:38
mordrededleafe: so, youknow - sorry in advance15:38
mordrededleafe, cdent: speaking of - dhellmann mentioned someting in one of the sessions that I think bears thinking about deeply and making a plan for15:39
* cdent sits comfortably15:39
mordredwith some of the new things we're writing up - we're winding up with 3 audiences for some of these API related specs- OpenStack Developers writing API services, Deployers registering things in such a way that affects API consumers, and API Consumers using the API services the OpenSTack Developers have written15:40
mordredso I _think_ I understood that dhellmann suggested we maybe make three different outputs that we publish - so we can point deployers at the info that's relevant to them without them needing to read about implementation internals or whatnot15:41
mordredor - something similar15:41
*** reedip_ has joined #openstack-sdks15:42
edleafemordred: that sort of meshes with the feeling I had reviewing your discovery docs (besides the dizziness)15:42
mordredthe dizziness means it's working15:42
mordredsoon I will have the mind control overyou!15:43
edleafemordred: that these aren't API guidelines, but more like deployment guidelines15:43
mordredsssh. I didnt' say that15:43
edleafeor something like that15:43
mordrededleafe: exactly. I mean - they're API guidelines in as much as we want the API to behave in a way, and the deployers have to participate on a few topics15:43
edleafeI didn't hear that. I hear only what the master tells me to hear15:43
mordrededleafe: :)15:43
edleafeI think of these guidelines as helping the OpenStack developers make good choices when creating APIs15:44
edleafeThese seem... different15:44
mordreddo you think they seem different enough to put into a separate source repo? my original thought was "no" - since the corpus is about OpenStack REST APIs ...15:45
mordredbut I am more than happy to agree with whatever opinions y'all have on that topic15:45
edleafemordred: not really sure. I'd like to get cdent and elmiko to weigh in on this15:46
mordredcdent, elmiko: ^^ ?15:47
cdentI think putting creation and consumption in the same place is a good idea because it is more contextualized15:47
dtroyer++  separate sections in the same repo would be good with me, but having to look in multiple places to find thw whole story is just painful.  More than a few of us fit multiples of those categories15:54
dhellmannmordred : we're working through whether it makes sense to have separate guides in the discussion with asettle about the future of docs15:55
dhellmannmordred : one option is to have 1 sphinx job that publishes nicely organized docs, but only one thing15:56
dhellmannanother option is to have separate jobs, publishing different sets of docs to different places15:56
dhellmannthere's more of a legacy concern there, because we want to deal with redirects if we change how things are published15:57
dhellmannif this is new content, you don't have that concern15:57
dhellmannso a single sphinx project publishing nicely organized content is more appealing15:57
dhellmannedleafe, cdent, dtroyer : ^^15:57
cdentideally we'd see more places linking into the guidelines, and that makes even more sense if we're covering both creation and consumption15:58
edleafecdent: +116:01
elmikomordred: edleafe, just saw the ping. reading back16:04
elmikomordred: so, i more or less agree with cdent, edleafe and dtroyer. seems more useful to have things in a place that is easier to find16:06
elmikoi'm not sure what shape that would take, but i like the idea of being able to navigate between the different guideline types in a convenient fashion16:07
*** e0ne has quit IRC16:08
edleafeThe only one that seems out of place a bit is the version discovery algorithm16:11
edleafebut in the context of the others, it fits16:11
mordreddhellmann: there is also at least one thing in the service-types-authority consumption spec that assumes we can publish the service-types-authority data to a location that will be solid/stable/well-known. It's currently written up as "https://specs.openstack.org/service-types.json" - which I think a job in s-t-a to publish post-merge should be easy enough to implement16:12
dhellmannmordred: it feels a little odd to publish machine-readable data to the root of the specs site, but I think I get it16:13
mordreddhellmann: yah - we could also spin up a new domain/web root for that I imagine too16:13
* dhellmann shrugs16:13
* mordred shrugs too16:13
cdenti think specs could very well be fine: it's sort of like a spec16:13
dhellmannyeah, it's just a new precedent16:14
cdentand helps give it some ooomph16:14
* cdent shrugs, because he wants to play along16:14
mordrededleafe: maybe if we re-org that doc slightly more cleanly into "develop/deploy/consume" portions rather than "this is all the information you need about consuming versions - oh, also, deployers please take note of this bit" it'll be easier to read too?16:14
*** cmurphy has quit IRC16:14
* edleafe hurts his shoulder from shrugging too much16:18
edleafemordred: or maybe "here's where we are", "here's why we are in the state we are", and "here's where we really want to be"16:19
mordrededleafe: yes. "this is the description of the idea state" - "this is description of the complete current state including the ideal state" - "these are recommendations for people who would like to achieve future perfection"16:20
mordrededleafe, cdent, elmiko: WHILE I'VE GOT YOUR ATTENTION ...16:20
*** prg3 has quit IRC16:20
* edleafe runs off scared16:20
* cdent follows edleafe 16:21
*** prg3 has joined #openstack-sdks16:21
mordredmost of the services I've found in openstack with microversions implementations use the nova form of version/min_version rather than the API-WG recommendation of max_version/min_version ... including nova, cinder, manila and ironic - although it seems magnum and zun have the min_version/max_version form16:23
mordredI'm mostly curious about the decision to recommend min/max (since I wasn't paying attentoin then) and how much effort we think should go in to adding max_version to the services which just have version?16:24
*** jpich has quit IRC16:24
mordred(I started a patch to add a "collections" link as from the version discovery thing just to see how bad it was (not) which is what got me thinking about this specifically)16:25
elmikoiirc, some of these projects were impementing microversion while we were still arriving at the guideline, that combined with the "nova effect" (copy what nova did) did not help16:25
elmikoit would be cool to bring the project up to speed with the guideline, but i don't have a strong handle on how interested in taking on the tech debt they would be16:26
elmikowe don't get strong participation on a good day, it's just tough to know how the individual projects would feel about it16:26
sdaguewell nova, ironic, and manila were out the door before there ever was an api-wg recommendation16:27
elmikomy gut feeling is that it will be like herding a small pack of cats16:27
mordredI mean, from a consume perspective, any consumer is going to have to handle both choices no matter what for the forseeable future so it's not a super big deal there16:27
elmikosdague: exactly16:27
mordredsdague: yah16:27
edleafedoes anyone use max_version?16:28
elmikoimo, it would be nice, but we (api-wg) don't exactly have a habit of chasing folks down to implement the guidelines16:28
mordredmagnum and zun at least - I haven't taken full catalog yet16:28
*** ralonsoh has quit IRC16:28
*** salv-orlando has quit IRC16:28
cdentI thnk the change probably happeend because there's a conflict between the default version you get if you don't specific and the concept of "version"16:28
cdentI would expect "version" to mean "what i get if I say nothing"16:28
mordredelmiko: :) -- my next couple of months are going to be essentially chasing folks down to let me implement some of the guidelines ... so I'm kind of poking around the edges to figure out how it's gone so far16:29
cdentwhich would mean min_version16:29
elmikomordred: ooh! neat =)16:29
elmikoin that case, +1 to adding them16:29
mordredelmiko: wish me luck!16:29
* elmiko wishes mordred luck16:29
cdentso by being explicit about max, min, we avoid the confusion16:29
edleafehmmm... maybe add a note to the microversion guideline about the existing services that don't follow16:29
mordrededleafe: I can do that in one of my next passes through the stack16:30
edleafeyeah, I mean, I know nova will never change this, so we should at least acknowledge reality16:30
elmikoedleafe: good point16:30
cdentwe did manage to add support for openstack-api-version: compute x.y16:31
* mordred is very much a fan of acknowledging reality16:31
cdentso we may not ever remove the old way, but we can add the new way16:31
edleafecdent: true, so maybe there's hope :)16:31
* cdent takes a break16:33
*** salv-orlando has joined #openstack-sdks16:37
*** salv-orlando has quit IRC16:42
*** salv-orlando has joined #openstack-sdks16:47
mordredmugsie, sdague: the sub-elements patch has examples published herE: http://docs-draft.openstack.org/55/464255/5/check/gate-nova-api-ref-src/f02b170//api-ref/build/html/ - versions and list-sever-details are both good examples to look at for output16:53
mordredI don't feel super strongly about this at all - it was more a thing I've hit up against before reading the docs so I thought I'd take a random stab at it16:53
*** cmurphy has joined #openstack-sdks16:55
*** reedip_ has quit IRC16:56
sdaguemordred: ok looking16:57
sdaguemordred: have we gotten a read from horizon folks as to if they like this approach?16:57
sdagueI think it has definite advantages, we probably need a good glossary explaining how to read it (maybe if we had a footnote added to the bottom of every table automatically)16:58
mordredsdague: I have not poked any of them but I can - what's the specific tie to horizon? (I may be missing context)16:58
sdaguejust, they are folks that tend to read our api-ref16:59
sdaguehonestly, I just want other readers16:59
mordredah- gotcha. yes- they would be great additional inputs16:59
mugsieI agree with the problem statement - I am just not sold on the format16:59
mugsiewe could iterate that16:59
sdaguebecause I'm so steeped in this that I don't trust my judgement on better/worse16:59
sdagueif we had a couple of common consumers say "yes please", I'd be all for a "you betcha"17:00
* mordred will go poke folks17:00
mugsiemordred: where did the '[]' come from - for me that looks a bit wierd17:01
mordredI also am not sold on the format either- so feedback/suggestions from folks would be great17:01
mordredmugsie: servers is an array - so servers.name looked weird to me17:01
sdaguemugsie: it is to distinguish array vs. object attr17:01
sdaguewhich makes sense17:01
mordredyah. I also _think_ I got the idea from the GCE docs - but I might e lying about that17:01
*** reedip has quit IRC17:02
sdagueso, because json requires a top level key, I do wonder if we can shorthand past the first key17:02
mordredbut it doesn't17:02
mordredwe actually do have APIs in openstack that do not return top level keys17:02
sdague... o really....17:02
mordredyup. glance single version image discovery springs immediately to mind- but there are others - I could go look17:03
mordreds/image discovery/version discovery/17:03
mordredalso I believe swift capabilities17:04
*** reedip has joined #openstack-sdks17:09
*** reedip_ has joined #openstack-sdks17:15
openstackgerritcaoyuan proposed openstack/python-openstackclient master: Correct the "extra spec" command openstack  https://review.openstack.org/46512217:16
*** dtantsur is now known as dtantsur|bbl17:19
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystoneauth master: Allow setting EndpointReference in ADFSPassword  https://review.openstack.org/46343217:21
*** dtantsur|bbl is now known as dtantsur|afk17:26
*** annegentle has joined #openstack-sdks17:41
*** dasanind has quit IRC17:43
*** amit213 has quit IRC17:43
*** sindhu has quit IRC17:43
*** amit213 has joined #openstack-sdks17:45
*** dasanind has joined #openstack-sdks17:46
*** sindhu has joined #openstack-sdks17:47
*** annegentle has quit IRC17:51
*** bobh has quit IRC17:51
*** reedip has quit IRC17:53
*** salv-orlando has quit IRC17:54
*** salv-orlando has joined #openstack-sdks17:54
*** csterret_ has joined #openstack-sdks17:59
*** cbsterrett has quit IRC18:02
*** jkilpatr_ has joined #openstack-sdks18:17
*** annegentle has joined #openstack-sdks18:17
*** openstackgerrit has quit IRC18:17
*** jkilpatr has quit IRC18:20
*** bobh has joined #openstack-sdks18:21
*** annegentle has quit IRC18:41
*** bobh has quit IRC18:54
*** annegentle has joined #openstack-sdks18:58
*** annegentle has quit IRC19:22
*** salv-orlando has quit IRC19:28
*** csterret__ has joined #openstack-sdks19:30
*** csterret_ has quit IRC19:32
*** jkilpatr_ has quit IRC19:40
*** trevormc has joined #openstack-sdks19:48
*** chit has joined #openstack-sdks19:57
chitHi, could anybody give me a high-level overview of the openstackclient code base? As in, where the control flow starts, and what calls what first and when. Thanks :)19:58
dtroyerchit: the basic structure is defined by cliff, the library that provides the app and command objects in use: http://git.openstack.org/cgit/openstack/cliff19:59
dtroyeryou will need python-openstackclient and osc-lib source to walk through the shell and ClientManager objects that do all of the cenral coordination20:00
dtroyerspecific commands are dispatched via setuptools' entry points20:00
*** e0ne has joined #openstack-sdks20:01
chitSo when the client performs something like a "openstack server list", would the constructors defined in the cliff library get called? Would the App and Command objects get created from there?20:09
*** dave-mccowan has quit IRC20:10
*** markvoelker has joined #openstack-sdks20:11
dtroyerchit: yes they do20:13
*** bobh has joined #openstack-sdks20:13
dtroyercommand-wise, though, only for the command(s) being executed20:13
*** openstackgerrit has joined #openstack-sdks20:14
openstackgerritMerged openstack/keystoneauth master: Allow setting EndpointReference in ADFSPassword  https://review.openstack.org/46343220:14
*** fguillot has quit IRC20:19
*** exploreshaifali has joined #openstack-sdks20:24
*** trevormc has left #openstack-sdks20:27
*** salv-orlando has joined #openstack-sdks20:41
*** e0ne has quit IRC20:43
*** jkilpatr has joined #openstack-sdks20:53
*** bobh has quit IRC21:02
*** salv-orlando has quit IRC21:02
*** bobh has joined #openstack-sdks21:03
*** exploreshaifali has quit IRC21:04
*** prg3 has quit IRC21:05
*** prg3 has joined #openstack-sdks21:07
*** bobh has quit IRC21:08
*** jkilpatr has quit IRC21:19
*** chit has quit IRC21:40
*** jkilpatr has joined #openstack-sdks22:03
*** salv-orlando has joined #openstack-sdks22:03
*** csterret__ has quit IRC22:15
*** dave-mccowan has joined #openstack-sdks22:37
*** salv-orlando has quit IRC22:44
*** salv-orlando has joined #openstack-sdks22:50
*** adriant has joined #openstack-sdks22:56
*** gouthamr has quit IRC23:00
openstackgerritMonty Taylor proposed openstack/os-client-config master: Keep a singleton to support multiple get_config calls  https://review.openstack.org/46519523:14
*** cdent has quit IRC23:17
*** sdague has quit IRC23:21
*** gouthamr has joined #openstack-sdks23:24
openstackgerritMerged openstack/keystoneauth master: Add ADFSPassword to keystoneauth1 entry points  https://review.openstack.org/46323423:33
*** gildub has joined #openstack-sdks23:55

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