| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-10-03 | |||
| 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 | |
| 21:28:10 | briancurtin | for example, most of what you tried to send | |
| 21:31:58 | briancurtin | people want (wanted?) one place to do all of this, one format, one thing to install, consistency all around. a bunch of things get renamed in the process to make it usable for the masses, but yeah, if you’re looking at what are probably database column names or something, they don’t always match up 1-1 with the names in openstacksdk. on purpose. | |
| 21:37:29 | mordred | ++ | |
| 22:16:23 | openstackgerrit | Dean Troyer proposed openstack/osc-lib master: --os-profile option suddenly causes trouble in unit tests https://review.openstack.org/509662 | |
| #openstack-sdks - 2017-10-05 | |||
| 01:09:50 | openstackgerrit | OpenStack Proposal Bot proposed openstack/osc-lib master: Updated from global requirements https://review.openstack.org/509448 | |
| 01:12:02 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/509460 | |
| 02:25:48 | openstackgerrit | Hongbin Lu proposed openstack/python-openstackclient master: Added AddNetwork command to server https://review.openstack.org/509209 | |
| 02:41:57 | openstackgerrit | OpenStack Proposal Bot proposed openstack/osc-lib master: Updated from global requirements https://review.openstack.org/509448 | |
| 02:43:59 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/509460 | |
| 02:44:35 | openstackgerrit | Merged openstack/python-openstackclient master: Support creating unaddress neutron port https://review.openstack.org/504817 | |
| 02:57:57 | openstackgerrit | OpenStack Proposal Bot proposed openstack/osc-lib master: Updated from global requirements https://review.openstack.org/509448 | |
| 02:59:51 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/509460 | |