| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-07 | |||
| 15:27:45 | snasir | javpipes: Oh so does that mean, that I can deploy baremetal nodes even if i dont set scheduler_host_manager=ironic_host_manager ? Is the regular host_manager smart to determine that | |
| 15:28:08 | snasir | jaypipes: Oh so does that mean, that I can deploy baremetal nodes even if i dont set scheduler_host_manager=ironic_host_manager ? Is the regular host_manager smart to determine that | |
| 15:28:37 | jaypipes | snasir: no, you still need to do the ironic_host_manager thing unfortunately. it's a giant mess. | |
| 15:29:42 | jaypipes | snasir: I don't know why it's still like that :( | |
| 15:30:01 | jaypipes | snasir: we really should just remove the ironic_host_manager entirely, IMHO | |
| 15:30:30 | snasir | jaypipes: Ok Basically I'm trying to figure out if I can share nova services to spawn both BM nodes and VMs. I know I have to have two nova-computes running (with their respective drivers), and looks like I'll need two nova-schedulers running too with their respective host_managers... Am i correct in saying that ? | |
| 15:34:29 | jaypipes | snasir: I believe so, yes. | |
| 15:34:58 | jaypipes | snasir: though I would point you to Ironic operators to get a definitive answer on that. | |
| 15:35:05 | jaypipes | snasir: of course, most are in Sydney :) | |
| 15:35:25 | jaypipes | snasir: so probably a good idea to post to the openstack@ or openstack-operators@ mailing list. | |
| 15:36:05 | jaypipes | snasir: I'm particularly thinking of James Penick as a possible resource for you. Usually he's on IRC as "penick", but he's in Sydney this week. | |
| 15:38:06 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: instance_mapping/request_spec records exist even after the instances are archived https://review.openstack.org/515034 | |
| 15:38:09 | snasir | jaypipes: I tried asking on the Ironic IRC, but couldn't get a definite answer....Thanks I'll post on @openstack.. Its too early in Sydney atm :) | |
| 15:38:21 | jaypipes | snasir: too late :) | |
| 15:38:43 | snasir | jaypipes: lol, yeah too late i meant, haha | |
| 15:47:31 | efried | jaypipes FYI, repeat performance at the dentist. Back in 60-90m | |
| 16:32:42 | openstackgerrit | C Leavett-Brown proposed openstack/nova master: Modify nova routing table to process null requests https://review.openstack.org/518119 | |
| 16:34:58 | jmlowe | jaypipes: you around? | |
| 16:35:10 | jaypipes | jmlowe: I am indeed. :) | |
| 16:36:03 | jmlowe | My knee jerk reaction is to just add a second test to the test_update_volume_xml unit test but I suspect that isn't the right thing to do | |
| 16:36:32 | jaypipes | jmlowe: I think your knee-jerk reaction is good. :) | |
| 16:37:09 | jaypipes | jmlowe: just make sure you put a little code comment in the test saying basically "make sure we don't change the disk device address if we're live migrating"... | |
| 16:38:10 | jmlowe | ok, I think I have all the stuff from a live broken one, will cover virtio-scsi and rbd not just virtio-block and iscsi once I'm done | |
| 16:39:27 | jmlowe | not sure my reply to your comment actually made it in there, changing a device address during cold migration is bad but doesn't cause a fatal error for the operator just the user of the vm | |
| 16:40:41 | jaypipes | gotcha | |
| 17:18:00 | jmlowe | here goes, my confidence in the unit test is a little shaky | |
| 17:18:05 | openstackgerrit | Mike Lowe proposed openstack/nova master: live-mig: keep disk device address same https://review.openstack.org/518022 | |
| 17:46:20 | efried | jaypipes Here's an interesting bug. I haven't fully nailed it down yet, but I think it works like this: | |
| 17:47:05 | efried | My non-sharing RP has one resource class. My sharing RP has three, including the same one as the non-sharing RP. I ask for all three. The candidates I get back are all effed up. | |
| 17:48:15 | efried | I get back three candidates. One of them is the common RC plus *one* of the others; and one of them is similar but with the *other* non-common RC (that is, two of the candidates come back with only two out of the three requested RCs) | |
| 17:48:46 | efried | The third candidate is the one you would expect: all three resources from the RP that has all three. | |
| 17:49:29 | efried | Now, I know this represents a couple things we don't support. But it seems to point to a flaw in the logic somewhere that should *never* be allowing a candidate that doesn't have all the requested resources. | |
| 17:58:41 | jaypipes | efried: correct. an allocation request should always contain all of the requested resources, provided by one or more resource providers. | |
| 17:59:16 | efried | jaypipes I'll write up a specific test case. Though it'll be pretty weird from a non-sharing-RP-is-always-the-compute-node perspective. | |
| 18:00:12 | openstackgerrit | Eric Fried proposed openstack/nova master: Test alloc candidates with same RC in cn & shared https://review.openstack.org/513149 | |
| 18:00:46 | jaypipes | efried: l | |
| 18:00:49 | jaypipes | efried: k | |
| 18:03:42 | efried | jaypipes Actually, I think I was in a situation where both of the RPs were marked as sharing. (And there would be no non-sharing RPs anywhere in the db) | |
| 18:05:26 | jaypipes | efried: in that case, if there were no non-sharing resource providers, there should be allocation request results. | |
| 18:05:51 | efried | jaypipes *no* allocation request results? | |
| 18:06:39 | jaypipes | efried: correct. allocation requests must contain at least one non-sharing provider. | |
| 18:07:00 | jaypipes | efried: because you can't send a boot request to a shared storage provider... | |
| 18:07:01 | efried | jaypipes So I suspect some of the stuff you did in the refactor will "fix" this. I'll write it up and confirm. | |
| 18:07:14 | jaypipes | k | |
| 18:07:26 | efried | jaypipes Well, again, that's assuming we're coming out of GET /allocation_candidates wanting to do a boot :) | |
| 18:07:49 | jaypipes | efried: yes, that is a basic assumption of GET /allocation_candidates right now. | |
| 18:07:54 | efried | ack | |
| 18:08:22 | openstackgerrit | Eric Fried proposed openstack/nova master: Test alloc candidates with same RC in cn & shared https://review.openstack.org/513149 | |
| 18:19:06 | efried | jaypipes Interesting. So before the refactor stack, the results are as I stated above - we have three candidates where two of them don't even have all the resources. | |
| 18:19:34 | efried | jaypipes After the refactor stack, the result is: we get two candidates. One has all the resources from the one RP; the other has the common resource from the other RP and the non-common resources from the first RP. | |
| 18:19:42 | efried | jaypipes Which is in fact how I think it *should* work - but is still "wrong" per your assertion that we should get back no results. | |
| 18:20:58 | efried | Soooo... I'll open a bug and comment the hell out of the test case I guess? | |
| 18:26:10 | efried | Dude, I added a compute RP providing one of the other resources and got back exactly the four candidates I would expect. IMO this ain't broke and we shouldn't fix it. | |
| 18:27:04 | efried | The compute-as-non-sharing-RP limitation will be imposed by the modeling from compute-ish consumers of placement, and shouldn't be imposed by placement itself. | |
| 19:05:43 | openstackgerrit | Mike Lowe proposed openstack/nova master: live-mig: keep disk device address same https://review.openstack.org/518022 | |
| 19:09:12 | openstackgerrit | Eric Fried proposed openstack/nova master: Test allocation_candidates with only sharing RPs https://review.openstack.org/518382 | |
| 19:09:18 | efried | jaypipes ^ thar she blows. | |
| 19:09:28 | efried | I got a cool bug number: 1730730 | |
| 19:53:46 | openstackgerrit | C Leavett-Brown proposed openstack/nova master: Modify nova routing table to process null requests https://review.openstack.org/518119 | |
| 19:56:56 | snasir | Hi, is it possible to have 2 nova-schedulers running on the same host ? One to manage baremetal nodes while the other for VMs? Can nova-api figure out which one is for what purpose if that is the case ? Thanks | |
| 20:22:27 | efried | jaypipes If I ask for _get_provider_ids_having_all_traits() with an empty trait list, I ought to get back... all the RPs, right? | |
| 20:32:01 | efried | jaypipes Okay, I see the above is accounted for by the caller. But that method is still broken for RPs that don't have any traits. | |
| 20:36:41 | efried | ...which again isn't a problem if it's never invoked with no traits. | |
| 20:36:45 | efried | Ignore me. | |
| 20:45:12 | jmlowe | let me ask something, should the resource_classes table in my placement db be empty? | |
| 20:46:18 | efried | jmlowe No | |
| 20:46:30 | efried | jmlowe It ought to have at least the standard classes in it. | |
| 20:46:35 | efried | jmlowe Wait, what version? | |
| 20:46:42 | jmlowe | ocata | |
| 20:46:49 | efried | ah. Don't know, then. | |
| 20:47:32 | jmlowe | I keep seeing things get way overcommitted, guessing it's trying to look up the allocations but doesn't find anything due to joining by name | |
| 20:48:50 | efried | jmlowe Based on https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/custom-resource-classes.html I would expect you should see the standard resource classes even in ocata. | |
| 20:48:58 | jmlowe | I'm guessing I can probably just create the three rows by hand if I could figure out the right name for mem cpu and disk | |
| 20:49:14 | efried | MEMORY_MB, VCPU, DISK_GB | |
| 20:49:20 | efried | But it's worrisome that those aren't there. | |
| 21:07:27 | snasir | Hi, I'm running into this error with nova-compute when i try to spawn baremetal nodes with nova-compute , "ERROR nova.compute.monitors.vswitch.vswitch_monitor [req-d9990173-da78-42b0-b2e7-911166c4c2f6 - - - - -] Could not get: http://localhost:9000/v1/engine/stats, error=HTTPConnectionPool" | |
| 21:07:58 | snasir | Can anybody tell me how to bypass or resolve this ? Is there some setting in nova.conf, that can prevent this vswitch check ? Thanks | |
| 21:31:48 | mriedem | andreas_s: can you disable zkvm CI from running on stable/newton changes? | |
| 21:40:37 | efried | jaypipes Do you have local changes to the refactor series? | |
| 21:41:27 | efried | jaypipes I'd like to add tests to https://review.openstack.org/#/c/517027/ | |
| 21:43:47 | jaypipes | efried: go for it. I don't have any local changes. | |
| 21:53:35 | openstackgerrit | Eric Fried proposed openstack/nova master: required traits for no sharing providers https://review.openstack.org/517027 | |
| 21:53:35 | openstackgerrit | Eric Fried proposed openstack/nova master: Add ProviderSummary.resource_class_names @property https://review.openstack.org/517646 | |
| 21:53:36 | openstackgerrit | Eric Fried proposed openstack/nova master: handle traits with sharing providers https://review.openstack.org/517119 | |
| 21:53:39 | efried | jaypipes Okay, added tests on both https://review.openstack.org/#/c/517027/ and https://review.openstack.org/#/c/517119/ | |
| 21:53:55 | efried | jaypipes Also fixed alex_xu's nit on the former. | |
| 21:56:22 | jaypipes | efried: k, thx | |
| 23:02:49 | openstack_newb_ | Hi I'm new to Openstack work ... I'm trying to create get the "AggregateImagePropertiesIsolation" filter working in NOVA (Ocata version) to schedule instances to each of two hypervisors based on OS version, I have created two aggregates and added a host each, I have set properties for each of two os versions - can't get it to work. It is not clear to me from the documentation what if anything should | |
| 23:02:49 | openstack_newb_ | be contained in the config value 'aggregate_image_properties_isolation_namespace' ??? | |
| 23:03:11 | openstack_newb_ | Can anyone help here? | |
| 23:05:39 | jaypipes | openstack_newb_: unfortunately, this is the OpenStack summit week and most folks are in Sydney, Australia at the summit (it's 10am local time there). Plus, this channel isn't really for support. I'd suggest emailing the openstack@ mailing list with your question, ok? | |
| 23:06:04 | openstack_newb_ | OK ... thank you.. yes... just desperation that brought me here | |
| 23:09:30 | jaypipes | openstack_newb_: which documentation are you following? | |
| 23:21:09 | openstack_newb_ | I've found several differing explanations by surfing around - seems to pertain to earlier versions however. My API node just seems to "round robin" instances despite my settings | |
| 23:22:52 | openstack_newb_ | Can you point me at the definitive version perhaps? None that I've so far seen really explain the use of these config values | |
| 23:34:38 | mriedem | dansmith: https://review.openstack.org/#/q/I29fac80d08baf64bf69e54cf673e55123174de2a | |
| 23:34:42 | melwitt | openstack_newb_: the config option is if you want to require specific namespace(s) for the keys related to aggregate image properties. you don't have to set it | |
| 23:35:02 | jaypipes | oh, look, it's Sydney nova folks :) | |
| 23:35:09 | melwitt | hi jaypipes :) | |
| 23:35:23 | jaypipes | melwitt: hey Melanie! having a good time in Roo-country? :) | |