| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-29 | |||
| 14:24:12 | artom | claudiub|2, there was also https://review.openstack.org/#/c/471116/ | |
| 14:24:25 | artom | But again, passed the gate, so by itself it's not the issue | |
| 14:24:37 | zul | andreaf: check with jamespage | |
| 14:24:56 | artom | claudiub|2, I don't suppose you're running with nova-network by omission? | |
| 14:25:14 | claudiub|2 | artom: i don't think i've ever used nova-network. :) | |
| 14:25:25 | artom | claudiub|2, good. | |
| 14:25:36 | andreaf | zul: cool thanks - jamespage: this is the tempest patch https://review.openstack.org/#/c/492577/ | |
| 14:26:00 | andreaf | jamespage: and this is nova-lxd code that would be affected http://git.openstack.org/cgit/openstack/nova-lxd/tree/nova_lxd_tempest_plugin/tests/api/compute/servers/test_create_server.py | |
| 14:26:14 | artom | claudiub|2, I'm sorry I can't be of more help, but I feel like you'll have to dig into tempest to figure out why it's doing that | |
| 14:26:46 | artom | The test itself doesn't assign any floating IPs, it just sets validatable=True | |
| 14:26:51 | claudiub|2 | artom: yeah, will do. thanks for the input though. :) | |
| 14:26:58 | artom | And then tempest does its thing behind the scenes | |
| 14:29:44 | artom | claudiub|2, it may have something to do with the tenant network in your deployment: https://github.com/openstack/tempest/blob/master/tempest/common/compute.py#L206 | |
| 14:31:03 | stephenfin | mriedem, jaypipes: Fancy taking a look at these? https://review.openstack.org/#/c/498817/ and successors | |
| 14:31:26 | stephenfin | They fix some broken links that dhellmann pointed out and should be backported to Pike | |
| 14:31:37 | mriedem | stephenfin: seems like something sdague would have an opinion about | |
| 14:31:40 | mriedem | regarding layout | |
| 14:31:50 | stephenfin | Indeed. Any idea when he's back? | |
| 14:31:57 | mriedem | this week | |
| 14:32:00 | mriedem | he was here yesterday | |
| 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 | |