| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-04 | |||
| 15:40:03 | dansmith | because there was "no-impact-upgrades" proposed at one point that covered that bit | |
| 15:40:16 | cdent | nobody is ever sure | |
| 15:40:36 | cdent | smcginnis tried to kill the accessible tag but then someone came along and said, but wait, nova and cinder match that one | |
| 15:40:57 | mriedem | there are like 5-6 upgrade tags | |
| 15:41:12 | mriedem | i didn't know what a "controlled resource" was in reading the description, | |
| 15:41:14 | mriedem | assumed it was a VM, | |
| 15:41:25 | mriedem | but without examples in the tag descriptions it's hard to know what the author intended | |
| 15:42:04 | mriedem | i know what it means to the ATF... | |
| 15:42:06 | cdent | in nova’s case it does mean that running vm survives and can be worked with (accessed) through an upgrade | |
| 15:42:21 | mriedem | so what is "no-impact-upgrades"? | |
| 15:42:22 | cdent | but yeah, it’s entirely unclear | |
| 15:42:27 | cdent | dunno! :) | |
| 15:42:31 | cdent | I don’t like tags | |
| 15:42:33 | mriedem | weeeeeeeee | |
| 15:42:44 | mriedem | i don't either really, but probably for slightly different reasons | |
| 15:43:08 | cdent | i cannot say, since I dont know why you don’t like | |
| 15:43:19 | mriedem | no one in the dev teams probably thinks about tags | |
| 15:43:25 | mriedem | e.g. there is no bi-annual audit | |
| 15:43:39 | mriedem | i do'nt know what stick or carrot exists for us to care about tags | |
| 15:44:09 | mriedem | and i do'nt know if people consuming openstack are really giving them much weight, but maybe they are depending on project, | |
| 15:44:22 | mriedem | e.g. if there are 3 monitoring type projects, you'd care about what tags are applied to those | |
| 15:44:25 | cdent | the stick or carror aspect is part of my concerns | |
| 15:46:53 | sdague | mriedem: a bunch of them were going to be purged | |
| 15:47:16 | sdague | mriedem: there is a distinction somewhere about 0 api downtime | |
| 15:47:23 | sdague | which is important for things like keystone | |
| 15:47:35 | sdague | because, if keystone is out, operations fail randomly | |
| 15:51:22 | mriedem | i think that's the zero-downtime-upgrade one | |
| 15:51:34 | mriedem | the zero-impact-upgrade one is about performance during upgrade, as my understanding | |
| 15:51:46 | mriedem | so there are subtle differences | |
| 15:51:47 | dansmith | yeah something | |
| 15:51:58 | mriedem | replied to the ML thread on this, | |
| 15:52:16 | mriedem | but i'd think zero-impact-upgrade re perf would be something like strain on the network doing live migrations while upgrading compute hosts | |
| 15:52:56 | mriedem | but i'm not sure how nova would really have anything to do with that, it seems like a deployment topology decision | |
| 15:53:45 | mriedem | let's put that tag on openstack public clouds :) | |
| 15:54:46 | mriedem | onto another topic, sounds like cern would like to be able to pass user_data to rebuild... | |
| 15:55:05 | mriedem | sounds like they rely on rebuild pretty heavily | |
| 16:01:26 | cfriesen | does anyone know why AggregateImagePropertiesIsolation and AggregateInstanceExtraSpecsFilter behave differently? It's confusing... | |
| 16:11:09 | bauzas | cfriesen: the reason is "historical" | |
| 16:11:22 | bauzas | in other words, two efforts made by two teams | |
| 16:15:43 | cfriesen | bauzas: why am I not surprised. :) | |
| 16:16:23 | bauzas | the problem is that changing a filter behaviour is something tricky | |
| 16:17:00 | bauzas | I'd prefer providing a new filter that would do both image and flavor checks with the same behaviour, and in the meantime deprecate the old two filters | |
| 16:17:22 | bauzas | so we would be super clear that the behaviour is changing | |
| 16:17:40 | bauzas | keep those filters for a couple of releases, and then remove them from the tree | |
| 16:17:49 | bauzas | if people want to keep them out-of-tree, I'm fine | |
| 16:18:02 | bauzas | cfriesen: fancy proposing that ? :) | |
| 16:18:14 | bauzas | after all, it's just filters | |
| 16:19:21 | cfriesen | bauzas: Will propose it internally. What do you think of my proposal for https://review.openstack.org/#/c/381912/ to have the "strictness" of the isolation be scoped to individual keys? | |
| 16:19:23 | mriedem | i thought that's what the new psec was | |
| 16:19:34 | mriedem | yeah that one | |
| 16:20:07 | cfriesen | mriedem: they're just proposing adding a new boolean flag on either the image or flavor to say the matching is strict....but that doesn't factor in that the behaviour of the two filters is different | |
| 16:20:20 | dansmith | edleafe: are you revising your alt hosts thing? | |
| 16:20:28 | cfriesen | mriedem: and I think it'd make more sense to allow strict matching on a per-key basis, specified in the aggregate metadata | |
| 16:20:39 | edleafe | dansmith: which alt hosts thing? | |
| 16:20:48 | dansmith | edleafe: https://review.openstack.org/#/c/486215/12 | |
| 16:21:34 | edleafe | dansmith: yeah, I'm working through the whole series to incorporate the changes to the Selection object based on the spec changes | |
| 16:21:50 | dansmith | edleafe: okay cool | |
| 16:23:04 | bauzas | cfriesen: well, I think I said "meh" in my comment | |
| 16:23:21 | bauzas | cfriesen: so, basically, I'm not opiniated | |
| 16:23:36 | bauzas | cfriesen: I tend to avoid having filter behaviours driven by keys | |
| 16:23:48 | bauzas | but looks like we need to be pragmatic | |
| 16:24:27 | bauzas | another option could be a config option, but that would be worst I think for interop | |
| 16:24:48 | bauzas | because two clouds would behave differently | |
| 16:25:09 | bauzas | cfriesen: so, honestly, maybe a key is okay | |
| 16:25:20 | bauzas | I dunno, I need more time to think about that | |
| 16:25:33 | cfriesen | bauzas: I was thinking that we might want to be strictly isolationist for some keys but not for others (as opposed to the all-or-nothing that the current spec proposes) | |
| 16:27:36 | bauzas | when you say "isolationist for a specific *key*", you mean either an aggregate extraspec key for matching the flavor, or an image property? | |
| 16:27:40 | bauzas | cfriesen: ^ | |
| 16:28:44 | bauzas | cfriesen: I just wonder how you would express that in the aggregate metadata | |
| 16:28:55 | bauzas | because of the k=v pair | |
| 16:29:12 | cfriesen | bauzas: I was thinking that the aggregate key could be something like '{"strict:os": "windows"}', in which case only instances with image property or flavor extra-spec of "os:windows" would match | |
| 16:29:25 | cfriesen | basically just a "strict:" namespace on the aggregate key | |
| 16:29:27 | bauzas | namespacing ? I don't like that | |
| 16:29:35 | bauzas | we already namespace keys AFAIKK | |
| 16:30:06 | cfriesen | we namespace them on the flavor/image, but not on the aggregate currently I think | |
| 16:30:09 | bauzas | nevermind, we namespace the image properties or the flavor specs | |
| 16:30:14 | bauzas | yeah that | |
| 16:30:41 | bauzas | cfriesen: the problem is that if you do that, you change the API | |
| 16:30:42 | cfriesen | bauzas: the nice thing about that is that it works with existing flavors/images | |
| 16:31:01 | cfriesen | bauzas: we're talking about a new filter anyway | |
| 16:31:03 | bauzas | cfriesen: say I already have aggregates that are tagged and filters | |
| 16:31:20 | bauzas | cfriesen: how can that work in an upgrade way? | |
| 16:31:39 | bauzas | you would default no namespace to the current behaviour ? | |
| 16:31:43 | cfriesen | bauzas: yes | |
| 16:31:53 | bauzas | cfriesen: honesty, I don't like that | |
| 16:31:55 | cfriesen | in the existing filters | |
| 16:32:02 | bauzas | you can create as many aggregates as you want | |
| 16:32:10 | cfriesen | in the new filter we'd want consistent behaviour for both image/flavor | |
| 16:32:11 | bauzas | and a host can be part of 1:N aggs | |
| 16:32:51 | bauzas | so, if you need strict isolation for only a couple of keys, why just not define two aggregates, one containing keys with no strictness, and the other with keys needing to be strict ? | |
| 16:32:53 | cfriesen | bauzas: with strict matching you'd need the flavor/image to match all the strict keys from all the aggregates the host is in | |
| 16:33:47 | cfriesen | bauzas: you're thinking a "strict-match" boolean flag on the aggregate? yeah, that could work. | |
| 16:34:00 | bauzas | I'm just talking of the current proposal | |
| 16:34:18 | bauzas | he proposes to add new keys that are global per-aggregate | |
| 16:35:17 | bauzas | cfriesen: in that case, if you need some keys with strict isolation, and some with not, just define two aggregates and only apply the new metadata tag image_strict_isolation=True to the aggregate containing the keys you want to be strict | |
| 16:36:34 | mriedem | dansmith: looking at https://review.openstack.org/#/c/498950/ - it occurs to me that if prep_resize fails, i don't think we ever set the migration status to 'failed' | |
| 16:36:40 | mriedem | dansmith: which i think is just a latent bug | |
| 16:37:26 | mriedem | if resize_instance fails it will, but we might not get that far | |
| 16:38:34 | cfriesen | bauzas: I guess. Although AggregateInstanceExtraSpecsFilter doesn't do isolation currently, and AggregateImagePropertiesIsolation doesn't ensure that what you specify in the image is present in the aggregate. | |
| 16:38:52 | mriedem | dansmith: oh i know why - because we never had the migration before that point, because the RT always created it | |