Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-10-19
14:55:19 kmalloc All doable with simple wsgiref webtest app.
14:56:00 kmalloc You're looking to do a simple reflector thing :)
14:56:09 mordred you're a simple reflector thing
14:56:42 dtantsur lol
14:59:08 mordred kmalloc: this is more moist than I prefer
14:59:45 kmalloc I suggest a lemur dryer then ;)
15:45:23 mnaser mordred: i was just hit by this .. https://github.com/ansible/ansible/pull/42913 -- do you mind giving it another shipit if it makes sense to you?
15:45:36 mnaser cc Shrews rcarrillocruz ^
15:55:14 mordred mnaser: seems reasonable - but also that kinda feels like a default behavior sdk should have on the backend
15:55:34 mordred oh - wait- I misread soemthing
16:09:31 mnaser mordred: in this case a cloud with multiple users having “admin” would fail (in different domains)
16:09:54 mnaser mordred: thank you!
17:07:42 kmalloc mordred: the limits code for SDK looks correct
18:17:58 mordred kmalloc: yay!
#openstack-sdks - 2018-10-20
11:03:51 openstackgerrit Yuval Shalev proposed openstack/openstacksdk master: Added assign function to identity proxy https://review.openstack.org/612006
11:08:05 openstackgerrit Yuval Shalev proposed openstack/openstacksdk master: Added assign function to identity v3 proxy https://review.openstack.org/612006
14:14:46 openstackgerrit Yuval Shalev proposed openstack/openstacksdk master: Added assign function to identity v3 proxy https://review.openstack.org/612006
#openstack-sdks - 2018-10-21
02:17:45 openstackgerrit Daniel Speichert proposed openstack/openstacksdk master: Fix upload of Swift object smaller than segment limit (create_object) https://review.openstack.org/612113
12:43:27 openstackgerrit Maxim Babushkin proposed openstack/openstacksdk master: Add vnic_type to create_port valid kwargs https://review.openstack.org/612162
13:33:12 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add support for per-service rate limits https://review.openstack.org/604521
15:26:09 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Replace TaskManager with a keystoneauth concurrency https://review.openstack.org/604926
15:26:09 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add support for per-service rate limits https://review.openstack.org/604521
15:30:14 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Don't start task managers passed in to Connection https://review.openstack.org/612186
15:43:34 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Don't start task managers passed in to Connection https://review.openstack.org/612186
15:54:49 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Replace TaskManager with a keystoneauth concurrency https://review.openstack.org/604926
15:54:49 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add support for per-service rate limits https://review.openstack.org/604521
15:59:19 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Replace TaskManager with a keystoneauth concurrency https://review.openstack.org/604926
18:03:43 samueldmq a few weeks ago we had a discussion around some clouds that use radosgw implementing swift APIs in OpenStack deployments
18:04:14 samueldmq we concluded that we don't need to support radosgw in SDK, and that's the very right thing aligned with OpenStack principles
18:04:44 samueldmq OpenStack Primarily Produces Software: '[...] We expect people who say they run “OpenStack” to run the software produced by and in the community, rather than alternative implementations of the API.'
18:04:52 samueldmq #link https://governance.openstack.org/tc/reference/principles.html
18:04:56 samueldmq just fyi
18:15:48 mordred samueldmq: well - we actually do support people running radosgw - and are using sdk to talk to both swift and radosgw in the upload-to-swift ansible role for swift
18:16:41 mordred samueldmq: I agree with the principle in general (I think I helped write it) - but in this case it's not clear to a user of an openstack cloud whether the cloud in question is running swift or radosgw - for the most part the differences have been reasonably minor
18:18:11 samueldmq mordred: interesting. for the user I agree it's not fair to say "I can't talk to that cloud because t does not meet the OpenStack principles, please talk to the cloud provider"
18:19:10 mordred yeah. similarly we have several piecesof logic in sdk to support weird behaviors in rackspace public cloud that also aren't *really* openstack
18:19:23 samueldmq but we also need to be careful how far that goes, for now it's just one in the future might be multiple code saying they support our apis
18:19:31 mordred samueldmq: but I think in each case we have to make a judgement call about whether or not we're going too far
18:19:33 mordred samueldmq: ++
18:19:40 mordred exactly
18:20:07 mordred like - we got a patch a couple of years ago from someone who wanted to support availability zones in a bunch of objects where openstack does not actually supportthem
18:20:25 mordred and we rejected that - because it was actually changing semantics of the cloud in an incompatible way
18:20:32 samueldmq mordred: in that specific case I had a test that did deleted(resoure)->get(resource) and it was not returning the exception we expected as per the swift api. it returned 200.
18:21:23 mordred samueldmq: yah- I think I remember that - and I don't know that we can do much more to work around that - because if the cloudreturns 200 when an object isn't there ...
18:21:29 samueldmq mordred: nice, that's a good case. looks like we should write down that somewhere in our docs
18:21:48 mordred ++ totally agree
18:22:09 samueldmq mordred: it's broken :-) we may even work around some services that are widely adopted (ceph radosgw and rackspace).. but not around craziness
#openstack-sdks - 2018-10-22
08:47:13 openstackgerrit Vishakha Agarwal proposed openstack/python-openstackclient master: Updated the take_actions for unified limits https://review.openstack.org/612283
08:50:33 openstackgerrit Vishakha Agarwal proposed openstack/python-openstackclient master: Updated the take_actions for unified limits https://review.openstack.org/612283
10:46:09 dtantsur mordred: hi! what if we start putting the old microversion headers to https://service-types.openstack.org/service-types.json ?
10:47:04 dtantsur I'm just trying to understand how I know X-OpenStack-Ironic-Api-Version from just "baremetal"
10:48:05 dtantsur though maybe I should use service_types_by_project hmmm
10:48:08 cdent old microversion headers --
10:48:12 cdent ;)
10:48:14 dtantsur ikr?
10:48:24 dtantsur but even nova did not use the new one from the beginning
10:49:05 cdent I'm not sure that nova has fully bought in to the new way, thus just happen to accept it because i put the code in
10:49:41 dtantsur heh
10:49:52 dtantsur oh, I don't need service_types_by_project, I need project_by_service_type :(
11:09:35 openstackgerrit Maxim Babushkin proposed openstack/openstacksdk master: Add vnic_type to create_port valid kwargs https://review.openstack.org/612162
11:18:28 openstackgerrit Maxim Babushkin proposed openstack/openstacksdk master: Add vnic_type to create_port valid kwargs https://review.openstack.org/612162
12:23:11 mordred dtantsur|brb: if you're using python, keystoneauth should be sending both old and new style headers for you already
12:50:29 mordred dtantsur|brb: oh - you're talking about service-types.json - I'm guessing maybe for the rust client ... yeah, os-service-types has a bunch of methods for stuff like that
13:04:32 dtantsur mordred: well, I'm not talking about Python :)
13:22:33 mordred dtantsur: yah ... I was thinking that might be the case :)
13:22:46 dtantsur :)
13:23:19 mordred dtantsur: http://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/session.py#n66
13:23:27 mordred dtantsur: that's what keystoneauth does to handle it
13:23:28 dtantsur I'd like to get rid of such explicit stuff: https://github.com/dtantsur/rust-openstack/blob/master/src/compute/base.rs#L341-L346
13:23:40 dtantsur OMG
13:24:19 mordred dtantsur: in ksa we decided to not spend to much time to make it elegant since it was just backwards-compat for 2 services
13:24:29 dtantsur so, all other services use the new form?
13:24:32 mordred (and didn't want to inspire anybody new to use the old thing)
13:24:38 mordred dtantsur: to my knowledge, yes
13:24:48 dtantsur okay, ugly hack be it :D
13:25:41 mordred \o/
13:54:42 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Replace TaskManager with a keystoneauth concurrency https://review.openstack.org/604926
13:54:42 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add support for per-service rate limits https://review.openstack.org/604521
14:20:27 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Stop running shade tests https://review.openstack.org/612407
15:10:59 openstackgerrit Merged openstack/openstacksdk master: Don't start task managers passed in to Connection https://review.openstack.org/612186
19:42:49 smcginnis I'm looking at a different command. For command.Lister commands there is the mechanism to provide better display names than the raw returned names. Is there something similar for command.ShowOne commands?
21:42:08 dtroyer smcginnis: no there isn't but cliff might like an optional one. IIRC it would basically be rewriting the data dict with new keys (its been a while, I hope I'm remembering that right)
21:42:32 smcginnis OK, that's what I figured walking through things. I think I have sort of a workaround.
21:42:44 smcginnis We'll see if it's too hacky. ;)
23:30:55 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Use python3 format syntax for citycloud https://review.openstack.org/612536
#openstack-sdks - 2018-10-23
07:11:21 ml mordred: thanks for the +2
12:29:20 openstackgerrit Dmitry Tantsur proposed openstack/keystoneauth master: Make new-style single endpoint version discovery actually work for ironic https://review.openstack.org/612680
12:30:07 dtantsur mordred: should fix the bifrost CI when released ^^^
12:31:09 dtantsur TheJulia ^^^
15:41:31 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Add volume backup import/export commands https://review.openstack.org/612735
16:47:32 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Remove deprecated volume commands and args https://review.openstack.org/612751
16:53:38 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Update release note version reference table https://review.openstack.org/612754
17:06:14 openstackgerrit Merged openstack/keystoneauth master: Make new-style single endpoint version discovery actually work for ironic https://review.openstack.org/612680
19:04:39 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Remove deprecated compute commands https://review.openstack.org/612781
20:40:53 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Remove deprecated identity commands and args https://review.openstack.org/612798
20:45:25 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Remove deprecated volume commands and args https://review.openstack.org/612751
#openstack-sdks - 2018-10-24
01:18:16 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Remove deprecated identity commands and args https://review.openstack.org/612798
02:52:33 openstackgerrit Monty Taylor proposed openstack/keystoneauth master: Add missing release note for ironic discovery fix https://review.openstack.org/612872
12:23:03 peschk_l Hello everybody, I'm from the cloudkitty team. In the last releases, we changed the way cloudkitty processes data. In consequence, we need to implement a new API. I saw on the wiki that the API workgroup holds two office sessions every thursday on this channel. Would these be the right place to ask some questions ? If so, are tomorrow's sessions maintained ? If not, where should I ask ? Thank you for your help
13:23:14 edleafe peschk_l: Office hours are the best times to engage with the API-SIG in IRC. If they aren't convenient for you, then an email with [api-sig] in the subject will also work.

Earlier   Later