Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Tony Breeds]

On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
>  4. Create a capabilitioes API of some description, that can be queried so 
> that
> consumers (horizon) can known

Thanks everyone for the input.  I'm going to go with the simple first step that
Sean described as it seesm liek the right long term direstion but it's also
doable this cycle.

Yours Tony.


pgpPHraFbN5NC.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Clint Byrum]

Excerpts from Tony Breeds's message of 2015-11-05 22:08:59 -0800:
> Hello all,
> I came across [1] which is notionally an ironic bug in that horizon 
> presents
> VM operations (like suspend) to users.  Clearly these options don't make sense
> to ironic which can be confusing.
> 
> There is a horizon fix that just disables migrate/suspened and other 
> functaions
> if the operator sets a flag say ironic is present.  Clealy this is sub optimal
> for a mixed hv environment.
> 
> The data needed (hpervisor type) is currently avilable only to admins, a quick
> hack to remove this policy restriction is functional.
> 
> There are a few ways to solve this.
> 
>  1. Change the default from "rule:admin_api" to "" (for 
> os_compute_api:os-extended-server-attributes and
> os_compute_api:os-hypervisors), and set a list of values we're
> comfortbale exposing the user (hypervisor_type and
> hypervisor_hostname).  So a user can get the hypervisor_name as part of
> the instance deatils and get the hypervisor_type from the
> os-hypervisors.  This would work for horizon but increases the API load
> on nova and kinda implies that horizon would have to cache the data and
> open-code assumptions that hypervisor_type can/can't do action $x
> 
>  2. Include the hypervisor_type with the instance data.  This would place the 
> burdon on nova.  It makes the looking up instance details slightly more
> complex but doesn't result in additional API queries, nor caching
> overhead in horizon.  This has the same opencoding issues as Option 1.
> 
>  3. Define a service user and have horizon look up the hypervisors details 
> via 
> that role.  Has all the drawbacks as option 1 and I'm struggling to
> think of many benefits.
> 
>  4. Create a capabilitioes API of some description, that can be queried so 
> that
> consumers (horizon) can known
> 

This.

A large part of why we want "clouds" and not "virtualization frontends"
is that we want to relieve the user of any need to know what hypervisor
is in use if we can. We want to provide them computers, and tools to
manage their computers. Whether they are VMs or real machines, our tools
should strive to be about the user and their workload, and not about the
operator and their technology.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Sylvain Bauza]

Le 06/11/2015 07:08, Tony Breeds a écrit :

Hello all,
 I came across [1] which is notionally an ironic bug in that horizon 
presents
VM operations (like suspend) to users.  Clearly these options don't make sense
to ironic which can be confusing.

There is a horizon fix that just disables migrate/suspened and other functaions
if the operator sets a flag say ironic is present.  Clealy this is sub optimal
for a mixed hv environment.

The data needed (hpervisor type) is currently avilable only to admins, a quick
hack to remove this policy restriction is functional.

There are a few ways to solve this.

  1. Change the default from "rule:admin_api" to "" (for
 os_compute_api:os-extended-server-attributes and
 os_compute_api:os-hypervisors), and set a list of values we're
 comfortbale exposing the user (hypervisor_type and
 hypervisor_hostname).  So a user can get the hypervisor_name as part of
 the instance deatils and get the hypervisor_type from the
 os-hypervisors.  This would work for horizon but increases the API load
 on nova and kinda implies that horizon would have to cache the data and
 open-code assumptions that hypervisor_type can/can't do action $x

  2. Include the hypervisor_type with the instance data.  This would place the
 burdon on nova.  It makes the looking up instance details slightly more
 complex but doesn't result in additional API queries, nor caching
 overhead in horizon.  This has the same opencoding issues as Option 1.

  3. Define a service user and have horizon look up the hypervisors details via
 that role.  Has all the drawbacks as option 1 and I'm struggling to
 think of many benefits.

  4. Create a capabilitioes API of some description, that can be queried so that
 consumers (horizon) can known

  5. Some other way for users to know what kind of hypervisor they're on, 
Perhaps
 there is an established image property that would work here?

If we're okay with exposing the hypervisor_type to users, then #2 is pretty
quick and easy, and could be done in Mitaka.  Option 4 is probably the best
long term solution but I think is best done in 'N' as it needs lots of
discussion.


I'm pretty opposed to giving hypervisor details to end-users for many 
reasons (security flaw, cloud abstractional model and API not being a 
discovery tool are my first top things coming in mind).


I'd rather prefer to see Horizon as an admin able to get the specific 
bits about the driver and only show to the user what the driver can support.


That's also IMHO a bit tied to the Hypervisor Support Matrix [1] and 
from a better and more maintenable standpoint, the Feature 
Classification effort [2] because it would ensure that the 
'capabilities' API that you mention is accurate and up-to-date.


-Sylvain

[1] http://docs.openstack.org/developer/nova/support-matrix.html
[2] 
https://review.openstack.org/#/c/215664/4/doc/source/feature_classification.rst,cm

Yours Tony.

[1] https://bugs.launchpad.net/nova/+bug/1483639


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Daniel P. Berrange]

On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
> Hello all,
> I came across [1] which is notionally an ironic bug in that horizon 
> presents
> VM operations (like suspend) to users.  Clearly these options don't make sense
> to ironic which can be confusing.
> 
> There is a horizon fix that just disables migrate/suspened and other 
> functaions
> if the operator sets a flag say ironic is present.  Clealy this is sub optimal
> for a mixed hv environment.
> 
> The data needed (hpervisor type) is currently avilable only to admins, a quick
> hack to remove this policy restriction is functional.
> 
> There are a few ways to solve this.
> 
>  1. Change the default from "rule:admin_api" to "" (for 
> os_compute_api:os-extended-server-attributes and
> os_compute_api:os-hypervisors), and set a list of values we're
> comfortbale exposing the user (hypervisor_type and
> hypervisor_hostname).  So a user can get the hypervisor_name as part of
> the instance deatils and get the hypervisor_type from the
> os-hypervisors.  This would work for horizon but increases the API load
> on nova and kinda implies that horizon would have to cache the data and
> open-code assumptions that hypervisor_type can/can't do action $x
> 
>  2. Include the hypervisor_type with the instance data.  This would place the 
> burdon on nova.  It makes the looking up instance details slightly more
> complex but doesn't result in additional API queries, nor caching
> overhead in horizon.  This has the same opencoding issues as Option 1.
> 
>  3. Define a service user and have horizon look up the hypervisors details 
> via 
> that role.  Has all the drawbacks as option 1 and I'm struggling to
> think of many benefits.
> 
>  4. Create a capabilitioes API of some description, that can be queried so 
> that
> consumers (horizon) can known
> 
>  5. Some other way for users to know what kind of hypervisor they're on, 
> Perhaps
> there is an established image property that would work here?
> 
> If we're okay with exposing the hypervisor_type to users, then #2 is pretty
> quick and easy, and could be done in Mitaka.  Option 4 is probably the best
> long term solution but I think is best done in 'N' as it needs lots of
> discussion.

I think that exposing hypervisor_type is very much the *wrong* approach
to this problem. The set of allowed actions varies based on much more than
just the hypervisor_type. The hypervisor version may affect it, as may
the hypervisor architecture, and even the version of Nova. If horizon
restricted its actions based on hypevisor_type alone, then it is going
to inevitably prevent the user from performing otherwise valid actions
in a number of scenarios.

IMHO, a capabilities based approach is the only viable solution to
this kind of problem.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Ghe Rivero]

Quoting Clint Byrum (2015-11-06 09:07:20)
> Whether they are VMs or real machines, our tools
> should strive to be about the user and their workload, and not about the
> operator and their technology.

+1 This should be in a poster in every office.

Ghe Rivero

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[John Garbutt]

On 6 November 2015 at 14:09, Sean Dague  wrote:
> On 11/06/2015 08:44 AM, Alex Xu wrote:
>>
>>
>> 2015-11-06 20:59 GMT+08:00 Sean Dague > >:
>>
>> On 11/06/2015 07:28 AM, John Garbutt wrote:
>> > On 6 November 2015 at 12:09, Sean Dague > > wrote:
>> >> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
>> >>> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
>>  Hello all,
>>  I came across [1] which is notionally an ironic bug in that
>> horizon presents
>>  VM operations (like suspend) to users.  Clearly these options
>> don't make sense
>>  to ironic which can be confusing.
>> 
>>  There is a horizon fix that just disables migrate/suspened and
>> other functaions
>>  if the operator sets a flag say ironic is present.  Clealy this
>> is sub optimal
>>  for a mixed hv environment.
>> 
>>  The data needed (hpervisor type) is currently avilable only to
>> admins, a quick
>>  hack to remove this policy restriction is functional.
>> 
>>  There are a few ways to solve this.
>> 
>>   1. Change the default from "rule:admin_api" to "" (for
>>  os_compute_api:os-extended-server-attributes and
>>  os_compute_api:os-hypervisors), and set a list of values we're
>>  comfortbale exposing the user (hypervisor_type and
>>  hypervisor_hostname).  So a user can get the
>> hypervisor_name as part of
>>  the instance deatils and get the hypervisor_type from the
>>  os-hypervisors.  This would work for horizon but increases
>> the API load
>>  on nova and kinda implies that horizon would have to cache
>> the data and
>>  open-code assumptions that hypervisor_type can/can't do
>> action $x
>> 
>>   2. Include the hypervisor_type with the instance data.  This
>> would place the
>>  burdon on nova.  It makes the looking up instance details
>> slightly more
>>  complex but doesn't result in additional API queries, nor
>> caching
>>  overhead in horizon.  This has the same opencoding issues
>> as Option 1.
>> 
>>   3. Define a service user and have horizon look up the
>> hypervisors details via
>>  that role.  Has all the drawbacks as option 1 and I'm
>> struggling to
>>  think of many benefits.
>> 
>>   4. Create a capabilitioes API of some description, that can be
>> queried so that
>>  consumers (horizon) can known
>> 
>>   5. Some other way for users to know what kind of hypervisor
>> they're on, Perhaps
>>  there is an established image property that would work here?
>> 
>>  If we're okay with exposing the hypervisor_type to users, then
>> #2 is pretty
>>  quick and easy, and could be done in Mitaka.  Option 4 is
>> probably the best
>>  long term solution but I think is best done in 'N' as it needs
>> lots of
>>  discussion.
>> >>>
>> >>> I think that exposing hypervisor_type is very much the *wrong*
>> approach
>> >>> to this problem. The set of allowed actions varies based on much
>> more than
>> >>> just the hypervisor_type. The hypervisor version may affect it,
>> as may
>> >>> the hypervisor architecture, and even the version of Nova. If
>> horizon
>> >>> restricted its actions based on hypevisor_type alone, then it is
>> going
>> >>> to inevitably prevent the user from performing otherwise valid
>> actions
>> >>> in a number of scenarios.
>> >>>
>> >>> IMHO, a capabilities based approach is the only viable solution to
>> >>> this kind of problem.
>> >>
>> >> Right, we just had a super long conversation about this in
>> #openstack-qa
>> >> yesterday with mordred, jroll, and deva around what it's going to
>> take
>> >> to get upgrade tests passing with ironic.
>> >>
>> >> Capabilities is the right approach, because it means we're future
>> >> proofing our interface by telling users what they can do, not some
>> >> arbitrary string that they need to cary around a separate library to
>> >> figure those things out.
>> >>
>> >> It seems like capabilities need to exist on flavor, and by proxy
>> instance.
>> >>
>> >> GET /flavors/bm.large/capabilities
>> >>
>> >> {
>> >>  "actions": {
>> >>  'pause': False,
>> >>  'unpause': False,
>> >>  'rebuild': True
>> >>  ..
>> >>   }
>> >>
>>
>>
>> Does this need admin to set the capabilities? If yes, that looks like
>> pain to admin to set capabilities for all the 

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Daniel P. Berrange]

On Fri, Nov 06, 2015 at 07:09:59AM -0500, Sean Dague wrote:
> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
> > 
> > I think that exposing hypervisor_type is very much the *wrong* approach
> > to this problem. The set of allowed actions varies based on much more than
> > just the hypervisor_type. The hypervisor version may affect it, as may
> > the hypervisor architecture, and even the version of Nova. If horizon
> > restricted its actions based on hypevisor_type alone, then it is going
> > to inevitably prevent the user from performing otherwise valid actions
> > in a number of scenarios.
> > 
> > IMHO, a capabilities based approach is the only viable solution to
> > this kind of problem.
> 
> Right, we just had a super long conversation about this in #openstack-qa
> yesterday with mordred, jroll, and deva around what it's going to take
> to get upgrade tests passing with ironic.
> 
> Capabilities is the right approach, because it means we're future
> proofing our interface by telling users what they can do, not some
> arbitrary string that they need to cary around a separate library to
> figure those things out.
> 
> It seems like capabilities need to exist on flavor, and by proxy instance.
> 
> GET /flavors/bm.large/capabilities
> 
> {
>  "actions": {
>  'pause': False,
>  'unpause': False,
>  'rebuild': True
>  ..
>   }
> 
> A starting point would definitely be the set of actions that you can
> send to the flavor/instance. There may be features beyond that we'd like
> to classify as capabilities, but actions would be a very concrete and
> attainable starting point. With microversions we don't have to solve
> this all at once, start with a concrete thing and move forward.

I think there are two distinct use cases for capabilities we need to
consider.

 1. Before I launch an instance, does the cloud provide features XYZ

 2. Given this running instance, am I able to perform operation XYZ

Having capabilities against the flavour /might/ be sufficient for
#1, but it isn't sufficient for #2.

For example, the ability to hotplug disks to a running instance will
depend on what disk controller the instance is using. The choice of
disk controller used will vary based on image metadata properties,
eg ide vs scsi vs virtio-blk. IDE does not support hotplug, but
scsi & virtio-blk do. So we can't answer the question "does hotplug
disk work for this instance" simply based on the flavour - we need
to ask it against the instance.

What we can answer against the flavour is whether the hypervisor
driver is able to support hotplug in principle, given a suitably
configured instance. That said, even that is not an exact science
if you take into account fact that the cloud could be running
compute nodes with different versions, and the flavour does not
directly control which version of a compute node we'll run against.

Having capabilities against the flavour would certainly allow for
an improvement in Horizon UI vs its current state, but to be able
to perfectly represent what is possible for an instance, Horizon
would ultimately require capabilities against the isntance,

So I think we'll likely end up having to implement both capabilities
against a flavour and against an instance. So you'd end up with a
flow something like

 - Check to see if cloud provider supports hotplug by checking
   flavour capability==disk-hotplug

 - When booting an instance mark it as requiring capability==disk-hotplug
   to ensure its scheduled to a node which supports that capability

 - When presenting UI for operations against an instance, check
   that the running instance supports capability==disk-hotplug


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[John Garbutt]

On 6 November 2015 at 12:09, Sean Dague  wrote:
> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
>> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
>>> Hello all,
>>> I came across [1] which is notionally an ironic bug in that horizon 
>>> presents
>>> VM operations (like suspend) to users.  Clearly these options don't make 
>>> sense
>>> to ironic which can be confusing.
>>>
>>> There is a horizon fix that just disables migrate/suspened and other 
>>> functaions
>>> if the operator sets a flag say ironic is present.  Clealy this is sub 
>>> optimal
>>> for a mixed hv environment.
>>>
>>> The data needed (hpervisor type) is currently avilable only to admins, a 
>>> quick
>>> hack to remove this policy restriction is functional.
>>>
>>> There are a few ways to solve this.
>>>
>>>  1. Change the default from "rule:admin_api" to "" (for
>>> os_compute_api:os-extended-server-attributes and
>>> os_compute_api:os-hypervisors), and set a list of values we're
>>> comfortbale exposing the user (hypervisor_type and
>>> hypervisor_hostname).  So a user can get the hypervisor_name as part of
>>> the instance deatils and get the hypervisor_type from the
>>> os-hypervisors.  This would work for horizon but increases the API load
>>> on nova and kinda implies that horizon would have to cache the data and
>>> open-code assumptions that hypervisor_type can/can't do action $x
>>>
>>>  2. Include the hypervisor_type with the instance data.  This would place 
>>> the
>>> burdon on nova.  It makes the looking up instance details slightly more
>>> complex but doesn't result in additional API queries, nor caching
>>> overhead in horizon.  This has the same opencoding issues as Option 1.
>>>
>>>  3. Define a service user and have horizon look up the hypervisors details 
>>> via
>>> that role.  Has all the drawbacks as option 1 and I'm struggling to
>>> think of many benefits.
>>>
>>>  4. Create a capabilitioes API of some description, that can be queried so 
>>> that
>>> consumers (horizon) can known
>>>
>>>  5. Some other way for users to know what kind of hypervisor they're on, 
>>> Perhaps
>>> there is an established image property that would work here?
>>>
>>> If we're okay with exposing the hypervisor_type to users, then #2 is pretty
>>> quick and easy, and could be done in Mitaka.  Option 4 is probably the best
>>> long term solution but I think is best done in 'N' as it needs lots of
>>> discussion.
>>
>> I think that exposing hypervisor_type is very much the *wrong* approach
>> to this problem. The set of allowed actions varies based on much more than
>> just the hypervisor_type. The hypervisor version may affect it, as may
>> the hypervisor architecture, and even the version of Nova. If horizon
>> restricted its actions based on hypevisor_type alone, then it is going
>> to inevitably prevent the user from performing otherwise valid actions
>> in a number of scenarios.
>>
>> IMHO, a capabilities based approach is the only viable solution to
>> this kind of problem.
>
> Right, we just had a super long conversation about this in #openstack-qa
> yesterday with mordred, jroll, and deva around what it's going to take
> to get upgrade tests passing with ironic.
>
> Capabilities is the right approach, because it means we're future
> proofing our interface by telling users what they can do, not some
> arbitrary string that they need to cary around a separate library to
> figure those things out.
>
> It seems like capabilities need to exist on flavor, and by proxy instance.
>
> GET /flavors/bm.large/capabilities
>
> {
>  "actions": {
>  'pause': False,
>  'unpause': False,
>  'rebuild': True
>  ..
>   }
>
> A starting point would definitely be the set of actions that you can
> send to the flavor/instance. There may be features beyond that we'd like
> to classify as capabilities, but actions would be a very concrete and
> attainable starting point. With microversions we don't have to solve
> this all at once, start with a concrete thing and move forward.
>
> Sending an action that was "False" for the instance/flavor would return
> a 400 BadRequest high up at the API level, much like input validation
> via jsonschema.

+1

>From memory we couldn't quite decide on the granularity of that
actions list, but we can work through that in a spec.

> This is nothing new, we've talked about it in the abstract in the Nova
> space for a while. We've yet had anyone really take this on. If you
> wanted to run with a spec and code, it would be welcome.

+1

I would love for it to eventually also reflect policy (per flavor
policy) in that list of available actions. That might be one way to
get something quickly, while working on a more automatic solution.

Not to delay that work, but there are related ideas around grouping
flavors, into flavor classes, so you attach policy to the class rather
than every 

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Sean Dague]

On 11/06/2015 07:28 AM, John Garbutt wrote:
> On 6 November 2015 at 12:09, Sean Dague  wrote:
>> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
>>> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
 Hello all,
 I came across [1] which is notionally an ironic bug in that horizon 
 presents
 VM operations (like suspend) to users.  Clearly these options don't make 
 sense
 to ironic which can be confusing.

 There is a horizon fix that just disables migrate/suspened and other 
 functaions
 if the operator sets a flag say ironic is present.  Clealy this is sub 
 optimal
 for a mixed hv environment.

 The data needed (hpervisor type) is currently avilable only to admins, a 
 quick
 hack to remove this policy restriction is functional.

 There are a few ways to solve this.

  1. Change the default from "rule:admin_api" to "" (for
 os_compute_api:os-extended-server-attributes and
 os_compute_api:os-hypervisors), and set a list of values we're
 comfortbale exposing the user (hypervisor_type and
 hypervisor_hostname).  So a user can get the hypervisor_name as part of
 the instance deatils and get the hypervisor_type from the
 os-hypervisors.  This would work for horizon but increases the API load
 on nova and kinda implies that horizon would have to cache the data and
 open-code assumptions that hypervisor_type can/can't do action $x

  2. Include the hypervisor_type with the instance data.  This would place 
 the
 burdon on nova.  It makes the looking up instance details slightly more
 complex but doesn't result in additional API queries, nor caching
 overhead in horizon.  This has the same opencoding issues as Option 1.

  3. Define a service user and have horizon look up the hypervisors details 
 via
 that role.  Has all the drawbacks as option 1 and I'm struggling to
 think of many benefits.

  4. Create a capabilitioes API of some description, that can be queried so 
 that
 consumers (horizon) can known

  5. Some other way for users to know what kind of hypervisor they're on, 
 Perhaps
 there is an established image property that would work here?

 If we're okay with exposing the hypervisor_type to users, then #2 is pretty
 quick and easy, and could be done in Mitaka.  Option 4 is probably the best
 long term solution but I think is best done in 'N' as it needs lots of
 discussion.
>>>
>>> I think that exposing hypervisor_type is very much the *wrong* approach
>>> to this problem. The set of allowed actions varies based on much more than
>>> just the hypervisor_type. The hypervisor version may affect it, as may
>>> the hypervisor architecture, and even the version of Nova. If horizon
>>> restricted its actions based on hypevisor_type alone, then it is going
>>> to inevitably prevent the user from performing otherwise valid actions
>>> in a number of scenarios.
>>>
>>> IMHO, a capabilities based approach is the only viable solution to
>>> this kind of problem.
>>
>> Right, we just had a super long conversation about this in #openstack-qa
>> yesterday with mordred, jroll, and deva around what it's going to take
>> to get upgrade tests passing with ironic.
>>
>> Capabilities is the right approach, because it means we're future
>> proofing our interface by telling users what they can do, not some
>> arbitrary string that they need to cary around a separate library to
>> figure those things out.
>>
>> It seems like capabilities need to exist on flavor, and by proxy instance.
>>
>> GET /flavors/bm.large/capabilities
>>
>> {
>>  "actions": {
>>  'pause': False,
>>  'unpause': False,
>>  'rebuild': True
>>  ..
>>   }
>>
>> A starting point would definitely be the set of actions that you can
>> send to the flavor/instance. There may be features beyond that we'd like
>> to classify as capabilities, but actions would be a very concrete and
>> attainable starting point. With microversions we don't have to solve
>> this all at once, start with a concrete thing and move forward.
>>
>> Sending an action that was "False" for the instance/flavor would return
>> a 400 BadRequest high up at the API level, much like input validation
>> via jsonschema.
> 
> +1
> 
> From memory we couldn't quite decide on the granularity of that
> actions list, but we can work through that in a spec.

My suggestion is that phase 1 is the list of ACTIONS you can POST to
/servers/UUID/action. That is already a fixed size list and is a
definitive concept today.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Sean Dague]

On 11/06/2015 07:46 AM, Daniel P. Berrange wrote:
> On Fri, Nov 06, 2015 at 07:09:59AM -0500, Sean Dague wrote:
>> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
>>>
>>> I think that exposing hypervisor_type is very much the *wrong* approach
>>> to this problem. The set of allowed actions varies based on much more than
>>> just the hypervisor_type. The hypervisor version may affect it, as may
>>> the hypervisor architecture, and even the version of Nova. If horizon
>>> restricted its actions based on hypevisor_type alone, then it is going
>>> to inevitably prevent the user from performing otherwise valid actions
>>> in a number of scenarios.
>>>
>>> IMHO, a capabilities based approach is the only viable solution to
>>> this kind of problem.
>>
>> Right, we just had a super long conversation about this in #openstack-qa
>> yesterday with mordred, jroll, and deva around what it's going to take
>> to get upgrade tests passing with ironic.
>>
>> Capabilities is the right approach, because it means we're future
>> proofing our interface by telling users what they can do, not some
>> arbitrary string that they need to cary around a separate library to
>> figure those things out.
>>
>> It seems like capabilities need to exist on flavor, and by proxy instance.
>>
>> GET /flavors/bm.large/capabilities
>>
>> {
>>  "actions": {
>>  'pause': False,
>>  'unpause': False,
>>  'rebuild': True
>>  ..
>>   }
>>
>> A starting point would definitely be the set of actions that you can
>> send to the flavor/instance. There may be features beyond that we'd like
>> to classify as capabilities, but actions would be a very concrete and
>> attainable starting point. With microversions we don't have to solve
>> this all at once, start with a concrete thing and move forward.
> 
> I think there are two distinct use cases for capabilities we need to
> consider.
> 
>  1. Before I launch an instance, does the cloud provide features XYZ
> 
>  2. Given this running instance, am I able to perform operation XYZ
> 
> Having capabilities against the flavour /might/ be sufficient for
> #1, but it isn't sufficient for #2.
> 
> For example, the ability to hotplug disks to a running instance will
> depend on what disk controller the instance is using. The choice of
> disk controller used will vary based on image metadata properties,
> eg ide vs scsi vs virtio-blk. IDE does not support hotplug, but
> scsi & virtio-blk do. So we can't answer the question "does hotplug
> disk work for this instance" simply based on the flavour - we need
> to ask it against the instance.
> 
> What we can answer against the flavour is whether the hypervisor
> driver is able to support hotplug in principle, given a suitably
> configured instance. That said, even that is not an exact science
> if you take into account fact that the cloud could be running
> compute nodes with different versions, and the flavour does not
> directly control which version of a compute node we'll run against.
> 
> Having capabilities against the flavour would certainly allow for
> an improvement in Horizon UI vs its current state, but to be able
> to perfectly represent what is possible for an instance, Horizon
> would ultimately require capabilities against the isntance,
> 
> So I think we'll likely end up having to implement both capabilities
> against a flavour and against an instance. So you'd end up with a
> flow something like
> 
>  - Check to see if cloud provider supports hotplug by checking
>flavour capability==disk-hotplug
> 
>  - When booting an instance mark it as requiring capability==disk-hotplug
>to ensure its scheduled to a node which supports that capability
> 
>  - When presenting UI for operations against an instance, check
>that the running instance supports capability==disk-hotplug

Yes, instances would definitely also have capabilities. Once an instance
is launched it has local flavor anyway, and capabilities would transfer
accordingly (plus possibly be modified beyond that for various reasons).

The reason this effort has remained stalled is that no one disagrees
with the concept, but the realm of possible information exposed blows up
to the point that it's like Tasks; a good idea but too big to make any
progress on.

Capabilities by server POST action on flavors/instances is discrete
enough to be proposed and done in a cycle. It definitively makes the
"baremetal flavors/instances can't be paused" discoverable and a thing
which is concretely better for users.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[John Garbutt]

On 6 November 2015 at 09:49, Daniel P. Berrange  wrote:
> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
>> Hello all,
>> I came across [1] which is notionally an ironic bug in that horizon 
>> presents
>> VM operations (like suspend) to users.  Clearly these options don't make 
>> sense
>> to ironic which can be confusing.
>>
>> There is a horizon fix that just disables migrate/suspened and other 
>> functaions
>> if the operator sets a flag say ironic is present.  Clealy this is sub 
>> optimal
>> for a mixed hv environment.
>>
>> The data needed (hpervisor type) is currently avilable only to admins, a 
>> quick
>> hack to remove this policy restriction is functional.
>>
>> There are a few ways to solve this.
>>
>>  1. Change the default from "rule:admin_api" to "" (for
>> os_compute_api:os-extended-server-attributes and
>> os_compute_api:os-hypervisors), and set a list of values we're
>> comfortbale exposing the user (hypervisor_type and
>> hypervisor_hostname).  So a user can get the hypervisor_name as part of
>> the instance deatils and get the hypervisor_type from the
>> os-hypervisors.  This would work for horizon but increases the API load
>> on nova and kinda implies that horizon would have to cache the data and
>> open-code assumptions that hypervisor_type can/can't do action $x
>>
>>  2. Include the hypervisor_type with the instance data.  This would place the
>> burdon on nova.  It makes the looking up instance details slightly more
>> complex but doesn't result in additional API queries, nor caching
>> overhead in horizon.  This has the same opencoding issues as Option 1.
>>
>>  3. Define a service user and have horizon look up the hypervisors details 
>> via
>> that role.  Has all the drawbacks as option 1 and I'm struggling to
>> think of many benefits.
>>
>>  4. Create a capabilitioes API of some description, that can be queried so 
>> that
>> consumers (horizon) can known
>>
>>  5. Some other way for users to know what kind of hypervisor they're on, 
>> Perhaps
>> there is an established image property that would work here?
>>
>> If we're okay with exposing the hypervisor_type to users, then #2 is pretty
>> quick and easy, and could be done in Mitaka.  Option 4 is probably the best
>> long term solution but I think is best done in 'N' as it needs lots of
>> discussion.
>
> I think that exposing hypervisor_type is very much the *wrong* approach
> to this problem. The set of allowed actions varies based on much more than
> just the hypervisor_type. The hypervisor version may affect it, as may
> the hypervisor architecture, and even the version of Nova. If horizon
> restricted its actions based on hypevisor_type alone, then it is going
> to inevitably prevent the user from performing otherwise valid actions
> in a number of scenarios.
>
> IMHO, a capabilities based approach is the only viable solution to
> this kind of problem.

+1 to capabilities approach.

This also feels very related to the policy discovery piece we have
debated previously.

Thanks,
John

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Sean Dague]

On 11/06/2015 08:44 AM, Alex Xu wrote:
> 
> 
> 2015-11-06 20:59 GMT+08:00 Sean Dague  >:
> 
> On 11/06/2015 07:28 AM, John Garbutt wrote:
> > On 6 November 2015 at 12:09, Sean Dague  > wrote:
> >> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
> >>> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
>  Hello all,
>  I came across [1] which is notionally an ironic bug in that
> horizon presents
>  VM operations (like suspend) to users.  Clearly these options
> don't make sense
>  to ironic which can be confusing.
> 
>  There is a horizon fix that just disables migrate/suspened and
> other functaions
>  if the operator sets a flag say ironic is present.  Clealy this
> is sub optimal
>  for a mixed hv environment.
> 
>  The data needed (hpervisor type) is currently avilable only to
> admins, a quick
>  hack to remove this policy restriction is functional.
> 
>  There are a few ways to solve this.
> 
>   1. Change the default from "rule:admin_api" to "" (for
>  os_compute_api:os-extended-server-attributes and
>  os_compute_api:os-hypervisors), and set a list of values we're
>  comfortbale exposing the user (hypervisor_type and
>  hypervisor_hostname).  So a user can get the
> hypervisor_name as part of
>  the instance deatils and get the hypervisor_type from the
>  os-hypervisors.  This would work for horizon but increases
> the API load
>  on nova and kinda implies that horizon would have to cache
> the data and
>  open-code assumptions that hypervisor_type can/can't do
> action $x
> 
>   2. Include the hypervisor_type with the instance data.  This
> would place the
>  burdon on nova.  It makes the looking up instance details
> slightly more
>  complex but doesn't result in additional API queries, nor
> caching
>  overhead in horizon.  This has the same opencoding issues
> as Option 1.
> 
>   3. Define a service user and have horizon look up the
> hypervisors details via
>  that role.  Has all the drawbacks as option 1 and I'm
> struggling to
>  think of many benefits.
> 
>   4. Create a capabilitioes API of some description, that can be
> queried so that
>  consumers (horizon) can known
> 
>   5. Some other way for users to know what kind of hypervisor
> they're on, Perhaps
>  there is an established image property that would work here?
> 
>  If we're okay with exposing the hypervisor_type to users, then
> #2 is pretty
>  quick and easy, and could be done in Mitaka.  Option 4 is
> probably the best
>  long term solution but I think is best done in 'N' as it needs
> lots of
>  discussion.
> >>>
> >>> I think that exposing hypervisor_type is very much the *wrong*
> approach
> >>> to this problem. The set of allowed actions varies based on much
> more than
> >>> just the hypervisor_type. The hypervisor version may affect it,
> as may
> >>> the hypervisor architecture, and even the version of Nova. If
> horizon
> >>> restricted its actions based on hypevisor_type alone, then it is
> going
> >>> to inevitably prevent the user from performing otherwise valid
> actions
> >>> in a number of scenarios.
> >>>
> >>> IMHO, a capabilities based approach is the only viable solution to
> >>> this kind of problem.
> >>
> >> Right, we just had a super long conversation about this in
> #openstack-qa
> >> yesterday with mordred, jroll, and deva around what it's going to
> take
> >> to get upgrade tests passing with ironic.
> >>
> >> Capabilities is the right approach, because it means we're future
> >> proofing our interface by telling users what they can do, not some
> >> arbitrary string that they need to cary around a separate library to
> >> figure those things out.
> >>
> >> It seems like capabilities need to exist on flavor, and by proxy
> instance.
> >>
> >> GET /flavors/bm.large/capabilities
> >>
> >> {
> >>  "actions": {
> >>  'pause': False,
> >>  'unpause': False,
> >>  'rebuild': True
> >>  ..
> >>   }
> >>
> 
> 
> Does this need admin to set the capabilities? If yes, that looks like
> pain to admin to set capabilities for all the flavors. This should be
> the capabilities the instance required. And hypervisor should report
> their capabilities, and reflect to instance.

No, in version 1 there should be some 

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Sean Dague]

On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
>> Hello all,
>> I came across [1] which is notionally an ironic bug in that horizon 
>> presents
>> VM operations (like suspend) to users.  Clearly these options don't make 
>> sense
>> to ironic which can be confusing.
>>
>> There is a horizon fix that just disables migrate/suspened and other 
>> functaions
>> if the operator sets a flag say ironic is present.  Clealy this is sub 
>> optimal
>> for a mixed hv environment.
>>
>> The data needed (hpervisor type) is currently avilable only to admins, a 
>> quick
>> hack to remove this policy restriction is functional.
>>
>> There are a few ways to solve this.
>>
>>  1. Change the default from "rule:admin_api" to "" (for 
>> os_compute_api:os-extended-server-attributes and
>> os_compute_api:os-hypervisors), and set a list of values we're
>> comfortbale exposing the user (hypervisor_type and
>> hypervisor_hostname).  So a user can get the hypervisor_name as part of
>> the instance deatils and get the hypervisor_type from the
>> os-hypervisors.  This would work for horizon but increases the API load
>> on nova and kinda implies that horizon would have to cache the data and
>> open-code assumptions that hypervisor_type can/can't do action $x
>>
>>  2. Include the hypervisor_type with the instance data.  This would place 
>> the 
>> burdon on nova.  It makes the looking up instance details slightly more
>> complex but doesn't result in additional API queries, nor caching
>> overhead in horizon.  This has the same opencoding issues as Option 1.
>>
>>  3. Define a service user and have horizon look up the hypervisors details 
>> via 
>> that role.  Has all the drawbacks as option 1 and I'm struggling to
>> think of many benefits.
>>
>>  4. Create a capabilitioes API of some description, that can be queried so 
>> that
>> consumers (horizon) can known
>>
>>  5. Some other way for users to know what kind of hypervisor they're on, 
>> Perhaps
>> there is an established image property that would work here?
>>
>> If we're okay with exposing the hypervisor_type to users, then #2 is pretty
>> quick and easy, and could be done in Mitaka.  Option 4 is probably the best
>> long term solution but I think is best done in 'N' as it needs lots of
>> discussion.
> 
> I think that exposing hypervisor_type is very much the *wrong* approach
> to this problem. The set of allowed actions varies based on much more than
> just the hypervisor_type. The hypervisor version may affect it, as may
> the hypervisor architecture, and even the version of Nova. If horizon
> restricted its actions based on hypevisor_type alone, then it is going
> to inevitably prevent the user from performing otherwise valid actions
> in a number of scenarios.
> 
> IMHO, a capabilities based approach is the only viable solution to
> this kind of problem.

Right, we just had a super long conversation about this in #openstack-qa
yesterday with mordred, jroll, and deva around what it's going to take
to get upgrade tests passing with ironic.

Capabilities is the right approach, because it means we're future
proofing our interface by telling users what they can do, not some
arbitrary string that they need to cary around a separate library to
figure those things out.

It seems like capabilities need to exist on flavor, and by proxy instance.

GET /flavors/bm.large/capabilities

{
 "actions": {
 'pause': False,
 'unpause': False,
 'rebuild': True
 ..
  }

A starting point would definitely be the set of actions that you can
send to the flavor/instance. There may be features beyond that we'd like
to classify as capabilities, but actions would be a very concrete and
attainable starting point. With microversions we don't have to solve
this all at once, start with a concrete thing and move forward.

Sending an action that was "False" for the instance/flavor would return
a 400 BadRequest high up at the API level, much like input validation
via jsonschema.

This is nothing new, we've talked about it in the abstract in the Nova
space for a while. We've yet had anyone really take this on. If you
wanted to run with a spec and code, it would be welcome.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Alex Xu]

2015-11-06 20:59 GMT+08:00 Sean Dague :

> On 11/06/2015 07:28 AM, John Garbutt wrote:
> > On 6 November 2015 at 12:09, Sean Dague  wrote:
> >> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
> >>> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
>  Hello all,
>  I came across [1] which is notionally an ironic bug in that
> horizon presents
>  VM operations (like suspend) to users.  Clearly these options don't
> make sense
>  to ironic which can be confusing.
> 
>  There is a horizon fix that just disables migrate/suspened and other
> functaions
>  if the operator sets a flag say ironic is present.  Clealy this is
> sub optimal
>  for a mixed hv environment.
> 
>  The data needed (hpervisor type) is currently avilable only to
> admins, a quick
>  hack to remove this policy restriction is functional.
> 
>  There are a few ways to solve this.
> 
>   1. Change the default from "rule:admin_api" to "" (for
>  os_compute_api:os-extended-server-attributes and
>  os_compute_api:os-hypervisors), and set a list of values we're
>  comfortbale exposing the user (hypervisor_type and
>  hypervisor_hostname).  So a user can get the hypervisor_name as
> part of
>  the instance deatils and get the hypervisor_type from the
>  os-hypervisors.  This would work for horizon but increases the
> API load
>  on nova and kinda implies that horizon would have to cache the
> data and
>  open-code assumptions that hypervisor_type can/can't do action $x
> 
>   2. Include the hypervisor_type with the instance data.  This would
> place the
>  burdon on nova.  It makes the looking up instance details
> slightly more
>  complex but doesn't result in additional API queries, nor caching
>  overhead in horizon.  This has the same opencoding issues as
> Option 1.
> 
>   3. Define a service user and have horizon look up the hypervisors
> details via
>  that role.  Has all the drawbacks as option 1 and I'm struggling
> to
>  think of many benefits.
> 
>   4. Create a capabilitioes API of some description, that can be
> queried so that
>  consumers (horizon) can known
> 
>   5. Some other way for users to know what kind of hypervisor they're
> on, Perhaps
>  there is an established image property that would work here?
> 
>  If we're okay with exposing the hypervisor_type to users, then #2 is
> pretty
>  quick and easy, and could be done in Mitaka.  Option 4 is probably
> the best
>  long term solution but I think is best done in 'N' as it needs lots of
>  discussion.
> >>>
> >>> I think that exposing hypervisor_type is very much the *wrong* approach
> >>> to this problem. The set of allowed actions varies based on much more
> than
> >>> just the hypervisor_type. The hypervisor version may affect it, as may
> >>> the hypervisor architecture, and even the version of Nova. If horizon
> >>> restricted its actions based on hypevisor_type alone, then it is going
> >>> to inevitably prevent the user from performing otherwise valid actions
> >>> in a number of scenarios.
> >>>
> >>> IMHO, a capabilities based approach is the only viable solution to
> >>> this kind of problem.
> >>
> >> Right, we just had a super long conversation about this in #openstack-qa
> >> yesterday with mordred, jroll, and deva around what it's going to take
> >> to get upgrade tests passing with ironic.
> >>
> >> Capabilities is the right approach, because it means we're future
> >> proofing our interface by telling users what they can do, not some
> >> arbitrary string that they need to cary around a separate library to
> >> figure those things out.
> >>
> >> It seems like capabilities need to exist on flavor, and by proxy
> instance.
> >>
> >> GET /flavors/bm.large/capabilities
> >>
> >> {
> >>  "actions": {
> >>  'pause': False,
> >>  'unpause': False,
> >>  'rebuild': True
> >>  ..
> >>   }
> >>
>

Does this need admin to set the capabilities? If yes, that looks like pain
to admin to set capabilities for all the flavors. This should be the
capabilities the instance required. And hypervisor should report their
capabilities, and reflect to instance.


> >> A starting point would definitely be the set of actions that you can
> >> send to the flavor/instance. There may be features beyond that we'd like
> >> to classify as capabilities, but actions would be a very concrete and
> >> attainable starting point. With microversions we don't have to solve
> >> this all at once, start with a concrete thing and move forward.
>

+1, Microversions give us a way to improve our API! And capabilities API is
really important.


> >>
> >> Sending an action that was "False" for the instance/flavor would return
> >> a 400 BadRequest high up at the API level, much like 

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Richard Jones]

+1 this would definitely be the best approach from Horizon's perspective
since we can cache the capabilities per-flavour. Having to request
capabilities per-instance would be an unreasonable burden on the poor users
of Horizon.

On 6 November 2015 at 23:09, Sean Dague  wrote:

> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
> > On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
> >> Hello all,
> >> I came across [1] which is notionally an ironic bug in that horizon
> presents
> >> VM operations (like suspend) to users.  Clearly these options don't
> make sense
> >> to ironic which can be confusing.
> >>
> >> There is a horizon fix that just disables migrate/suspened and other
> functaions
> >> if the operator sets a flag say ironic is present.  Clealy this is sub
> optimal
> >> for a mixed hv environment.
> >>
> >> The data needed (hpervisor type) is currently avilable only to admins,
> a quick
> >> hack to remove this policy restriction is functional.
> >>
> >> There are a few ways to solve this.
> >>
> >>  1. Change the default from "rule:admin_api" to "" (for
> >> os_compute_api:os-extended-server-attributes and
> >> os_compute_api:os-hypervisors), and set a list of values we're
> >> comfortbale exposing the user (hypervisor_type and
> >> hypervisor_hostname).  So a user can get the hypervisor_name as
> part of
> >> the instance deatils and get the hypervisor_type from the
> >> os-hypervisors.  This would work for horizon but increases the API
> load
> >> on nova and kinda implies that horizon would have to cache the data
> and
> >> open-code assumptions that hypervisor_type can/can't do action $x
> >>
> >>  2. Include the hypervisor_type with the instance data.  This would
> place the
> >> burdon on nova.  It makes the looking up instance details slightly
> more
> >> complex but doesn't result in additional API queries, nor caching
> >> overhead in horizon.  This has the same opencoding issues as Option
> 1.
> >>
> >>  3. Define a service user and have horizon look up the hypervisors
> details via
> >> that role.  Has all the drawbacks as option 1 and I'm struggling to
> >> think of many benefits.
> >>
> >>  4. Create a capabilitioes API of some description, that can be queried
> so that
> >> consumers (horizon) can known
> >>
> >>  5. Some other way for users to know what kind of hypervisor they're
> on, Perhaps
> >> there is an established image property that would work here?
> >>
> >> If we're okay with exposing the hypervisor_type to users, then #2 is
> pretty
> >> quick and easy, and could be done in Mitaka.  Option 4 is probably the
> best
> >> long term solution but I think is best done in 'N' as it needs lots of
> >> discussion.
> >
> > I think that exposing hypervisor_type is very much the *wrong* approach
> > to this problem. The set of allowed actions varies based on much more
> than
> > just the hypervisor_type. The hypervisor version may affect it, as may
> > the hypervisor architecture, and even the version of Nova. If horizon
> > restricted its actions based on hypevisor_type alone, then it is going
> > to inevitably prevent the user from performing otherwise valid actions
> > in a number of scenarios.
> >
> > IMHO, a capabilities based approach is the only viable solution to
> > this kind of problem.
>
> Right, we just had a super long conversation about this in #openstack-qa
> yesterday with mordred, jroll, and deva around what it's going to take
> to get upgrade tests passing with ironic.
>
> Capabilities is the right approach, because it means we're future
> proofing our interface by telling users what they can do, not some
> arbitrary string that they need to cary around a separate library to
> figure those things out.
>
> It seems like capabilities need to exist on flavor, and by proxy instance.
>
> GET /flavors/bm.large/capabilities
>
> {
>  "actions": {
>  'pause': False,
>  'unpause': False,
>  'rebuild': True
>  ..
>   }
>
> A starting point would definitely be the set of actions that you can
> send to the flavor/instance. There may be features beyond that we'd like
> to classify as capabilities, but actions would be a very concrete and
> attainable starting point. With microversions we don't have to solve
> this all at once, start with a concrete thing and move forward.
>
> Sending an action that was "False" for the instance/flavor would return
> a 400 BadRequest high up at the API level, much like input validation
> via jsonschema.
>
> This is nothing new, we've talked about it in the abstract in the Nova
> space for a while. We've yet had anyone really take this on. If you
> wanted to run with a spec and code, it would be welcome.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
>