Earlier  
Posted Nick Remark
#openstack-nova - 2017-09-27
18:00:56 mriedem ...
18:00:58 mriedem jesus
18:00:58 dansmith that might explain why mriedem sees a bigger hit
18:01:15 dansmith you know what
18:01:19 mriedem where is cfriesen when it's time to talk about performance degradation?
18:01:19 dansmith I think we might want to backport this fix
18:01:27 mriedem we for sure do
18:01:33 dansmith I mean.. maybe
18:01:44 mriedem the policy thing is backportable
18:01:46 mriedem check once
18:01:54 dansmith we could leave it and just further relegate pike to the trashcan of releases
18:01:59 mriedem ha
18:02:02 mriedem but,
18:02:06 mriedem ocata is already in that trashcan
18:02:09 dansmith haha
18:02:36 mriedem i've literally been sending emails internally for weeks saying, "once you upgrade to pike, this should all be much better"
18:02:46 mriedem should*
18:02:57 mriedem *: not actual statement of fact backed up by any evidence
18:03:19 melwitt heh
18:05:23 sdague it would be nice if a context only evaluated a particular policy rule once
18:05:36 openstackgerrit John Garbutt proposed openstack/nova-specs master: Support traits in the Ironic driver https://review.openstack.org/507052
18:06:29 sdague because it's going to be a little awkward to handle cases where you need to send down the preevaluted permission through a bunch of function calls
18:07:25 mriedem this one shoudn't be too terrible
18:07:28 mriedem dansmith: are you started on the fix?
18:07:29 dansmith right this one should be easy
18:07:37 dansmith mriedem: no but I can
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

Earlier   Later