| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-28 | |||
| 10:10:22 | bauzas | johnthetubaguy: frickler: just in case you need more knowledge, there are kludges with those opts https://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs | |
| 10:10:39 | bauzas | see the warning section ^ | |
| 10:10:41 | johnthetubaguy | yeah, its the config doc that is confusing | |
| 10:10:46 | openstackgerrit | John Garbutt proposed openstack/nova master: Fix default_availability_zone docs https://review.openstack.org/438887 | |
| 10:11:08 | johnthetubaguy | bauzas: its very tempting to just deprecate that one | |
| 10:11:53 | bauzas | ah, gotcha | |
| 10:11:55 | johnthetubaguy | frickler: bauzas makes a good point though, the AZ stuff was never really "finished" its all a bit broken honestly. Now placement API work should mean we can look at fixing some of that all soo | |
| 10:11:58 | johnthetubaguy | n | |
| 10:12:11 | bauzas | so, lemme clarify some tribal knowledge | |
| 10:12:28 | johnthetubaguy | bauzas: sure | |
| 10:13:01 | bauzas | first, we have a weird concept of a "default" AZ | |
| 10:13:18 | bauzas | ie. controlplane services have AZs too | |
| 10:13:34 | bauzas | while we can't actually schedule them as a target :) | |
| 10:14:42 | bauzas | secondly, we differenciate hosts vs. instances when they have no AZs | |
| 10:15:00 | bauzas | instead of saying "I don't care at all about AZs so the AZ field should be blank" | |
| 10:15:16 | bauzas | we then have 2 opts that are different: | |
| 10:15:31 | bauzas | if you don't care about AZs for your instance, then you need to set it blank | |
| 10:15:49 | bauzas | but if you don't care about AZs for your hosts, then you need to set it as "nova" | |
| 10:15:55 | bauzas | so much fun around | |
| 10:16:50 | bauzas | anyway, given that, fixing AZs a long way towards, and I don't want us to diverge from the placement effort | |
| 10:16:58 | bauzas | somehow, that has to be a trait | |
| 10:17:02 | johnthetubaguy | bauzas: yeah, in summary, its nuts | |
| 10:17:30 | bauzas | yeah, I'm personnally in favor of deprecating the whole concept of AZs and just leave it at the API level | |
| 10:17:40 | bauzas | instead, computes have location traits | |
| 10:17:57 | johnthetubaguy | so... once we get the cinder "AZ" and routed networks sorted, it gets interesting again | |
| 10:17:59 | bauzas | and instances could request affinity based on those location traits | |
| 10:18:14 | johnthetubaguy | ah, generic location traits are my preference, but AZ is just one of those | |
| 10:18:25 | bauzas | long-term anyway | |
| 10:18:28 | johnthetubaguy | there was a great spec on that from randall nortman, somewhere | |
| 10:18:36 | bauzas | so in the meantime, what we can fix is docs | |
| 10:18:49 | bauzas | but there could be room for some slight improvement tho | |
| 10:18:51 | johnthetubaguy | changing up server groups to deal with generic location specifiers, and multiple of them | |
| 10:18:59 | bauzas | yeah I remember that one | |
| 10:19:09 | johnthetubaguy | thats the one our users really want | |
| 10:19:17 | bauzas | I know | |
| 10:19:29 | johnthetubaguy | cool, just making that the explicit goal I guess | |
| 10:19:37 | johnthetubaguy | we might want to make that a backlog spec actually | |
| 10:20:06 | bauzas | tbh, affinity based on location specifiers is an old old story I have in my pipe | |
| 10:20:06 | openstackgerrit | Lee Yarwood proposed openstack/nova master: objects: Add attachment_id to BlockDeviceMapping https://review.openstack.org/437665 | |
| 10:20:06 | openstackgerrit | Lee Yarwood proposed openstack/nova master: db: Add attachment_id to block_device_mapping https://review.openstack.org/437597 | |
| 10:20:31 | johnthetubaguy | lyarwood: is that the first steps of the Cinder thing? | |
| 10:20:31 | bauzas | anyway, let's move on | |
| 10:21:01 | lyarwood | johnthetubaguy: yeah I guess, I had the bdm uuid changes still in my backlog so thought I'd just do the same again for attachment_id | |
| 10:21:15 | johnthetubaguy | lyarwood: ah, good idea | |
| 10:21:16 | bauzas | wow, Gerrit is in a bad shape | |
| 10:21:33 | johnthetubaguy | lyarwood: I have this one that could do with some eyes: https://review.openstack.org/#/c/373203/ | |
| 10:21:47 | johnthetubaguy | I mean you could just poke your eyes yourself, but I have a lovely spec to do that for you | |
| 10:22:01 | johnthetubaguy | bauzas: so I thought my internet was just slow, but you might be right | |
| 10:22:14 | bauzas | HTTP502 killed me | |
| 10:22:21 | bauzas | so, no, this is not internet :p | |
| 10:22:28 | johnthetubaguy | oh, its tipped over into death land then | |
| 10:22:29 | lyarwood | johnthetubaguy: haha yeah, I'll go over the spec again this morning | |
| 10:22:38 | johnthetubaguy | lyarwood: awesome, thank you | |
| 10:22:50 | johnthetubaguy | I have a feeling I forgot some details from the discussion | |
| 10:23:12 | bauzas | johnthetubaguy: I actually wonder if we couldn't just try to fix default_availability_zone as wezll | |
| 10:23:26 | johnthetubaguy | bauzas: ? | |
| 10:23:40 | bauzas | johnthetubaguy: having it set to none by default would just fix a looooooot of problems | |
| 10:23:47 | bauzas | s/problems/misunderstandings | |
| 10:24:01 | bauzas | johnthetubaguy: and we could then deprecate default_schedule_zon | |
| 10:24:03 | johnthetubaguy | at this point most folks are used to seeing the Nova AZ default I guess, I could go either way | |
| 10:24:38 | johnthetubaguy | hmm, I duno, some folks want to send all builds into a certain zone at times, I think thats why HP public cloud added that | |
| 10:24:45 | bauzas | johnthetubaguy: lemme rephrase, if we could have default_availability_zone having None as default and having default_schedule_zone be deprecated, that would be a nice improvement | |
| 10:25:04 | johnthetubaguy | ah, I just mixed them up | |
| 10:25:39 | bauzas | johnthetubaguy: you mean, HPE wanted to default add the AZ without asking the user to do this ? | |
| 10:25:50 | johnthetubaguy | yeah, maybe, duno if that breaks things, like existing deployments | |
| 10:25:51 | bauzas | that's probably then a good reason for *not | |
| 10:25:59 | bauzas | *not* deprecating it | |
| 10:26:28 | johnthetubaguy | bauzas: its just a scheduling decision, if the user didn't specify it, it probably should be a scheduler filter switch really | |
| 10:26:40 | johnthetubaguy | its all a bit of a hack right now | |
| 10:26:42 | bauzas | johnthetubaguy: that conf opt is more than that | |
| 10:26:57 | bauzas | johnthetubaguy: if you set default_schedule_zone to something else | |
| 10:26:59 | johnthetubaguy | if it is, then the docs are wrong | |
| 10:27:08 | bauzas | johnthetubaguy: then your instance will be constrainted forever to that AZ | |
| 10:27:20 | bauzas | johnthetubaguy: yeah, I'm about to review that patch | |
| 10:27:27 | johnthetubaguy | yep, anywhere you land its meant to stay there forever, I thought | |
| 10:27:40 | frickler | so let me just add our deployment scenario for reference: we have three AZs of compute nodes with local storage and do maintainance on them in turn for a single AZ at a time. | |
| 10:27:50 | bauzas | johnthetubaguy: yup, because instance.az should never be modified | |
| 10:28:03 | johnthetubaguy | right, so its just a scheduling decision | |
| 10:28:05 | frickler | customers that want HA for their service will need to deploy three instances, one per AZ | |
| 10:28:30 | johnthetubaguy | frickler: totally, that makes sense | |
| 10:28:40 | bauzas | johnthetubaguy: in terms of placement, you're right | |
| 10:28:49 | openstackgerrit | Gao Yuan proposed openstack/nova master: Stop using mox stubs in nova.tests.unit.api.openstack.compute.test_serversV21 https://review.openstack.org/438873 | |
| 10:29:04 | bauzas | johnthetubaguy: that conf opt default instances to be placed on a specific AZ, that's what it means | |
| 10:29:22 | johnthetubaguy | frickler: the server groups stuff, once its fixed up, is how you can do that in a better way, but we got loads of placement work before we get there | |
| 10:29:41 | johnthetubaguy | bauzas: yep, I thats what I was trying to say, anyways | |
| 10:29:43 | bauzas | (but there are ways to migrate your server out of that AZ :D) | |
| 10:29:59 | frickler | now we still would like to have "don't care" instances scheduled to any of the AZs. which seems difficult, at least in the dashboard | |
| 10:30:28 | johnthetubaguy | frickler: ah, that should be the default, the dashboard may have broken that | |
| 10:30:43 | frickler | any my idea was to set default_schedule_zone differently on three API servers that are accessed round robin | |
| 10:30:48 | johnthetubaguy | frickler: like "nova boot myserver image_7" should do that | |
| 10:30:51 | bauzas | frickler: that's a separate usecase | |
| 10:31:26 | johnthetubaguy | frickler: so I have a feeling we spoke about this a few months back, and I got confused then too | |
| 10:31:27 | bauzas | frickler: setting default_schedule_zone to None (well, to that ugly empty string rather) means "I don't care about AZs" | |
| 10:31:32 | jsheeren | hi all, i looking at curl calls and filtering results on listing the servers | |
| 10:31:33 | johnthetubaguy | frickler: I thought default_schedule_zone = None does what you want | |
| 10:31:48 | bauzas | but it doesn't force the instance to stick with that AZ | |
| 10:32:03 | johnthetubaguy | bauzas: it should do I thought | |
| 10:32:03 | bauzas | frickler: for your usecase, you could just use a scheduling filter tho | |
| 10:32:38 | jsheeren | with a curl to "https:// |
|
| 10:32:53 | jsheeren | if i use "https:// |
|