Hi Shaheed,
A really good suggestion! I think we could to manage what you have
suggested in the same implementation as they overlap. I'm +1 for the idea
of putting a cluster into the "Maintenance Mode" manually for diagnostic
purposes and stop autoscaling it. We could introduce new API methods to
manage this. The only question is whether we could use the same instance
state for all the scenarios:
1. Update platform (might need to use the term platform here as it may get
confused with the software that may run on the platform)
2. Apply patches
3. Pause a cluster for diagnostic purposes
I would like to suggest to change the updateSoftware API method to
updatePlatform:
POST /applications/{applicationId}/updatePlatform
May be we could introduce a new API method as follows to put a cluster into
"Maintenance/Diagnostic Mode":
POST /clusters/{clusterId}/pause
Thanks
Imesh
On Thu, Mar 26, 2015 at 3:01 PM, Shaheedur Haque (shahhaqu) <
shahh...@cisco.com> wrote:
>
> 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)
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
