Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-11-06
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'm out o/
23:16:53 efried I'll let you sleep on it :)
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 https://review.opendev.org/692465
16:25:12 efried https://review.opendev.org/692464
16:25:12 efried oh yeah, I ended up with this:
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.
17:00:00 efried so as long as stephenfin / other cliff maintainers are okay with "polluting" the config space with another option, this solution is reasonably simple and clean.
17:00:28 efried I'll go back and add tests if I get some time, but I'm not in a rush as I don't expect stephenfin to look until next week at the very earliest.
17:00:31 elmiko later all, have a good weekend o/
17:00:35 efried o/ elmiko
17:02:01 cdent elmiko:
17:02:09 cdent hi
17:02:11 cdent that is all
17:02:44 elmiko hey cdent! =)
17:02:45 gtema_ looks like "That's all Folks"
17:13:08 dtroyer gtema_: so I'm just making time now, as that isn't as large as I remembered and I didn't realize you only did v2…
17:13:44 dtroyer the deal with image create from stdin isn a significant change and at a bare minimum needs to be release-noted. There are a few placed it would break scripts I've written
17:13:45 gtema_ yeah, this is exactly the next point - what do we want to do with v1 (drop or port it in followup)
17:14:17 dtroyer I don't want to drop v1, we'll need to convert it too eventuallly, I _REALLY_ want to get rid of glancelcient and it's weird deps
17:14:49 gtema_ for the moment create from stdin is supported, but not efficient
17:15:28 gtema_ ok, then I can work on v1 in a followup. I had nowhere a real v1 to test it works and didn't want change to explode
17:16:32 dtroyer yeah, that was supposed to be tested with other ancient APIs in that devstack-like mitaka cloud I was working on when starlingx destroyed my (work) life…
17:16:52 gtema_ what I find funny - in real usage OSC becomes faster in lots of cases, but osc tests are tiny bit longer
17:17:24 gtema_ the func-ones I mean

Earlier   Later