Skip to content
This repository has been archived by the owner on Jul 24, 2019. It is now read-only.

Address Naming Convention for Entire Project #267

Open
renmak opened this issue Mar 13, 2017 · 9 comments
Open

Address Naming Convention for Entire Project #267

renmak opened this issue Mar 13, 2017 · 9 comments

Comments

@renmak
Copy link
Contributor

renmak commented Mar 13, 2017

Is this a bug report or feature request? (choose one): Feature request

Kubernetes Version (output of kubectl version): Any

Helm Client and Tiller Versions (output of helm version): Any

Development or Deployment Environment?: Development

Release Tag or Master:

Expected Behavior: Proper naming convention for entire project

What Actually Happened:

How to Reproduce the Issue (as minimally as possible):

Any Additional Comments:

@renmak
Copy link
Contributor Author

renmak commented Mar 13, 2017

I can pick this up
@alanmeadows and @v1k0d3n can you share what are your thoughts on this feature item listed on roadmap xls.

@v1k0d3n v1k0d3n added this to the 0.3.0 milestone Mar 13, 2017
@v1k0d3n
Copy link
Collaborator

v1k0d3n commented Mar 13, 2017

@renmak one other thing you could do while performing this sweeping change across all of the charts, is capturing issue #207 as well, but the links are stale. @intlabs can you update the links with what you want @renmak to update (example: intended vs. current).

the licenses threw the L#'s numbers off.

@renmak
Copy link
Contributor Author

renmak commented Mar 14, 2017

@v1k0d3n @alanmeadows
Can you guys provide more information on this feature/issue? Need to understand what needs to be done here. thanks

@wilkers-steve
Copy link
Contributor

@renmak, this would involve finding a "standard" name to use for common fields/types across all charts. As @v1k0d3n mentioned, #207 captures standardizing the node label names. There may be other fields/types that multiple charts use that could be standardized as well.

@renmak
Copy link
Contributor Author

renmak commented Mar 15, 2017

@wilkers-steve Ah i see. K Then let me first start with #207 and will focus on other fields/types later on. Thanks for clarification.

@renmak
Copy link
Contributor Author

renmak commented Mar 16, 2017

@alanmeadows @intlabs @v1k0d3n

I was reviewing values.yaml of neutron and notice that how we define labels is not consistent with other charts.

  1. Neutron's nested labels
    labels:
    ovs:
    node_selector_key: openvswitch
    node_selector_value: enabled
    agent:
    dhcp:
    control_node_selector_key: openstack-control-plane
    control_node_selector_value: enabled
    ...
  2. Other charts
    labels:
    control_node_selector_key: openstack-control-plane
    control_node_selector_value: enabled

Is this something we need to address?

@renmak
Copy link
Contributor Author

renmak commented Mar 31, 2017

Just to share update. As part of Issue #207 (PR #302) code change, i have updated Nova's values.yaml to align with Neutron. We will create other issues for charts that also needs naming standardization.

@renmak
Copy link
Contributor Author

renmak commented Mar 31, 2017

@v1k0d3n @alanmeadows @wilkers-steve

Following charts (value.yaml) needs to be updated to align with Nova and Neutron.

A) For Cinder, Ceph, Glance, Heat charts, Labels needs to be separated (just like replicas) to achieve parity with Nova & Neutron

  1. Cinder
replicas:
  api: 1
  volume: 1
  scheduler: 1

labels:
  node_selector_key: openstack-control-plane
  node_selector_value: enabled

@renmak
Copy link
Contributor Author

renmak commented Apr 4, 2017

@v1k0d3n @alanmeadows @wilkers-steve
Created a new issue for above charts #326

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants