Hi There is certainly a lot of interest around Docker and TripleO. There is the tricky aspect of it adding another layer of deployment, but how hard can it be? :)
Cheers. Chris Jones [email protected] www.tenshu.net On 23 Jan 2014, at 21:10, Fox, Kevin M <[email protected]> wrote: > Would docker work for this? > > Assume every service gets its own docker container. A deployed node is then a > docker base image with a set of service containers. Updating an image could > be: > Check if base part of image updated (kernel, docker). if so, full redeploy > the node. > Sync each container image, restart container only if different? > > Maybe the same trick could be done with python virtualenvs instead... > > Kevin > ________________________________________ > From: Chris Jones [[email protected]] > Sent: Thursday, January 23, 2014 7:17 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [TripleO] our update story: can people live > with it? > > Hi > > Not a tarball. The node would notice from Heat metadata that it should update > to a new image and would fetch that image and sync the contents to its /. > This would leave it bit for bit identical to a fresh deployment of the new > image, at least on disk. The running state would differ and that still > requires some design and implementation to figure out. > > Cheers, > -- > Chris Jones > >> On 23 Jan 2014, at 12:57, Angus Thomas <[email protected]> wrote: >> >> On 22/01/14 20:54, Clint Byrum wrote: >>>>> >>>>> I don't understand the aversion to using existing, well-known tools to >>>>> handle this? >>>>> >>> These tools are of course available to users and nobody is stopping them >>> from using them. We are optimizing for not needing them. They are there >>> and we're not going to explode if you use them. You just lose one aspect >>> of what we're aiming at. I believe that having image based deploys will >>> be well received as long as it is simple to understand. >>> >>>>> A hybrid model (blending 2 and 3, above) here I think would work best >>>>> where >>>>> TripleO lays down a baseline image and the cloud operator would employ an >>>>> well-known >>>>> and support configuration tool for any small diffs. >>>>> >>> These tools are popular because they control entropy and make it at >>> least more likely that what you tested ends up on the boxes. >>> >>> A read-only root partition is a much stronger control on entropy. >>> >>>>> The operator would then be empowered to make the call for any major >>>>> upgrades that >>>>> would adversely impact the infrastructure (and ultimately the >>>>> users/apps). He/She >>>>> could say, this is a major release, let's deploy the image. >>>>> >>>>> Something logically like this, seems reasonable: >>>>> >>>>> if (system_change > 10%) { >>>>> use TripleO; >>>>> } else { >>>>> use Existing_Config_Management; >>>>> } >>>>> >>> I think we can make deploying minor updates minimally invasive. >>> >>> We've kept it simple enough, this should be a fairly straight forward >>> optimization cycle. And the win there is that we also improve things >>> for the 11% change. >> >> Hi Clint, >> >> For deploying minimally-invasive minor updates, the idea, if I've understood >> it correctly, would be to deploy a tarball which replaced selected files on >> the (usually read-only) root filesystem. That would allow for selective >> restarting of only the services which are directly affected. The >> alternative, pushing out a complete root filesystem image, would necessitate >> the same amount of disruption in all cases. >> >> There are a handful of costs with that approach which concern me: It >> simplifies the deployment itself, but increases the complexity of preparing >> the deployment. The administrator is going to have to identify the services >> which need to be restarted, based on the particular set of libraries which >> are touched in their partial update, and put together the service restart >> scripts accordingly. >> >> We're also making the administrator responsible for managing the sequence in >> which incremental updates are deployed. Since each incremetal update will >> re-write a particular set of files, any machine which gets updates 1,2, 3, >> there's an oversight, and then update 5 is deployed would end up in an odd >> state, which would require additional tooling to detect. Package based >> updates, with versioning and dependency tracking on each package, mitigate >> that risk. >> >> Then there's the relationship between the state of running machines, with >> applied partial updates, and the images which are put onto new machines by >> Ironic. We would need to apply the partial updates to the images which >> Ironic writes, or to have the tooling to ensure that newly deployed machines >> immediately apply the set of applicable partial updates, in sequence. >> >> Solving these issues feels like it'll require quite a lot of additional >> tooling. >> >> >> Angus >> >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
