Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-10-05
17:29:22 mordred Shrews: ^^ just for you
20:33:50 openstackgerrit Ruby Loo proposed openstack/python-openstackclient master: Add --property option to 'server rebuild' command https://review.openstack.org/608350
22:20:48 openstackgerrit Merged openstack/openstacksdk master: Remove profile https://review.openstack.org/604414
22:20:48 openstackgerrit Merged openstack/openstacksdk master: Set endpoint_override from endpoint with noauth https://review.openstack.org/604415
#openstack-sdks - 2018-10-06
12:47:57 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Use discovery instead of config to create proxies https://review.openstack.org/600292
12:47:57 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Remove api version default values https://review.openstack.org/600330
12:47:58 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Use network proxy in openstack.cloud https://review.openstack.org/604645
12:47:58 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Remove all the deprecated stuff https://review.openstack.org/605508
12:47:59 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Start shifting cloud object-store methods to proxy https://review.openstack.org/608317
12:47:59 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Make it clear that OpenStackCloud is a mixin https://review.openstack.org/608318
12:54:22 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Make use of keystoneauth service-type filtering for versions https://review.openstack.org/585030
13:27:55 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Import rate limiting TaskManager from nodepool https://review.openstack.org/574285
13:28:20 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Make RateLimitingTaskManager the TaskManager https://review.openstack.org/604520
13:28:49 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add support for per-service rate limits https://review.openstack.org/604521
13:40:09 mordred ml: comments left on your wrapper method patch
13:40:33 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add some warnings and clarifications for discovery https://review.openstack.org/606113
13:49:30 ml mordred: thanks. Will take a look
14:01:02 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Replace TaskManager with a semaphore and lock https://review.openstack.org/604926
14:01:25 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Replace TaskManager with a semaphore and lock https://review.openstack.org/604926
14:11:28 mordred ml: sorry it took so long to review that - that OOM test timeout was really annoying :)
14:12:03 ml Nah, it's fine man. It didn't block me at all.
14:14:33 ml Actually, I'm really grateful that you could review it that quickly.
15:33:52 openstackgerrit Merged openstack/openstacksdk master: Import rate limiting TaskManager from nodepool https://review.openstack.org/574285
15:33:52 openstackgerrit Merged openstack/openstacksdk master: Make RateLimitingTaskManager the TaskManager https://review.openstack.org/604520
#openstack-sdks - 2018-10-08
09:27:52 openstackgerrit Stephen Finucane proposed openstack/os-api-ref master: tests: Support Sphinx 1.8+ https://review.openstack.org/607984
11:38:55 openstackgerrit Matthias Lisin proposed openstack/openstacksdk master: openstackcloud.py: Implement FWaaS wrapper methods. https://review.openstack.org/604811
13:43:12 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Correct updating baremetal nodes by name or ID https://review.openstack.org/608674
13:43:22 dtantsur mordred: sigh ^^^
13:47:21 cmurphy dtroyer: this command removal https://review.openstack.org/546924 got released in 3.16.0 instead of a 4.0, was that intentional?
13:50:31 dtroyer cmurphy: I can't recall why I did that without waiting, I've made other things wait… is it causing trouble?
13:53:29 cmurphy dtroyer: it caught us (suse internal) by surprise is all, we can update our automation but i wouldn't expect to have to without a major release
13:55:04 dtroyer you are correct about that assumption, which is why I'm frustrated why I can't remember doing that…
13:55:34 dtroyer it also points out we may need to do better at deprecation warnings
13:55:44 dtroyer would a noiser warning have been noticed in your case?
14:00:00 cmurphy dtroyer: probably not tbh
14:00:19 cmurphy but that's on us
14:01:01 dtroyer but like you said you're not expecting it now…
14:01:43 dtroyer ok, I was just curious if my expectations/experience on scripted usage matched the real-world
14:01:44 dtroyer thanks
15:48:49 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Correct updating baremetal nodes by name or ID https://review.openstack.org/608674
18:20:31 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Add volume pool list command https://review.openstack.org/608740
21:45:21 openstackgerrit Merged openstack/python-openstackclient master: Add --property option to 'server rebuild' command https://review.openstack.org/608350
#openstack-sdks - 2018-10-09
06:35:19 openstackgerrit Fan Zhang proposed openstack/python-openstackclient master: Add --key-name and --key-unset option for server rebuild API. https://review.openstack.org/576422
10:54:08 openstackgerrit Julie Pichon proposed openstack/python-openstackclient master: Allow endpoint filtering on both project and project-filtering https://review.openstack.org/608912
11:33:52 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: [WIP] Wire in retries for all baremetal actions https://review.openstack.org/603427
11:43:28 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: [WIP] Wire in retries for all baremetal actions https://review.openstack.org/603427
11:46:50 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: [WIP] Wire in retries for all baremetal actions https://review.openstack.org/603427
13:23:55 openstackgerrit Julie Pichon proposed openstack/python-openstackclient master: Allow endpoint filtering on both project and project-domain https://review.openstack.org/608912
13:31:17 openstackgerrit Vieri proposed openstack/os-service-types master: Don't quote {posargs} in tox.ini https://review.openstack.org/608973
15:28:34 smcginnis dtroyer: I had a question about the cliff autodoc you mentioned. Is there something extra that needs to be done to use that? I get the error: No commands found in the "openstack.volume.v2" namespace using the "volume capability" command name/pattern. Are you sure this is correct and the application being documented is installed?
15:28:52 smcginnis dtroyer: This is for the next command I had started to work on, so different than the one you had commented on.
15:35:51 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Wire in retries for all baremetal actions https://review.openstack.org/603427
15:41:54 dtroyer smcginnis: I didn't think anything special needed to be set up, we're already using it in the OSC repo.
15:42:21 dtroyer I'm looking to see if there is any additional config required...
15:42:48 smcginnis dtroyer: Do you know how it maps the command name to the class name? Maybe I have something messed up there.
15:43:13 dtroyer it's part of cliff so it uses the entrypoint mapping
15:52:09 smcginnis dtroyer: Got it. I needed a "*" at the end to pick up the actual command. I had "volume capability" but needed "volume capability *".
15:56:37 smcginnis dtroyer: I'm realizing both cinder list-pools and get-capabilities are really backend-centric commands and "volume capability show" doesn't make sense. Do you think "volume backend capabilities" and "volume backend pools" make sense? Or should it be the long "volume backend capability show" and "volume backend pool list" form be preferrable?
15:57:06 smcginnis Personally I like the shorter, but having "list" and "show" seems to be the more commonly used formats.
16:00:04 dtroyer smcginnis: this is the hardest part, naming things. 'backend' by itself is still too generic so it needs the qualifier, if something other than 'volume' makes sense that would be fine, but I can't think of one, 'volume backend' seems correct for what you are describing. but ya, it is really long
16:00:55 dtroyer is 'storage capabilities' or 'storage pools' too generic? we have multiple types of storage so it may be
16:02:13 smcginnis Yeah, I think "volume backend" is used enough that it most likely would make sense to users, wheras "storage foo" might be too generic.
16:03:03 smcginnis What about including the "show" and "list" at the end vs just "volume backend capabilities" and "volume backend pools"?
16:04:00 dtroyer I'll strongly recommend to stick with the 'object verb' command format…it's less to remember which verb to use based on the kind of output you want than to rememebr which commands don't have one
16:21:21 smcginnis dtroyer: OK, so "volume backend capability show" and "volume backend pool list" then?
18:48:38 dtroyer smcginnis: I think so
18:49:53 smcginnis dtroyer: Cool, thanks. That's what I'm working on now.
20:26:49 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Add volume backend capability show command https://review.openstack.org/609122
20:32:06 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Add volume backend capability show command https://review.openstack.org/609122
20:56:40 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Add volume pool list command https://review.openstack.org/608740
20:57:29 openstackgerrit Sean McGinnis proposed openstack/python-openstackclient master: Add volume backend pool list command https://review.openstack.org/608740
#openstack-sdks - 2018-10-10
02:33:03 openstackgerrit Nguyen Van Trung proposed openstack/cliff master: Don't quote {posargs} in tox.ini https://review.openstack.org/609185
10:04:44 mordred ml: that patch looks great!
10:05:28 mordred samueldmq: https://review.openstack.org/#/c/604811 <-- you might find this interesting
10:05:44 ml Thanks for the review!
10:10:15 samueldmq mordred: oh that's using the sdk data model
10:15:32 samueldmq mordred: ml : commented on that. suggested a few improvements
10:15:36 mordred samueldmq: yah - I haven't gotten far enough along to explore that yet - but I've been thinking that we could migrate from the normalize methods to using the sdk data model - and maybe some times have some of the logic be in the sdk proxy methods - I was going to try it with create_image
10:15:40 mordred samueldmq: awesome, thanks!
10:16:15 ml samueldmq: Thanks, will have a look#
10:16:36 samueldmq mordred: we'd still need something like normalzie anyways
10:17:09 samueldmq I know sdk data model already maps some of the attributes, such as enabled -> is_enabled in the data model definition
10:17:27 samueldmq but we'd need to map that against the current shade contract/data model
10:17:32 samueldmq because we don't want to change that right
10:20:17 mordred yes, you're exactly right
10:20:49 mordred although maybe it'll be enough to just update the sdk model to be the same as the normalize contract in shade?
10:21:33 samueldmq if the sdk side is okay updating their contact, it'd be awesome
10:22:28 ml samueldmq: you think it's a good idea to put 14 parameters in the function signature? Feels messy
10:23:12 samueldmq ml: well, see https://github.com/openstack/openstacksdk/blob/master/openstack/cloud/openstackcloud.py#L6751-L6766 for create_server
10:23:25 samueldmq ml: don't necessarily need to put in the signature, see the valid_kwargs annotation
10:23:50 samueldmq ml: I'd probably go with that as you don't do any work on the parameters before passsing on to the server
10:24:35 ml ahh, yeah. @_utils.valid_kwargs sounds good
10:26:12 samueldmq ml: awesome. btw I didn't mean you should because create_server does more params than that
10:26:13 ml also, sadly no, name_or_id doesn't uniquely identify the resource since multiple resources can have the same name
10:26:20 samueldmq but for the reasons I put on the review :)
10:27:26 samueldmq ml: so please make it clear in the docs that filters might need to be used when a name is provided
10:27:51 samueldmq also, document what happens if you provider a name and filters combination that gets you more than one resource
10:28:12 samueldmq when you're callling the update or delete mehtod, for example. does it update'em all? delete them all? throws exception?
10:28:38 samueldmq s/throws/raises , throwing exceptions remembers me of java
10:30:18 ml alright, I'll add :raises [exc]: where necessary

Earlier   Later