| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-28 | |||
| 03:31:43 | openstackgerrit | Li Yingjun proposed openstack/nova-specs master: Spec for support set vgamem for video https://review.openstack.org/438787 | |
| 03:51:26 | openstackgerrit | Li Yingjun proposed openstack/nova master: libvirt: Enable custom video vgamem setting https://review.openstack.org/411191 | |
| 04:12:51 | openstackgerrit | Huan Xie proposed openstack/nova master: Make xenserver driver compatible with assert_can_migrate https://review.openstack.org/438792 | |
| 07:26:39 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: Remove mox from nova.tests.unit.virt.xenapi.test_xenapi[1] https://review.openstack.org/438825 | |
| 07:28:20 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: Remove mox from nova/tests/unit/virt/xenapi/test_xenapi.py[1] https://review.openstack.org/438825 | |
| 07:38:35 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: List/show all server migration types https://review.openstack.org/407237 | |
| 07:59:38 | Dinesh_Bhor | Hi all, I have fresh OpenStack installed on Ubuntu 14.04 but I am unable to boot vm. Logs in n-cpu says that: "InternalError: Nova requires libvirt version 1.2.9 or greater." | |
| 08:01:52 | Dinesh_Bhor | I tried to update libvirt version but it only installs 1.2.2. I have ubuntu 14.04 LTS. | |
| 08:02:09 | openstack | Launchpad bug 1532460 in libvirt (Ubuntu) "Please upgrade to allow virsh blockcommit in Ubuntu 14. libvirt-1.2.9 (and above)" [Undecided,Fix released] | |
| 08:02:09 | Dinesh_Bhor | I found some bug here: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1532460 | |
| 08:43:26 | gmann | alex_xu: mriedem: this looks good but new error code bug me - https://review.openstack.org/#/c/429476/4 | |
| 09:00:57 | vsaienk0 | Hello nova team I'm wondered why multinode tempest test is skipped on grenade multinode in base tests? http://logs.openstack.org/76/429476/4/check/gate-grenade-dsvm-neutron-multinode-ubuntu-xenial/f6613ff/logs/grenade.sh.txt.gz#_2017-02-26_23_56_30_146 | |
| 09:05:39 | vsaienk0 | I meant is it expected behavior? | |
| 09:08:34 | frickler | can someone explain the difference between default_availability_zone and default_schedule_zone? both descriptions look roughly the same to me here: https://docs.openstack.org/draft/config-reference/compute/config-options.html#id3 | |
| 09:25:12 | openstackgerrit | Gao Yuan proposed openstack/nova master: Stop using mox stubs in nova.tests.unit.api.openstack.compute.test_serversV21 https://review.openstack.org/438873 | |
| 09:38:23 | johnthetubaguy | frickler: I did look into all that AZ stuff when we tidied up the descriptions, but you are right, its not very clear from that | |
| 09:39:22 | openstack | Launchpad bug 1668542 in openstack-manuals "nova.conf - az configuration options in Configuration Reference" [Undecided,New] | |
| 09:39:22 | frickler | johnthetubaguy: I just opened https://bugs.launchpad.net/openstack-manuals/+bug/1668542 because looking at the code I became even more confused | |
| 09:39:39 | johnthetubaguy | frickler: that probably needs to be a nova bug, the text lives in nova | |
| 09:40:29 | frickler | johnthetubaguy: added. probably the "open bug" link on the bug page could need amending then, too | |
| 09:40:50 | frickler | s/bug page/doc page/ | |
| 09:42:35 | johnthetubaguy | frickler: yeah, it probably does, not sure if you can change that per page, probably worth a manuals bug for that! | |
| 09:44:10 | johnthetubaguy | frickler: ah, so one is about where the host lives by default, and one is about where instances go, I think... | |
| 09:50:08 | frickler | johnthetubaguy: yes, that is my interpretation, but would be nice to get it confirmed, then I could make a patch for the docs | |
| 09:52:29 | frickler | johnthetubaguy: hmm, the source for the page seems to be ./doc/config-reference/source/compute/config-options.rst in openstack-manuals, though | |
| 09:57:40 | johnthetubaguy | frickler: that thing is auto-generated by a script, so its a two part ifx | |
| 09:57:42 | johnthetubaguy | fix | |
| 09:58:19 | openstackgerrit | John Garbutt proposed openstack/nova master: Fix default_availability_zone docs https://review.openstack.org/438887 | |
| 09:59:09 | johnthetubaguy | frickler: does that patch look like it makes it cleaer? | |
| 10:00:29 | johnthetubaguy | hmm, not sure my wording is brilliant, but suggestions welcome | |
| 10:01:35 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: WIP: Backlog spec on preemptible instances https://review.openstack.org/438640 | |
| 10:04:02 | frickler | johnthetubaguy: ah, nice, I was just about to do a patch for doc/config-reference/source/tables/nova-availabilityzones.rst , will that get synced from the data in nova? or should I do my patch in parallel anyway? | |
| 10:04:41 | johnthetubaguy | frickler: I think the sync is manual, there is a readme on how to do that in that repo somewhere | |
| 10:04:57 | johnthetubaguy | frickler: but I think you could checkout my patch on your system, inside the docs build system, to pull in the change | |
| 10:05:29 | johnthetubaguy | frickler: maybe its easier just to patch it directly for now! yeah, do it in parallel, and have a depends-on header pointing to my patch I think | |
| 10:06:29 | frickler | johnthetubaguy: will do after you replied to my small comments ;) | |
| 10:08:12 | bauzas | morning folks | |
| 10:09:41 | bauzas | johnthetubaguy: frickler: context around AZs ? | |
| 10:10:22 | bauzas | johnthetubaguy: frickler: just in case you need more knowledge, there are kludges with those opts https://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs | |
| 10:10:39 | bauzas | see the warning section ^ | |
| 10:10:41 | johnthetubaguy | yeah, its the config doc that is confusing | |
| 10:10:46 | openstackgerrit | John Garbutt proposed openstack/nova master: Fix default_availability_zone docs https://review.openstack.org/438887 | |
| 10:11:08 | johnthetubaguy | bauzas: its very tempting to just deprecate that one | |
| 10:11:53 | bauzas | ah, gotcha | |
| 10:11:55 | johnthetubaguy | frickler: bauzas makes a good point though, the AZ stuff was never really "finished" its all a bit broken honestly. Now placement API work should mean we can look at fixing some of that all soo | |
| 10:11:58 | johnthetubaguy | n | |
| 10:12:11 | bauzas | so, lemme clarify some tribal knowledge | |
| 10:12:28 | johnthetubaguy | bauzas: sure | |
| 10:13:01 | bauzas | first, we have a weird concept of a "default" AZ | |
| 10:13:18 | bauzas | ie. controlplane services have AZs too | |
| 10:13:34 | bauzas | while we can't actually schedule them as a target :) | |
| 10:14:42 | bauzas | secondly, we differenciate hosts vs. instances when they have no AZs | |
| 10:15:00 | bauzas | instead of saying "I don't care at all about AZs so the AZ field should be blank" | |
| 10:15:16 | bauzas | we then have 2 opts that are different: | |
| 10:15:31 | bauzas | if you don't care about AZs for your instance, then you need to set it blank | |
| 10:15:49 | bauzas | but if you don't care about AZs for your hosts, then you need to set it as "nova" | |
| 10:15:55 | bauzas | so much fun around | |
| 10:16:50 | bauzas | anyway, given that, fixing AZs a long way towards, and I don't want us to diverge from the placement effort | |
| 10:16:58 | bauzas | somehow, that has to be a trait | |
| 10:17:02 | johnthetubaguy | bauzas: yeah, in summary, its nuts | |
| 10:17:30 | bauzas | yeah, I'm personnally in favor of deprecating the whole concept of AZs and just leave it at the API level | |
| 10:17:40 | bauzas | instead, computes have location traits | |
| 10:17:57 | johnthetubaguy | so... once we get the cinder "AZ" and routed networks sorted, it gets interesting again | |
| 10:17:59 | bauzas | and instances could request affinity based on those location traits | |
| 10:18:14 | johnthetubaguy | ah, generic location traits are my preference, but AZ is just one of those | |
| 10:18:25 | bauzas | long-term anyway | |
| 10:18:28 | johnthetubaguy | there was a great spec on that from randall nortman, somewhere | |
| 10:18:36 | bauzas | so in the meantime, what we can fix is docs | |
| 10:18:49 | bauzas | but there could be room for some slight improvement tho | |
| 10:18:51 | johnthetubaguy | changing up server groups to deal with generic location specifiers, and multiple of them | |
| 10:18:59 | bauzas | yeah I remember that one | |
| 10:19:09 | johnthetubaguy | thats the one our users really want | |
| 10:19:17 | bauzas | I know | |
| 10:19:29 | johnthetubaguy | cool, just making that the explicit goal I guess | |
| 10:19:37 | johnthetubaguy | we might want to make that a backlog spec actually | |
| 10:20:06 | openstackgerrit | Lee Yarwood proposed openstack/nova master: db: Add attachment_id to block_device_mapping https://review.openstack.org/437597 | |
| 10:20:06 | openstackgerrit | Lee Yarwood proposed openstack/nova master: objects: Add attachment_id to BlockDeviceMapping https://review.openstack.org/437665 | |
| 10:20:06 | bauzas | tbh, affinity based on location specifiers is an old old story I have in my pipe | |
| 10:20:31 | bauzas | anyway, let's move on | |
| 10:20:31 | johnthetubaguy | lyarwood: is that the first steps of the Cinder thing? | |
| 10:21:01 | lyarwood | johnthetubaguy: yeah I guess, I had the bdm uuid changes still in my backlog so thought I'd just do the same again for attachment_id | |
| 10:21:15 | johnthetubaguy | lyarwood: ah, good idea | |
| 10:21:16 | bauzas | wow, Gerrit is in a bad shape | |
| 10:21:33 | johnthetubaguy | lyarwood: I have this one that could do with some eyes: https://review.openstack.org/#/c/373203/ | |
| 10:21:47 | johnthetubaguy | I mean you could just poke your eyes yourself, but I have a lovely spec to do that for you | |
| 10:22:01 | johnthetubaguy | bauzas: so I thought my internet was just slow, but you might be right | |
| 10:22:14 | bauzas | HTTP502 killed me | |
| 10:22:21 | bauzas | so, no, this is not internet :p | |
| 10:22:28 | johnthetubaguy | oh, its tipped over into death land then | |
| 10:22:29 | lyarwood | johnthetubaguy: haha yeah, I'll go over the spec again this morning | |
| 10:22:38 | johnthetubaguy | lyarwood: awesome, thank you | |
| 10:22:50 | johnthetubaguy | I have a feeling I forgot some details from the discussion | |
| 10:23:12 | bauzas | johnthetubaguy: I actually wonder if we couldn't just try to fix default_availability_zone as wezll | |
| 10:23:26 | johnthetubaguy | bauzas: ? | |
| 10:23:40 | bauzas | johnthetubaguy: having it set to none by default would just fix a looooooot of problems | |
| 10:23:47 | bauzas | s/problems/misunderstandings | |
| 10:24:01 | bauzas | johnthetubaguy: and we could then deprecate default_schedule_zon | |
| 10:24:03 | johnthetubaguy | at this point most folks are used to seeing the Nova AZ default I guess, I could go either way | |
| 10:24:38 | johnthetubaguy | hmm, I duno, some folks want to send all builds into a certain zone at times, I think thats why HP public cloud added that | |
| 10:24:45 | bauzas | johnthetubaguy: lemme rephrase, if we could have default_availability_zone having None as default and having default_schedule_zone be deprecated, that would be a nice improvement | |