Please pick up my OpenStack task!
by Matt Wagner
Hi folks,
I'm going to be in a training session all next week, which means I won't
be able to work on Aeolus. While a week away from the project breaks my
heart enough, I had a great task going to try to get OpenStack support
finished up, and unfortunately I didn't get far. I'm hoping someone
wants to pick up where I left off next week.
The task is https://www.aeolusproject.org/redmine/issues/3814
I posted a blog post on Monday about where I got; I never got any
further. See http://ma.ttwagner.com/aeolus-and-openstack-todays-status/
There is a known-good internal OpenStack server I got an account on. I
forwarded my credentials there to Angus to share if someone does pick
this task up.
#858030 is still outstanding and blocks further progress; it still has
an open pull request. If you can get that ACKed, you can move onto the
really fun stuff -- trying to build and launch images! (With the patch
applied I was able to import and launch an existing image, but then
totally unrelated local breakage with dbomatic kept me from getting any
further.)
I've got the boring stuff out of the way. (And Oneiroi did much of the
heavy lifting quite some time ago.) Now that the boring stuff is out of
the way, will one of you pick this task up while I'm out next week?
Success can be yours! I don't want to see this one fall by the wayside
again.
Best,
Matt
10 years, 5 months
RFC: Integrating Aeolus with Heat
by Tomas Sedovic
Hey Folks,
I've been contributing to the Heat project lately and I think it's
gotten to a point where we (the Aeolus community) could look at it and
figure out if it's something we want to use.
Please forgive me the length of this email. I tried to make it as short
but there's a lot to cover. Grab your favourite beverage and sit
comfortably.
A little background
-------------------
Heat is a project that provides orchestration and high availability to
OpenStack. Its API is modelled after Amazon CloudFormation.
What it does in Aeolus' terms is: you create a deployable and pass it to
Heat API along with any launch-time parameters. Heat will decide on the
correct order of the resources (instances, databases, load balancers,
remote storage, floating IP addresses, etc.) and launches and configures
the whole thing to produce a running deployment.
Heat started about five months ago and hopes to become one of the core
OpenStack components. It's written in Python following the OpenStack
development model and tools.
What's this to do with Aeolus?
------------------------------
We're trying to solve some of the same problems:
* launching multiple instances in correct order
* passing parameters that are only known when an instance is launched
* configuring and advertising the services running inside the VMs
If we could outsource this to a project whose sole focus is solving
these issues, we could focus on things that make Aeolus unique: building
great UI, tools and APIs for managing cross-cloud deployments.
As a side benefit, we would get the current and future features of Heat
for free:
* high availability
* auto-scaling
* load-balancing
OpenStack? Huh?
---------------
Heat is an OpenStack project and the developers did not put effort into
making sure that it works with anything else.
However, Ian Main and I looked into the code and it seems that we could
integrate Deltacloud support with little changes in the Heat codebase.
The Deltacloud backend would be an external package that would not
pollute Heat's code and dependencies. The changes to add supports for a
custom backend would be small so there's a good chance they'd be accepted.
Proof of concept
----------------
It would be cool if we had a working prototype to demonstrate the
strengths and weaknesses as a reference for the discussion.
We're not there yet but Ian and I have came up with a plan that should
produce a basic prototype reasonably quickly.
The first step is to get Conductor to launch multi-instance deployments
using Heat, nothing else. The plan is at the end of this email.
Image management
----------------
Heat's image management is very similar to Aeolus'.
The images are built using Oz and stored in Glance (OpenStack's image
storage tool).
Heat supports both installing everything at runtime from bare (JEOS)
images and using preconfigured images and just launching those.
So far the focus has been on the former but both approaches work and
Heat developers are spending more time making the experience with image
prebuilding smoother.
Since Conductor supports both modes as well (prebuilt images with Image
Factory, post-launch with Audrey), there shouldn't be an impedance mismatch.
We will keep building images in Image Factory, we'll pass the image IDs
from Deployable XMLs to Heat that will in turn pass them to Deltacloud.
What's next?
------------
You can read the plan for the proof-of-concept and the long-term phases
and I would like your feedback. Please post correction on anything I've
missed or said wrong and anything else that comes in your mind. Do you
think integrating with Heat makes sense?
I want stress that this is not a done deal. I think that that Heat can
be very useful to Aeolus but it's quite possible that I've missed
something and we still need to see it in action before we commit to
anything.
There's a real possibility that this just is not a good match in which
case we'll go our separate ways (unless we decide to make it a good
match). Feel free to ask anything that's unclear.
Gimme teh links!
----------------
If you want to try Heat out, follow these steps:
https://github.com/heat-api/heat/blob/master/docs/GettingStarted.rst
Heat developers hang out at #heat on freenode and are all really nice chaps.
The repo for experimental integration of Deltacloud into Heat:
https://github.com/tomassedovic/heat/tree/multiple-backends
The Deltacloud client for Python lives in the official Deltacloud
repository:
https://git-wip-us.apache.org/repos/asf?p=deltacloud.git;a=tree;f=clients...
The client is very barebones at the moment. We'll be adding the
necessary features here:
https://github.com/tomassedovic/deltacloud/tree/python-client
and work on getting them accepted upstream.
The API Heat uses at the moment is based on AWS CloudFormation. You can
read the documentation here:
http://docs.amazonwebservices.com/AWSCloudFormation/latest/APIReference/W...
Here are some Deployable descriptions that Heat accepts and is able to
launch (in Heat and CloudFormation terminology, these are called
"templates", the deployment is called "stack")
https://github.com/heat-api/heat/tree/master/templates
What follows is the short-term and long-term plan on getting this done.
Take care,
Thomas
Proof of concept
----------------
### Getting Deltacloud to work with Python ###
The Deltacloud API is language-agnostic but we still need Python bindings.
Deltacloud ships with a Python client but it hasn't been touched for
over a year. I've sent a few patches to fix it but more work is required
for it to be usable.
### Passing the Provider credentials from Heat API to Deltacloud ###
Currently, the Heat API user can authenticate using either Keystone or
the EC2-style credentials.
We need a new authentication handler that will receive Deltacloud-style
credentials and pass them to the Deltacloud API.
Ian has written a patch that does this.
### Integrating Deltacloud client with Heat ###
Heat is currently using the Nova python client to launch instances, etc.
The calls are already reasonably isolated.
I've written a shim module that provides the same API as the Nova client
and we hooked it up to Ian's authentication code.
It's not connected to Deltacloud yet (that's the next step), but as far
as majority of Heat's codebase is concerned, everything works without
making a single call to OpenStack.
### Getting Aeolus Conductor to generate AWS::CFN Template ###
Conductor already has all the info it needs to launch the instances
stored in the Deployable XML.
We'll take the XML, parse it and generate the equivalent JSON template
that Heat accepts.
### Passing the generate template from Conductor to Heat ###
Once we have the converted deployable, Conductor will send it to Heat
via the current CloudFormation API.
Heat will launch the deployment/stack via its Deltacloud bindings.
### Querying Heat data from Conductor ###
Heat doesn't support any callbacks. When Conductor wants to know details
about the stack it launched, it will use the CloudFormation API to query
the data.
For the proof of concept stage, we will just issue the query to Heat
upon every relevant UI action: e.g. `ListStacks` when showing
deployables in the UI, `DescribeStackResource` when shoving a details of
a single deployable, `DescribeStackEvents` to get deployable events, etc.
Long-term
----------
### Dead Nova client dependencies ###
Parts of the Heat code import Nova and Glance clients but they don't use
the code. These should be removed.
### Nova client exceptions ###
Several libraries import the exception classes from Nova client.
If we could make the Deltacloud backend to raise the same exceptions
without depending on the `python-novaclient` library, that would be cool.
Barring that, we'll either have to wrap the backend exceptions or have
the Deltacloud code bite the bullet and depend on the novaclient lib
(the Heat package depends on it anyway so it may not be as bad).
### Make the backends swappable at the configuration level ###
Similarly to how Heat can change between the AMQP implementations for
Fedora and Ubuntu, we need a configuration option that replaces
OpenStack with Deltacloud.
### Make the Heat Deltacloud backend a separate package ###
Heat doesn't have to ship additional backends if they don't want to. The
configuration option from previous task would take a Python package
namespace.
That way it doesn't care if it's within the main codebase or a
third-party module.
### Template format ###
Aeolus uses a different format from Heat to describe deployables.
We need to settle on what's the best thing to use. Options:
1) Translate Aeolus Deployable XML to Amazon CloudFormation JSON
2) Implement Aeolus Deployable XML format in Heat
3) Adopt CloudFormation JSON in Conductor
4) Have both Aeouls and Heat adopt another (open standard) format
With all likelihood Heat will reject 2), we won't switch to 3) and since
*both* communities would have to accept and implement 4), we'll probably
stick to 1) for some time.
Still, listing it here as it needs to be decided.
### Heat-Conductor communication ###
Heat is working on implementing a proper RESTful API that will
1) be more consistent with other OpenStack components
2) suck less
Once that's done, Conductor should probably adopt this API.
We then need to figure out how to pass data from Heat back to Conductor.
If Conductor's launching instances via Heat, how does that information
get updated?
1) Conductor asks Heat every time it needs the data
2) Conductor asks Heat periodically and caches the results
3) Heat allows Conductor to register a callback -- either via HTTP
(webhooks) or via RPC -- and tells Conductor when stuff happens (e.g. an
instance was launched, crashed, etc.)
4) Conductor continues to use DBomatic to query the instances directly
via Deltacloud, ignoring any additional information Heat may provide
For the proof of concept, everything other than 1) is a premature
optimization and then we'll see.
I think 4) would be rather brittle especially since adopting Heat might
possibly let us drop DBomatic entirely.
### Is Heat going to be the only way to launch deployments in Conductor
or will it be an optional part? ###
We will need to see how stable and usable Heat is. How easy it is to
deploy and keep up (it would be another dependency, after all) and how
much benefit and code cleanup it brings to Aeolus.
### Missing parts in Deltacloud ###
Deltacloud provides only a subset of the information OpenStack clients
have access to. A lot of these are provider-specific.
We need to identify these cases and decide what to do with them:
1) Have Deltacloud provide the access for providers that support them
and advertise the support properly
2) Don't let Heat provide them for non-Openstack providers
3) Implement them in Heat for providers that support them and keep
Deltacloud as the lowest common denominator
This includes working with the Deltacloud people: we're going to let
them know what's missing and discuss the appropriate solution.
Since Deltacloud API is already focused towards discoverability (e.g.
when showing an instance, it lists the actions that can be done to the
instance) that may be the best approach if all parties agree.
10 years, 5 months
[image-management-engine] Model associations and controllers (#20)
by jguiditta
You can merge this Pull Request by running:
git pull https://github.com/mtaylor/image-management-engine model_associations_and_controllers
Or you can view, comment on it, or merge it online at:
https://github.com/aeolus-incubator/image-management-engine/pull/20
-- Commit Summary --
* Created Added User Attributes Filter
* Updated BaseImage/BaseImagesControler
* Updated ImageVersions/ImageVersionsController
* Updated TargetImage/TargetImagesController
* updated ProviderImage/ProviderImageController
* Removed ARec Base Patch specs
* Updated Template/TemplateController
-- File Changes --
M app/controllers/image_management/application_controller.rb (4)
M app/controllers/image_management/base_images_controller.rb (11)
M app/controllers/image_management/image_versions_controller.rb (27)
M app/controllers/image_management/provider_images_controller.rb (38)
M app/controllers/image_management/target_images_controller.rb (40)
M app/controllers/image_management/templates_controller.rb (27)
M app/models/image_management/base_image.rb (21)
M app/models/image_management/image_version.rb (10)
M app/models/image_management/provider_image.rb (17)
M app/models/image_management/target_image.rb (21)
M app/models/image_management/template.rb (13)
A lib/filters/image_management/user_keys_filter.rb (42)
M lib/image_management.rb (4)
M spec/controllers/base_images_controller_spec.rb (8)
M spec/controllers/image_versions_controller_spec.rb (6)
M spec/controllers/provider_images_controller_spec.rb (2)
M spec/factories/image_management/image_version.rb (6)
A spec/filters/user_keys_filter_spec.rb (40)
D spec/models/base_spec.rb (37)
M spec/models/template_spec.rb (8)
M spec/spec_helper.rb (1)
-- Patch Links --
https://github.com/aeolus-incubator/image-management-engine/pull/20.patch
https://github.com/aeolus-incubator/image-management-engine/pull/20.diff
---
Reply to this email directly or view it on GitHub:
https://github.com/aeolus-incubator/image-management-engine/pull/20
10 years, 5 months
The new dev scripts-- now with rbenv
by cwolferh
The latest iteration of the dev scripts now supports (in addition to
system ruby), the ability to download and install an arbitrary ruby
version via rbenv.
Also, it is now possible to set up two conductor development
environments side by side since the conductor port is scriptable.
For instance, to apply a pull request to one instance but not the other:
In one shell:
export FACTER_CONDUCTOR_PORT=3000
export WORKDIR=/tmp/test
export DEV_USERNAME=test
export RBENV_VERSION=1.9.3-p194
curl https://raw.github.com/cwolferh/aeolus-cfg/master/bootstrap.sh |
/bin/sh
In another shell (although a good idea to let the first one finish
installing 1.9.3-p194 in /home/test/.rbenv before running) :
export FACTER_CONDUCTOR_PORT=3001
export WORKDIR=/tmp/test2
export DEV_USERNAME=test
export RBENV_VERSION=1.9.3-p194
export FACTER_CONDUCTOR_PULL_REQUEST=71
curl https://raw.github.com/cwolferh/aeolus-cfg/master/bootstrap.sh |
/bin/sh
In this case, as expected there is one instance running on port 3000
without a pull request applied, and another instance running on port
3001 with pull request 71 applied. Both are using rbenv to set the
ruby version to 1.9.3-p194. They both use the system user, test, to
check out and build the projects along with RBENV_VERSION ruby. They
use separate work directories of /tmp/test and /tmp/test2. Finally,
the presence of FACTER_CONDUCTOR_PULL_REQUEST in the second case
indicates that we want to apply a pull request (it must be an active
pull request).
Additional Notes
* System ruby and puppet are still installed and used as the framework
for creating the conductor/aeolus-image-rubygem/aeolus-cli work
directories and associated setup (mainly git commands). However, if
RBENV_VERSION is specified, rbenv and the relevant local rbenv ruby
is used for the conducutor/aeolus-image-rubygem gem, bundler and run
tasks. In other words, don't panic if you see system ruby being
installed when you run bootstrap.sh but a RBENV_VERSION is set.
* No .bashrc or similar shell-effecting changes are made to
$DEV_USERNAME'S homedir (intentionally). If you su to $DEV_USERNAME
and you want to pick up the rbenv that was installed by boostrap.sh,
you can either prepend ~/.rbenv/bin:~/.rbenv/shims to your PATH or,
as per the rbenv installer instructions, add the following to
.bashrc, for example:
export RBENV_ROOT="${HOME}/.rbenv"
if [ -d "${RBENV_ROOT}" ]; then
export PATH="${RBENV_ROOT}/bin:${PATH}"
eval "$(rbenv init -)"
fi
*Currently, the scripts are located at
https://github.com/cwolferh/aeolus-cfg, but we do want to rebase this
under aeolus-incubator at some point (with a different project name).
10 years, 5 months
[PATCH] RM#3877 Implement deployment destroy and multidestroy actions in background
by Tomas Hrcka
---
src/app/controllers/deployments_controller.rb | 28 +++++++++++++++------------
src/app/models/deployment.rb | 5 -----
2 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/src/app/controllers/deployments_controller.rb b/src/app/controllers/deployments_controller.rb
index d8e24fa..0f53579 100644
--- a/src/app/controllers/deployments_controller.rb
+++ b/src/app/controllers/deployments_controller.rb
@@ -278,13 +278,16 @@ class DeploymentsController < ApplicationController
errors = []
begin
require_privilege(Privilege::MODIFY, deployment)
- deployment.stop_instances_and_destroy!
- rescue Aeolus::Conductor::Base::NotStoppableDeployment
- cant_stop = true
- errors = deployment.not_stoppable_or_destroyable_instances.map {|i|
- t('deployments.errors.instance_state',
- :name => i.name,
- :state => i.state)}
+ if deployment.not_stoppable_or_destroyable_instances.empty?
+ deployment.delay.stop_instances_and_destroy!
+ else
+ cant_stop = true
+ errors = deployment.not_stoppable_or_destroyable_instances.map {|i|
+ t('deployments.errors.instance_state',
+ :name => i.name,
+ :state => i.state)}
+
+ end
rescue
errors = t('deployments.flash.error.not_deleted',
:name => deployment.name,
@@ -322,15 +325,16 @@ class DeploymentsController < ApplicationController
ids = Array(params[:deployments_selected])
Deployment.find(ids).each do |deployment|
- begin
- require_privilege(Privilege::MODIFY, deployment)
- deployment.stop_instances_and_destroy!
+ require_privilege(Privilege::MODIFY, deployment)
+ if deployment.not_stoppable_or_destroyable_instances.empty?
+ deployment.delay.stop_instances_and_destroy!
destroyed << deployment.name
- rescue
+ else
errors << t('deployments.flash.error.not_deleted',
:name => deployment.name,
- :error => $!.message)
+ :error => t("deployments.errors.all_stopped"))
end
+
end
respond_to do |format|
format.html do
diff --git a/src/app/models/deployment.rb b/src/app/models/deployment.rb
index e612ab1..552bcda 100644
--- a/src/app/models/deployment.rb
+++ b/src/app/models/deployment.rb
@@ -176,11 +176,6 @@ class Deployment < ActiveRecord::Base
end
def stop_instances_and_destroy!
- unless not_stoppable_or_destroyable_instances.empty?
- raise Aeolus::Conductor::Base::NotStoppableDeployment,
- I18n.t("deployments.errors.all_stopped")
- end
-
if destroyable?
destroy
else
--
1.7.11.4
10 years, 5 months
Options for/Issues with BZ821341
by Jason Guiditta
This patch makes a simple fix that should match the output of the ui
in cli. The issue remaining here is that both messages are not i18n
strings. If that is acceptable, this patch can be used as is. If
not, we need to see if:
A) nokogiri is capable of generating an i18n string for the error (we
cannot reasonably put it in the dictionary, in my opinion, as the
string may change depending on what is wrong with the xml).
B) we can make the api and ui controller methods call TemplateXML in
the same way, and alter the called validation method to return a
generic i18n parse message, along with the actual noko message (this
part may not be reable for the user, depending on their language).
This message is currently silently swalloed in the TemplateXML
validate instance method, so that would need to be fixed as well.
Any i18n requirement here has the additonal (possible) issue of
displaying i18n in the cli output. I do not know the code well enough
to know if we pass in the user's system language setting, so conductor
knows what language to return. If we do not already do this, I do not
know how much work it would be to add.
Lastly, if we push the validation back into conductor (where it should
be, imo), there is one other place we woudl need to fix the same way
(import_command, I think it was).
-j
10 years, 5 months
Aeolus Community-Building Meeting #2 Notes
by Matt Wagner
Hi folks,
Yesterday we had our second ever Hangout to discuss building and growing
the Aeolus community, and how to better share news about our project. A
number of people attended; thanks!
I wrote a blog post[1] so that this will appear on the Aeolus Project
blog[2], but I'm going to duplicate the meeting recap section below so
we can discuss it more extensively here.
The video from the call is here (39 minutes):
https://www.youtube.com/watch?v=2LC58nFzYAc&feature=g-upl
Here's a summary of what was discussed, though:
* Mo Morsi gave a preview of his upcoming talks on Aeolus. He put the
slides on the Aeolus Presentations wiki page[3].
* We should have a release calendar on our site, and also make sure to
make noise (on our blog, and on Twitter/Facebook/etc.) about our
releases.
* It would be valuable to look at integrating with CloudStack and
documenting how to use it. Google Compute / Google Cloud Platform, too!
* Our templates site is a really good idea that needs to be finished
up and launched. The template repo[4] Justin set up is a good interim
solution.
* It would be interesting to look at integrating with other sources of
templates, like Bitnami or CloudFormation.
* In general, we really need to support more providers, and finally
arrive at a complete API.
* Justin has been working on getting OpenShift Origin running on
Aeolus. This would be an excellent blog post, and maybe a good marketing
angle.
* Sponsoring "drinkups" seems to work well for attracting interest,
though it's not clear if there's actually a good return on it.
* Someone suggested cotton candy at booths. I love that idea. Cotton
candy kind of looks like a cloud, too!
* Stickers and flyers are a must. We need to get a ton ordered.
* We should do more with social media. We have a Facebook page[5] and a
Google Plus page[6], and we're @aeolusproject on Twitter, and we have a
blog[7]. But we don't make extensive use of them. What we really need are
others to blog about us, retweet us, and share our stuff on Facebook.
* We need to get people to take these tasks and commit to making them
happen, and we should be in good shape for the next meeting!
That's all I took for notes. Please feel to chip in with things I
missed, or follow up with new ideas and ideas.
Best regards,
Matt Wagner
[1] http://ma.ttwagner.com/aeolus-community-building-meetup-2/
[2] http://blog.aeolusproject.org/
[3]
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Presentations
[4] https://github.com/aeolus-incubator/templates
[5] https://www.facebook.com/AeolusProject
[6] https://plus.google.com/109718770418645820147/posts
[7] http://blog.aeolusproject.org/
10 years, 5 months
[PATCH conductor] BZ 815783 - fixed checking of launch time params (rev. 1)
by Jan Provazník
From: Jan Provaznik <jprovazn(a)redhat.com>
If there are multiple tabs (=multiple assemblies) on launch time params page,
then checking of empty params doesn't work properly - only params on last tab
are checked.
This patch also fixes CSS for disabled buttons (after consultation with
UI guys).
https://bugzilla.redhat.com/show_bug.cgi?id=815783
---
src/app/stylesheets/_buttons.scss | 8 ++++----
src/app/views/deployments/launch_time_params.html.haml | 4 +++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/app/stylesheets/_buttons.scss b/src/app/stylesheets/_buttons.scss
index 3f6703b..91055b2 100644
--- a/src/app/stylesheets/_buttons.scss
+++ b/src/app/stylesheets/_buttons.scss
@@ -42,9 +42,9 @@ Application Button Set
*display: inline;
}
-.button:hover,
-.button:focus,
-.button:active,
+.button:not(.disable):hover,
+.button:not(.disable):focus,
+.button:not(.disable):active,
.button.active {
border-color: #3072b3;
border-bottom-color: #2a65a0;
@@ -58,7 +58,7 @@ Application Button Set
background-image: linear-gradient(#599bdc, #3072b3);
}
-.button:active,
+.button:not(.disable):active,
.button.active {
border-color: #2a65a0;
border-bottom-color: #3884cd;
diff --git a/src/app/views/deployments/launch_time_params.html.haml b/src/app/views/deployments/launch_time_params.html.haml
index 78cbd69..57e3661 100644
--- a/src/app/views/deployments/launch_time_params.html.haml
+++ b/src/app/views/deployments/launch_time_params.html.haml
@@ -47,15 +47,17 @@
:javascript
function checkEnteredParams() {
+ var allFilled = true;
$('.launch-time-params .parameters').each(function() {
var $parameters = $(this).find('.parameter input');
var filledOut = _.all($parameters, function(item) {
return ! _.isEmpty($(item).val());
});
var param_id = $(this).attr('id');
+ if (!filledOut) allFilled = false;
$('.labels').find('#' + param_id).toggleClass('filled-out', filledOut);
- $('#submit_params').attr('disabled', !filledOut);
});
+ $('#submit_params').toggleClass('disable', !allFilled).attr('disabled', !allFilled);
};
(function () {
--
1.7.11.4
10 years, 5 months
Musing: Things we need (code-wise)
by Matt Wagner
I was just going to clean a whiteboard, and got to a list I named
"Things We Need." It started off as a couple of vague thoughts, and over
time I've been adding things that I've heard people ask about only to be
told that they didn't exist or didn't work.
Many of these are pretty open-ended, but I thought the list might lead
to some valuable discussion, so here it is:
* A good glossary of terms, with examples / use cases. Beyond the fact
that I struggle with some of the terms myself sometimes, it would be
fantastic to be able to have something to point people to when they ask
what realms are or why you would use Environments.
* API Documentation. (There is next to none today. I believe Katello is
using apipie for this.)
* A real API, that presents all the functionality that exists in our UI.
* Non-ugly Redmine. This is probably more of a pet peeve than something
that has much actual community value. But when I compare our wiki to
something like GitHub wikis, they just look so crisp, organized, and
easy to read. Also, a Markdown plugin since no I'm pretty sure no one
in the world uses Textile except for whoever created Redmine.
* The ability to use multiple datacenters with one RHEV or vSphere
provider, or good documentation explaining how to handle this
(probably common) use case.
* Debian/Ubuntu guest support. (Bonus for being able to package and run
Aeolus for Debian/Ubuntu.)
* Support for OpenStack and Rackspace. (This may work now, at least to
some degree, but it needs testing and us to actually say that it
works.)
-- Matt
10 years, 5 months
[PATCH conductor] BZ 815783 - fixed checking of launch time params
by Jan Provazník
From: Jan Provaznik <jprovazn(a)redhat.com>
If there are multiple tabs (=multiple assemblies) on launch time params page,
then checking of empty params doesn't work properly - only params on last tab
are checked.
This patch also fixes CSS for disabled buttons (after consultation with
UI guys).
https://bugzilla.redhat.com/show_bug.cgi?id=815783
---
src/app/stylesheets/_buttons.scss | 8 ++++----
src/app/views/deployments/launch_time_params.html.haml | 9 +++++----
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/src/app/stylesheets/_buttons.scss b/src/app/stylesheets/_buttons.scss
index 3f6703b..91055b2 100644
--- a/src/app/stylesheets/_buttons.scss
+++ b/src/app/stylesheets/_buttons.scss
@@ -42,9 +42,9 @@ Application Button Set
*display: inline;
}
-.button:hover,
-.button:focus,
-.button:active,
+.button:not(.disable):hover,
+.button:not(.disable):focus,
+.button:not(.disable):active,
.button.active {
border-color: #3072b3;
border-bottom-color: #2a65a0;
@@ -58,7 +58,7 @@ Application Button Set
background-image: linear-gradient(#599bdc, #3072b3);
}
-.button:active,
+.button:not(.disable):active,
.button.active {
border-color: #2a65a0;
border-bottom-color: #3884cd;
diff --git a/src/app/views/deployments/launch_time_params.html.haml b/src/app/views/deployments/launch_time_params.html.haml
index 78cbd69..7d7c80f 100644
--- a/src/app/views/deployments/launch_time_params.html.haml
+++ b/src/app/views/deployments/launch_time_params.html.haml
@@ -47,15 +47,16 @@
:javascript
function checkEnteredParams() {
- $('.launch-time-params .parameters').each(function() {
- var $parameters = $(this).find('.parameter input');
+ var allFilled = _.all($('.launch-time-params .parameters'), function(tab) {
+ var $parameters = $(tab).find('.parameter input');
var filledOut = _.all($parameters, function(item) {
return ! _.isEmpty($(item).val());
});
- var param_id = $(this).attr('id');
+ var param_id = $(tab).attr('id');
$('.labels').find('#' + param_id).toggleClass('filled-out', filledOut);
- $('#submit_params').attr('disabled', !filledOut);
+ return filledOut;
});
+ $('#submit_params').toggleClass('disable', !allFilled).attr('disabled', !allFilled);
};
(function () {
--
1.7.11.4
10 years, 5 months