Restructure the docker directory
Structure new templating-based build of the docker-templates directory into "infra", "main", and "aux" directories. Development priority will be given to "infra" and "main", while "aux" will be worked on as developers wish. Our general policy will be to require the project to be listed in the governance/
Prioriority - Essential (E), High (H), Low (L)
docker_templates
+ infra
+ ceph (H)
+ galera (E)
+ haproxy (E)
+ keepalived (E)
+ kolla-ansible (E)
+ memcached (H)
+ mongodb (E)
+ openvswitch (E)
+ rabbitmq (E)
+ main
+ cinder (H)
+ ceilometer (H)
+ glance (E)
+ heat (E)
+ horizon (E)
+ keystone (E)
+ neutron (E)
+ nova (E)
+ swift (H)
+ aux
+ designate (L)
+ gnocchi (L)
+ ironic (L)
+ magnum (L)
+ zaqar (L)
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Low
- Drafter:
- Steven Dake
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
- Mark Goddard
Related branches
Related bugs
Sprints
Whiteboard
As discussed in IRC, I don't agree with separating out the infra services like listed here. All services that are required to building Kolla should be in one folder. And naming it core would probably get confusing since Openstack also uses core in places. I recommended 'basic' as a name. -- SamYaple
Even though the word core is used elsewhere in the OpenStack world, I still think it's a better name here than "basic". I do agree with not separating the infra services. My vote would be to merge "basic+infra" into "core", and rename "supp" to "contrib". -- pbourke
I don't want the name contrib. It implies someone contributed something that we don't implicitly implement ourselves. I hate to use the word support so I wont, but it also seems to imply we don't actively maintain stuff in contrib either. That is why the word supplemental was chosen, but that is too long, so supp it is. --sdake
The advantages of an infra directory 1) it defines the build from binary packages that are in the system 2) it is a marker for humans that they are dealing with a non openstack service 3) it costs nothing in terms of separation other then an extra cd operation. We already need that for the supplmental directory. An infra directory essentially has no downside and some minor positives. --sdake
I can give you the 'infra' separation, I don't particularly like it but I see you care so I will go along with you. I would offer a counter point up that there may be a container that is in the 'supp' group, but has to go into the infra group.
On this note, let me say these are directories that have no affect on tagging. We can have longer explicit names. 'infrastructure' 'supplemental' are totally fine. If you insist on short names, I am going to insist on a different name than 'supp'. I also want a different name than 'basic' if you are going to keep the 'infra' separation.
I like 'infra' 'main' and 'aux' if we have to go with short names.
I like 'infrastructure' 'primary' and 'secondary' if we can go with longer names. -- SamYaple
aux·il·ia·ry
ôɡˈzilyərē,
adjective
1.
providing supplementary or additional help and support.
I am good with aux ;) I am good with main. I don't care long vs short, short = less typing ;) all that said, this blueprint would come after the removal of the docker dir which seems higher priority then a restructure. I'm not sure we will get to this restructure in rc1... --sdake
Can we handle this without a directory structure change? Instead in the tox build things and/or flags for build.py? I dont really see the need to change directory structure to achieve this. it will also make backports much more difficult. --SamYaple
Gerrit topic: https:/
Addressed by: https:/
Add build profiles to build.py
Addressed by: https:/
Add build profiles to build.py
Work Items
Dependency tree
* Blueprints in grey have been implemented.
