| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-29 | |||
| 13:54:35 | mriedem | oh also a red hat employee | |
| 14:01:36 | openstackgerrit | Dan Smith proposed openstack/nova-specs master: WIP: Add migration-allocations spec https://review.openstack.org/498510 | |
| 14:07:14 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add user index page https://review.openstack.org/498817 | |
| 14:07:15 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Cleanup of existing index pages https://review.openstack.org/498819 | |
| 14:07:15 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add configuration index page https://review.openstack.org/498818 | |
| 14:07:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Rename cellsv2_layout -> cellsv2-layout https://review.openstack.org/498821 | |
| 14:07:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add contents pages https://review.openstack.org/498820 | |
| 14:08:19 | sean-k-mooney | beagles: hi o/ did you get an answer to your os-vif question? | |
| 14:09:37 | openstack | Launchpad bug 1713590 in os-vif "Plugging VFs no longer works without a readable phys_switch_id" [Undecided,New] | |
| 14:09:37 | beagles | sean-k-mooney, no I ended up filing a bug to avoid falling through cracks https://bugs.launchpad.net/os-vif/+bug/1713590 | |
| 14:10:37 | beagles | sean-k-mooney, I'm not 100% on the code path so there might be something else going on or the configuration of the test system might be missing something. From the information I had, this seemed a valid issue | |
| 14:11:30 | artom | claudiub|2, hey, back, took longer than planned, sorry | |
| 14:11:47 | claudiub|2 | artom: no problem. :) | |
| 14:12:51 | claudiub|2 | artom: i have a question regarding the test_device_tagging tempest test | |
| 14:12:56 | artom | claudiub|2, sure | |
| 14:13:02 | claudiub|2 | artom: what kind of image are you using when testing it? | |
| 14:13:10 | claudiub|2 | artom: i assume cirros, right? | |
| 14:13:43 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Remove deprecated call to sphinx.util.compat https://review.openstack.org/498824 | |
| 14:15:57 | sean-k-mooney | beagles: os vif does not handel pluging vf normally | |
| 14:16:17 | sean-k-mooney | beagles: its should only do this if you have ovs with hardware offlod support. | |
| 14:16:36 | artom | claudiub|2, it uses a boot volume, created from whatever's image defined in the configuration | |
| 14:17:00 | artom | claudiub|2, https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_device_tagging.py#L102 | |
| 14:17:01 | sean-k-mooney | beagles: in you ml2_conf.ini i would guess you have the openvswitch mech driver listeted before the sriovnic agent correct? | |
| 14:17:02 | claudiub|2 | artom: i know. :) | |
| 14:17:12 | claudiub|2 | artom: but what do *you* use to test it with? :D | |
| 14:17:23 | artom | claudiub|2, doh, hah! Yeah, I used cirros | |
| 14:17:34 | andreaf | zul: around? I have a change in Tempest that if merged would break some nova-lxd integration tests from the in-tree tempest plugin | |
| 14:17:34 | claudiub|2 | hm interesting | |
| 14:17:47 | artom | claudiub|2, what's up? | |
| 14:17:51 | beagles | sean-k-mooney, interesting ... tbh I don't know, the test system is likely gone at the moment. Where there was a patch that introduced this change to tripleo a short while ago, I think that's a safe bet | |
| 14:18:21 | andreaf | zul: but I don't see those tests running anywhere in nova-lxd gate, so I was wondering if I can just change tempest and propose a patch to fix nova-lxd afterward? | |
| 14:18:31 | sean-k-mooney | beagles: basically is you want sriov and ovs in the same deployment and all your sriov host dont supprot hardware offload you have to list sriov first. | |
| 14:19:07 | claudiub|2 | artom: i'm also using a cirros, but only eth0 is configured in it, even if all the interfaces are attached. the problem is that the interface which gets to be eth0 is random, and making the VM un-ssh-able | |
| 14:19:35 | claudiub|2 | artom: as the floating IP is associated with just one of the many private IPs the VM has. | |
| 14:20:08 | beagles | sean-k-mooney,k. I'll check on that | |
| 14:20:16 | sean-k-mooney | beagles: that said we can probaly harden that could a more and retrun a specific exction rather then causing an io error by reading a file that does not exist | |
| 14:20:22 | claudiub|2 | artom: was wondering if you had an issue like this | |
| 14:20:43 | artom | claudiub|2, I haven't run it manually in a long time | |
| 14:20:53 | artom | claudiub|2, how long has this been going on? | |
| 14:21:18 | claudiub|2 | artom: i've started testing the pike release, so i've only seen it nowadays | |
| 14:21:56 | artom | claudiub|2, interesting. https://review.openstack.org/#/c/463837/ merged recently, and it changes which floating ip client gets used | |
| 14:22:16 | artom | But it passed the gate, so in and of itself it's not the root cause | |
| 14:23:02 | claudiub|2 | hm, interesting | |
| 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 ? | |