aeolus-devel October 2012

aeolus-devel@lists.fedorahosted.org

43 participants
110 discussions

[PATCH] BZ 870479 - fixed checking of "stopped after creation" state
by Jan Provazník 20 Nov '12

20 Nov '12

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

2 1

RFC: to show Credential Definitions with Provider Type or not
by Petr Blaho 13 Nov '12

13 Nov '12

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

4 4

RFC: frontend realms, deployments, and instances api
by Richard Su 12 Nov '12

12 Nov '12

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_-_Fro… 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

3 5

scenario: single rhev datacenter with multiple data domains
by Giulio Fidente 06 Nov '12

06 Nov '12

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

2 1

Personas - shared vision for our projects
by Jiří Stránský 01 Nov '12

01 Nov '12

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

6 7

Deploying fedora infrastructure (koji) across clouds
by Mo Morsi 31 Oct '12

31 Oct '12

// Deploying fedora infrastructure (koji) across clouds // As promised, steps to deploy kojihub to an openstack instance communicating with builders on ec2 // Any provider supported by deltacloud will work // (lots of em: http://deltacloud.apache.org/drivers.html) // A short video of these steps in action can be seen here: // http://youtu.be/qF2ctg7ItNc // install deltacloud & drivers $ sudo yum install wget deltacloud-core deltacloud-core-openstack deltacloud-core-ec2 // start it $ deltacloudd -i mock // small wrapper script around deltacloud: $ wget https://raw.github.com/movitto/mycloud/master/mycloud.rb $ chmod +x mycloud.rb // template describing kojihub cloud deployment $ wget https://raw.github.com/aeolus-incubator/templates/master/fedora_infra/koji/… // template describing kojibuild cloud deployment $ wget https://raw.github.com/aeolus-incubator/templates/master/fedora_infra/koji/… // edit kojihub deployment to contain openstack credentials $ vim koji_f17.xml // startup an instance on openstack w/ kojihub setup togo $ ./mycloud.rb koji_f17.xml // grab public address from output, grab kojibuild ssl credentials from new instance $ scp -i ~/os.key ec2-user@kojihub:/etc/pki/koji/kojiadmin.pem . $ scp -i ~/os.key ec2-user@kojihub:/etc/pki/koji/koji_ca_cert.crt . // edit kojibuild deployment to deploy to ec2 w/ correct koji credentials & hub address $ vim koji_builder_f17.xml // startup an instance on ec2 w/ kojibuild communicating w/ the hub $ ./mycloud.rb koji_builder_f17.xml // open up a webbrowser, navigating to http://kojihub/koji to use your Koji instance! -Mo

3 3

Deployables API draft, continued
by Maros Zatko 31 Oct '12

31 Oct '12

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

1 0

[PATCH conductor 0/1] #871484 - Add logging to provider account creation
by Matt Wagner 30 Oct '12

30 Oct '12

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

2 2

Winged Monkey
by Greg Blomquist 30 Oct '12

30 Oct '12

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

12 53

Our website now runs from GitHub Pages
by Justin Clift 29 Oct '12

29 Oct '12

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel October 2012