| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-10-02 | |||
| 22:22:32 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Move base functional test job in-repo https://review.openstack.org/509015 | |
| 22:43:18 | openstackgerrit | Dean Troyer proposed openstack/openstackclient master: Add OSC plugin job https://review.openstack.org/509012 | |
| 22:54:08 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Move base functional test job in-repo https://review.openstack.org/509015 | |
| 23:29:58 | openstackgerrit | John Dennis proposed openstack/cliff master: Fix codec error when format=csv https://review.openstack.org/508760 | |
| 23:44:34 | openstackgerrit | John Dennis proposed openstack/cliff master: Fix codec error when format=csv https://review.openstack.org/508760 | |
| #openstack-sdks - 2017-10-03 | |||
| 06:09:25 | openstackgerrit | Bhagyashri Shewale proposed openstack/keystoneauth master: Added new logger to log request_id https://review.openstack.org/509088 | |
| 06:52:22 | slaweq | hello briancurtin, Qiming: can You maybe take a look at https://review.openstack.org/#/c/504111/ ? | |
| 06:52:25 | slaweq | thx in advance | |
| 11:47:55 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Add support for network quota details command https://review.openstack.org/504111 | |
| 12:08:55 | briancurtin | mordred: when is sdk being taken over? i have a contributor guidelines/naming/concepts doc i need to get merged at some point here, just want to make sure it gets in | |
| 13:07:54 | openstackgerrit | Dean Troyer proposed openstack/openstackclient master: Add OSC plugin job https://review.openstack.org/509012 | |
| 15:44:20 | openstackgerrit | Hongbin Lu proposed openstack/python-openstackclient master: [WIP] Added AddNetwork command to server https://review.openstack.org/509209 | |
| 18:51:28 | cfriesen | hi...has there been any serious discussion about properly adding support for nova microversions to osc? I saw https://bugs.launchpad.net/python-openstackclient/+bug/1677372 but that looks to be at a very early stage. | |
| 18:51:29 | openstack | Launchpad bug 1677372 in python-openstackclient "Compute API version defaults to '2.1' not '2.latest'" [Undecided,New] | |
| 19:17:10 | dtroyer | cfriesen: it is in progress for OSC 4, there is a big pile-o-arguemnt handling mess being cleaned up there and one of the reasons we need a major rev as some of the options are going to change behaviours slightly | |
| 19:20:48 | cfriesen | dtroyer: thanks...can you point me at any specs/blueprints/etc? | |
| 19:22:04 | cfriesen | I didn't see anything obvious at https://blueprints.launchpad.net/python-openstackclient | |
| 19:23:28 | dtroyer | cfriesen: there aren't any, the short version is we're basically consuming os-client-config and keystoneauth directly and minimizing the compatibility hacks added where OSC historically was different. That'll give us the version discovery/negotiation, leaving only those cases where we may want a command to have selectable behaviour | |
| 19:29:35 | cfriesen | dtroyer: there are a fair number of those in nova, no? and to do it properly wouldn't we need to handle version discovery the way novaclient does (where a new client can talk to any version of the server) | |
| 19:32:02 | cfriesen | dtroyer: like if we start allowing use of "get-me-a-network" on server creation we'd need to handle the case where the server isn't new enough to support it. | |
| 19:32:05 | dtroyer | cfriesen: we default to 2.1 now, with negotiation we will default to latest negotiated. Individual commands that need special consideration will have to be addressed as required. I REALLY do not want to require users to be aware of microversions, but have an ability for those who are to know and control what is going on. | |
| 19:32:40 | dtroyer | cfriesen: yes, and some amount of that is going to be built into the client. But there is not a blanket policy there yet | |
| 19:36:26 | cfriesen | dtroyer: okay, fair enough. thanks for the info. | |
| #openstack-sdks - 2017-10-04 | |||
| 07:32:51 | slaweq | briancurtin: hello, can You take a look once again at https://review.openstack.org/#/c/504111/? | |
| 07:33:17 | slaweq | briancurtin: Your W+1 disappeared probably because of zuul v2 <--> v3 migrations | |
| 08:47:32 | slaweq | hi, when will be some new version of openstacksdk released? | |
| 08:48:26 | slaweq | I need one feature from it to make properly patch https://review.openstack.org/#/c/501868/ | |
| 08:48:45 | slaweq | and I will also need one more patch from SDK for OSC later | |
| 08:49:01 | slaweq | is there any schedule of releases for openstack sdk? | |
| 09:01:27 | flanders_ | slaweq: you'll want to chat with the API-SIG over on #openstack-api | |
| 09:01:40 | slaweq | flanders_: ok, thx | |
| 09:01:44 | slaweq | I will talk there | |
| 09:02:17 | flanders_ | slaweq: ask for edleafe | |
| 09:31:43 | slaweq | ok, thx for tip flanders_ | |
| 11:18:44 | briancurtin | slaweq: not sure what he’s talking about, this is the right place. i’ll take a look at what else has been merged and i can put together a release | |
| 11:20:15 | briancurtin | slaweq: i just w+1’ed it so it should be merged soon | |
| 11:23:42 | openstackgerrit | Merged openstack/python-openstacksdk master: Add support for network quota details command https://review.openstack.org/504111 | |
| 11:28:38 | slaweq | briancurtin: thx a lot | |
| 11:29:08 | slaweq | briancurtin: in fact I will need for OSC patches also this patch which You just w+1'ed :) | |
| 13:08:31 | mordred | briancurtin: sorry for the delay, yesterday was a bit hectic ... | |
| 13:10:49 | mordred | briancurtin: I'm not anticipating much moving or shaking this week what with all the zuul v3 stuff flying around this week. | |
| 13:12:05 | mordred | briancurtin: that said, there was never any intention of removing any existing cores, so I don't think there shouldn't be any time-related issues for getting that in | |
| 18:47:03 | openstackgerrit | Hongbin Lu proposed openstack/python-openstackclient master: Added AddNetwork command to server https://review.openstack.org/509209 | |
| 20:52:29 | mriedem | hello! | |
| 20:52:37 | mriedem | so apparently the openstack python sdk doesn't have any support for flavor extra specs | |
| 20:52:40 | mriedem | which is pretty basic if you're using nova | |
| 20:52:46 | mriedem | does anyone know if someone is already working on this? | |
| 20:53:22 | briancurtin | no. | |
| 20:54:23 | mriedem | no you don't know, or no no one is working on it? | |
| 20:56:45 | briancurtin | no, i didn’t get around to implementing that in my free time and i am not working on it nor will i be. | |
| 20:56:53 | briancurtin | it’s pretty basic though | |
| 20:57:12 | mriedem | ok, yeah, should be - i've just never done any sdk coding, so wanted to ask before spending any time on it | |
| 20:57:19 | mriedem | for now i sent someone to novaclient | |
| 20:57:24 | briancurtin | great | |
| 20:59:54 | flanders_ | Have you looked at python shade SDK mriedem ? | |
| 21:00:11 | mriedem | nope | |
| 21:00:19 | mriedem | i really don't venture outside of novaclient | |
| 21:00:31 | flanders_ | No worries. | |
| 21:00:46 | flanders_ | Good luck. | |
| 21:00:56 | mriedem | flanders_: so i've heard you have some gap analysis charts | |
| 21:01:08 | mriedem | would that be so detailed to the point of knowing some of these major gaps in the compute api in the openstacksdk? | |
| 21:01:54 | flanders_ | Analysis was usability study on getting started quickly with each of the sdks | |
| 21:02:05 | flanders_ | Shade is the easiest, in short. | |
| 21:02:46 | flanders_ | Worth talking with chairs of API-SIG for feedback via #openstack-api | |
| 21:02:47 | briancurtin | mriedem: i doubt anyone knows such a thing, but yeah, someone could look at the docs, look at the code, and implement what’s not there. same for just about everything ever. | |
| 21:02:49 | mriedem | to get started, but not the most feature complete | |
| 21:03:01 | briancurtin | API-SIG and openstack-api has nothing to do with this project. | |
| 21:03:10 | mriedem | flanders_: ^ | |
| 21:03:36 | briancurtin | yeah it’s not the most feature complete because people building it weren’t on the server-side projects and no one on the server-side projects cared about SDK, so we built what we knew and what we were using | |
| 21:03:56 | flanders_ | My bad briancurtin - mea culpa | |
| 21:04:09 | mriedem | briancurtin: tbc, i was replying to flanders_ about shade | |
| 21:04:13 | edleafe | flanders_: FWIW, we hang out here, not #openstack-api | |
| 21:05:05 | flanders_ | Duly noted edleafe | |
| 21:05:19 | mriedem | hells bells it's edleafe | |
| 21:09:51 | mordred | mriedem: we've got flavor extra specs in shade - I expect we'll add support for it to sdk as we work on getting the shade layer and the sdk layer integrated with each other | |
| 21:10:11 | mriedem | mordred: so if i worked on extra specs in the sdk, that would ultimately benefit shade? | |
| 21:10:28 | mriedem | and the sdk | |
| 21:12:51 | mordred | mriedem: sure nuff | |
| 21:18:17 | xarses | to echo the conversation that was going on in #openstack-dev " |
|
| 21:18:38 | xarses | API is: https://developer.openstack.org/api-ref/compute/#flavors-extra-specs-flavors-os-flavor-extra-specs | |
| 21:19:51 | briancurtin | xarses: create_flavor would take any of the names on https://developer.openstack.org/sdks/python/openstacksdk/users/resources/compute/v2/flavor.html#openstack.compute.v2.flavor.Flavor, so create_flavor(disk=blah, ram=blah, ephemeral=False, …) and calling that does what? | |
| 21:20:24 | mordred | adding extra specs to a flavor is an additional call - it's not part of the create_flavor flow | |
| 21:20:43 | briancurtin | sure, but create_flavor shouldn’t be doing nothing | |
| 21:20:53 | mordred | once you have a flavor, you POST to /flavors/{id}/os-extra_specs | |
| 21:21:04 | mordred | briancurtin: agreed | |
| 21:22:08 | xarses | f = {'property': {'hw:cpu_policy': 'dedicated', 'hw:cpu_sockets': 1, 'hw:cpu_threads': 2, 'cost': 148.5, 'hw:cpu_cores': 8, 'hw:cpu_thread_policy': 'prefer'}, 'vcpus': 16, 'ram': 32256, 'name': 'm32-c16-d320-as', 'disk': 320, 'id': 'e2193116-f4f6-4db1-9191-33ef7d958895'} | |
| 21:22:17 | xarses | create_flavor(**f) | |
| 21:22:23 | xarses | returns the flavor object | |
| 21:22:42 | xarses | no info about that keys where ignored | |
| 21:23:22 | briancurtin | yeah, should probably output that and/or fail. i believe there was a ticket to output a warning with the ignored keys | |
| 21:23:29 | xarses | I see two problems, it took extra keys | |
| 21:23:34 | briancurtin | everything you pass has to match up with something on the associated resource | |
| 21:23:51 | xarses | and that there is no interface in sdk.compute to set os-extra_specs | |
| 21:24:03 | briancurtin | yeah well someone has the add the later | |
| 21:24:43 | briancurtin | im also not sure how you figured you could just send an arbitrary list of keys | |
| 21:25:10 | briancurtin | (that’s horribly worded…it’s not a list. arbitrary keyword arguments) | |
| 21:25:37 | xarses | by sending them and it just returning the result that I sort-of expected and moving on | |
| 21:25:57 | xarses | then accidentally reviewing the output of `openstack flavor list --long` and seeing they where missing | |
| 21:26:49 | xarses | I get the most frustrated when the sdk objects don't resemble what you get back on the CLI (like keys are wholly renamed) | |
| 21:27:48 | briancurtin | that’s a feature of the SDK, as there are several naming formats across openstack REST responses, including keys which cannot be python names | |