| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-11-06 | |||
| 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:21:11 | openstack | Launchpad bug 1802001 in Zun "please add documentation and example for python-zunclient API" [Undecided,New] | |
| 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/ | |
| 15:00:39 | samueldmq | \o/ | |
| 15:51:46 | elmiko | edleafe: i will be around here, but i have a call to listen in on at the same time. just a heads up | |
| 15:55:21 | edleafe | elmiko: dtantsur: no problem | |
| 15:55:33 | edleafe | I'll try to handle the crowds all by myself :) | |
| 16:00:07 | edleafe | The API-SIG Office Hour has officially begun. | |
| 16:01:08 | elmiko | lol | |
| 16:02:06 | edleafe | Well, we don't use #startmeeting, so I gotta write something :) | |
| 16:02:22 | elmiko | #putsfeetondesk | |
| 16:03:09 | elmiko | and i wasn't lol'ing at your announcement (i like it), i was laughing at the exchange between you and mordred =) | |
| 16:04:37 | edleafe | That mordred thinks he's so tough | |
| 16:05:01 | elmiko | indeed | |
| 16:36:50 | openstackgerrit | Ed Leafe proposed openstack/api-sig master: Add idempotent DELETE guidance https://review.openstack.org/616610 | |
| 16:36:55 | edleafe | elmiko: dtantsur: finally got around to writing this ^^ | |
| 16:37:05 | elmiko | \o/ | |
| 16:38:18 | dtantsur | w00t | |
| 17:01:05 | edleafe | wow, another busy office hour | |
| 17:02:44 | elmiko | lol | |
| 17:02:51 | elmiko | hey, you posted a PR! | |
| 17:03:59 | elmiko | edleafe: just a heads up, i won't be around next week. gonna be at a conference | |
| 17:04:21 | elmiko | although, isn't next week the forum too? | |