| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-29 | |||
| 14:32:11 | stephenfin | Oh, then I can wait for him too | |
| 14:32:23 | stephenfin | (fwiw, I'm mostly just moving his stuff about) | |
| 14:34:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional recreate test for live migration pre-check fails https://review.openstack.org/498627 | |
| 14:35:24 | claudiub|2 | artom: hm, so basically, the fip is always associated with the tenant network. while the NIC which gets to be eth0 in the VM is random for me. | |
| 14:36:15 | claudiub|2 | artom: while before it seems that the fip was associated with the VM, not just one port. | |
| 14:36:16 | sdague | stephenfin: https://review.openstack.org/#/c/498817/1/doc/source/index.rst I really don't want to do that until we decide that's our direction at PTG | |
| 14:36:26 | sdague | because we just went the other way | |
| 14:37:01 | stephenfin | sdague: We don't have much of a choice though. If we don't do this, we can't hook into the likes of https://docs.openstack.org/pike/user/ | |
| 14:37:27 | sdague | stephenfin: we can | |
| 14:37:41 | stephenfin | We need solid landing pages for each of those. I can duplicate stuff into the main index page, but that seems rather unhelpful :/ | |
| 14:37:43 | sdague | we don't have to take out all the deep linking from the main index page | |
| 14:38:10 | sdague | stephenfin: people are navigating in from all different directions, having every single one of them being explainatory is good | |
| 14:38:41 | stephenfin | Would a simple '.. include' of each index page be a viable option? | |
| 14:38:56 | stephenfin | *...option, in that case? | |
| 14:38:59 | sdague | stephenfin: I don't know, it probably won't be coherent | |
| 14:39:16 | stephenfin | Aye, probably not :/ | |
| 14:39:39 | sdague | It's really ok to explain things multiple ways and give multiple setups for why following a link is useful before you do it | |
| 14:39:41 | mriedem | so the problem is you get this today? https://docs.openstack.org/nova/pike/user/ | |
| 14:39:47 | mriedem | which has no index | |
| 14:39:57 | sdague | mriedem: right, we should *definitely* fix that | |
| 14:40:24 | mriedem | same for https://docs.openstack.org/pike/admin/ and others i imagine | |
| 14:40:25 | sdague | which is this - https://review.openstack.org/#/c/498817/1/doc/source/user/index.rst | |
| 14:40:28 | sdague | which is fine | |
| 14:40:34 | mriedem | oh we have https://docs.openstack.org/nova/pike/admin/ | |
| 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 | sdague | I think the point is we need to realize that *all* of these are landing pages, for different contexts | |
| 14:41:29 | stephenfin | like, I cut and paste | |
| 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 | 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:32 | mriedem | which an end user would want | |
| 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? | |