| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-27 | |||
| 18:07:57 | dansmith | I'd rather fix this and you finish reviewing my patch | |
| 18:08:08 | mriedem | which patch? the kahuna? | |
| 18:08:16 | mriedem | i can't finish what i haven't started | |
| 18:08:25 | dansmith | I'd rather fix this and you start reviewing my patch | |
| 18:08:49 | Tengu | hello! anyone can point me a valid doc for pike and host aggregation + flavor pinning? I'm stuck right now trying to get all working, and I find contradictory docs :/ | |
| 18:09:24 | mriedem | define "flavor pinning" | |
| 18:09:35 | mriedem | you can associate a host aggregate with a specific flavor via metadata / extra specs | |
| 18:09:46 | Tengu | mriedem: "m1.small must run on that aggregate, while m2.small must run on this aggregate" | |
| 18:09:48 | mriedem | however, any other aggregate which is not tied to that flavor can still use it | |
| 18:09:52 | mriedem | there is no exclusion | |
| 18:10:32 | mriedem | Tengu: i think you're looking for this then https://review.openstack.org/#/c/381912/ | |
| 18:10:32 | Tengu | what should I put in the metadata? | |
| 18:10:42 | Tengu | ah, will check that | |
| 18:11:13 | Tengu | 3 days ago? darn… pretty fresh | |
| 18:11:27 | mriedem | that spec has been around quite awhile | |
| 18:11:36 | mriedem | almost a year | |
| 18:11:45 | Tengu | we saw something like that for Icehouse | |
| 18:11:53 | mriedem | see L466 here https://etherpad.openstack.org/p/nova-ptg-queens | |
| 18:12:17 | mriedem | apparently the stakeholders were not yet synergized as promised | |
| 18:12:25 | Tengu | ah, that's for queens… we're running pike :/. don't tell me there isn't anything working right now? | |
| 18:12:46 | mriedem | well, read the spec first and confirm if that's what you're asking for | |
| 18:13:49 | Tengu | looks like what we want, yes. but that's strange, I found some doc, even at Redhat, saying "it works" but without proper example. | |
| 18:14:04 | mriedem | to summarize, we talked about this at the pike ptg in february, we needed to have the various use cases documented in the spec to make sure the solution would cover them, and there were at least 2 stakeholders in the room saying, "we have an out of tree filter that does something like this" and we said, ok read this and tell us if it will replace your out of tree filter, and those people never replied to ack that it does | |
| 18:14:35 | Tengu | erf | |
| 18:14:46 | Tengu | may I explain what I did? | |
| 18:15:13 | Tengu | and point to the doc I followed - maybe a solution might be found | |
| 18:16:25 | Tengu | mriedem: I followed https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/6/html/Administration_Guide/section-host-aggregates.html - I think that one has some equivalent in openstack "open" doc | |
| 18:17:16 | Tengu | mriedem: I activated AggregateInstanceExtraSpecsFilter filter in nova.conf, and created two aggregate - all hosts are in those aggregates (in fact, for now, only two hosts - hence once per group). | |
| 18:17:36 | Tengu | mriedem: the metadata is like "gen1=true" for first aggregate, "gen2=true" for the second. | |
| 18:17:43 | melwitt | Tengu: I think if you tag your flavors with extra_specs and then use the AggregateInstanceExtraSpecsFilter you can do what you want | |
| 18:18:12 | Tengu | after that, the flavor were created, and a metadata was added in the form "gen1=true" for m1.medium, and "gen2=true" for m2.medium | |
| 18:18:18 | mriedem | the problem is, | |
| 18:18:31 | mriedem | flavor1 is associated to agg1 and flavor2 is associated to agg2, | |
| 18:18:36 | mriedem | but that doesn't exclude agg2 from using flavor1 | |
| 18:18:38 | mriedem | and vice versa | |
| 18:18:42 | mriedem | that's the strict isolation problme | |
| 18:18:42 | Tengu | hmm ok. | |
| 18:18:44 | mriedem | *problem | |
| 18:18:56 | Tengu | not a really big issue - for now, we have "no host found" in fact | |
| 18:19:01 | melwitt | I thought if the flavors were tagged it would require that key to pass? | |
| 18:19:24 | mriedem | honestly i'd have to re-read https://review.openstack.org/#/c/381912/ | |
| 18:19:33 | melwitt | I'm reading it again now | |
| 18:19:35 | mriedem | i am definitely not an expert here on the existing capabilities and gaps | |
| 18:19:36 | Tengu | melwitt: same for me - actually, for now, we're unable to start any instance because it doesn't find any host to run it | |
| 18:20:45 | Tengu | mriedem: but maybe it's "just" the metadata format that fails me. is there any doc for that? | |
| 18:20:57 | melwitt | Tengu: and you added gen1=true and gen2=true to your host aggregates? | |
| 18:21:11 | Tengu | yup, as a metadata as well | |
| 18:21:40 | mriedem | the now deleted ops guide might have had something specific for this | |
| 18:21:48 | Tengu | :'( | |
| 18:22:14 | cdent | it got moved to the wiki? | |
| 18:22:14 | Tengu | I found a doc saying the metadata on the flavor should be in the form aggregate_instance_extra_specs:gen1='true' | |
| 18:22:20 | Tengu | but that doesn't work either | |
| 18:22:20 | cfriesen_ | mriedem: dansmith: just saw the mention of microversion 2.47...there was already a call to "instance.get_flavor()" previously, so I had assumed it would get the whole flavor. I suspect you're right that it's lazy-loading extra-specs. | |
| 18:22:33 | mriedem | it would be in here if it existed https://docs.openstack.org/nova/latest/admin/index.html | |
| 18:22:40 | dansmith | cfriesen_: no it's policy | |
| 18:22:55 | dansmith | cfriesen_: the policy is checked per instance now, which is an fs call at least | |
| 18:23:09 | cfriesen_ | dansmith: ah...I had a networking glitch, missed some irc. | |
| 18:23:43 | cfriesen_ | dansmith: fix is what, cache the policy? | |
| 18:23:56 | dansmith | cfriesen_: check once per list and not once per instance | |
| 18:24:01 | dansmith | cfriesen_: I'm cooking it up now | |
| 18:24:03 | dansmith | smells like bacon | |
| 18:24:16 | cfriesen_ | dansmith: do we even need that? couldn't we check it the first time and cache it? | |
| 18:24:26 | dansmith | cfriesen_: that's what I just said | |
| 18:24:37 | cfriesen_ | I meant the first time on process startup | |
| 18:24:54 | mriedem | Tengu: i've seen a better doc than that red hat one, sec | |
| 18:25:12 | dansmith | cfriesen_: it depends per request | |
| 18:25:46 | Tengu | mriedem: that would be nice :) | |
| 18:25:47 | cfriesen_ | dansmith: ah, of course | |
| 18:25:53 | melwitt | Tengu: I found this doc https://docs.openstack.org/ocata/config-reference/compute/schedulers.html#host-aggregates | |
| 18:26:04 | dansmith | mriedem: confirmed the knee in the same place on master | |
| 18:26:05 | Tengu | I've also followed https://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/ - but failed. | |
| 18:26:27 | Tengu | melwitt: ah, ocata, might work, pike is just one version ahead. will check that, thanks! | |
| 18:26:43 | mriedem | melwitt: yeah https://docs.openstack.org/ocata/config-reference/compute/schedulers.html#example-specify-compute-hosts-with-ssds | |
| 18:26:57 | mriedem | openstack flavor set --property aggregate_instance_extra_specs:ssd=true ssd.large | |
| 18:27:08 | Tengu | duh… ok, I was also on that one -.-' | |
| 18:27:17 | melwitt | Tengu: the main thing I saw ppl run into a snag is that you apparently have to use that prefix when you set the key on the flavor but NOT use it when you set the key on the aggregate | |
| 18:27:37 | Tengu | melwitt: yup, I have done that | |
| 18:27:45 | Tengu | but to no success until now. | |
| 18:27:46 | mriedem | and that key prefix is only used with AggregateInstanceExtraSpecsFilter | |
| 18:27:53 | cfriesen_ | was just going to mention the filter | |
| 18:27:56 | mriedem | and you have to make sure you have that enabled | |
| 18:28:08 | melwitt | Tengu: yeah, did you add that filter to your configured filters for the FilterScheduler? | |
| 18:28:12 | melwitt | in nova.conf | |
| 18:28:16 | Tengu | it's enabled. should it be in the first position? | |
| 18:28:20 | mriedem | no | |
| 18:28:24 | Tengu | melwitt: yep, it's present | |
| 18:28:28 | mriedem | order only matters for performance | |
| 18:28:43 | Tengu | and I rebooted the controllers in order to ensure all is running at the latest config version | |
| 18:28:47 | melwitt | Tengu: no but you will want to check nova-scheduler logs to make sure some other filter isn't rejecting it | |
| 18:28:48 | Tengu | mriedem: hmm ok. | |
| 18:29:12 | melwitt | at DEBUG log level. it's possible something else is going wrong and not the key match for the metadata | |
| 18:29:16 | Tengu | melwitt: yup, but I didn't see anything. the instance "directory" was created on the right node in /var/lib/nova/instances | |
| 18:29:31 | melwitt | if you're getting NoValidHost you should see something | |
| 18:29:49 | Tengu | but after a while, paff, directory is removed, and crash, "no host found"… although it actually HAD found a host | |
| 18:30:00 | melwitt | unless a compute host rejected the request in which case you should see an error in the nova-compute logs or the nova-conductor logs | |
| 18:30:08 | Tengu | hmmm. | |
| 18:30:29 | Tengu | will check that one. | |
| 18:30:53 | melwitt | the way it works is if scheduling filters all pass, it goes to nova-compute, if something fails while it builds it, it will tear it down, log stuff, and try to reschedule to another host if you have retries configured | |
| 18:31:05 | Tengu | what would be the patter of a rejection in nova-compute.log ? | |
| 18:31:16 | Tengu | hmm ok. | |