Open Stack

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:dtantsur at redhat.com]
>> Sent: 24 August 2015 19:31
>> To: openstack-dev at 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-request at 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-request at 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-
>> request at 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-request at 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