| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-22 | |||
| 14:05:55 | mriedem | because it would auto load balance in the background cluster and we wouldn't know about the resource tracking changes, except the virt driver would hook back into the resource tracker and fiddle things for us, which we didn't want | |
| 14:06:08 | mriedem | johnthetubaguy: ok so it literally is only implemented by one virt driver, and does nothing :) | |
| 14:06:12 | johnthetubaguy | mriedem: yeah, that | |
| 14:06:18 | mriedem | that's aweoms | |
| 14:06:21 | mriedem | *awesome | |
| 14:06:23 | johnthetubaguy | agreed | |
| 14:06:46 | mriedem | i guess the description on https://docs.openstack.org/developer/nova/support-matrix.html#operation_maintenance_mode is a lie then | |
| 14:08:26 | dansmith | mriedem: yeah it's always been xen-only | |
| 14:08:38 | dansmith | and very specific to how its own maintenance mode works, IIRC | |
| 14:08:53 | dansmith | which is why we didn't use it for force-down | |
| 14:09:04 | johnthetubaguy | mriedem: yeah, I think it might stop new instances being built, but thats it | |
| 14:09:38 | johnthetubaguy | I think its time to kill os-hosts | |
| 14:09:45 | johnthetubaguy | in the deprecate sense of kill | |
| 14:10:03 | mriedem | johnthetubaguy: yeah, i'll send something to the ML to see if anyone is actually using it | |
| 14:10:15 | johnthetubaguy | sounds good | |
| 14:10:15 | mriedem | i think i might draft a spec to go before this other one, | |
| 14:10:25 | johnthetubaguy | ah, yeah, that makes sense | |
| 14:10:37 | mriedem | so we could deprecate os-hosts first, and then to the uuid things on os-services and os-hypervisors | |
| 14:16:02 | mriedem | jaypipes: were you going to submit a forum topic session for placement on http://forumtopics.openstack.org/ or should i just do that? | |
| 14:17:24 | mriedem | bauzas: i did not see a discussion between you and ttx about the forum, no | |
| 14:18:13 | bauzas | dansmith: even after reviewing my comment ? | |
| 14:18:31 | bauzas | oh wait, you got commented too | |
| 14:18:53 | openstackgerrit | Andrey Volkov proposed openstack/nova-specs master: User-controlled SR-IOV ports allocation https://review.openstack.org/182242 | |
| 14:19:00 | bauzas | mriedem: basically got more explanations | |
| 14:21:18 | jaypipes | mriedem: I had put a couple ideas into the NFV/Telcom forum area: https://etherpad.openstack.org/p/BOS-UC-brainstorming-Telecom&NFV | |
| 14:21:20 | bauzas | dansmith: okay, it's clear now that updating API flavors should be done after all nodes are Pike and before Queens | |
| 14:21:38 | mriedem | jaypipes: in case you haven't heard, the brainstorming etherpads are so last week | |
| 14:21:51 | bauzas | dansmith: and the nova-status check pre-flight test could warn them if not | |
| 14:21:52 | mriedem | jaypipes: this week the new hotness is submitting a session idea to forumtopics.o.o | |
| 14:22:00 | mriedem | jaypipes: and those get voted on by the TC/UC/Foundation | |
| 14:23:30 | mriedem | if you want i can just submit something generic for placement, | |
| 14:23:39 | jaypipes | mriedem: go for it. | |
| 14:23:41 | mriedem | that will be mostly geared toward ops and devs | |
| 14:23:42 | mriedem | ok | |
| 14:23:57 | mriedem | i'll just take dansmith's cells abstract and s/cells/placement/ :) | |
| 14:24:06 | dansmith | heh | |
| 14:26:25 | ttx | mriedem: FYI http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-03-22.log.html#t2017-03-22T08:26:04 | |
| 14:26:42 | ttx | mriedem: but then I also answered on the ML thread | |
| 14:27:16 | mriedem | yup i'm reading the ML now | |
| 14:27:25 | dansmith | mriedem: I just hit your uuid spec, btw | |
| 14:27:33 | mriedem | ok | |
| 14:37:46 | jroll | bauzas: thanks for the spec merge :) | |
| 14:40:06 | stvnoyes | good morning. I am having a lot of trouble in my devstack env after updating to latest. The error is "Failed to retrieve resource provider record from placement API". It seems to have started with this change: "virt: add get_inventory() virt driver API method". The [placement] info in nova.conf looks ok. any ideas? Thanks. | |
| 14:44:52 | sfinucan | jaypipes: I've what looks like a frickin' essay left in https://review.openstack.org/#/c/364468/ :D | |
| 14:46:21 | jaypipes | sfinucan: I shall respond, then, in haiku form. | |
| 14:48:26 | cdent | jaypipes will respond, in the form of a haiku, we all wait breath held | |
| 14:48:50 | jaypipes | cdent: :) | |
| 14:50:17 | mriedem | bauzas: you've got some unit test failures in https://review.openstack.org/#/c/391060/ | |
| 14:50:39 | mriedem | stvnoyes: are you using ironic? | |
| 14:51:04 | bauzas | mriedem: yeah, need to address those | |
| 14:51:10 | bauzas | in a meeting atm | |
| 14:52:39 | mriedem | bauzas: ok, after your meeting, can you update the whiteboard on plans for https://blueprints.launchpad.net/nova/+spec/request-spec-use-by-compute | |
| 14:52:55 | bauzas | roger. | |
| 14:53:27 | jaypipes | sfinucan: done. | |
| 14:53:58 | openstackgerrit | Mikhail Feoktistov proposed openstack/nova master: Remove fstype param from ploop init https://review.openstack.org/444970 | |
| 14:54:13 | jaypipes | sfinucan: I'm sure cdent will appreciate my review comment. | |
| 14:54:29 | sfinucan | jaypipes: Ha! | |
| 14:54:52 | cdent | nice | |
| 14:55:41 | cdent | jaypipes did respond, it was indeed an haiku, much celebration | |
| 14:55:51 | cdent | a not an, but close enough | |
| 14:56:31 | stvnoyes | @mriedem: no, no ironic | |
| 14:57:24 | sfinucan | jaypipes: Out of curiosity, where do weighers fit into resource providers? | |
| 14:57:53 | sfinucan | I'm assuming they'll be the same, only querying resources rather than nova-compute hosts directly? | |
| 14:58:00 | sfinucan | ...or something like that | |
| 14:59:19 | dansmith | sfinucan: I see filters as always being a nova only thing (or project only) | |
| 14:59:29 | dansmith | sfinucan: like, placement can replace a bunch of the filters, but not all | |
| 14:59:48 | mriedem | stvnoyes: then that patch would not impact you | |
| 14:59:59 | mriedem | stvnoyes: the only virt driver that implements that get_inventory method right now is the ironic virt driver | |
| 15:00:00 | dansmith | placement may be able to order things a bit, I guess, but the nova will always need some filters and weighers for very nova-specific things | |
| 15:01:34 | sfinucan | Makes sense. I fail to see how affinity groups would fit into the placement model | |
| 15:01:51 | stvnoyes | mriedem: hmm, ok thx. i will dig into it some more. It's got to be something in my env as no one else is seeing this. | |
| 15:02:37 | jaypipes | sfinucan: they don't currenlty. | |
| 15:03:32 | jaypipes | sfinucan: we return just the filtered set of providers to the scheduler and the scheduler pulls a giant ComputeNode.get_all_by_uuids() query and uses that information passed in to the weighers. | |
| 15:03:57 | jaypipes | and yeah, what dansmith said :) | |
| 15:13:11 | sdague | jaypipes: so how does that impact cross service placement if all the rules aren't in placement? | |
| 15:13:23 | frickler | mriedem: it seems you missed to update releasenotes/notes/libvirt-script-with-empty-path*yaml with https://review.openstack.org/448203, will you do a follow-up? | |
| 15:13:43 | openstackgerrit | Sujitha proposed openstack/nova master: Add description to policies in cloudpipe.py https://review.openstack.org/448271 | |
| 15:13:45 | jaypipes | sdague: sorry, not following you. can you elaborate with an example? | |
| 15:14:24 | sdague | we are in a future where cinder is using placement. And there is a desire for locality between volumes and instances. | |
| 15:16:45 | jaypipes | sdague: if a nova instance is booted with a volume UUID, we would look up the traits and aggregates associated with the provider of that volume and winnow the set of compute node providers based on that list of traits and aggregates. | |
| 15:17:05 | mriedem | frickler: i guess i hadn't planned on updating that release note since it's already released | |
| 15:17:12 | mriedem | frickler: if we mention anything, it would be in a new release note | |
| 15:18:02 | openstackgerrit | Sujitha proposed openstack/nova master: Add description to policies in certificates.py https://review.openstack.org/448267 | |
| 15:19:03 | mriedem | jaypipes: sdague: this also came up in the dev ML http://lists.openstack.org/pipermail/openstack-dev/2017-February/112903.html | |
| 15:19:06 | mriedem | for that exact use case | |
| 15:19:17 | mriedem | jaypipes: if you have thoughts or details on how to solves that, please reply to that thread | |
| 15:19:30 | openstackgerrit | Sujitha proposed openstack/nova master: Add description to policies in admin_actions. https://review.openstack.org/440829 | |
| 15:19:56 | jaypipes | mriedem: ok | |
| 15:21:20 | frickler | mriedem: I think the release notes are confusing anyway. 14.0.4 lists the known issue, 14.0.5 doesn't list it anymore, so one could assume it being resolved there already | |
| 15:21:43 | sneti | johnthetubaguy, Can you please review https://review.openstack.org/#/c/396420/. I have just resolved merge conflict. | |
| 15:23:06 | mriedem | johnthetubaguy: on the host power action (shutdown/reboot) API, is the nova-compute service running on a separate host managing the backend hypervisor cluster | |
| 15:23:07 | mriedem | ? | |
| 15:23:42 | mriedem | johnthetubaguy: because otherwise the sync_instance_power_states periodic wouldn't be running if the nova-compute service is dead (because you stopped the host), and we wouldn't update the instance states to show them as shutdown | |
| 15:24:07 | johnthetubaguy | mriedem: not usually, its generally in a VM on that host | |
| 15:24:19 | johnthetubaguy | mriedem: yes, the power status stuff is all broken I suspect | |
| 15:24:48 | mriedem | ok, so if you run that api to stop your host, you effecitvely kill nova-compute managing the guests on that host :) | |
| 15:25:04 | mriedem | reboot would/should eventually come back, the service might be disabled for a time via the servicegroup health check, | |
| 15:25:06 | johnthetubaguy | yep | |
| 15:25:18 | mriedem | but otherwise the instances are never 'stopped' in the nova db status sense | |
| 15:25:19 | johnthetubaguy | I am fairly sure we only added that because the API was there | |