Thursday, 2019-08-29

openstackgerritMerged openstack/python-openstackclient master: Remove token_endpoint auth type
*** enriquetaso has quit IRC00:47
*** slaweq has joined #openstack-sdks01:11
*** slaweq has quit IRC01:15
*** ricolin has joined #openstack-sdks01:48
openstackgerritBrin Zhang proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve
*** ricolin has quit IRC02:04
*** ricolin has joined #openstack-sdks02:05
*** slaweq has joined #openstack-sdks02:11
*** slaweq has quit IRC02:16
openstackgerritBrin Zhang proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve
*** ricolin has quit IRC02:32
*** ricolin has joined #openstack-sdks02:32
*** openstackgerrit has quit IRC02:37
*** ricolin has quit IRC03:21
*** gkadam has joined #openstack-sdks03:50
*** gkadam has quit IRC03:50
*** adriant has quit IRC04:05
*** adriant has joined #openstack-sdks04:05
*** slaweq has joined #openstack-sdks04:11
*** slaweq has quit IRC04:16
*** dave-mccowan has quit IRC04:41
*** openstackgerrit has joined #openstack-sdks05:02
openstackgerritDean Troyer proposed openstack/python-openstackclient master: Bump min osc-lib to 1.14.0
*** Luzi has joined #openstack-sdks05:05
openstackgerritDean Troyer proposed openstack/python-openstackclient master: Clean up app initialization and config
*** adriant has quit IRC05:10
*** adriant has joined #openstack-sdks05:11
*** factor has joined #openstack-sdks05:51
*** slaweq has joined #openstack-sdks06:11
*** slaweq has quit IRC06:16
*** ricolin has joined #openstack-sdks06:38
*** slaweq has joined #openstack-sdks06:58
*** gtema has joined #openstack-sdks07:17
*** tosky has joined #openstack-sdks07:23
*** slaweq has quit IRC07:27
*** slaweq has joined #openstack-sdks07:31
*** jpena|off is now known as jpena07:40
*** jpich has joined #openstack-sdks07:42
openstackgerritTakashi Kajinami proposed openstack/python-openstackclient master: Add parent project filter for listing projects
openstackgerritTakashi Kajinami proposed openstack/python-openstackclient master: Add parent project filter for listing projects
openstackgerrityanpuqing proposed openstack/openstacksdk master: Modify the 'auth_type' value to correct
*** ralonsoh has joined #openstack-sdks08:04
*** e0ne has joined #openstack-sdks08:11
*** cdent has joined #openstack-sdks08:18
*** e0ne has quit IRC08:20
*** ITD27M01 has joined #openstack-sdks08:30
*** e0ne has joined #openstack-sdks08:34
*** e0ne has quit IRC08:59
*** gtema has quit IRC09:09
*** gtema has joined #openstack-sdks09:26
*** e0ne has joined #openstack-sdks09:27
*** e0ne has quit IRC09:27
*** gtema has quit IRC09:29
*** gtema has joined #openstack-sdks09:33
ITD27M01gtema: Hello! Could you advise on unscoped authentication.09:57
ITD27M01I would like to get a list of the current user's projects by calling the: connection function.identity.user_projects(user=user_id) On new versions of the SDK it works okay, but on older version (0.17.2) I get the error: EmptyCatalog: The service catalog is empty. Is there some workaround for this bug in older versions?09:57
ITD27M01The clouds.yaml is
ITD27M01For openstacksdk==0.35.0 it works fine:
ITD27M01But for older version (0.17.2):
gtemainteresting. Was not seeing this.09:59
gtemaare you stuck with an old version?10:00
gtemacan you please also show the trace itself?10:01
*** Kl4us1912 has joined #openstack-sdks10:01
ITD27M01gtema: I am stuck with an older version shipped with RHEL 7 rpms, the full traceback:
Kl4us1912can openstacksdk get a Connection.get_project_by_id method (similar to get_user and get_user_by_id).10:17
Kl4us1912use case is querying one's own project without having the list projects permission10:17
Kl4us1912i implemented a workaround by copying and slightly modifying get_user_by_id10:19
gtemaitd27m01: actually you should use not the unscoped, but domain scoped token. Then it is expected, that service catalog is properly populated10:19
ITD27M01gtema: How I can change my clouds.yaml for this?10:20
gtemayou remove project_name/id and set domain_id/name=user_domain_id/name (so really both)10:21
*** e0ne has joined #openstack-sdks10:21
gtemafor me it is defining user_domain_name AND domain_name with same values10:21
*** dtantsur|afk is now known as dtantsur10:24
ITD27M01gtema: With domain_name + user_domain_name I get the 401 Error. But only user_domain_name works. Is it policy caveat?10:25
gtemaprobably yes10:25
gtemait's a funny case how you configure, so that libs get domain scoped token. And normally it is absence of project and presence of domain data10:26
gtemauser_domain_name is used kind of for authorization agains cloud at all, but domain - to get a domain token10:27
*** e0ne has quit IRC10:27
gtemaif you get 401 maybe you are missing privs. But then the question why it works with newer SDK10:27
gtemathere were tons of changes, so figuring out what is different will be a challenge10:28
gtemacan you trace newer SDK to understand which token is retrieved? I do not believe you can get list of projects with unscoped token10:30
ITD27M01gtema: The purpose of my code is to provide to users the list of their projects. If I understand this correctly the domain scoped token only available for admins but unscoped token available for everyone authenticated.10:31
ITD27M01gtema: I see that service_catalog is empty for newer SDK too. But the method connection.identity.user_projects(user=user_id) works10:32
gtemacan you compare the endpoints for requests?10:33
gtemaor maybe the problem is not the SDK, but keysoneauth1?10:33
gtemaif you stuck with older versions it might be a problem10:33
gtemain this case you might try hardcoding endpoint (for single region cloud should be normally not a problem)10:34
ITD27M01gtema: In virtualenv the keystoneauth1 is the same10:34
ITD27M01gtema: In the long term I want to build rpm for new releases of openstacksdk. Perhaps there is already such a repository?10:35
gtemaeeh, this is a problem for everyone. I myself build RPMs for our cloud in OpensuseBuild10:36
gtemabut you can look for RDO packages10:36
ITD27M01gtema: For stein the 0.27.0 is available I will check it10:39
ITD27M01gtema: BTW by tracing the call I need to find the source of the identity url?10:40
gtemaif nothing works you can try doing conn.identity.get('YOUR_KEYSTONE_URL/v3/user_id/projects')10:40
gtemayou can see this in the project_scoped token response10:40
gtemait's only that this API need to be allowed for the user10:41
gtemaalternatively /v3/auth/projects10:42
gtemathis last might be available with unscoped token10:43
ITD27M01gtema: conn.identity.get('{}/v3/user_id/projects'.format(conn.auth['auth_url'])) ?10:45
gtemaalmost - {}/v3/users/REQUESTED_USER_ID/projects10:46
gtemaor really conn.identity.get('users/{}/projects')10:48
gtemares = conn.identity.get('users/%s/projects' % conn.current_user_id)10:52
ITD27M01gtema: projects = connection.identity.get('{auth_url}/v3/users/{user_id}/projects'.format(auth_url=str(connection.auth['auth_url']), user_id=str(user_id))) - this works for me. But without auth_url this return the same catalog is empty10:55
ITD27M01gtema: Thank you10:55
gtemaand if you connect as default project?10:55
ITD27M01gtema: Hm, what is default project? The project defined in clouds?10:56
gtemayeah, in your domain there is root project10:57
gtemai will try something in 10 minutes10:57
*** e0ne has joined #openstack-sdks11:00
*** gtema has quit IRC11:01
*** gtema has joined #openstack-sdks11:04
*** gtema_ has joined #openstack-sdks11:11
ITD27M01gtema: I am checking now and found that simple call (connection.identity.user_projects(user=user_id)) works in at least 0.28.0. In 0.27.0 it does not work yet11:14
gtema_well, if this works - cool. I can't actually connect to the my cloud without specifying project or domain11:14
ITD27M01gtema: Ok, thank you11:18
*** dave-mccowan has joined #openstack-sdks11:18
*** e0ne has quit IRC11:20
gtema_btw: conn.session.get('{auth_url}/auth/projects'.format(auth_url=str(conn.auth['auth_url']))) might be a 'cleaner' solution11:21
gtema_or including /v3 - depending what is your case11:22
*** e0ne has joined #openstack-sdks11:23
*** e0ne has quit IRC11:32
*** jpena is now known as jpena|lunch11:35
*** e0ne has joined #openstack-sdks11:40
*** gtema_ has quit IRC11:42
*** gtema_ has joined #openstack-sdks11:43
*** cdent has quit IRC11:47
*** gtema_ has quit IRC11:49
*** gtema_ has joined #openstack-sdks11:53
*** gtema_ has quit IRC11:54
*** gtema_ has joined #openstack-sdks11:56
*** cdent has joined #openstack-sdks12:00
*** gtema_ has quit IRC12:09
*** e0ne has quit IRC12:11
*** gtema_ has joined #openstack-sdks12:26
*** cdent has quit IRC12:35
*** gtema has quit IRC12:40
*** jpena|lunch is now known as jpena12:41
*** Kl4us1912 has quit IRC12:44
*** Luzi has quit IRC12:44
*** cdent has joined #openstack-sdks12:45
ITD27M01gtema: I got it!
ITD27M01gtema: The auth_url is used for identity service in the case of unscoped token12:54
gtema_aah, yeah12:54
ITD27M01this change12:54
*** enriquetaso has joined #openstack-sdks13:00
*** mriedem has joined #openstack-sdks13:07
*** zbr has quit IRC13:08
*** zbr has joined #openstack-sdks13:16
*** e0ne has joined #openstack-sdks13:40
*** e0ne has quit IRC13:43
*** efried is now known as efried_afk13:47
*** dave-mccowan has quit IRC13:54
*** dave-mccowan has joined #openstack-sdks13:54
*** mordred has quit IRC13:57
*** mordred has joined #openstack-sdks13:59
*** e0ne has joined #openstack-sdks14:22
*** Kl4us1912 has joined #openstack-sdks14:31
*** ITD27M01 has quit IRC14:55
*** efried_afk is now known as efried15:13
*** e0ne has quit IRC15:14
* elmiko waits anxiously15:59
elmikoAPI SIG office hours now starting, grab yer popcorn!16:00
openstackgerritMatt Riedemann proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve
edleafeI was waiting for you to type something :)16:00
gtema_oh, yeah. It's again happy hour16:00
elmikohaha, i kinda felt so after about 10 seconds16:01
elmikothis hour brought to you by our undying love for edleafe =)16:01
edleafeOh, that's rich!16:01
elmikois dtantsur around?16:05
elmikoi kinda wnat to talk about the suggestions that came up on the ml16:05
elmikolike, should we spend some time over the next week or two to triage all the todos and reviews?16:05
dtantsurthe only reason we haven't done it already is that nobody has time for it16:05
elmikowith the goal being to clean up things that we won't get to, or have shifted scope significantly16:05
elmikoi'm gonna take an action to make some progress there16:06
dtantsurI'm open to an hour of a call to try tackle it16:06
dtantsurI think a general "let's do it" won't help :)16:06
elmikohow about this, i will start by going through the open reviews and adding my thoughts about them to each16:06
elmikomaybe next week during the hour we can go through and just make some decisions about keeping them open, closing, or w/e16:07
elmikook, cool16:07
elmikogtema_: i am happy to include you in any of this if you would like?16:07
dtantsurof course he would :)16:07
edleafeThey aren't so much "ToDos" as they are "We know there's a gap here"16:08
gtema_hehe, dtantsur - you own me a review16:08
elmikoedleafe: ++16:08
dtantsurreally? you owe me a beer!16:08
elmikoi'm not sure what to do about the todos16:08
dtantsur(I'm in DUS starting next week, so do your math!)16:08
gtema_I am not in DUS, was there already 2 times last week and not willing to go again - too crowded16:08
elmikoi wonder if we could replace the todos with some specific language about there not being any guidance yet? is that any better than just a "todo"16:09
gtema_but I am on DOST in Sept in Berlin. Are you there?16:09
dtantsurgtema_: in in Dusseldorf the whole September probably16:09
dtantsuranybody going to OpenInfra Nordics?16:09
gtema_beh was not to Nordics16:09
dtantsurI may end up here mid-September, depending on various circumstances16:10
gtema_I'm not - only "Deutsche OpenStack Tage"16:10
dtantsurbut my primary goal is to find a flat in DUS asap16:10
* dtantsur is presenting on OpenInfra Nordics16:10
elmikoooh, nice dtantsur !16:10
*** jpena is now known as jpena|off16:11
dtantsurelmiko: I suggest we file a bug per each TODO and then follow the same process16:11
dtantsurfix it OR close and remove the todo16:12
elmikoi feel like that is where we are stuck though, the "fix it or forget it" stage16:12
elmikobut, i like the idea of making some bugs to track this better16:12
elmikowell, maybe not better, but just not in the docs themselves16:12
elmikoso, it's a long holiday weekend here in the states, but i will make some actions next week when i return16:14
gtema_Guys, what do you think about API header “Accept: “? It does not make any sense from my POV and due to some patch/API Gateways in front some of the requests to Swift in my cloud are failing.16:15
efriedmerge enormous doc patches, even though they're known to be incomplete, as long as they're at least largely technically accurate. open bugs for known gaps therein.16:15
dtantsurgtema_: in what context? in some contexts it does make sense16:15
dtantsurefried: ++ that's what we're discussing16:16
gtema_i.e. HEAD request16:16
elmikoefried: my concern here is removing the "TODO" language from the docs and migrating that into bugs16:16
gtema_currently in SDK we enforce "Accept: " for head requests and for create object16:16
efriedI like the idea of keeping TODOs in docs, because they're more likely to be noticed by people consuming the docs, and more noticed is more likely to be acted upon.16:16
elmikoefried: ahh, i see though, you are saying we should push through some of these long standing doc patchs?16:16
efriedyes elmiko, this ^16:17
efriedThey're stagnant because they're so huge that nobody wants to review them.16:17
elmikomy only problem with that notion is that they have been there for a long time and no one has acted on them16:17
dtantsurI'm not convinced anybody will ever fix TODOs that we don't fix16:17
elmikothe todos that is16:17
elmikodtantsur: ++16:17
efriedthat doesn't mean we should get rid of them16:17
efriedthat would be like denying that the gaps exist.16:17
dtantsurgtema_: sending Accept without expecting a body is certainly weird16:17
efriedIf nobody cares about the gaps, then indeed nobody will close them. But that doesn't mean they don't exist.16:18
elmikoi would prefer changing the language from "TODO" to something more reflective of our actual position though.16:18
dtantsuryeah, maybe we should change the syntax to something more user-friendly and saying "The API SIG doesn't currently have a guidance on ..."16:18
elmikoat least let folks know that we have been unable to agree on, or generate guidance for those todos16:18
dtantsura raw TODO in text may give an impression that we're working on it16:19
dtantsurwhile we're not working :)16:19
elmiko"todo" sounds like we might actually get around to it16:19
elmikodtantsur: yes!16:19
dtantsurelmiko: are you reading my thoughts???16:19
gtema_dtantsur: that's what we do. But it is something more general, that from the API pov there are no real guidance16:19
* elmiko concentrates16:19
efriedConsider a new16:19
efried.. help-wanted::16:19
elmikothat's a nice thought efried16:19
dtantsurthat would be ideal16:19
efriedstephenfin could work that up for us in all his spare time.16:19
edleafeelmiko: "todo" sounds like there is a plan to actually get around to it :)16:20
elmikoedleafe: exactly, i want to be more transparent16:20
elmikoefried: i would be happy with a "help wanted" plus changing the todo language to something more honest16:20
elmikowell, more reflective of our actual intentions16:21
dtantsurand maybe some rough ideas on what a guidelines could look like16:21
efriedI didn't want to get into this on the ML, but I don't like the idea that "if nobody is asking it must not be important".16:21
stephenfin.. admonition:: Help wanted16:21
dtantsur"We don't know for sure, but something in spirit of RFC XYZ"16:21
stephenfin    Stuff.16:21
elmikoefried: ++, that's a good thought to capture16:21
efriedstephenfin: cool, I had a feeling there might be something existing that would work.16:21
elmikothey _are_ important, but we have failed as a sig to arrive at any guidance on those topics16:22
dtantsurtripleo-docs uses admonitions quite actively, we can check how they do it16:22
elmikodtantsur: ++16:22
efriedAll too often people just give up because it's too hard or time consuming or soul-sucking to continue complaining about stuff that's been TODO f'rever.16:22
dtantsurif we had one person per each big project.. cough-cough16:22
* efried suddenly has somewhere else to be16:23
efriedIt's just that we're all stretched so thin16:23
efriedunfortunately docs always end up being a thing that suffers, falls off the bottom.16:23
dtantsuryep. and dev docs is the least liked kind of docs16:23
elmikoi feel like even migrating from TODO to "we could use help here but have no guidance currently" is at least more reflective of where we are at16:23
edleafeSo like elmiko said, let's be transparent about that16:24
dtantsurvery much agreed16:24
efriedso anyway, the path of least resistance but biggest effect IMO is to keep the TODOs (with help-wanted admonition makeover if desired) and keep them in front of people's faces (i.e. keep them in the docs).16:24
elmikocool, i have _some_ time (he said sheepishly), i'll take the lead on geting something moving16:24
elmikoefried: ack, we won't take them out but i would really like to make them more explicit16:25
efriedwe are all in violent agreement16:25
elmikowe can argue about the details on review ;)16:25
dtantsuroh we can :)16:25
efriedalso, consider merging the massive-doc-patches as is and refacing the TODOs in subsequent patches.16:25
* dtantsur unpacks his nitpicker16:25
dtantsurefried: also true. especially with the version discovery monster.16:26
gtema_oj, the nitpicker of dtantsur is a killer bomb ;-)16:26
efriedbecause there's a mental barrier to re-reviewing a 1KLOC patch.16:26
elmikoefried: yes, i will make notes about this when i triage next week. if those patches are in good enough shape to merge i will weigh that heavily in my comments.16:26
efriedregardless of how small the inter-patch delta is.16:26
elmikoefried: ++16:26
*** jpich has quit IRC16:26
efriedespecially with docs, as long as the patch moves the ball forward and doesn't introduce actual inaccuracies, we should be able to be much less perfectionist about merging16:27
efriedit's not like we're going to introduce a security regression or something.16:27
efriedbreak CERN's deployment.16:27
elmikoi think we've just been really nitpicky about getting the details correct16:28
elmikoand that version discovery beast is tough to wrangle16:28
efriedno joke16:28
elmikoespecially when we stay true to our processes and ask for input from the community16:28
elmikoefried: so that's a question i have though. we have clear guides about how we will merge changes, i don't think it's a good idea to break them /but/ we do open ourselves up to drive by -1's when we do this and that throws the whole process off. any suggestions?16:29
efriedclear guides written for different times; we should have the temerity to alter those processes.16:30
efriedA number of teams are, out of necessity, moving to single-core approvals. Not saying thats' a good idea here necessarily, just that it's a thing.16:31
elmikoappreciate all the feedback, it is helpful16:31
dtantsurand the version discovery one doesn't have -1's16:31
elmikodtantsur: ++16:31
dtantsurso strictly speaking we can approve it16:31
elmikocool, maybe we just do that16:31
elmikogive it one more read through to make sure there are not glaring errors16:32
efriedYeah, for something like this, if it's clear it's been thoroughly reviewed by people with at least some understanding of the content, it's reasonable to proxy their +1 as a +2 when there's a dearth of cores available.16:32
efriedIIRC I went through one or more of those enormous patches and +1ed.16:32
efriedI consider myself at least somewhat up on version discovery.16:32
efriedand changes since my +1 have been minimal, so feel free to carry those forward.16:33
elmikoack, thanks16:33
elmikois it time for cake and punch?16:33
gtema_I was missing in the version discovery rules on what is open and what requires AUTH. This got lost in some restructuring16:34
elmikogtema_: definitely add comments if you can figure out where it was16:34
gtema_did it already16:34
gtema_long time ago16:34
gtema_but that is the point - there are way to many to see the overview16:34
elmikook, cool. i will inevitably come across them ;)16:34
elmikoyeah, i'm gonna carve out like half a day for going reviewing these16:35
dtantsurI've seen gtema_'s comments, just never got to fixing them16:35
elmikook, maybe i can help16:35
dtantsurand again, I'd prefer to fix in a follow-up16:35
elmikoif there are easy fixes though, i will try to just add them16:36
gtema_dtantsur: what do you think about
gtema_can we change it to "Accept: *"?16:42
gtema_empty value is somehow not RFC-nice16:43
dtantsurgtema_: I wonder why we send *anything* if we don't expect a body16:46
dtantsurHEAD + Accept doesn't make sense to me16:46
gtema_well, some APIs might return a body16:46
dtantsurto HEAD?? Oo16:46
gtema_or, no16:47
gtema_looked to the wrong section16:47
gtema_I would suggest either remove it completely, or set a "*"16:47
gtema_not an empty value16:47
edleafeA HEAD with a body is, well, a whole person16:48
dtantsurI'd remove it16:49
gtema_ok, will do.16:49
dtantsurand see if mordred complains16:49
gtema_and now PUT, which might return body, but contain no body in request (swift create object)16:49
dtantsurAccept is related to returned body, right?16:50
elmikodtantsur: the ultimate test ;)16:50
dtantsurso if you expect that a body might be returned, you should be sending Accept16:50
dtantsur(although the exactly value depends on the call)16:50
gtema_yeah, but not the "Accept: ", at least "Accept: *" or "Accept: application/json"16:50
dtantsurprobably the default should be Accept:* or no accept16:50
gtema_this empty value is what breaks it for me16:51
dtantsurthen everything except for swift should use Accept: application/json16:51
timburkefwiw, requests adds an "Accept: */*" header by default. if i had to guess, i'd say the empty was trying to prevent that, but i don't know why16:51
gtema_my small test was not confirming that - after removing this empty there was nothing at all16:52
timburkeif you really want to drop the header entirely, you could try {'Accept': None}16:52
dtantsurI'm not sure why we would want that16:52
dtantsurI would expect that no header is equivalent to Accept:*/*16:52
gtema_this is also how I interpret RFC16:53
timburkei know that i've done that for Accept-Encoding before, where swiftclient will freak out a bit if requests goes and decompresses object data as it's getting downloaded16:53
dtantsurgtema_: propose a fix and see if anybody complains16:53
edleafe"Accept: None" should mean "don't return *any* body in the response"16:53
dtantsurtimburke: but it's swiftclient specific, right? not openstacksdk?16:53
gtema_exactly SDK16:53
elmikoi don't want to break up the accept discussion too much, but before we end the office hour i /do/ want to thank edleafe one more time. he has been a pillar of this community and i personally have learned a great deal from him. thank you again Ed =)16:54
gtema_yeah, thanks Ed16:54
edleafeI am going to miss hanging out with all of you. Even elmiko!16:55
elmikohehehe <316:55
dtantsurthanks you edleafe!16:55
timburkei'm not sure what you guys do when downloading object data ;-) i know swiftclient wants to do some checksumming, which'll require the raw (compressed, if it was stored compressed) stream16:55
dtantsurgood question16:55
gtema_there is hell amount of logic16:56
gtema_at least for uploading16:57
gtema_for downloading we also set "Accept: bytes"16:58
gtema_but we do not do download checksumming17:01
elmikoi'm heading out for the weekend, take care all o/17:01
*** e0ne has joined #openstack-sdks17:02
gtema_yeah, EOD for me as well. See ya tomorrow17:02
timburkegtema_, curious! good thing swift doesn't do anything with that. we'd 400 it for container listings, complaining "Invalid Accept header"17:02
* dtantsur leaves as well17:03
*** dtantsur is now known as dtantsur|afk17:03
gtema_timburke: thanks for hint. Will try to check that tomorrow17:03
*** cdent has quit IRC17:03
*** e0ne has quit IRC17:04
*** gtema_ has quit IRC17:04
*** e0ne has joined #openstack-sdks17:04
*** e0ne has quit IRC17:04
*** gtema has joined #openstack-sdks17:05
*** gtema has quit IRC17:09
*** enriquetaso has quit IRC17:21
*** e0ne has joined #openstack-sdks17:35
*** e0ne has quit IRC17:35
*** ralonsoh has quit IRC17:43
*** ricolin has quit IRC17:55
*** e0ne has joined #openstack-sdks18:29
*** Kl4us1912 has quit IRC18:30
*** e0ne has quit IRC18:32
*** e0ne has joined #openstack-sdks18:55
*** enriquetaso has joined #openstack-sdks19:01
*** e0ne has quit IRC19:01
*** e0ne has joined #openstack-sdks19:03
*** slaweq has quit IRC19:04
*** e0ne has quit IRC19:04
*** e0ne has joined #openstack-sdks19:05
*** e0ne has quit IRC19:05
*** slaweq has joined #openstack-sdks19:11
*** slaweq has quit IRC19:15
*** enriquetaso has quit IRC19:21
*** enriquetaso has joined #openstack-sdks19:21
*** enriquetaso has quit IRC19:44
*** slaweq has joined #openstack-sdks19:59
*** slaweq has quit IRC20:04
*** slaweq has joined #openstack-sdks20:10
*** slaweq has quit IRC20:16
*** factor has quit IRC20:42
*** factor has joined #openstack-sdks20:42
*** icarusfactor has joined #openstack-sdks20:53
*** factor has quit IRC20:54
*** gtema has joined #openstack-sdks21:05
*** gtema has quit IRC21:10
*** slaweq has joined #openstack-sdks21:10
*** slaweq has quit IRC21:15
*** brtknr has quit IRC21:22
*** brtknr has joined #openstack-sdks21:23
*** slaweq has joined #openstack-sdks22:11
*** brtknr has quit IRC22:11
*** slaweq has quit IRC22:15
*** tosky has quit IRC22:29
openstackgerritBrin Zhang proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve
openstackgerritBrin Zhang proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve

Generated by 2.15.3 by Marius Gedminas - find it at!