Steve, If you have any concerns with recording the Hangouts meetings, we may try to run Zoom for that.
On Fri, Jun 3, 2016 at 3:50 AM, Steven Dake (stdake) <std...@cisco.com> wrote: > 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: > 1. Prototype base with <block> operations using the specification > items in the elemental DSL > 2. Prototype mariadb with <block> operations using the > specification items in the elemental DSL > 3. 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. > 4. 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Ihor Dvoretskyi, OpenStack Operations Engineer --- Mirantis, Inc. (925) 808-FUEL
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev