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)
