Open Stack

Isnt this an existing issue with traits specified in flavor as well?

Server is created using flavor1 requiring trait A on RP1. Before the
rebuild is called, the underlying RP1 can be updated to remove trait A and
when a rebuild is requested(regardless of whether the image is updated or
not), we skip scheduling and allow the rebuild to go through.

Now, even though the flavor1 requests trait A, the underlying RP1 does not
have that trait the rebuild will succeed...

I think maybe there should be some kind of report or query which runs
periodically to ensure continued conformance with respect to instance
running and their traits. But since traits are intend to provide hints for
scheduling, this is different problem to solve IMO.

On Wed, May 2, 2018 at 3:45 PM, Matt Riedemann <mriedemos at gmail.com> wrote:

> On 5/2/2018 5:39 PM, Jay Pipes wrote:
>
>> My personal preference is to add less technical debt and go with a
>> solution that checks if image traits have changed in nova-api and if so,
>> simply refuse to perform a rebuild.
>>
>
> So, what if when I created my server, the image I used, let's say image1,
> had required trait A and that fit the host.
>
> Then some external service removes (or somehow changes) trait A from the
> compute node resource provider (because people can and will do this, there
> are a few vmware specs up that rely on being able to manage traits out of
> band from nova), and then I rebuild my server with image2 that has required
> trait A. That would match the original trait A in image1 and we'd say,
> "yup, lgtm!" and do the rebuild even though the compute node resource
> provider wouldn't have trait A anymore.
>
> Having said that, it could technically happen before traits if the
> operator changed something on the underlying compute host which invalidated
> instances running on that host, but I'd think if that happened the operator
> would be migrating everything off the host and disabling it from scheduling
> before making whatever that kind of change would be, let's say they change
> the hypervisor or something less drastic but still image property
> invalidating.
>
> --
>
> Thanks,
>
> Matt
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Arvind N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180502/2b9751cb/attachment.html>