Open Stack

+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 <sean at dague.net> 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)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151107/40178fb2/attachment.html>