settingsLogin | Registersettings

[openstack-dev] [ironic] [Openstack-operators] replace node "tags" with node "traits"

0 votes

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/approved/nodes-tagging.html
[2] https://review.openstack.org/#/c/504531/


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Oct 30, 2017 in openstack-dev by Loo,_Ruby (3,520 points)   2 2

5 Responses

0 votes

Sending again, I don't think it went to openstack-operators@.

--ruby

On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby ruby.loo@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/
approved/nodes-tagging.html

[2] https://review.openstack.org/#/c/504531/


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 25, 2017 by opensrloo_at_gmail.c (800 points)  
0 votes

Hi,

On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby ruby.loo@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/approved/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.

--
Mathieu


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 25, 2017 by mgagne_at_calavera.c (1,700 points)   1 3
0 votes

On 10/25/2017 12:55 PM, Mathieu Gagné wrote:
Hi,

On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby ruby.loo@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/approved/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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 26, 2017 by Jay_Pipes (59,760 points)   3 9 13
0 votes

On Fri, Oct 27, 2017 at 12:19 AM, Jay Pipes jaypipes@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 27, 2017 by Vladyslav_Drok (1,460 points)   1
0 votes

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@mirantis.com wrote:

On Fri, Oct 27, 2017 at 12:19 AM, Jay Pipes jaypipes@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@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 30, 2017 by opensrloo_at_gmail.c (800 points)  
...