Open Stack

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