16:00:00 <gibi> #startmeeting nova
16:00:01 <openstack> Meeting started Thu Oct  8 16:00:00 2020 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:04 <openstack> The meeting name has been set to 'nova'
16:00:47 <gmann> o/
16:01:21 <gibi> \o
16:01:24 <_erlon_> \o
16:01:30 <navidp> \o
16:01:58 <gibi> let's wait an extra minute for the others
16:03:37 <elod> o/
16:04:02 <gibi> #topic Bugs (stuck/critical)
16:04:16 <gibi> No critical bug
16:04:21 <gibi> #link 6 new untriaged bugs (+2 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:04:28 <stephenfin> o/
16:04:43 <gibi> We have a fix for the focal bug #link https://bugs.launchpad.net/nova/+bug/1882521 but it did not merged yet on master #link https://review.opendev.org/#/c/755799
16:04:46 <openstack> Launchpad bug 1882521 in OpenStack Compute (nova) "Failing device detachments on Focal" [High,In progress] - Assigned to Lee Yarwood (lyarwood)
16:05:30 <gibi> this means that it is probably not in the victoria release too
16:05:47 <gmann> ohk, i was typing same to ask
16:05:48 <gibi> but we can release from stable/victoria when it is ready
16:06:04 <gibi> I mean we can release an extra point release
16:06:09 <gmann> k
16:06:41 <gibi> any other bug to discuss?
16:07:55 <bauzas> \o (in a meeting)
16:08:04 <gibi> #topic Release Planning
16:08:11 <gibi> Today is the last day to cut RC2 if needed.
16:08:15 <gibi> Nothing is on the stable/victoria branch that would justify an RC2
16:08:31 <gibi> so we will release RC1 as the Victoria release
16:08:46 <gibi> any comments?
16:09:47 <gmann> i am holding integrated comoute job switch to Focal until we merge Focal fix in victoria on nova side - https://review.opendev.org/#/c/755525/3
16:10:13 <gmann> as Tempest master run on Victoria gate too, it will start failing victoria gate
16:10:39 <gibi> so this also means that the focal switch is not part of the Victoria release
16:10:53 <tosky> unless you merge that fix, I guess
16:11:27 <gibi> unless that fix is merged _today_ as today is the last day for an RC2
16:11:34 <gmann> gibi: it is and once we merge the fix on victoria as part of rc or backport with new release we start pending compute job to run on Focal
16:11:54 <gibi> gmann: sure I'm OK with a backport
16:12:05 <stephenfin> no one's going to consume the .0 release; .1 is fine imo
16:12:12 <gmann> gibi: i will also keep eyes on gate to merge it today
16:12:17 <stephenfin> in case you were looking for opinions :)
16:12:33 <gibi> gmann: if we merge it today, does it also mean you would like to have RC2?
16:13:12 <gmann> gibi: humm either is fine. .1 also ok with backport for me.
16:13:26 <gmann> i think you said no others change pending for RC2 righjt
16:13:49 <gibi> gmann: yeah, we merged nothing to stable/victoria that needs an RC2
16:14:01 <elod> just a question: if it merges today, will we have time to backport it to victoria to release RC2? (the "Failing device detachments on Focal" fix i mean)
16:14:27 <gmann> yeah backport also need time then.
16:14:34 <gibi> elod: good point
16:14:51 <gmann> I think we can leave RC2
16:14:59 <gibi> lets go with RC1 for Victoria. Then release .1 after the focal fix and the switch to focal
16:15:04 <gmann> +1
16:15:26 <elod> sounds OK
16:15:59 <gibi> anything else about the release?
16:17:12 <gibi> #topic Stable Branches
16:17:49 <elod> i think stable branches are OK, nothing new issue there
16:18:17 <gibi> cool, thanks elod
16:18:21 <gibi> #topic Sub/related team Highlights
16:18:25 <gibi> API (gmann)
16:18:43 <gmann> nothing specific from me
16:19:05 <gibi> thanks
16:19:05 <gibi> Libvirt (bauzas)
16:19:13 <bauzas> nothing to report, sir.
16:19:52 <gibi> thanks
16:20:06 <gibi> #topic Open discussion
16:20:15 <gibi> there is one item on the agenda
16:20:16 <gibi> Adding a filter scheduler for server groups on availability zone. #link https://review.opendev.org/#/c/756380
16:20:25 <gibi> navidp: I think it is yours
16:20:36 <navidp> yap
16:21:19 <navidp> I just wanted to get some reviews and general idea about the use case.
16:21:28 <gibi> could you summarize the use case here
16:22:58 <navidpustchi> I got disconnected.
16:24:03 <navidpustchi> The use case is that for instances with requirements to deploy across or within a single AZ,
16:24:09 <gibi> navidpustchi: either you give us a short summary about the use case here so we can discuss it quickly or we can continue the review in the spec
16:25:18 <navidpustchi> Instances with higher reliability and availability must be created ondifferent racks or locations such as hosts from different availability zones.Currently, the group affinity implementation supports instances in the group tobe created on a single host or be created on different hosts. Specially fordeployments with large number of availability
16:25:19 <navidpustchi> zones, it is not practical towatch available zones and instances in the group. Current server groupanti-affinity filter only guarantee instances in the server group withanti-affinity policy on different hosts, but these hosts can be in the sameavailability zone.
16:26:00 <gibi> so you would need availability zone level affinity and anti-affinity
16:26:07 <navidpustchi> exactly.
16:26:08 <bauzas> that's my understanding
16:26:53 <bauzas> but you get anti-affinity for free with AZs, right?
16:26:59 <gibi> I guess that would need new policies like az-affinity and az-anti-affinity, or a property on the server group that defines the scope of the affinity
16:27:13 <_erlon_> Yes, the way can distribute a group of VMs for an application is to create each one of then with a given AZ. But if you have a large se of AZs that becames hard to track them
16:27:24 <bauzas> gibi: I personnally think it would be a bad idea to pursue into adding more to servergroups IMHO
16:28:07 <bauzas> _erlon_: navidpustchi: I'm lost, why can't you use then aggregates affinity ?
16:28:18 <navidpustchi> We can wither add to server groups or use the current server groups and have scheduler hint.
16:28:34 <_erlon_> @bauzas the aggregate affinity only agregates hosts
16:28:59 <_erlon_> not az, your hosts can be in the same az
16:29:56 * bauzas tries to find the existing filter that says "exclude my new vm from this agg"
16:30:06 <bauzas> I'm pretty sure it exists
16:30:22 <_erlon_> unless you could create a group with all hosts from different AZ?
16:30:53 <_erlon_> navidpustchi: do you thing that would be possible to your case?
16:30:58 <gibi> bauzas: I'm not sure it exists. We have two isolation filter AggregateMultiTenancyIsolation AggregateImagePropertiesIsolation
16:31:26 <_erlon_> bauzas: we couldnt find one either
16:31:33 <navidpustchi> no, there was a proposal for aggregate affinity but it never implemented.
16:32:03 <bauzas> okay, I'm still struggling with the usecase
16:32:05 <navidpustchi> this filter, address that issue as well.
16:32:12 <_erlon_> #link https://blueprints.launchpad.net/nova/+spec/aggregate-affinity
16:32:19 <bauzas> so you want to tell "I want this VM to be not in this AZ" ?
16:32:37 <bauzas> and "I want this VM to be in this AZ" ?
16:32:45 <bauzas> if so, I can help your case
16:32:53 <gibi> bauzas: they want to tell that these 3 VMs are in different AZs
16:32:56 <navidpustchi> no, it is very similar to host affinity, I want to tell it this group of instances to be in an AZ
16:33:24 <bauzas> gibi: with multi-create, gotcha
16:33:34 <navidpustchi> or this group of instances to be on different AZs, meaning they will be created on hosts from a different AZ.
16:34:20 <gibi> bauzas: not just multicreate. You can create VMs one after the other but if they are in the same server group then the policy of the group would instruct the scheduler to place them to separate AX
16:34:24 <gibi> AZ
16:34:39 <navidpustchi> yes
16:34:45 <gibi> it is basically AZ (or aggregate) level (anti-)affinity
16:34:52 <navidpustchi> yes
16:34:54 <bauzas> gibi: well, if that's for sequential creates, you can specific which AZ you wanna land to
16:34:55 <gibi> we have host level today
16:35:05 <bauzas> and then you don't need server groups
16:35:21 <gibi> bauzas: correct,
16:35:22 <navidpustchi> it works for couple of instances.
16:35:45 <navidpustchi> but for a group of instances to keep track of it, becomes impossible
16:35:58 <bauzas> you're asking nova to orchestrate your cloud
16:36:29 <_erlon_> its actually the same concept as affinity for server groups
16:36:46 <bauzas> again, assuming you need this for failure domains
16:37:02 <_erlon_> yes
16:37:05 <bauzas> I assume that you also know what to land and where
16:37:36 <bauzas> tbc, the only miss I see from nova is multicreate with AZ anti-affinity
16:38:03 <bauzas> because the sequential case is just a matter of knowing what to tell nova to go where
16:38:44 <navidpustchi> I agree, though having this knowledge is not expected from the user who creates the instance.
16:39:01 <navidpustchi> I mean the sequential case.
16:39:03 <bauzas> give me an example of a confusing situation, please
16:40:09 <navidpustchi> I'm a user, trying to create three VMs, want to have them on different AZ for better reliability, dont just want them on seperate host.
16:40:30 <bauzas> so as a user, I ask nova to give me the list of AZs
16:40:37 <bauzas> and then I pick three differents
16:40:41 <navidpustchi> for this case I need to know which AZs I can create a VM to specify them
16:40:56 <bauzas> right
16:41:05 <bauzas> but the AZ list is known to the user
16:41:07 <navidpustchi> and I want them to stay on different AZ.
16:41:12 <_erlon_> you can also do that with hosts, and cast each instance into a different host
16:41:25 <_erlon_> bauzas: if you have s small number of operators and modest sized cloud you know where you want to land, the use case here is that if you have lets say dozens of AZs, them controlling that is a problem
16:41:36 <bauzas> _erlon_: if you specify different AZs per instance, those will necessarly be on different hosts
16:41:39 <navidpustchi> if there is a maintentance and we need to move a VM, it can break the initial AZs
16:42:13 <bauzas> _erlon_: again, I'm not convinced : the user can see the long list of AZs, and pick three different ones for each of their VMs
16:42:42 <bauzas> and he will get the guaranttee that the instances will be exclusively running on different hosts
16:43:02 <bauzas> navidpustchi: i thought this was an user usecase, not an operator one
16:43:11 <navidpustchi> may I ask what part you are not convinced,
16:43:19 <navidpustchi> it is a user case,
16:43:27 <bauzas> navidpustchi: if you wanna do maintenance on a host, just live migrate the VMs, those will stick on the same AZ
16:43:39 <bauzas> (provided the instances were created with an AZ argument)
16:43:45 <gibi> I thik this AZ level (anti-)affinity question boils down to the fact that nova does not want to implement much more orchestration logic https://docs.openstack.org/nova/rocky/contributor/project-scope.html#no-more-orchestration
16:44:24 <bauzas> hah, I was about to explain why I wasn't convinced
16:44:33 <bauzas> but I'll continue and logs will show
16:44:34 <gibi> nova provide the interface for the list of AZs and the way to specify AZ for an instance so an external entity can do the orchestration logic
16:44:47 <bauzas> ^ this
16:45:11 <gibi> this does not necessary needs to be the end user
16:45:15 <gibi> we have heat for example for orchestration
16:45:23 <bauzas> whather the number of AZs a cloud has, a user can be sure that they can boot instances on different hosts by specific different AZs
16:45:45 <bauzas> because he just has to pick different AZs from the list
16:46:15 <bauzas> even if the cloud is running 100000 instances and has 1000 AZs
16:46:32 <bauzas> pick the three first AZs and spin instances against each of them
16:46:52 <bauzas> and then you'll get AZ anti-affinity
16:46:53 <bauzas> but,
16:46:58 <bauzas> there is one miss I reckon
16:47:08 <bauzas> you can't do it at once in a single API call
16:47:44 <bauzas> that being said, and people can testify, I'm really not a super-fan of multi-create
16:48:19 <bauzas> and I'm not really happy to add more complexity to multi-create as I'd personnally like to live it die
16:48:21 <gibi> yeah, with multi create you can only specify one AZ for all the instances in the request
16:48:37 <bauzas> to leave* it
16:48:45 <bauzas> (pardon my French (c) )
16:49:26 <bauzas> navidpustchi: do you think we answered your question ? we can continue off-meeting
16:49:35 <navidpustchi> makes sense, though if you want to create 500 VMs will it work ?
16:49:58 <gibi> the external orchestrator does not need to be a human ^^
16:49:58 <bauzas> navidpustchi: if you create 500 VMs sequentially, yes
16:49:59 <navidpustchi> ok
16:50:22 <navidpustchi> we cna continue offline.
16:50:26 <gibi> O
16:50:31 <gibi> is there anything else for the today meeting?
16:50:35 <bauzas> navidpustchi: if you want to have 500 VMs to be mutually exclusive, use a servergroup or write a feature
16:50:43 <bauzas> at once*
16:50:45 <_erlon_> ok, we will discuss the alternatives you guys suggested and if we have something that cant be accomplished we bring that over
16:50:59 <gibi> _erlon_, navidpustchi: thanks
16:51:04 <bauzas> thanks indeed
16:51:12 <navidpustchi> thanks
16:51:24 <_erlon_> bauzas++ gibi++
16:51:24 <_erlon_> thanks guys
16:51:50 <gibi> if no any other thing for today then thanks for joining
16:52:23 <gibi> o/
16:52:25 <gibi> #endmeeting