Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-04
17:27:13 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Remove hard-coded "admin" in test_port https://review.openstack.org/650082
17:28:00 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Remove hard-coded "admin" in test_port https://review.openstack.org/650082
18:54:03 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Remove hard-coded "admin" in test_port https://review.openstack.org/650082
19:14:24 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Remove hard-coded "admin" in test_port https://review.openstack.org/650082
19:43:04 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Remove hard-coded "admin" in test_port https://review.openstack.org/650082
20:17:48 openstackgerrit Merged openstack/openstacksdk master: Test _alternate_id logic https://review.openstack.org/379594
23:00:58 openstackgerrit James E. Blair proposed openstack/openstacksdk master: Expand on a brief error message https://review.openstack.org/650161
#openstack-sdks - 2019-04-05
06:09:57 stephenfin mordred: Are we collecting things for osc 4.0? Is so, thoughts on converting the likes of 'openstack security group create' to 'openstack security-group create' (with aliases, maybe)? The former feels wrong 'openstack security' isn't a command and I think it was only done because of cliff's use of underscores in entry point names
08:22:05 frickler stephenfin: mordred: I'd say keep those consistent with "floating ip", "subnet pool" and others. you also most certainly don't want "security-group-rule create" in addition
08:23:13 frickler if you want to change something in that regard, my vote would be to make "key pair" instead of "keypair", because to me that is inconsistent with all the other variants and always makes me need two attempts to get right
10:16:03 stephenfin frickler: Oh yeah, I mean anything where the top level command ('openstack floating' would fall into this) doesn't make sense or means something entirely different ('openstack subnet' would fall into this)
10:46:01 dtantsur stephenfin: I think the idea is to keep it as close to a human language sentence as possible
10:46:37 dtantsur and it's not friendly to users to make them remember where we use dashes and where spaces
10:46:59 dtantsur like, 'security-group create' makes as much sense as security-group-create
10:58:43 stephenfin dtantsur: I'd think of it in terms of 'openstack [resource] [action]'
10:59:06 stephenfin So 'openstack security-group create' makes far more sense to me. Helps from an autocomplete perspective too
11:06:11 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Remove hard-coded "admin" in test_port https://review.openstack.org/650082
11:15:16 dtantsur stephenfin: that's more correct technically, but more confusing to those who don't have a clear idea of what openstack resources are
11:15:36 stephenfin fair point
11:15:45 stephenfin Guess this isn't quite the no-brainer I thought it was :)
11:15:46 dtantsur also this simple schema can be quite confusing, e.g. when action has a complex subject, like "server add floating ip"
11:16:23 stephenfin yeah, nested resources are trickier
11:16:37 stephenfin 'server-floating-ip add' seems icky
11:17:37 dtantsur our schema is not without problems, of course. I still remember TripleO people once ending up with "openstack overcloud scale stack overcloud overcloud" :D
11:25:26 mordred wow. I just woke up to that sentence
11:27:46 dtroyer stephenfin: the multiple work resource names is intentional. 'security group' is the name
11:28:48 dtroyer keypair is unfortuante and I'm all for fixing that one, there are a couple more that I'd like to change too. we already did change ip floating to floating ip moving to 3.0, it isn't hard, and aliases are easy too, just add to setup.cfg whatever you like
11:29:04 dtroyer for a long time I kept the old verb-object format for commands that we started with...
11:30:20 dtroyer dtantsur: that is partyl a result of thinking you have to prefix every resource name, you don't…
11:48:28 cdent dtroyer: since you're about and in an osc naming frame of mind, your input on: https://review.openstack.org/#/c/640898/ would be most appreciated
11:48:46 cdent (see gibi's comment on ps5)
12:01:41 mordred gtema: re: https://review.openstack.org/#/c/649329 - something to think about - in the shade layer we put unknown object properties into a 'properties' property on the main object - largely to make it clear to people that they can't necessarily be depended on as part of the object model (this is a thing glance did in v1 and broke in v2) - now granted, we ALSO would leave them on the main body of the
12:01:43 mordred object so that people could do whatever if stict mode wasn't on
12:02:37 mordred gtema: in looking at that patch, I'm mostly pondering how it'll interact with the goal of being able to eventually get the shade methods to just return Resource objects - whether what you're doing there will make it harder or easier
12:03:06 mordred gtema: I don't have enough coffee in my blood yet to have smart thoughts - mostly wanted to word-vomit at you about that while I try to caffiene myself
12:03:10 gtema yes, it is clear to me this was done in shade/cloud. But we are not able to get "unknown" props for Image service
12:03:56 gtema and that somehow blocks normal switch from direct get/post/delete in the cloud._image services to proxy methods
12:04:19 mordred yeah. oh - I totally understand the motivation of the patch - I think I'm saying - I'm not sure we should put them on the object itself vs. making a magical properties attribute
12:04:31 mordred we should ABSOLUTELY expose the unknown stuff
12:05:55 gtema do you want to say that everything unknown should go dynamically under properties?
12:06:06 mordred MAYBE? I think I need more coffee :)
12:06:36 mordred I like your add_attribute thing too ... it actually makes me think it wouldn't be completely insane to fetch the jsonschema objects glance publishes and use that metadata somehow
12:06:39 gtema maybe, I just got my second one and that should be it for today, otherwise I will create some crazy patches
12:07:32 gtema as far as I remember there were also some issues with setting "sdk" shaXXX properties in the image uploads and objects
12:07:48 gtema do not joke with me and coffee - it might end bad
12:08:05 gtema it's affects me like a drug
12:08:14 gtema really :D
12:08:26 mordred ah. then yes - please to only have the second cup :)
12:09:07 gtema so I was not somehow able to switch all of the _image and _object methods to use proxy due to those "dynamic" things
12:09:29 gtema you might have fixed _object however
12:11:28 gtema yeah - _SHADE_IMAGE_OBJECT_KEY
12:11:45 gtema this was one of the problem s
12:12:19 gtema so basically glance accepts anything and we need to be able to set this "anything" in Resource
12:16:12 mordred yeah
12:39:45 dtroyer cdent: looking… at a glance, the way OSC typically sorts these things is to start with the object being manipulated, that is the name that appears first in the command followed by a verb and then the rest of the options. I'll need to tap into mordred's coffee IV and digest that in detail to get a sense of what I would have done...
13:11:11 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Remove hard-coded "admin" in test_port https://review.openstack.org/650082
13:11:51 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Remove hard-coded "admin" in test_port https://review.openstack.org/650082
13:12:27 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Remove hard-coded "admin" in test_port https://review.openstack.org/650082
13:30:05 openstackgerrit Merged openstack/openstacksdk master: Expand on a brief error message https://review.openstack.org/650161
13:30:18 dtroyer cdent: ok, there, I stuck my nose in y'alls business… https://review.openstack.org/#/c/640898/5
13:34:34 cdent thanks dtroyer. I'm attempting to decode what you've written. Should have it once my post lunch fuzz has waned.
14:58:38 dtroyer cdent: hey, you found my gabbi experiment :) since I am working against a running devstack I think I need to actually get a token with SDK to set up for the test to include, right? anyway, that's where I am right now…I'll try one more thing then push it up to show you where I've wandered
14:59:06 cdent yeah, if you're running like you need a token
14:59:27 cdent you might be able to clean some magic from my gabbi-tempest plugin (which is on git.o.o)
14:59:36 cdent s/like/live/
15:00:08 cdent s/clean/glean/
15:00:09 dtroyer cool, I had not studied that yet
15:00:18 cdent apparently I have not recovered from post-lunch fuzz at all
15:00:46 dtroyer is my agregate working to opaque? I may have still been in that sort of shape myself when I wrote it
15:00:55 dtroyer s/working/wording/
15:01:16 cdent I gave you my disease!
15:01:17 cdent huzzah
15:01:30 cdent I think mel was able to grok it properly, and likes it, so gtg
15:02:54 dtroyer yeah, she seems to have deciphered it.
15:11:27 openstackgerrit LIU Yulong proposed openstack/openstacksdk master: Add floating IP port forwarding related methods https://review.openstack.org/650063
15:25:55 cdent dtroyer: Instead of post-lunch fuzz, I'm going with "this is a day where I need my reading glasses"
15:36:04 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: [WIP] Support for the baremetal introspection service https://review.openstack.org/650044
15:59:22 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: [WIP] Support for the baremetal introspection service https://review.openstack.org/650044
16:15:22 openstackgerrit LIU Yulong proposed openstack/python-openstackclient master: Add floating IP Port Forwarding commands https://review.openstack.org/650062
16:20:07 openstackgerrit Artem Goncharov proposed openstack/python-openstackclient master: WIP: Switch image to use SDK https://review.openstack.org/650374
17:04:40 openstackgerrit Artem Goncharov proposed openstack/python-openstackclient master: WIP: Switch image to use SDK https://review.openstack.org/650374
17:44:13 JeremyHouser Quick question: are there any current known bugs related to openstack quotas in python-openstackclient?
17:52:57 openstackgerrit Merged openstack/python-openstackclient master: Volume backup functional test tweak https://review.openstack.org/649327
20:16:22 openstackgerrit Merged openstack/os-service-types master: add python 3.7 unit test job https://review.openstack.org/647397
#openstack-sdks - 2019-04-06
12:02:57 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Clarify error if no version can be found https://review.openstack.org/640835
12:02:57 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Bail earlier on a version mismatch for a supported service https://review.openstack.org/637563
#openstack-sdks - 2019-04-08
09:08:41 ITD27M01 mordred: Hi. If you have a time, can you please participate in discussion http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004695.html ?
10:10:20 gtema ITD27M01: which API filters are you missing on the nova side? Let's say covering existing filters in SDK is not a problem
10:29:48 ITD27M01 gtema: The basic idea is to transfer the filtering to nova API itself. In this way, the nova api will produce only requested data and we will get less work on the client side. As I said, the benefit will be the same for the server itself - fewer data will be transferred to the client. For large environments, this does lead to problems. Significant delays in processing large amounts of data.
10:31:00 gtema that's clear. As I read your message you want to extend nova filtering. What are you missing here. It currently support a lot (what we do not support so far, I'm preparing change for it now)
10:46:23 mordred ITD27M01: responded to email
10:49:08 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Improve error message for version_kwargs mismatch https://review.openstack.org/650845
10:49:15 mordred dtantsur: ^^ fixed your suggestion in a followup
10:52:39 ITD27M01 mordred: Thank you, I am in the process of understanding.
10:54:52 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Fix get_server to work with use_direct_get https://review.openstack.org/540389
11:03:07 gtema mordred: I'm currently working on switching Image in OSC from glanceclient to SDK and found, that OSC has a use-case to only create "placeholder" for image without data.
11:03:13 dtantsur thanks mordred
11:03:33 gtema we currently do not "support" that in SDK. Any thoughts? Simply implement?
11:06:39 mordred gtema: you can't just create an Image resource?
11:06:53 mordred gtema: oh - you mean a remote image without uploading data to it yet?

Earlier   Later