On 24/08/15 18:19 +0000, Tim Bell wrote:
From a user perspective, where bare metal and VMs are just different flavors
(with varying capabilities), can we not use the same commands (server
create/rebuild/...) ? Containers will create the same conceptual problems.
OSC can provide a converged interface but if we just replace '$ ironic XXXX' by
'$ openstack baremetal XXXX', this seems to be a missed opportunity to hide the
complexity from the end user.
Can we re-use the existing server structures ?
Tim
To my knowledge, overriding or enhancing existing commands like that
is not possible.
-----Original Message-----
From: Dmitry Tantsur [mailto:dtant...@redhat.com]
Sent: 24 August 2015 19:31
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin
On 08/24/2015 07:25 PM, Brad P. Crochet wrote:
> On 24/08/15 17:56 +0200, Dmitry Tantsur wrote:
>> On 08/24/2015 05:41 PM, Jay Pipes wrote:
>>> On 08/24/2015 08:03 AM, Brad P. Crochet wrote:
>>>> I am working on extending the current set of patches that implement
>>>> the OSC plugin for Ironic. I would like some discussion/guidance
>>>> about a couple of command structures.
>>>>
>>>> Currently provisioning state is set via 'openstack baremetal set
>>>> --provision-state [active|deleted|rebuild|inspect|provide|manage]
>>>> $NODE'
>>>>
>>>> dtantsur suggests it be top-level a command (which I concur)
>>>> 'openstack baremetal
[active|delete|rebuild|inspect|provide|manage]
>>>> $NODE'
>>>>
>>>> Question there is does that make sense?
>>>
>>> I prefer the current CLI command structure.
>>>
>>> `openstack baremetal active $NODE` does not make grammatical
sense.
>>>
>>> `openstack baremetal activate $NODE` would make more sense, but I
>>> actually think the original is easier.
>>
>> As it is now it's a bit hard to understand what "openstack baremetal
>> set" command actually does, as it corresponds to 2 API's (and I hope
>> it won't also do node updating, will it?)
>
> I'm not sure what you mean about node updating... Do you mean setting
> properties? Because it does that. Can you be more specific about what
> you mean?
So is it a replacement for 3 APIs/commands:
ironic node-set-maintenance
ironic node-set-provision-state
ironic node-update
?
If so, that's too much IMO.
>
>>
>>>
>>> Best,
>>> -jay
>>>
>>>
__________________________________________________________
__________
>>> ______
>>>
>>> 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
>
__________________________________________________________
________________
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
--
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385 (w) 919.301.3231
__________________________________________________________________________
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
