| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-29 | |||
| 14:40:35 | sdague | we actually have an admin index already | |
| 14:40:45 | mriedem | and https://docs.openstack.org/nova/pike/reference/ | |
| 14:40:56 | sdague | my objection is stripping out the context from https://review.openstack.org/#/c/498817/1/doc/source/index.rst at the same time | |
| 14:40:59 | mriedem | so yeah why not just fix the user index? | |
| 14:41:04 | stephenfin | the admin index needs work though. It's ugly as sin :) | |
| 14:41:11 | sdague | stephenfin: sure, which is fine | |
| 14:41:20 | stephenfin | mriedem: because it's basically duplicating exactly what's on the main index | |
| 14:41:29 | stephenfin | like, I cut and paste | |
| 14:41:29 | sdague | I think the point is we need to realize that *all* of these are landing pages, for different contexts | |
| 14:41:36 | sdague | stephenfin: which is fine | |
| 14:42:21 | sdague | nova needs a coherent landing page for hitting the nova docs directly, the various guides need index pages that make sense in the context of the content they are exposed in | |
| 14:42:22 | mriedem | stephenfin: why would it be the same as the main index? | |
| 14:42:28 | mriedem | shouldn't /user just be what's in https://docs.openstack.org/nova/latest/#for-end-users ? | |
| 14:42:31 | mriedem | from the main page? | |
| 14:42:39 | stephenfin | sdague: I don't know. It seems impractical to be taking a two hat approach in the long term | |
| 14:42:40 | mriedem | and exclude "for operators" and "for contributors" stuff | |
| 14:42:51 | sdague | stephenfin: that's what good documentation looks like | |
| 14:43:02 | sdague | it has a context and an audience | |
| 14:43:18 | stephenfin | But...but...bother and hassle :( | |
| 14:43:30 | stephenfin | So if I drop the index page changes, the rest of it is reasonable enough? | |
| 14:43:34 | sdague | the deep content isn't replicated, but the context and "why would I ever want to follow this link" is taylored to the reader you expect | |
| 14:43:37 | stephenfin | at least, at first glance | |
| 14:43:44 | sdague | stephenfin: yeh, I'd be fine with that | |
| 14:44:01 | stephenfin | Kewl. I'll do that. | |
| 14:44:21 | stephenfin | which isn't to say I'm enamoured with leaving the index page the way it is, but that's PTG stuff | |
| 14:44:35 | stephenfin | Also, mriedem: that's what I did :) | |
| 14:44:53 | stephenfin | But I stripped the stuff from the main index page then as duplication | |
| 14:46:07 | mriedem | your proposed user index has a bunch of operator stuff in it | |
| 14:46:28 | mriedem | and nothing about the API version history or compute API reference | |
| 14:46:32 | mriedem | which an end user would want | |
| 14:46:32 | gibi | cdent, mriedem: fyi, there is a resource allocation bug in resize same host when custom resources are involved: https://bugs.launchpad.net/nova/+bug/1713739 | |
| 14:46:33 | openstack | Launchpad bug 1713739 in OpenStack Compute (nova) "VM resize and confirm on the same host fails with custom resources" [Undecided,New] | |
| 14:46:51 | gibi | cdent, mriedem: regression test is being created | |
| 14:46:52 | cdent | gibi: we were having _so_ much fun until you came back | |
| 14:47:27 | stephenfin | mriedem: Yeah, none of that is in the '/user' directory though. I was keeping only that stuff in there. A cross-reference wouldn't be any harm tho | |
| 14:48:02 | mriedem | i guess that is either external or in reference directory | |
| 14:48:35 | sdague | stephenfin: we don't strictly have to only list stuff in /user | |
| 14:48:38 | mriedem | guh, so...just have source/user/index.rst link back to the top level main index and be done with it | |
| 14:48:42 | gibi | cdent: It is not my finding :) I just suggested the certain test case to be created | |
| 14:49:11 | sdague | honestly, to avoid 404s, I'd say just write the user guide we think should be there, link whatever content is whereever, and it's fine | |
| 14:49:19 | sdague | links are not restricted about where they can go | |
| 14:49:36 | sdague | and the only people that will care that user isn't in the url are in this room | |
| 14:49:38 | cdent | the bug makes sense: the allocation creation routines are insufficiently custom resource class aware | |
| 14:49:43 | cdent | gibi: ^ | |
| 14:50:26 | openstackgerrit | Steve Noyes proposed openstack/nova master: update live migration to use v3 cinder api https://review.openstack.org/463987 | |
| 14:51:12 | sean-k-mooney | stephenfin: did ye bottom out on how to handel pci devices on power yesterday? | |
| 14:51:37 | gibi | cdent: interestingly we only see problems in the resize same host case so far | |
| 14:51:52 | openstackgerrit | Ed Leafe proposed openstack/nova-specs master: Return Destination Objects https://review.openstack.org/498830 | |
| 14:52:42 | edleafe | mriedem: dansmith: cdent: jaypipes: ^^ wrote a quick spec on the object solution we discussed yesterday. Feedback appreciated! | |
| 14:53:13 | cdent | edleafe: thanks. probably won’t have a chance to look with any rigor until tomorrow afternoon | |
| 14:53:43 | openstackgerrit | Ed Leafe proposed openstack/nova-specs master: Return Destination Objects https://review.openstack.org/498830 | |
| 14:54:09 | jaypipes | edleafe: cool. will review this evening. | |
| 14:54:13 | jaypipes | edleafe: which is soon :) | |
| 14:54:17 | edleafe | jaypipes: thx | |
| 14:54:21 | stephenfin | sean-k-mooney: I think efried and claudiub|2 opened some blueprints | |
| 14:54:37 | stephenfin | https://blueprints.launchpad.net/nova/+spec/allow-pci-alias-choose-subset-of-devices and https://blueprints.launchpad.net/nova/+spec/devices-as-resources | |
| 14:54:59 | sean-k-mooney | edleafe: ovo for scheuler info from placement make sense or at least object instead of dictionaries. | |
| 14:55:46 | sean-k-mooney | stephenfin: there are two other spec that related to sriov bonding that would be good to group with those | |
| 14:56:05 | edleafe | sean-k-mooney: placement is http, so ovo isn't applicable. | |
| 14:56:26 | edleafe | sean-k-mooney: but yeah, from scheduler->conductor, ovo will help | |
| 14:56:48 | sean-k-mooney | edleafe: it is if you call object_to_primitive and then jsonutils.dump on it first | |
| 14:57:26 | sean-k-mooney | i would be really happy if we could start passing json serialised ovo across our apis in the future | |
| 14:57:33 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: Fix _delete_inventory log message in report client https://review.openstack.org/498833 | |
| 14:58:59 | mriedem | edleafe: jaypipes: dansmith: we should return compute node uuid back in the dict from select_destinations too, that would make lookups for providers on the client side quicker, so the client doesn't need to lookup a compute node by host/node just to get the uuid | |
| 14:59:23 | edleafe | mriedem: agreed. I already did that in my first crack at these objects | |
| 14:59:24 | mriedem | the dict that's returned isn't even versioned today | |
| 14:59:32 | dansmith | I wasn't really paying attention to that conversation so I'll have to catch up when I look at that | |
| 14:59:40 | mriedem | this is unrelated | |
| 14:59:51 | mriedem | but to fix a bug with cleaning up allocations during live migration, | |
| 14:59:57 | jaypipes | mriedem: yup, agreed. good idea. | |
| 15:00:07 | mriedem | i need the compute node uuid to remove the allocations and only have the dict from select_destinations which has the host/nodename | |
| 15:00:10 | edleafe | mriedem: we don't really need that dict per se, just the data in it | |
| 15:00:29 | edleafe | and the object will version that | |
| 15:00:36 | mriedem | so let's say i added a uuid key to the dict that's returned today, what would we change for the version? | |
| 15:00:39 | mriedem | the client rpc? | |
| 15:00:45 | mriedem | *scheduler client rpc? or manager? | |
| 15:01:21 | edleafe | probably the former | |
| 15:01:30 | mriedem | well it's 4.5 either way i think | |
| 15:01:47 | edleafe | but there's no point if we're gonna be changing the interface to use objects | |
| 15:02:24 | mriedem | plus i couldn't backport this, and we need to backport this fix... | |
| 15:02:26 | mriedem | TODO in the code it is | |
| 15:03:24 | beagles | sean-k-mooney, thanks for the info btw! | |
| 15:03:25 | edleafe | mriedem: you mean you don't have any reference to the compute node in the migration? | |
| 15:03:27 | sean-k-mooney | mriedem: well for now you would have to do a condtional check to see if the uuid is present in the dictionary and look it up if not | |
| 15:03:39 | mriedem | edleafe: not when we're still in the conductor task | |
| 15:03:45 | mriedem | i have the dict returned from select_destinations | |
| 15:03:55 | mriedem | which has the host/nodename, which i can use to lookup the ComputeNode to get the UUID | |
| 15:03:56 | sean-k-mooney | beagles: no worries i was off since thursday so just go back | |
| 15:03:57 | mriedem | it's just a hassle | |
| 15:04:05 | artom | claudiub|2, fips have always been associated to ports IIRC | |
| 15:04:19 | edleafe | mriedem: I see | |
| 15:04:22 | mriedem | sean-k-mooney: i'd rather not write in dead code | |
| 15:05:13 | sean-k-mooney | mriedem: agreed but it may be needed for the backport. if we go to ovo defintions and and a object based interfaces then we can do it correctly in that version for queens on | |
| 15:05:48 | claudiub|2 | artom: yeah, you're right. anyways. will let you know what i'll find out | |
| 15:06:32 | artom | claudiub|2, sure, thanks | |
| 15:06:36 | cdent | edleafe: i lied, apparently i had something to say now | |
| 15:07:32 | edleafe | cdent: typical | |
| 15:08:05 | mriedem | sean-k-mooney: i'm just going to lookup the compute node using the host and node strings that i already have | |
| 15:08:07 | mriedem | old school | |
| 15:08:18 | mriedem | we can clean it up in queens with a uuid we get back later if that happens | |