First, let me say that I like a lot of what is proposed in this JIRA, but I am forking the thread here because I would like to suggest that we generalise just one part of it, the API into Stratos to cover a set of related use cases.
In the current version of this JIRA, the proposed API into Stratos looks like this: PUT /api/applications/{applicationId} /updateSoftware (see the JIRA section 2.3 for the details). I think this is actually one of a set of possible runtime states that we would like to put VM instances and various parts of Stratos in. Notice that I am deliberately not using specific terms such as "cluster" or "Autoscalar" because working that out is the point of this email. So, the sorts of use cases I have in mind are: * Updating the cartridge software as per this JIRA * Putting a cluster (or maybe an instance) into a "maintenance mode" for diagnostic reasons. There could be multiple versions of this maintenance mode where (for example) * The instance(s) might still handle traffic and deliver "I'm alive" health stats but no autoscaling is done. * The instance(s) don't deliver health stats but no health stats * Some of these would deliver notifications to the cartridge agent, others might only affect Stratos component(s). * etc...other ideas anybody? Thus, it might make sense to generalise the API to support a set of closely related cases. Is there interest in taking such an approach to address this JIRA as well in clarifying and addressing the other use cases? Thanks, Shaheed ________________________________________ From: Sandaruwan Nanayakkara (JIRA) [j...@apache.org] Sent: 25 March 2015 08:36 To: d...@stratos.incubator.apache.org Subject: [jira] [Commented] (STRATOS-1234) Software Update Management Solution for Stratos [ https://issues.apache.org/jira/browse/STRATOS-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379497#comment-14379497 ] Sandaruwan Nanayakkara commented on STRATOS-1234: ------------------------------------------------- Hi all, I have updated the Google doc with updating scenarios and please share your ideas by commenting and will be pretty much appreciated. https://docs.google.com/document/d/1Ep2EwLubQnAv0bQGXE2ynwIDrRFCtMnCZ1E52KtzUH4/edit?usp=sharing After days I finally deployed almost all of the Stratos samples with kubernates and openstack :) Now the main fuss is on triggering updates in different software. Can you give an example on a software and how update is triggered manually. A practical approach?? Suppose that I have a software in a single cartridge application. So when triggering update with the REST we need a specific way to communicate with the software. Is there any way that this updating command is given to the software? Thanks Sandaruwan > Software Update Management Solution for Stratos > ------------------------------------------------ > > Key: STRATOS-1234 > URL: https://issues.apache.org/jira/browse/STRATOS-1234 > Project: Stratos > Issue Type: New Feature > Reporter: Imesh Gunaratne > Labels: gsoc2015, mentor > > Stratos uses Virtual Machines and Containers for hosting platform services on > different Infrastructure as a Service (IaaS) solutions. At present Puppet is > used for orchestration management on Virtual Machine based systems and > manages all required software in Puppet Master. Container based systems > creates Docker images for each platform service by including required > software in the Docker image itself. > In Virtual Machine use-case VM instances will communicate with Puppet master > and execute the software installation. The same approach can be used for > applying software updates. > In Docker use-case we do not use Puppet because a new container with required > software can be started in few seconds. This is very efficient compared to > using Puppet and installing software on demand. > The requirement of this project is to implement a core Stratos feature to > propagate software updates in a live PaaS environment. > 1. Puppet based solution: > - Push software updates of a cartridge to Puppet Master (might not need to > automate). > - Invoke the software update process via the Stratos API for a given > application. > - Stratos Manager could send a new event to trigger puppet agent in each > instance to apply the updates. > 2. Docker based solution > - Create a new docker image (with a new image id) for the cartridge with > software updates (might not need to automate). > - Invoke the software update process via the Stratos API for a given > application. > - Autoscaler can implement a new feature to bring down existing instances and > create new instances with the new docker image id. > Important! > - In each scenario if updates are backward compatible, software update > process should execute in phases, it should not bring down the entire cluster > to apply the updates. If so the service will be unavailable for a certain > time period. The idea is to apply the updates to set of members at a time. > - If the updates are not backward compatible, we could make the entire > cluster unavailable at once and apply the updates. > - Member's state needs to be changed to a new state called "Updating" when > applying the updates. > If there is an interest on doing this project please send a mail to imesh at > apache dot org by copying Apache Dev mailing list [1]. Please refer Stratos > Wiki [2] for more information on Stratos architecture and how it works. > [1] http://stratos.apache.org/community/mailing-lists.html > [2] https://cwiki.apache.org/confluence/display/STRATOS -- This message was sent by Atlassian JIRA (v6.3.4#6332)