Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-11-06
22:32:51 johnsom efried Let me noodle on it a bit.
22:34:15 efried dtroyer: Yeah, the right thing is probably to split the neutron/nova-net commands/opts into distinct classes (preferably in distinct packages), but I'm not sure how the CLI would decide which entry points to load up.
22:34:48 efried uhh, maybe the framework is already there, because of how we use --os-*-api-versionZ
22:36:07 dtroyer efried: the problem there is there is nobody to do that work. That also needs to be done for volume v2/v3 and has sat there for 2-3 years now
22:37:04 dtroyer and I am now stuck trying to sort out how to deal with the SDK release breaking the snot out of nodepool and cleaning up the mess that made in my 3ci stacks
22:39:34 johnsom I think we can make the tags code in osc_lib take a version qualifier and produce the same result, just by handling the tags params special on the OSC side. I think a generic parameter like "version_qualifier" would be ok for the shared tags code.
22:41:16 efried johnsom: but then you have to duplicate the text, translation, formatting, and conditioning in osc-lib.
22:41:30 efried I suppose you could just *move* it in there, shrug.
22:43:16 johnsom One question I have is we don't call out api versions on any of the other commands right? We just assume the "not implemented" response is clear enough.
22:44:12 efried what do you mean?
22:44:52 johnsom Well, here: https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/network.html#network-create
22:45:15 johnsom --dns-domain only exists on certain versions of neutron API. We don't call that out here.
22:45:55 johnsom Same with --qos-policy which is only available in certain versions of neutron API and with the neutron extension loaded.
22:46:24 efried Yeah, that would be nice. Not a reason to move backwards on neutron vs nova-net though
22:47:10 efried and btw, the "not implemented" response is not necessarily clear.
22:47:49 efried as an osc noob I had a hell of a time figuring out that my under-the-covers microversion wasn't adequate, and how to remedy it.
22:48:27 johnsom I'm just noticing that this is the first time we have added any version information to the python-openstackclient docs.
22:48:28 efried Can't imagine someone trying to figure out why they can't use the --subnet flag
22:48:35 efried oh, no it's not at all
22:48:53 efried The previous version of these same docs had these same decorations.
22:48:54 efried stand by
22:49:00 johnsom Weil, in server create, the micro-versions aren't called out for those commands
22:49:06 efried https://docs.openstack.org/python-openstackclient/train/cli/command-objects/network.html#network-create
22:49:54 efried no, microversions aren't. That would arguably be a nice enhancement. Ideally it would somehow tie back into the client code to discover that automatically, rather than being hardcoded.
22:50:24 efried I'm just saying for neutron vs nova-net, it *was* called out, which is why I didn't see it being a viable path forward to stop doing that when the docs were generated.
22:51:12 efried also fwiw https://docs.openstack.org/python-openstackclient/train/cli/command-objects/role.html identity docs had v2 vs v3 markers.
22:51:21 johnsom were those static pages before?
22:51:22 efried that's major version of course, not microversion.
22:51:24 efried yes
22:51:29 johnsom ah
22:52:41 efried oh, and the way I found out this was even a thing was by trying to build the docs by running both paths. That gives errors on conflicting opts. If you look at the rest of the offending patch, you'll see where I had to put in some pretty weird "if docs build" conditions in some places.
22:53:04 johnsom Yeah, I saw those
22:53:47 efried anyway, as dtroyer implied, there's a right way and there's an expedient way. Unless you're signing up to do the former (I'm not) we're pretty much stuck doing the latter, even though it's kind of distasteful.
22:54:30 johnsom I think we can leave that nastiness in OSC. I'm just working on a way to allow passing that stuff into osc_lib in a more clean way, focused on the tags library for now.
22:54:58 johnsom Well, no good dead goes unpunished. I volunteered to do the tags library work... lol
22:55:25 efried for what it's worth, I played around with other "more clean" options when I was authoring the patch.
22:55:46 efried Believe it or not, this turned out to be the cleanest, from a DRY standpoint.
22:56:12 johnsom So you are advocating for leaving duplicate code in OSC and osc_lib?
22:56:42 efried oh, sorry, no; I'm advocating adding the enhance_help kwarg in osc-lib, properly documented.
22:57:07 efried Yeah, I guess there's two "expedient" solutions, but I was assuming "leave it like it is" (and abandon the removal patch) wasn't on the table.
23:14:17 johnsom Ugh, I really hate having to modify osc_lib again and start this cycle over and I'm not a fan of pulling forward this setup.
23:14:54 openstackgerrit Eric Fried proposed openstack/osc-lib master: WIP: Add enhance_help kwarg to tags option generators https://review.opendev.org/693267
23:15:10 efried johnsom: well, fwiw there's the code side ^
23:16:53 efried I'll let you sleep on it :)
23:16:53 efried I'm out o/
23:24:51 openstackgerrit Michael Johnson proposed openstack/python-openstackclient master: Switch to using osc_lib.utils.tags https://review.opendev.org/662864
23:25:50 johnsom Not sure those jobs are going to pick up that tags library hack patch, so mine is probably going to fail out even with the depends-on.
#openstack-sdks - 2019-11-07
16:00:14 elmiko API SIG office hour is now starting
16:00:26 efried whee
16:00:50 elmiko hehe
16:01:22 efried does the API SIG extend its tentacles into osc ux?
16:02:34 elmiko not specifically, but we have had talks in the past about helping the user community if possible
16:02:42 elmiko sadly, that work never really panned out
16:12:00 dtroyer efried: I'm afraid all of the blame for OSC UX falls on my shoulders (except for putting the resource name in front of the verb. That I resisted for a long time)
16:13:15 efried dtroyer: I'm not slinging blame, I think it's pretty cool given the scope of what it needs to do. I was just going to solicit an opinion on the thing we were talking about last night with johnsom
16:13:57 efried and really ux where u is "developer" more than anything, though there are routes we could take where u is the docs consumer
16:14:33 elmiko efried: from that standpoint, the api-sig explicitly does not get into the business of regular "code" apis
16:14:42 johnsom OSC is a huge leap forward from the old clients. We have also got a lot of positive feedback about it for our project. Just saying....
16:19:53 johnsom That said, yeah, the topic here is good-form for shared library method signatures.
16:21:13 johnsom efried FYI, it looks like the tips job on my patch with the depends-on did pass.
16:21:57 johnsom The others will not pass now until your osc-lib patch merges given the other changes.
16:22:12 efried johnsom: Okay, I hadn't looked yet this morning. IRL we would have to get it released and through u-c and required by python-openstackclient before merging.
16:22:13 johnsom Well, merges, releases, and upper-constraints merges
16:22:22 efried jinx
16:22:26 johnsom Yeah, all that
16:22:36 efried There was another osc-lib change I was looking for...
16:22:39 johnsom Thus my grumpy mood yesterday
16:23:43 efried oh, it was this: right now the generated docs from within python-openstackclient are still tagged with "This command is provided by the python-openstackclient plugin"
16:24:18 efried I was trying to fix that from osc-lib, but I think I found out it has to be fixed either from python-openstackclient itself or from cliff, or possibly both, I can't remember if I closed the gap all the way yet.
16:25:12 efried oh yeah, I ended up with this:
16:25:12 efried https://review.opendev.org/692464
16:25:12 efried https://review.opendev.org/692465
16:30:56 dtroyer efried: I gave that cliff review a +2 but you might want to remove WIP from the commit just for cleanliness sake.
16:31:06 dtroyer otherwise it looks good
16:31:45 gtema dtroyer, you are finally online at the same time as I.
16:31:53 gtema What about https://review.opendev.org/#/c/650374 - switch image to SDK
16:32:19 gtema I know it's huge, but we need to do something
16:32:57 dtroyer I'm still pondering on https://review.opendev.org/#/c/693267, I'm assuming it isn't done yet, update_tags_for_set() isn't touched...
16:33:57 dtroyer gtema: yes, it is huge and I haven't been able to get the kind of block of time to go through that yet. I also want to make sure we have decent enough functional tests to validate everything before and after (you may have that)
16:34:52 gtema I understand. Just want to get clear on that change to decide what/how to do next.
16:35:25 gtema I introduced in this change another sdk_utils, and wanted in the followup to clean it up in compute
16:36:01 dtroyer gtema: is that something that maybe belings in osc-lib? would plugins want it?
16:36:26 gtema well, this is something what any SDK based plugin might want
16:36:32 dtroyer we're gearing up to release osc-lib soon for the tags changes anyway
16:37:09 gtema should I propose adding it there then?
16:38:11 dtroyer if you think it is stable, sure. if it makes more sense to expand it to another API first to make sure it is 'done' then maybe wait. I'll try to take a look at that today
16:38:37 gtema well, it is there since network uses SDK, so yes, it is stable
16:39:16 gtema it's basically more or less just to kinda "show" SDK resource
16:39:33 dtroyer yeah, even if they don't belong in osc-lib network does have some things that should be generalized for osc itself
16:55:26 efried dtroyer: none of the update_tags_for_* methods are touched. How would they be?
16:56:01 efried dtroyer: I think the cliff WIP might have been because I wanted to add some kind of testing.
16:56:30 dtroyer efried: doh, right on update_*()
16:56:46 efried phew, cause I couldn't imagine how that would work :P
16:57:20 dtroyer cliff is used outside OpenStack so we're a bit more cautious about changes there, I don't see this one as an issue, but yeah, tests++
16:57:41 efried dtroyer: also wanted to make sure stephenfin had a crack at the concept before I invested too much time in it.
16:58:02 efried dtroyer: btw, the other approach was to override Command etc. to provide a dummy App from within python-openstackclient
16:58:09 efried because that's what cliff is bouncing off of when it generates that line.
16:58:39 efried I tried doing that from within osc-lib but then the package is... osc-lib, and you get the message anyway :(
16:59:17 dtroyer yeah, there is a small set of things like that that can't move into osc-lib
16:59:19 efried also, the App superclass is *really* not designed to be "docs build" oriented, so that would be a serious hack.

Earlier   Later