Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-07
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? :)
23:35:26 melwitt openstack_newb_: you also have to set the keys on your images, did you do that?
23:35:35 mriedem mtreinish: https://review.openstack.org/#/q/I29fac80d08baf64bf69e54cf673e55123174de2a
23:35:43 melwitt jaypipes: yeah, it's very nice here :)
23:35:49 jaypipes good to hear!
23:36:35 mriedem mtreinish: this is the tempest test for ^ but it's hit a niggle as johnthetubaguy would say https://review.openstack.org/#/c/516396/5/tempest/api/compute/servers/test_server_actions.py@322
23:36:40 mriedem i would never say that word, except just now
23:38:44 melwitt jaypipes: wish you and julie were here too
23:39:07 jaypipes melwitt: well, hopefully I'll see you in Dublin eh? :)
23:39:26 melwitt yeah :)
23:39:48 openstack_newb_ Thank you! So having "aggregate_image_properties_isolation_namespace = None" is fine
23:40:59 openstack_newb_ I haven't set the keys on my images, I set os=cirros and os=linux ....
23:41:18 openstack_newb_ isn't that the same thing?
23:41:53 openstack_newb_ For example : glance image-update --property os=linux a51553ae-7b85-4b79-92ec-33a20221e611
23:42:39 openstack_newb_ And then in my aggregates I did for example: nova aggregate-set-metadata linux os=linux
23:43:04 openstack_newb_ But I'm not seeing it work at all .... the filter still returns two hosts in the log
23:45:59 melwitt sounds like you're having this same issue https://ask.openstack.org/en/question/30934/aggregateimagepropertiesisolation-returns-hosts-that-shouldnt-be-applicable/
23:46:28 melwitt you only have two hosts though and each one is in an aggregate, one tagged os=cirros and one tagged os=linux, right?
23:46:39 openstack_newb_ Yes... exactly
23:46:49 openstack_newb_ one tagged linux and one cirros
23:47:26 openstack_newb_ and each aggregate has one of the hosts ... should work - right?
23:48:28 melwitt yeah. did you set the aggregate_image_properties_isolation_namespace option? if you don't want a namespace, then don't set it. I think if you set it to "None" it might expect you do prefix your tags with "None" or something
23:48:45 openstack_newb_ OK... will disable that
23:48:46 melwitt s/do/to/
23:49:03 openstack_newb_ Might be the problem
23:49:12 openstack_newb_ Thank you!
23:49:32 melwitt okay, hope that works
23:54:27 openstack_newb_ No luck but I'm seeing a warning in the scheduler log ... Host 'hv142.ostk.sc1.corp.gq1.yahoo.com' has a metadata key 'os' that is not present in the image metadata.

Earlier   Later