Open Stack

Hi,

Thanks for your 3 votes. Every vote counts; you've convinced me of the
usefulness of having both tags and traits as separate features. I shall
advocate for you all :)

--ruby


On Fri, Oct 27, 2017 at 5:41 AM, Vladyslav Drok <vdrok at mirantis.com> wrote:

>
>
> On Fri, Oct 27, 2017 at 12:19 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>
>> On 10/25/2017 12:55 PM, Mathieu Gagné wrote:
>>
>>> Hi,
>>>
>>> On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby <ruby.loo at intel.com> wrote:
>>>
>>>> Hello ironic'ers,
>>>>
>>>> A while ago, we approved a spec to add node tag support to ironic [1].
>>>> The
>>>> feature itself did not land yet (although some of the code has). Now
>>>> that
>>>> the (nova) community has come up with traits, ironic wants to support
>>>> node
>>>> traits, and there is a spec proposing that [2]. At the ironic node
>>>> level,
>>>> this is VERY similar to the node tag support, so the thought is to drop
>>>> (not
>>>> implement) the node tagging feature, since the node traits feature
>>>> could be
>>>> used instead. There are a few differences between the tags and traits.
>>>> "Traits" means something in OpenStack, and there are some restrictions
>>>> about
>>>> it:
>>>>
>>>> - max 50 per node
>>>>
>>>> - names must be one of those in os-traits library OR prefixed with
>>>> 'CUSTOM_'
>>>>
>>>> For folks that wanted the node tagging feature, will this new node
>>>> traits
>>>> feature work for your use case? Should we support both tags and traits?
>>>> I
>>>> was wondering about e.g. using ironic standalone.
>>>>
>>>> Please feel free to comment in [2].
>>>>
>>>> Thanks in advance,
>>>>
>>>> --ruby
>>>>
>>>> [1]
>>>> http://specs.openstack.org/openstack/ironic-specs/specs/appr
>>>> oved/nodes-tagging.html
>>>>
>>>> [2] https://review.openstack.org/#/c/504531/
>>>>
>>>>
>>> Are tags/traits serving a different purpose? One serves the purpose of
>>> helping the scheduling/placement while the other is more or less aims
>>> at grouping for the "end users"?
>>> I understand that the code will be *very* similar but who/what will be
>>> the consumers/users?
>>> I fell they won't be the same and could artificially limit its use due
>>> to technical/design "limitations". (must be in os-traits or be
>>> prefixed by CUSTOM)
>>>
>>> For example which I personally foresee:
>>> * I might want to populate Ironic inventory from an external system
>>> which would also injects the appropriate traits.
>>> * I might also want some technical people to use/query Ironic and
>>> allow them to tag nodes based on their own needs while not messing
>>> with the traits part (as it's managed by an external system and will
>>> influence the scheduling later)
>>>
>>> Lets not assume traits/tags have the same purpose and same user.
>>>
>>
>> I agree with Matthieu 100% here.
>>
>> Traits are structured, formalized, and set by the system or the operator
>> against resource providers.
>>
>> Tags are for end-users to, well, tag their instances with whatever
>> strings they want.
>>
>> Best,
>> -jay
>
>
> I'd also vote for having them separate. We can refactor the common bits of
> code instead.
>
> -Vlad
>
>
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171030/d8b7d926/attachment.html>