[PATCH] BZ 870479 - fixed checking of "stopped after creation" state
by Jan Provazník
From: Jan Provaznik <jprovazn(a)redhat.com>
For rhevm/vsphere an instance goes to 'stopped' state after creation so
conductor has to send explicit start request. To distinguish "stopped after
creation" state and common "stopped" state conductor checks if last
instance launch request was sent after last deployment launch request
(there can be multiple launch requests for deployment/instance because of
rolblack+retry process).
In some cases it was possible that instance launch request was picked up by
delayed_job in same second when the deployment was created, so checking create
times by seconds was not precise enough.
---
src/app/models/instance.rb | 2 +-
src/spec/models/instance_spec.rb | 18 ++++++++++++++++++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/src/app/models/instance.rb b/src/app/models/instance.rb
index 8e02002..2d27394 100644
--- a/src/app/models/instance.rb
+++ b/src/app/models/instance.rb
@@ -525,7 +525,7 @@ class Instance < ActiveRecord::Base
# also make sure that the 'create' task was created after
# last deployment launch request - instance can be stopped
# since previous rollback+retry request
- last_task.created_at.to_i > last_launch_time.to_i &&
+ last_task.created_at.to_f > last_launch_time.to_f &&
provider_account &&
provider_account.provider.provider_type.goes_to_stop_after_creation?
end
diff --git a/src/spec/models/instance_spec.rb b/src/spec/models/instance_spec.rb
index 3f9a6f5..26fea33 100644
--- a/src/spec/models/instance_spec.rb
+++ b/src/spec/models/instance_spec.rb
@@ -379,4 +379,22 @@ describe Instance do
errors.should_not be_empty
errors.select {|e| e.include?("no Config Server available") }.should_not be_empty
end
+
+ describe ".stopped_after_creation?" do
+ before(:each) do
+ @instance = FactoryGirl.create(:instance, :pool_id => @pool.id, :state => 'stopped')
+ @deployment = FactoryGirl.create :deployment
+ @deployment.instances << @instance
+ end
+
+ it "should be true if the deployment is pending and the provider doesn't start an instance automatically" do
+ @instance.provider_account.provider.provider_type.
+ stub!(:goes_to_stop_after_creation?).and_return(true)
+ @deployment.update_attribute(:state, Deployment::STATE_PENDING)
+ @instance.tasks << InstanceTask.create!({:user => nil,
+ :task_target => @instance,
+ :action => InstanceTask::ACTION_CREATE})
+ @instance.stopped_after_creation?.should be_true
+ end
+ end
end
--
1.7.11.4
11 years, 4 months
RFC: to show Credential Definitions with Provider Type or not
by Petr Blaho
Hi,
I am working on show action for Provider Type API and I am not sure if I
should include Credential Definitions in XML representation of Provider
Type resource at all (probably bad idea), use only ids and hrefs or if
hsould I include the whole subresource there.
The similar question goes for create action. Should the user
be able to create new Credential Definitions from within Provider Type
data XML provided to create action? And the same for update action.
Or should be Credential Definition resource of its own?
Looking for your input.
--
With Regards
Petr Blaho
11 years, 4 months
RFC: frontend realms, deployments, and instances api
by Richard Su
Hi,
On the wiki we have preliminary versions of the request and responses we
are looking to implement for frontend realms, deployments, and instances
api. I will highlight a few points that may generate some discussions.
1. For frontend realms, when specifying the xml respresentation, users
will map directly to provider realms and providers. On the backend we'll
put each mapping into a backend realm target. But from a user's
perspective they don't need to worry about how things are actually
modelled in the backend.
https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Realms_-_F...
2. Once created, most deployment fields become read-only. The only two
that can be changed are name and state. For state, we will display an
available_states field indicating the possible transitions from the
current state. Users can PUT the entire xml deployment representation.
Changes to read-only fields will be ignored if it is something trivial
like a create_at, or will result in an error message if say a change was
made to associate with a different pool.
https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Deployments
3. Instances is similar to deployments in that only name and state can
be changed on the instance has been created. There is one additional
available_states called reboot. Putting an instance into the reboot
state will queue the reboot. From what I have gathered reboots happens
entirely on the cloud provider. From conductor's perspective the state
doesn't change and stays as running. The history will indicate that a
reboot had been queued at a particular time.
https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Instances
- Richard
11 years, 4 months
scenario: single rhev datacenter with multiple data domains
by Giulio Fidente
hi there,
as per subject, I'm currently looking at a scenario where one configures
ovirt/rhev with a single datacenter and multiple data domains
currently I don't think imgfac allows for configuration of the data
domain where the templates are imported
ovirt/rhev can only instantiate VMs on the same data domain where the
template
is located
these two seem to prevent cloudforms from being used efficiently in such
a configuration
are there workarounds I'm not aware of? work in progress? worth an RFE?
--
Giulio Fidente, gpg key id 08D733BA
11 years, 4 months
Personas - shared vision for our projects
by Jiří Stránský
Hi everybody,
while I was reading the Winged Monkey thread, I realized we might be missing a key thing in our projects - some shared vision of what are we building and who are we building it for. I started reading the WM thread being sceptic and gradually moved to a point "yeah, it starts to make sense to build this thing". But I had to do a lot of thinking and read a lot of explanations before I was able to come up in my mind with ideas of concrete people who would actually want to use Winged Monkey. I think this lack of clear vision and target users causes some confusion in communication and lengthy mailing list threads where we come to a shared point of view quite slowly. I'm thinking of whole Aeolus, not just Winged Monkey.
I don't think our scrum user stories are enough to provide us with a shared point of view. They state what is the purpose of each feature, but they don't give us any idea *who* will need such thing in the first place. "As a user, I want..." is not enough, because I still don't know who is the user. And this leaves room for endless debates about whether features are needed or not.
A good tool for getting a shared point of view about a project is personas (= imaginary people who will use our product). I've seen Francesco and Justin discussing personas on IRC, but I'm not sure what was the result, so I'd like to bring them up again here. For getting familiar with personas and why they are useful I recommend reading first half of this article [1], sections "Defining Personas", "Personas as a Comminication Tool" and "Empathetic Focus". It's quite short :)
I believe that personas, when done right, would enable us to make project decisions with less friction. I believe that many of the differences in opinions are caused by the fact that each one of us has a slightly different idea of users and their use cases for Aeolus.
We could also find personas helpful when defining long-term project roadmaps.
====
An example with decision making:
Should we build APIs over network (e.g. REST) between our components, or will we just use components as Ruby gems?
1) - I don't want to put network in between our components. It makes things more complicated and there's no real benefit.
- No, it's important for connecting the components to other systems.
- Well but we still don't know if anyone will want to do that.
(... 2 hour conversation about whether external API is needed ...)
2) - Hmm, I think John, the IT infrastructure administrator in the small business company, would want to use just /this component/ and have it communicating with his /that app/.
- Hmm, so we will need some external API.
(... still far from conclusion ;) but moving forward faster ...)
The important thing is that the personas should be defined well, so that they help us with such ^^ decisions.
====
I should also admit here that personas are a lot of work and it is probably going to have to be done by someone else than me, as I have no experience with the business side of cloud computing so I have little knowledge of what users/customers might need. But "As an engineer, I'd like to have personas in order to make community decisions more effectively and efficiently" :)
Take care,
J.
[1] http://www.jnd.org/dn.mss/personas_empath.html
11 years, 5 months
Deployables API draft, continued
by Maros Zatko
On 10/29/2012 10:50 AM, Maros Zatko wrote:
> Hi folks!
> There's a draft [1] of deployables API I've put together.
> There's a room for improvement though, so please feel free
> and share your thoughts about it.
>
> Thanks for your time!
> - maros
>
> [1] -
> https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Deployables
Hi Maros,
From the UI, today, a person can see the build status of each image and
whether they have been pushed to each provider. How much we need to also
duplicate in the API is unclear to me. At the minimum, I think we should
provide enough information so that the build and push status can be
determined through further API calls.
I see that the image ids are embedded in the deployables xml. They are
just ids and don't point to an image resource in the API. I think we
should do add an <images> field to deployables. It would be read-only
based off of what is in the deployables xml.
<images>
<image id='51a42ec2-1e5d-11e2-8ad5-52540053d8d3'
href='https://localhost/conductor/api/images/51a42ec2-1e5d-11e2-8ad5-52540053d8d3'></images>
...
</images>
Deployables.get_image_details may be helpful in generating a list of the
images.
The UI also doesn't present an option to launch a deployable if the
image has not been pushed to at least one provider. From the UI one can
create a deployable that is not ready to launch, and navigate to one is
ready and select launch, but if you end up selecting the deployable that
is not ready to launch on the deployment form, then the UI does display
an error indicating that an image has not been pushed to the selected
provider.
So there are already built in checks to prevent a user from getting into
trouble if they don't themselves figure out the build and push status of
each image in the deployable. For convenience and usability, it would be
nice to have an launchable field, but this could be implemented as phase
2. Even without it, the API would still be usable. What are other's
opinion on this?
Some minor corrections:
* the response under create is missing the catalog.
* show response is missing the owner id
* I could be wrong, but I don't think we need to track the xml filename
Thanks for getting deployables started,
Richard
11 years, 5 months
[PATCH conductor 0/1] #871484 - Add logging to provider account creation
by Matt Wagner
This is a quick fix for https://bugzilla.redhat.com/show_bug.cgi?id=871484 -- if we get a Deltacloud error when creating a provider account, we swallow the error and just display a nice message to the user. That makes it really hard to track down what is going on, and #832568 is hampered by this. This patch allows us to log the exception and a stack trace, while still showing a "nice" message to the user.
Because this will help track down an intermittent bug (832568) and because it's just adding logging versus any substantial code changes, this has been marked as a 1.1 blocker+.
-- Matt
11 years, 5 months
Winged Monkey
by Greg Blomquist
What is Winged Monkey?
The idea for Winged Monkey started as a simple end user cloud access portal.
We are trying our best to stick to this idea. But, it requires a certain set
of consistent key ideas:
* Winged Monkey is geared towards users and not administrators
* Winged Monkey should provide simple usable access to cloud back ends
* Winged Monkey cannot do anything that a back end provider cannot do
In the end, we want it to be an attractive, simple, and intuitive user
interface that makes the resources of multiple underlying cloud providers
accessible to non-technical users who are focused on achieving their goals
rather than on attempting to understand the "cloud".
Why Winged Monkey?
Originally, the name started as joke. But, like all project names, we
rationalized the name to fit the project. The monkey only knows how to do
simple things. If you teach the monkey, it can eventually learn to do more
complex things. It's still just a monkey, though, and will never be the
smartest primate in the room. It's one advantage is that it has wings, so it
can play in the clouds.
Monkey Goals
The primary focus is to make a simple user interface for cloud resource
consumption. The simplest interface we think we can provide is one where a
user can start/stop VMs and launch pre-existing applications.
The simplest ideas are sometimes the hardest to implement. For instance, how
do we provide the ability to start/stop VMs against various back ends while
trying to shield the user from having to configure the access to those back
ends? Clearly there needs to be an administrative component. We're just
doing our best not to worry too much about the administrative side at this
point. The fact is that there are several other applications that handle
cross cloud administration. Eventually, we'll likely just tie into one of
those systems to off load the administrative
portions.
If it turns out we need to implement something that's already implemented by
another application, we'll grudgingly do it. But, we're gonna exhaust every
potential integration point, first.
A Winged Monkey is not a ...
... Conductor. Winged Monkey will avoid providing any type of cloud account
multiplexing directly. It will avoid cloud management interfaces. It will
not build or push images to back end providers. And, it will not implement
quota and cost management.
Instead, it's more likely that Winged Monkey would like to plug into Conductor
APIs to take advantage of these features.
... Deltacloud. Winged Monkey is an end-user application, and not intended to
be an API.
If Winged Monkey takes advantage of Conductor's API for account multiplexing
and cloud cost/quota, it will in turn be using the Deltacloud API to connect
to cloud back ends.
... Heat API. Winged Monkey will not have a concept of stack templates or
managing the high availability of applications running in the cloud.
Winged Monkey will rely on APIs like Heat to provide stack (or application)
deployments and health monitoring.
... Foreman. Winged Monkey will not present puppet classes or manifests for
configuration management. It will not contain administration for networking
configuration of hosts or guests.
Winged Monkey could use the Foreman API to launch systems that connect to a
puppetmaster for configuration management.
Progress so far
Everything we've done so far has been in the vein of brainstorming.
Jeremy Perry has put together some excellent wireframes[1] that nicely convey
the theme of simple user interface for consuming cloud resources.
We threw together some high level user stories[2] that try to capture what we
would want this thing to do.
And, I've started an extremely simple rails app[3] that attempts to meet
Jeremy's wireframes. The current goal of the rails app is to connect directly
to oVirt and show what pieces of the proposed user interface can actually be
provided.
Milestones
We're still working on these.
Call for help
We are in need of people who want to explore this idea further. We're looking
for people who:
* are good at visual design and user experience
* have interesting ideas about servicing end users of cloud resources
* dream in ruby/rails
Initially, we want the team to stay small. There's not a lot of work to divvy
out right now, so there's not a immediate need for a bunch of helping hands.
But, we also want feedback. If you think we're heading down the wrong path,
speak up! If you have ideas about how to make this idea work, speak up! If
you just wanna find out why we would do this, speak up!
[1]: https://github.com/wingedmonkey/documents
[2]: https://github.com/wingedmonkey/documents/wiki/Winged-Monkey-User-Stories
[3]: https://github.com/wingedmonkey/wingedmonkey
---
Greg
11 years, 5 months
Our website now runs from GitHub Pages
by Justin Clift
Hi everyone,
Good news. :) The www.aeolusproject.org website now runs
completely out of GitHub Pages.
(technically, www.aeolusproject.org is now a CNAME redirect
to aeolusproject.github.com)
This makes updating the website very quick and simple.
Everything in the new GitHub repo is in Markdown (kramdown
variety), with the website automatically regenerated on
every new commit:
https://github.com/aeolusproject/aeolusproject.github.com
To change anything, just submit a pull request like a standard
GitHub project now. :)
Page regeneration happens within a few minutes of every merge.
If anyone needs it, the repo for the old nanoc based website is
now here:
https://github.com/aeolusproject/aeolus-website-old
Caveats
*******
+ The temporary redirects from www.aeolusproject.org/redmine
to redmine.aeolusproject.org don't work any more.
To link to the Redmine site from here on, you have to use
the https://redmine.aeolusproject.org/redmine URL.
Credits
*******
Several people need thanking for their work on this:
* Francesco Vollero for the idea to use GitHub Pages in the
first place, then creating the initial concept website to
show it works, plus getting the DNS changes done.
* Matt Wagner for writing up the initial ToDo list plan,
moving Redmine to it's own subdomain, and creating all of
the apache rewrite rules.
* Jason Guiditta for the GitHub repo admin-ing.
* Myself for bulk converting the old website contents to
Markdown. :)
Regards and best wishes,
Justin Clift
--
Aeolus Community Manager
http://www.aeolusproject.org
11 years, 5 months