Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-10-28
17:39:17 efried even if the docs never get published, that job running in zuul will allow us to gate and detect future option help breakages.
17:40:08 dtroyer efried: ok, thanks for spending time on this
17:40:17 efried eventually if the docs do get published, we can stuff redirects in python-openstackclient, but we would probably still want *some* of the docs available there, so I'm not going to get real excited about that yet. Problem for future-us.
17:40:29 efried yahyoubetcha.
17:43:42 efried ...seems to have worked fine
17:50:56 efried ...which actually could be useful for our purposes here. Means I could make the docs build gate plugin projects without actually having to worry about whether the docs are pretty or correct.
17:50:56 efried okay, it's not publishing because it's using the build-...-pti job, not the publish-...-pti job.
17:51:29 efried dtroyer: that said, if you *do* want to start publishing those, it would be trivial at this point. Do you want me to pull that trigger?
18:29:52 openstackgerrit Merged openstack/openstacksdk master: Switch to Ussuri jobs https://review.opendev.org/691158
19:26:31 dtroyer efried: I'm not sure I want to publish docs outside of where they are maintained. ie, a single consolidated doc requires someone to curate it and I'm not signing up for that. I understand the ux sux but adding anything beyond pointers to the individual pieces eventually makes a worse experience when it gets stale
19:27:02 dtroyer I've always found bad docs more frustrating than no docs FWIW
19:27:05 efried dtroyer: that's not really the question at the moment.
19:27:47 dtroyer than I'm misunderstanding it
19:27:48 efried Maybe I misunderstood, but I thought the eventual goal was to maintain the osc docs in the openstackclient project, not python-openstackclient.
19:28:06 efried this would be a step in that direction, though not getting us all the way there yet.
19:28:18 efried do you mean maintaining docs outside of where the corresponding code is maintained?
19:28:27 dtroyer no, the OSC docs belong with the code, just like the plugin docs
19:28:58 dtroyer a unified guide of some sort would be great, but that's what we don't have the capacity to do, very similar to the overall docs efforts
19:31:53 efried - Make sure all the plugin projects gate on openstack-plugin-jobs. This prevents them from merging patches with broken option helps.
19:31:53 efried - Beef up the openstackclient-plugin-jobs template to include building those docs ^.
19:31:53 efried - Copy the python-openstackclient docs to the openstackclient project. Keep the build-...-pti, don't publish yet.
19:31:53 efried okay, so here's my current strategy:
19:32:37 dtroyer I don't want to move docs from python-openstackclient to openstackclient
19:33:06 dtroyer unless they are bits talking about the entire collection of things. leave the individual command stuff with the commands
19:33:46 efried Right.
19:33:47 efried - Start publishing openstackclient docs.
19:33:47 efried - Scrub the docs in both projects to keep the appropriate ones in the appropriate project. Add redirects from any python-openstackclient ones we remove. (No redirects from openstackclient are necessary because never published.)
19:33:47 efried The next (future, I'm not planning on doing this any time soon) steps would be:
19:34:17 efried but for now the easiest thing to achieve the goal (which is being able to prevent broken plugin docs from merging) is to do a full copy.
19:34:49 dtroyer can you do it the same way you do the plugins today? I don't think you are planning to copy those docs too, right?
19:35:17 efried That's exactly what I'm doing, albeit with a slightly bigger hammer.
19:35:59 efried I could pick and choose which docs to copy over, to achieve the sole goal of preventing the breakages, but that would be harder and the resulting docs would be not necessarily cohesive (not that that really matters at this stage).
19:35:59 dtroyer ok, when you say copy, I read check-in, is that incorrect?
19:36:30 efried I meancp -r python-openstackclient/doc/source openstackclient/doc/source
19:36:36 efried git add -A
19:36:38 efried git commit
19:36:49 dtroyer you are doing that with all plugins too?
19:37:26 efried the plugin "docs" that are part of python-openstackclient are just a couple dozen pages with one autoprogram-cliff line in them. That automatically sucks in the docs from the respective projects.
19:37:37 efried so those are coming along, in the same referential-y way.
19:38:14 efried produces this https://docs.openstack.org/python-openstackclient/latest/cli/plugin-commands/sahara.html
19:38:14 efried this https://opendev.org/openstack/python-openstackclient/raw/branch/master/doc/source/cli/plugin-commands/sahara.rst
19:38:14 efried example:
19:40:40 dtroyer it seems like way overkill to just copy it all only to filter it someday. having two copies out there _will_ confuse someone even if we don't publish it
19:41:11 dtroyer if you fix zuul for me I'll copy the structure over tonight…
19:42:32 efried "the structure"?
19:42:51 efried and "fix zuul"?
19:44:48 efried If you strongly prefer not to have two copies, I can make a hacked-up page that's hidden from view that just does the auto doc generation stuff. It would still build (and thus break if plugins f'ed up their opt helps) but we would have no duplication.
19:57:59 openstackgerrit Merged openstack/openstacksdk master: CI: add ironic-python-agent-builder to the ironic job https://review.opendev.org/691630
20:36:25 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: Use autoprogram-cliff for remaining plugin docs https://review.opendev.org/690387
20:37:04 openstackgerrit Eric Fried proposed openstack/openstackclient master: Add docs build to openstackclient-plugin-jobs template https://review.opendev.org/691751
20:37:04 openstackgerrit Eric Fried proposed openstack/openstackclient master: Copy in python-openstackclient docs https://review.opendev.org/691750
20:46:16 openstackgerrit Eric Fried proposed openstack/openstackclient master: Add docs build to openstackclient-plugin-jobs template https://review.opendev.org/691751
20:46:16 openstackgerrit Eric Fried proposed openstack/openstackclient master: Copy in python-openstackclient docs https://review.opendev.org/691750
21:00:22 efried - copies over all the docs from python-openstackclient https://review.opendev.org/691750
21:00:22 efried - updates the index https://review.opendev.org/691728
21:00:22 efried - I pushed up the openstackclient series above, which
21:00:22 efried - those reqs bumps merged, so this patch ought to be ready for review (python-openstackclient, autodocs the last five plugins): https://review.opendev.org/#/c/690387/
21:00:22 efried dtroyer: Update:
21:00:23 efried - tries to make the openstack-plugin-jobs template build docs (but I did it way wrong, need to rework) https://review.opendev.org/691751
21:02:08 efried oh, and trying to do autoprogram-cliff:: openstack doesn't work. It needs to match the entry point exactly.
21:02:25 efried the granularity is accomplished via that :command: syntax - but is optional.
22:31:24 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: WIP: neutron: autogenerate docs https://review.opendev.org/691767
22:31:46 efried dtroyer: FYI, I'm at least starting to go through and replace hardcoded content with autogen ^
#openstack-sdks - 2019-10-29
10:16:47 openstackgerrit Riccardo Pittau proposed openstack/openstacksdk master: Add reset_interfaces argument to patch_node https://review.opendev.org/689414
10:18:10 openstackgerrit Riccardo Pittau proposed openstack/openstacksdk master: Add reset_interfaces argument to patch_node https://review.opendev.org/689414
10:54:40 openstackgerrit Dirk Mueller proposed openstack/cliff master: Revert "Pin cmd2 back to <0.9 on all versions" https://review.opendev.org/691841
11:55:11 openstackgerrit Merged openstack/openstacksdk master: Increase dogpile version for Py3.7 compatibility https://review.opendev.org/691680
13:57:35 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: Remove redundant OpenStackShell.prepare_to_run_command https://review.opendev.org/691865
13:57:51 efried dtroyer, mordred: Easy one ^
14:22:57 dtroyer efried: not necessarily easy, there were reasons that exists, and at the moment I don't recall if all of those reasons are gone yet. They should be but I wouldn't bet dinner on it right now
14:23:21 efried dtroyer: I linked the superclass impl in there
14:23:58 efried But anyway, this is why we have reviews...
14:23:58 efried At least from what I can tell, it's doing the same thing. And you said yourself (in the TODO) that it could be removed after 1.4.0 :P
14:24:17 dtroyer Then it should be good, but consider the author
14:24:26 efried hehe
15:44:54 umbSublime with a connection object is it possible to specify the api microversion. Something equivalent to conn.compute.get('/os-hypervisors?with_servers=true', microversion='2.53')
15:49:45 efried umbSublime: Yes, all the methods (including the REST primitives like .get(), .put(), etc.) should take a microversion kwarg. Let me double check how it's spelled...
15:51:53 umbSublime efried: sorry I wasn't really clear, my example works
15:52:16 efried oh, you want to specify the default microversion for the connection so you don't have to put in the kwarg every time?
15:52:19 umbSublime My question was more, is this possible with for example conn.compute.hypervisors()
15:55:43 efried umbSublime: I was wrong, the non-primitives don't take a microversion. You can set the default microversion on the proxy though.
15:56:39 umbSublime Is that something I setup when creating the connection
15:56:57 efried Sorry, conn.compute is the proxy
15:57:05 efried conn.compute.default_microversion = XXX
15:57:05 efried So it should definitely work like:
15:57:22 efried But there's probably a prettier way to do it, via config or something.
15:57:24 umbSublime Ahh I see, thanks
15:58:10 efried dtantsur: do you have that answer off the top ^ ?
15:58:13 umbSublime and what about the 'with_servers=True', I see it works with .get, but with .hypervisors() it get's ingored.
15:58:34 umbSublime I pass it as a kwarg on .hypervisors()
15:58:57 dtantsur I suspect something like default_compute_microversions
15:59:16 dtantsur however, if you need to set it for e.g. conn.compute.hypervisors, then somebody is doing it wrong: other we or you :)
15:59:36 dtantsur openstacksdk is expected to use the latest microversions it knows. if it doesn't - it's a bug.
15:59:46 dtantsur if it does, then changing the default won't help you
15:59:57 efried dtantsur: Didn't mordred just fix something for that?
16:00:27 dtantsur maybe, I haven't been following closely the last couple of weeks
16:00:38 dtantsur (relocation)
16:00:39 umbSublime "somebody is doing it wrong" -> most likely me
16:00:56 dtantsur umbSublime: it may help if you describe the problem you're facing
16:01:16 efried https://review.opendev.org/#/c/685999/ implies we weren't getting the compute microversion we were expecting.

Earlier   Later