[openstack-dev] [kolla] Google Hangouts discussion for dueling specifications for Dockerfile customization

Steven Dake (stdake) stdake at cisco.com
Fri Jun 3 00:50:50 UTC 2016


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160603/9a8cf9ef/attachment.html>


More information about the OpenStack-dev mailing list