| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-11-06 | |||
| 14:34:40 | mordred | dtantsur: ++ | |
| 14:34:49 | Shrews | swift actually handles this very well, too | |
| 14:35:17 | Shrews | yeah yeah, i know | |
| 14:35:27 | Shrews | i was curious | |
| 14:35:49 | Shrews | and pleasantly surprised, tbh | |
| 14:36:44 | mordred | weird | |
| 14:37:33 | Shrews | "swift" being the language, not the object store thingy (if that wasn't clear) | |
| 14:38:28 | mordred | yeah. I mean - I'm sure swift the object store would also handle this well | |
| 14:38:49 | mordred | but that's largely just becaues timburke finds all the bugs | |
| 14:53:52 | Shrews | mordred: this is unrelated to your change, yeah? http://logs.openstack.org/32/614832/3/check/osc-functional-devstack-tips/aa1ce44/job-output.txt.gz#_2018-11-04_15_03_56_197747 | |
| 14:54:12 | Shrews | i've never seen that failure before | |
| 15:58:50 | mordred | Shrews: yeah - I think that's a rando | |
| 16:01:57 | Shrews | mordred: k k | |
| 16:45:37 | mordred | Shrews: replied on https://review.openstack.org/#/c/614834 - good point about testing though - I'll go lift that from nodepool | |
| 16:46:58 | Shrews | mordred: gotcha. can live w/o the depends | |
| 16:47:10 | mordred | Shrews: I could also totes go the other way :) | |
| 16:49:08 | Shrews | mordred: let's not add it until we *need* to | |
| 16:49:15 | mordred | ++ | |
| 17:27:43 | openstackgerrit | melanie witt proposed openstack/python-openstackclient master: Handle multiple ports in AddFloatingIP https://review.openstack.org/615353 | |
| 20:18:23 | openstackgerrit | melanie witt proposed openstack/python-openstackclient master: Handle multiple ports in AddFloatingIP https://review.openstack.org/615353 | |
| 21:21:11 | openstack | Launchpad bug 1802001 in Zun "please add documentation and example for python-zunclient API" [Undecided,New] | |
| 21:21:11 | hongbin | hi, i am traiging this bug: https://bugs.launchpad.net/zun/+bug/1802001 , and wondering why the user is trying to consume zun-api via openstacksdk, does openstacksdk supports zun? | |
| 21:35:10 | mordred | hongbin: we don't REALLY support it - you can get a configured REST client for any openstack service in openstacksdk | |
| 21:35:43 | mordred | hongbin: so conn.application_container.get('/containers') should work and return a requests.response.Response | |
| 21:36:05 | mordred | hongbin: but we do not currently have any support for zun in the object layer | |
| 21:36:41 | mordred | hongbin: of course, support for zun is totaly _welcome_ :) | |
| 21:36:55 | hongbin | mordred: i see, then to be exact, what is the difference between the confiugred REST client and the support in object layer? | |
| 21:37:31 | hongbin | any pointer to a docs would be enough :) | |
| 21:38:30 | mordred | hongbin: the wrapper layer makes higher level objects - so for example, for neutron, there is http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/network/v2/_proxy.py | |
| 21:39:09 | mordred | hongbin: which provides things liek "create_network()" and "networks()" ... and then each resource that is managed gets a Resouce object | |
| 21:39:18 | mordred | like http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/network/v2/network.py | |
| 21:39:39 | hongbin | i see | |
| 21:40:11 | mordred | https://docs.openstack.org/openstacksdk/latest/user/guides/network.html has some examples of using that | |
| 21:40:42 | hongbin | mordred: everything is clear now, thank for the information | |
| 21:41:03 | mordred | sure thing! let me know if I can be helpful with anything | |
| 21:41:59 | hongbin | thanks, will ping you know if anything else comes up | |
| #openstack-sdks - 2018-11-07 | |||
| 05:06:09 | openstackgerrit | Ian Wienand proposed openstack/openstacksdk master: Add a __main__ handler, version command https://review.openstack.org/616070 | |
| 13:41:06 | openstackgerrit | Merged openstack/openstacksdk master: Test python2 with py27 https://review.openstack.org/615543 | |
| 13:56:53 | openstackgerrit | Sven Wegener proposed openstack/python-openstackclient master: image/v2: support multiple property filters https://review.openstack.org/615850 | |
| 14:33:50 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Add wait functions to orchestration proxy https://review.openstack.org/615702 | |
| 15:41:07 | openstackgerrit | Merged openstack/openstacksdk master: [Trivial Fix] Correct spelling error of "bandwidth" https://review.openstack.org/615421 | |
| 16:03:07 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Slightly refactor vendor profile loading https://review.openstack.org/616227 | |
| 16:03:08 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: WIP Support remote vendor profiles https://review.openstack.org/616228 | |
| 16:03:21 | mordred | mnaser: ^^ there's a first-stab at that idea | |
| 16:07:51 | mordred | mnaser: it works for me against vexxhost in local testing, so I think it's ok. needs tests and docs | |
| 17:27:05 | openstackgerrit | Nguyen Hai Truong proposed openstack/openstacksdk master: Add coverage job https://review.openstack.org/616257 | |
| 17:38:27 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Slightly refactor vendor profile loading https://review.openstack.org/616227 | |
| 17:38:28 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: WIP Support remote vendor profiles https://review.openstack.org/616228 | |
| 18:29:11 | samueldmq | oops | |
| 19:19:20 | mordred | cdent, edleafe, elmiko: "{scheme}://{netloc}/.well-known/openstack/client" ... in terms of a well-known entry (like from the mailing list) ... do we like that? or would .well-known/openstack/api (or something else) be better? | |
| 19:21:54 | cdent | mordred: I fergit, was client a directory or a filename? I'd be vaguely inclined in the api direction either way if only because I think "client" implies a certain style of talking to the api | |
| 19:23:52 | cdent | and i'd be inclined in not-a-directory | |
| 20:05:32 | mordred | cdent: it's a filename | |
| 20:05:56 | mordred | cdent: and yeah - I think that's what I'm thinking re: api vs. client | |
| 20:06:12 | mordred | the json contents returned from that url contain informatoin _about_ the openstack api | |
| 20:06:41 | cdent | yes | |
| 20:08:07 | edleafe | I concur with api | |
| 20:09:43 | mordred | mnaser: if you get a sec, would you mind moving that test file to .well-known/openstack/api instead of .well-known/openstack/client ? | |
| 20:10:19 | mordred | mnaser: also - thank you for putting it there - it made verifying the new consumption code very nice | |
| 20:20:48 | openstackgerrit | Merged openstack/openstacksdk master: Shift swift segment async code out of adapter https://review.openstack.org/614832 | |
| 21:00:29 | openstackgerrit | Merged openstack/openstacksdk master: Remove unused Task classes https://review.openstack.org/614833 | |
| 21:12:09 | elmiko | mordred: sorry, just saw the ping | |
| 21:12:28 | elmiko | i agree with edleafe and cdent though (no surprise) | |
| 21:16:05 | mordred | elmiko: \o/ | |
| 21:16:33 | cdent | elmiko: I'm sorry to report we _still_ haven't used that syrup. We keep saying we'll make pancakes and then forget. But we are very pleased to see it in the cupboard every time we look. | |
| 23:16:22 | mnaser | mordred: https://vexxhost.com/.well-known/openstack/api | |
| #openstack-sdks - 2018-11-08 | |||
| 01:45:22 | openstackgerrit | Merged openstack/python-openstackclient master: Handle multiple ports in AddFloatingIP https://review.openstack.org/615353 | |
| 02:44:01 | openstackgerrit | wangqi proposed openstack/python-openstackclient master: Trivial: Fix the pep8 warning https://review.openstack.org/616395 | |
| 05:40:17 | openstackgerrit | Merged openstack/python-openstackclient master: image/v2: support multiple property filters https://review.openstack.org/615850 | |
| 06:21:04 | openstackgerrit | Vishakha Agarwal proposed openstack/python-openstackclient master: Modify the help message for 'registered limit set' https://review.openstack.org/609985 | |
| 11:12:33 | openstackgerrit | melissaml proposed openstack-infra/shade master: fix the word 'bandwith' https://review.openstack.org/616513 | |
| 12:57:17 | mordred | mnaser: you are amazing | |
| 13:55:18 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: WIP Support remote vendor profiles https://review.openstack.org/616228 | |
| 14:26:35 | samueldmq | morning | |
| 14:27:43 | samueldmq | is it correcto to say "At the service level, OpenStack has native support for API level interoperability, certifying clouds via the RefStack program." | |
| 14:29:25 | samueldmq | this allows heterogeneous clouds running the same service API versions to fully interoperate | |
| 14:29:34 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: WIP Collect request stats https://review.openstack.org/614834 | |
| 14:29:58 | samueldmq | and then it comes to sdk providing an upper abstraction layer for supporting multiple service (nova-net vs neutron) and versions of the smae service (keystone v2 and v3) | |
| 14:35:08 | mordred | samueldmq: it's ... the optimistic way of saying it, yes | |
| 14:36:52 | samueldmq | mordred: but that's what refstack does, correct? | |
| 14:37:22 | samueldmq | you mean optimistic because I am putting so much of the glory in sdk I guess | |
| 14:50:35 | mordred | samueldmq: no - I mean optimistic about RefStack :) | |
| 14:50:49 | samueldmq | mordred: oh | |
| 14:51:35 | mordred | samueldmq: but I think what you're saying is the intent - and my pessimistic side just sees the bugs | |
| 14:51:37 | samueldmq | what does it do in practice? just run tempest tests against clouds and reports results? | |
| 14:52:00 | samueldmq | mordred: bugs.. for example? I need to know more downsides of it | |
| 14:52:12 | mordred | samueldmq: so you could say all of the above, but then also that sdk's abstraciton layer does what you say it does - and also works around bugs/holes in the interoperability that refstack aims to provide | |
| 14:52:47 | mordred | samueldmq: well - places where refstack doesn't have a story for something yet - or where people can't agree that a given feature should be covered by refstack certification | |
| 14:53:30 | mordred | samueldmq: at the sdk level we can provide a consistency quickly - while aligning different operating clouds might take a bit longer | |
| 14:54:04 | samueldmq | hmmm | |
| 14:54:12 | samueldmq | so refstack's intent was to standardize? | |
| 14:54:15 | samueldmq | is* | |
| 14:55:49 | samueldmq | mordred: that's very interesting... standardizing things that are already alive don't work well. literature and experience shows that | |
| 14:56:07 | samueldmq | also - standards translates into cutting some use cases, and flexibility :-) | |
| 14:58:59 | mordred | samueldmq: yes - that's right - and you're exactly right | |
| 14:59:09 | mordred | samueldmq: refstack started well after there were already many production deployments | |
| 14:59:15 | mordred | so it has to take a conservative approach | |
| 15:00:01 | samueldmq | oh well, that's a good story to be written... thanks!! | |
| 15:00:08 | mordred | sdk also started after many production deployments - so it was able to look at what reality was, and then provide an abstraction on top of that to hide differences that exist due to refstack not existing in the beginning | |
| 15:00:12 | mordred | samueldmq: \o/ | |