Hey folks,
IRC and mailing list were going far too slow for us to make progress on the
competing specifications for handling Dockerfile customization. Instead we
held a hangout, which I don't like because it isn't recorded, but it is high
bandwidth and permitted us to work through the problem in 1 hour instead of 1
month.
The essence of the discussion:
1. I will use inc0's patch as a starting point and will do the following:
* Prototype base with <block> operations using the specification items
in the elemental DSL
* Prototype mariadb with <block> operations using the specification
items in the elemental DSL
* I will create a document assuming these two prototypes work that
describe how to use the jinja2 <block> operations to replace or merge sections
of Dockerfile.j2 files.
* We will stop specification development as it has served its purpose
(of defining the requirements) assuming the prototypes meet people's taste test
2. We believe the Jinja2 <block> operation will meet the requirements set
forth in the original elemental DSL specification
3. We as a community will need to modify our 115 dockerfiles, of which I'd
like people to take 1 or 2 container sets each (40 in total), in a distributed
fashion to implement the documentation described in section 1.3
4. We will produce an optional DSL parser (based upon the prototyping work)
that outputs the proper <block> Dockerfile.j2 files or alternatively operators
can create their own block syntax files
5. All customization will be done in one master block replacement file
6. Original dockerfile.j2 files will stay intact with the addition of a
bunch of block operations
7. Some RUN layer compression will be lost (the && in our Dockerfiles)
8. There are 8 DSL operations but we will need twice as many to handle both
override and merging in a worst case scenario. That means 16 blocks will need
to be added to each Dockerfile.
9. Operators that have already customized their Dockerfile.j2 files can
carry those changes or migrate to this new customization technique when this
feature hits Newton, up to them
10. If the prototypes don't work, back to the drawing board - that said I am
keen to have any solution that meets the requirements so I will do a thorough
job on the prototypes of inc0's work
If you have questions, or I missed key points, please feel fee to ask or speak
up.
Regards
-steve
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev