On 7/18/2018 1:13 PM, melanie witt wrote:
Can we get rid of multi-create? It keeps causing complications, and
it already
has weird behaviour if you ask for min_count=X and max_count=Y and only X
instances can be scheduled. (Currently it fails with NoValidHost, but
it should
arguably start up X instances.)
We've discussed that before but I think users do use it and appreciate
the ability to boot instances in batches (one request). The behavior you
describe could be changed with a microversion, though I'm not sure if
that would mean we have to preserve old behavior with the previous
microversion.
Correct, we can't just remove it since that's a backward incompatible
microversion change. Plus, NFV people *love* it.
After talking with Sean Mooney, we have another fix which is
self-contained to
the scheduler [5] so we wouldn't need to make any changes to the
RequestSpec
handling in conductor. It's admittedly a bit hairy, so I'm asking for
some eyes
on it since either way we go, we should get going soon before we hit
the FF and
RC1 rush which *always* kills the gate.
One of your options mentioned using RequestSpec.num_instances to
decide if it's
in a multi-create. Is there any reason to persist
RequestSpec.num_instances?
It seems like it's only applicable to the initial request, since after
that each
instance is managed individually.
Yes, I agree RequestSpec.num_instances is something we shouldn't persist
since it's only applicable to the initial server create (you can't
multi-migrate a group of instances, for example - but I'm sure people
have asked for that at some point), and it should be set per call to the
scheduler, but that's a wider-ranging change since it would touch
several parts of conductor, plus the request spec, plus the
ServerGroupAntiAffinitySchedulerFilter.
Honestly I'm OK with doing either, and I don't think they are mutually
exclusive things, so we could make num_instances a per-request thing in
the future for sanity reasons.
--
Thanks,
Matt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
