Deployables, templates, images and you
by Mark McLoughlin
Hey,
Hugh and I have spent the week trying to work through everyone's
understanding of deployables, assemblies, services, templates, images,
etc. in order to resolve the confusion that has been evident lately.
I think the most important realization we've come to is that if the
deployable and template problem spaces are very clearly separated, a lot
of the confusion melts away.
We've also realized that trying to design UIs for designing deployables
and templates isn't going to give an ideal user experience in the near
term. These tasks are so complex, we are much better starting with CLI
tools in the short term.
Finally, we realized that a UI for managing builds of templates,
noticing updates to source contents of image, etc. is much more suited
to systems management tools like Katello.
The plan we've written up below is the result of those discussions, but
has been written up hastily so that everyone can dig into the details.
This shouldn't be read as some dictat, as it is completely up for
discussion. If anything described below seems arbitrarily different from
what we currently have, please do shout and we can either discuss the
motivation or update the plan to reflect what we currently have.
Finally, FWIW, I'm pretty excited that this will get us out of some of
the ratholes we've been in lately.
Cheers,
Mark.
Changes From Before
===================
- There are two XML document formats - deployables and templates - and
they are quite independent
- Deployables (or rather, assemblies) contain image references rather
than template references
- An image reference maps to multiple versions of the image, where
each version has multiple provider images
- Images can be built from a template, or imported from elsewhere
- Services are at the deployable level, not the template level
- Templates expose parameters, but they're not described as services
- Use of ruby string interpolation as a more flexible and expressive way
to manipulate parameters
Parameters and Returns
======================
At each level of the model, the concept of parameters and returns are
used.
A parameter is an input and a return is an output. Parameters are
typed, returns are strings. Both have names and human consumable
descriptions.
When declaring a parameter that is made available by a level of the
model to the level above it, you do e.g.
<param type="string">
<name>admin_user</name>
<description>Administrator's username</description>
<value>admin</value>
</param>
A default value may be supplied, essentially making the parameter
optional.
When supplying a parameter from a level of the model to the level
below it you do e.g.
<param>
<name>admin_user</name>
<value>admin</value>
</param>
i.e. the type attribute and description element is irrelevant.
When declaring a return that is supplied from a level of the model to
the level above it, you do e.g.
<return>
<name>http_port</name>
<description>HTTP port number</description>
<value>80</value>
</return>
A <value> element of a parameter or return may use Ruby's string
interpolation to reference other parameter or return values e.g.
<return>
<description>URL of the Redmine project management system</description>
<value>http://#{frontend.ip_address}:#{frontend.http_port}/</value>
</return>
or:
<params>
<param>
<name>url</name>
<value>http://#{hostname}:#{http_port + 100}/redmine/</value>
</param>
</params>
Services
========
Services encapsulate a configuration script or recipe for a configuration
management tool.
So, for example, a script referenced by a URI:
<service>
<script href="...."/>
<params/>
<returns/>
<script>
</service>
or a script embedded in the document:
<service>
<script>
<contents><![CDATA[
#!/bin/bash
...
]]</contents>
<params/>
<returns/>
</script>
<service>
Parameters are passed to the script on stdin using a <params/> element
and the script writes a <returns/> element to stdout.
Puppet manifests and chef recipes are handled similarly using <puppet/>
and <chef/> elements with appropriate ways for params and returns to be
exchanged.
Images
======
The term "image" refers to an abstract concept here, as opposed to a binary
disk image.
An image is created by importing as a disk image from elsewhere or by building
a template.
An image has multiple versions. Each version has a set of provider images and
(optionally) a provider agnostic disk image.
The concept exists to allow deployables to refer to disk images without
referencing a template, a specific template build or provider image.
Assemblies
==========
Assemblies encapsulate an image reference and a set of services.
An image is referenced by ID. e.g.
<assembly>
<name>frontend</name>
<image id="11abf870-894c-4336-bc9f-37904c394924">
...
</image>
</assemly>
Optionally, the image reference can include a version id:
<assembly>
<name>frontend</name>
<image id="11abf870-894c-4336-bc9f-37904c394924" version="be2a8e6">
...
</image>
</assemly>
This ID and optional version can be resolved by conductor, via metadata
and tags IWHD, to the set of provider image builds associated with the
image.
The image reference also describes the parameters to pass to instance
when it is started:
<assembly>
<name>frontend</name>
<image id="11abf870-894c-4336-bc9f-37904c394924">
...
<params>
<param>
<name>http_port</name>
<value>#{http_port}</value>
</param>
...
</params>
</image>
<assembly>
When an instance is launched, it can return information and these are
also described in the image reference:
<assembly>
<name>frontend</name>
<image id="11abf870-894c-4336-bc9f-37904c394924">
...
<returns>
<return>
<name>http_port</name>
</return>
</returns>
</image>
<assembly>
Like all other objects, assemblies have returns. However, they also
implicitly have some returns which do not need to be explicitly
defined, like ip_address.
Finally, Assemblies include a list of services:
<assembly>
...
<services>
<service/>
<service/>
...
</services>
</assemblies>
== Deployables ==
A deployable encapsulates all the information required to launch a set
of cooperating instances. It contains:
- Its name and description:
<deployable>
<name>Redmine</name>
<description>Redmine is a web-based project management application</description>
...
</deployable>
- Some parameters that the user launching the deployable may
specify:
<deployable>
...
<params>
<param type="string">
<name>admin_user</name>
<description>Administrator's username</description>
<value>admin</value>
</param>
<param type="string">
<name>admin_passwd</name>
<description>Administrator's password</description>
<secret>true</secret>
</param>
<param type="int">
<name>http_port</name>
<description>HTTP port number</description>
<value>80</value>
</param>
<param type="string">
<name>timezone</name>
<description>Timezone in which to run the application>
<values>
<value>America/New_York</value>
<value>Europe/Paris</value>
</value>
</param>
...
</deployable>
When a user launches a deployable, a form is displayed allowing
the user to enter values for the parameters. The form is
pre-populated with default values. Where multiple default values
are specified, a drop-down box is used to allow the user choose
one of the values.
- Assemblies, which may be included inline in the deployable:
<deployable>
...
<assemblies>
<assembly>
<name>frontend</name>
<image id="11abf870-894c-4336-bc9f-37904c394924">
<params>
<param>
<name>redmine_admin</name>
<value>#{admin_user}</value>
</param>
<param>
<name>redmine_passwd</name>
<value>#{admin_passwd}</value>
</param>
</params>
</image>
<assembly>
</assemblies>
...
</deployable>
Notice that because this assembly is inline, it can directly
reference the deployables parameter values.
Assemblies can also be included by reference:
<deployable>
...
<assemblies>
<assembly href="http://myserver/redmine/frontend.assy">
<params>
<param>
<name>admin_user</name>
<value>#{admin_user}</value>
</param>
<param>
<name>admin_passwd</name>
<value>#{admin_passwd}</value>
</param>
</params>
</assembly>
</assemblies>
</deployable>
Here, because the assembly is included by reference, the
deployable must explicitly pass the parameters required by the
assembly. In this example, it has two parameters and we pass the
values of the equivalent deployable parameters straight
through.
It is common to use the return values of an assembly as the
paramaters to another assembly e.g.
<assembly href="http://myserver/redmine/caching-proxy.assy">
<param>
<name>base_url</name>
<value>http://#{frontend.ip_address}:#{frontend.http_port}/</value>
</param>
</assembly>
- Return values which may be displayed to the user e.g.
<deployable>
...
<returns>
<return>
<description>URL of the Redmine project management system</description>
<value>http://#{frontend.ip_address}:#{frontend.http_port}/</value>
</return>
</returns>
</deployable>
In summary, a deployable has a description, a set of typed parameters
with defaults, a set of (inline or included by reference) assemblies
and their parameter values and a set of user consumable return
values.
In conductor, a user launches a deployable simply by supplying a URI
to the deployable definition, or by selecting from a list of
deployable URIs supplied by the administrator.
Templates
=========
Templates are an XML document which describe how to build an image and
what the parameters and returns of the image will be. For example:
<template>
<name>win2kjeos</name>
<os>
<name>Windows</name>
<version>2008</version>
<arch>x86_64</arch>
<install type='iso'>
<iso>http://directory_path/windows2008x64.iso</iso>
</install>
<key></key>
</os>
<description>Windows 2008</description>
<repos>
<repo url="smb://domain\user:UserName@IP\share" name="Default"/>
<repo url="smb://domain\user:UserName@IP\another_share" name="Alternative"/>
</repos>
<packages>
<package>
<repo name="Default"/>
<name>Dot Net 4.0</name>
<file>dotNetFx40_Full_x86_x64.exe</file>
<arguments>/passive</arguments>
</package>
<package>
<repo name="Alternative"/>
<name>Winrar</name>
<file>winrarx64393.exe</file>
<arguments>/s</arguments>
</package>
</packages>
</template>
(Yes, that's copied and pasted from imgfac(1) man page :-)
Image Warehouse Metadata
========================
Image warehouse will contain enough metadata for conductor to resolve
an image reference to a set of provider images.
One possible way of storing that metadata would be as follows:
- An image descriptor XML document describing the image is stored as
an object. The UUID of the object is the image ID.
- Each provider agnostic disk image is also an object and represents
a build of a template. So an image version/build is identified by
this object's UUID. The other attributes of this object include the
image UUID and UUID of its parent version, if any.
- Each provider image has the disk image UUID as an attribute.
A special case we need to think about is where an image is imported
from e.g. EC2. In that case, the provider agnostic disk image doesn't
exist, so perhaps we'd create an empty object with the metadata we
need.
In order to find all the provider images associated with an image, you
find all the disk images referencing the image UUID and find all the
provider images referencing all the disk image UUIDs.
In order for conductor to resolve a versionless image reference to a
specific version, we include a "latest version" attribute on the image
object. We may choose to expand that to e.g. "latest dev version",
"latest production version" attributes so that the version resolution
can be influenced by the environment.
The image descriptor XML is used by conductor for the "Launch Instance"
UI. But, more importantly, it is used by deployable authors when
choosing image references to include in their deployables. The image
descriptor contains a human consumable description, information like
OS type and the parameters and returns of the image.
Image Building CLI
==================
We need a CLI to build templates and push images using image factory.
We also need this CLI to manipulate the image metadata in IWHD - e.g.
when a new build of a template is created, it should be able to set
or update the attributes on provider images, disk images and the image
itself.
This CLI also needs to be able to import images into IWHD.
UI Implications
===============
The conductor UI will not include any UI for creating deployables
or templates. Nor will it have a UI for managing template builds or
importing images.
The UI will have a "Launch Deployable" UI which accepts a URI to a
deployable descriptor. This UI will parse the deployable and display
a form where the user can supply parameters for the launch. The UI
should also maintain a history of deployable URIs for each user so
that they can easily be re-used.
The UI will also have the ability for an admin to import populate
a list of deployable URIs which the user can choose from instead of
specifying a URI.
The UI will also have a simple "Launch Instance" UI where the user
can directly launch an image without creating a deployable. A
simple wrapper deployable will be created behind the scenes for the
user.
Finally, the UI will have the ability to visualize a deployable before
and after it launched. It will show the instances in the deployable,
the images used and the interconnections between the instances.
Deployable and Template Author Tools
====================================
Deployables and templates are complex beasts. We will not initially
have a UI for creating either, but we still need a rich experience
for deployable and template authors.
Firstly, we need detailed example based documentation on the format
of the descriptors.
Secondly we need CLI tools to help authors initially create these
descriptors and do things like adding assemblies/services to the
deployable.
This could be a rails-like tool to generate XML chunks which the
user can start from. One option is that we use a filesystem tree
to represent the deployable e.g.
mydeployable/
mydeployable.xml
Rakefile
assemblies/
redmine/
redmine.assy
services/
foo/
foo.svc
foo.sh
db/
db.assy
services/
bar/
bar.svc
bar.sh
and then a "rake deployable:compose" to generate the full deployable
document.
As an added bonus, the CLI would initialize a local git repo containing
this directory structure when creating the initial skeleton.
Example Deployables
===================
We need a small set of fully fledged example deployables both for the
sake of users to try out conductor and for deployable authors to get
an understanding of the format.
The three examples we should create are:
1) A redmine deployable with the web frontend in one instance and
the DB here
2)
3) Nominate your favourite examples here!
Open Questions
==============
- Permissions/authorization - we need to restrict which images are
available to which users. How that is done is completely open at
this point.
- Environments - the notion of how the environment influences image
reference resolution needs further thought.
References
==========
http://www.aeolusproject.org/page/Audrey_Specification
http://www.aeolusproject.org/page/Audrey_Overview
http://www.aeolusproject.org/page/Audrey_SDK
http://www.aeolusproject.org/page/ImageObjectModel
http://www.aeolusproject.org/page/PermissionStorage
https://fedorahosted.org/pipermail/aeolus-devel/2011-May/001425.html (Implementing Services)
https://fedorahosted.org/pipermail/aeolus-devel/2011-May/001451.html (Sample AR model for implementing services)
http://cloudformation-templates-us-east-1.s3-website-us-east-1.amazonaws.... (sample amazon cloud formations templates)
http://aws.amazon.com/documentation/cloudformation/ (amazon cloud formations documentation)
12 years, 11 months
newui branch merged into next
by Jan Provazník
Hi, I merged newui branch into next so when you are working on new UI,
work with next branch again. New UI is far from being done, and is
active only for pools controller (so don't be scared if you see unstyled
data in 'resource management -> pools').
Jan
12 years, 11 months
[PATCH 1/2] RHEV-M init script in aeolus puppet recipe
by Francesco Vollero
From: Francesco Vollero <fvollero(a)redhat.com>
---
recipes/aeolus_recipe/aeolus_recipe.pp | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/recipes/aeolus_recipe/aeolus_recipe.pp b/recipes/aeolus_recipe/aeolus_recipe.pp
index 8574584..6ae1827 100644
--- a/recipes/aeolus_recipe/aeolus_recipe.pp
+++ b/recipes/aeolus_recipe/aeolus_recipe.pp
@@ -56,6 +56,11 @@ aeolus::provider{"ec2-us-west-1":
port => 3004,
require => Aeolus::Site_admin["admin"] }
+aeolus::provider{"rhevm":
+ type => "rhevm",
+ port => 3005,
+ require => Aeolus::Site_admin["admin"] }
+
aeolus::conductor::hwp{"hwp1":
memory => "1",
cpu => "1",
--
1.7.4.4
12 years, 11 months
Test message
by Chris Lalancette
This is a test message, please ignore.
--
Chris Lalancette
12 years, 11 months
Change to the mailing list setup
by Chris Lalancette
All,
I just went in and made a minor change to how the mailing list was setup.
Previously, the list would attempt to suppress duplicate messages; that is,
if you were subscribed to the list and a message was mailed to the list and
CC'ed to you, you would only get a single copy of the message.
I've now changed it so that if a message is sent both to you and the list,
you will get both copies of it. I've also made that the default behavior for
new subscribers. If this really doesn't jive with your email setup, you have
2 options:
1) Filter the duplicate messages locally
2) Log into the aeolus-devel mailing list web interface
(https://fedorahosted.org/mailman/listinfo/aeolus-devel) and set "nodupes"
back on for your particular account
Let me know if you have any questions.
--
Chris Lalancette
12 years, 11 months
[PATCH conductor] Fixed cucumber tests to work with new UI
by Jan Provazník
From: Jan Provaznik <jprovazn(a)redhat.com>
---
src/app/controllers/deployments_controller.rb | 2 +-
src/app/views/deployments/_list.haml | 5 ++-
src/app/views/layouts/application.haml | 1 +
src/app/views/pools/_list.haml | 1 +
src/app/views/pools/_scoreboard_index.haml | 4 +-
src/features/breadcrumbs.feature | 6 +---
src/features/deployment.feature | 19 +++++++++--------
src/features/instance.feature | 5 ++-
src/features/pool.feature | 23 +++++++++++----------
src/features/step_definitions/deployment_steps.rb | 2 +-
10 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/src/app/controllers/deployments_controller.rb b/src/app/controllers/deployments_controller.rb
index 5a036e3..53ec037 100644
--- a/src/app/controllers/deployments_controller.rb
+++ b/src/app/controllers/deployments_controller.rb
@@ -173,7 +173,7 @@ class DeploymentsController < ApplicationController
load_deployments
render :partial => 'list'
end
- format.html { redirect_to deployments_path }
+ format.html { redirect_to pools_path(:details_tab => 'deployments', :filter_view => filter_view?) }
format.json { render :json => {:success => notices, :errors => errors} }
end
end
diff --git a/src/app/views/deployments/_list.haml b/src/app/views/deployments/_list.haml
index fe65891..7916f3b 100644
--- a/src/app/views/deployments/_list.haml
+++ b/src/app/views/deployments/_list.haml
@@ -2,7 +2,8 @@
= render :partial => '/layouts/notification'
- form_tag do
- = link_to "New Deployment", new_deployment_path, { :class => 'button' }
+ = link_to "New Deployment", launch_new_deployments_path, { :class => 'button' }
+ = restful_submit_tag "Stop", "multi_stop", multi_stop_deployments_path, 'POST', :id => 'stop_button'
= label_tag "More actions"
= select_tag("more_actions",nil, :disabled => true)
@@ -49,4 +50,4 @@
%td
= deployment.pool.pool_family.name
%td
- = deployment.owner
+ = owner_name(deployment)
diff --git a/src/app/views/layouts/application.haml b/src/app/views/layouts/application.haml
index f0f2c5c..7f0fa43 100644
--- a/src/app/views/layouts/application.haml
+++ b/src/app/views/layouts/application.haml
@@ -34,6 +34,7 @@
#content
-# works with any 960 container (.container_16 or .container_24)
= render :partial => 'layouts/nav_history'
+ = render :partial => '/layouts/notification'
= yield
%footer.standard
diff --git a/src/app/views/pools/_list.haml b/src/app/views/pools/_list.haml
index 3c7e1b8..6949fae 100644
--- a/src/app/views/pools/_list.haml
+++ b/src/app/views/pools/_list.haml
@@ -1,5 +1,6 @@
- form_tag do
= link_to "New Pool", new_pool_path, { :class => 'button' }
+ = restful_submit_tag "Destroy", "destroy", multi_destroy_pools_path, 'DELETE', :id => 'delete_button'
= label_tag "More actions"
= select_tag("more_actions",nil, :disabled => true)
%p
diff --git a/src/app/views/pools/_scoreboard_index.haml b/src/app/views/pools/_scoreboard_index.haml
index 45e885c..22aceb6 100644
--- a/src/app/views/pools/_scoreboard_index.haml
+++ b/src/app/views/pools/_scoreboard_index.haml
@@ -3,7 +3,7 @@
%ul.groups
%li
%dt= t("pools.index.pools")
- %dd.count.pool= @pools.count
+ %dd.count.pool= @user_pools.count
%dd.count.pool.partial= @statistics[:pools_in_use]
%li
%dt= t("deployments.deployments")
@@ -27,4 +27,4 @@
%dd.fraction.instance
%span.part 21
%span.divider.label.small.caps of
- %span.total 25
\ No newline at end of file
+ %span.total 25
diff --git a/src/features/breadcrumbs.feature b/src/features/breadcrumbs.feature
index 3fcccf4..abad08a 100644
--- a/src/features/breadcrumbs.feature
+++ b/src/features/breadcrumbs.feature
@@ -18,9 +18,7 @@ Feature: Breadcrumbs
Then I should be on the pools page
Scenario: Dont create breadcrumb when reloading or pointing to the same route
- Given a pool "testpool" exists
- And I am on the deployments page
+ Given I am on the deployments page
When I go to the pools page
- And I follow "testpool"
- When I follow "testpool"
+ And I go to the pools page
Then I should see "Deployments"
diff --git a/src/features/deployment.feature b/src/features/deployment.feature
index 67f6a62..515f3f1 100644
--- a/src/features/deployment.feature
+++ b/src/features/deployment.feature
@@ -8,18 +8,19 @@ Feature: Manage Deployments
And I am logged in
Scenario: List deployments
- Given I am on the homepage
- And there is a deployment named "MySQL Cluster" belonging to "Databases" owned by "bob"
- When I go to the deployments page
+ Given there is a deployment named "MySQL Cluster" belonging to "Databases" owned by "bob"
+ And I am on the pools page
+ When I follow "Filter View"
+ And I follow "Deployments"
Then I should see "MySQL Cluster"
And I should see "bob"
Scenario: List deployments over XHR
- Given I am on the homepage
- And there is a deployment named "MySQL Cluster" belonging to "Databases" owned by "bob"
+ Given there is a deployment named "MySQL Cluster" belonging to "Databases" owned by "bob"
+ And I am on the pools page
And I request XHR
- When I go to the deployments page
- Then I should get back a partial
+ When I follow "Filter View"
+ And I follow "Deployments"
Then I should see "MySQL Cluster"
And I should see "bob"
@@ -30,7 +31,7 @@ Feature: Manage Deployments
And there is an assembly named "testassembly" belonging to "testdeployable"
And there is an assembly named "testassembly" belonging to "testtemplate" template
When I go to the deployments page
- And I press "Launch new"
+ And I follow "New Deployment"
Then I should see "Launch new deployment via"
When I select "testdeployable" from "deployable_id"
When I press "Launch"
@@ -44,7 +45,7 @@ Feature: Manage Deployments
And there is an assembly named "testassembly" belonging to "testtemplate" template
And I request XHR
When I go to the deployments page
- And I press "Launch new"
+ And I follow "New Deployment"
Then I should see "Launch new deployment via"
And I should get back a partial
When I select "testdeployable" from "deployable_id"
diff --git a/src/features/instance.feature b/src/features/instance.feature
index 92139ea..155ed21 100644
--- a/src/features/instance.feature
+++ b/src/features/instance.feature
@@ -39,8 +39,9 @@ Feature: Manage Instances
And I am on the home page
When I follow "Resource Management"
Then I should be on the pools page
- When I follow "Instances"
- Then I should be on the instances page
+ When I follow "Filter View"
+ And I follow "Instances"
+ Then I should be on the pools page
And I should see "mock1"
Scenario: I want to view all instances over XHR
diff --git a/src/features/pool.feature b/src/features/pool.feature
index 1482843..5828842 100644
--- a/src/features/pool.feature
+++ b/src/features/pool.feature
@@ -18,10 +18,7 @@ Feature: Manage Pools
And I fill in "quota_instances" with "unlimited"
And I press "Save"
Then I should be on the pool page
- And I should see "Pool added"
- And I should see "mockpool"
- And I should see "default"
- And I should see "unlimited"
+ And I should see "mockpool Pool"
And I should have a pool named "mockpool"
Scenario: Create a new Pool over XHR
@@ -58,6 +55,7 @@ Feature: Manage Pools
And a pool "Amazon Startrek Pool" exists
And a pool "Redhat Voyager Pool" exists
When I go to the pools page
+ And I follow "Filter View"
Then there should be 3 pools
When I check "Redhat Voyager Pool" pool
And I check "Amazon Startrek Pool" pool
@@ -72,7 +70,8 @@ Feature: Manage Pools
Given I am on the pools page
And there is not a pool named "mockpool"
And there is not a pool named "foopool"
- When I follow "New Pool"
+ When I follow "Filter View"
+ And I follow "New Pool"
Then I should be on the new pool page
And I should see "Create a new Pool"
When I fill in "pool_name" with "mockpool"
@@ -82,7 +81,9 @@ Feature: Manage Pools
And I should see "Pool added"
And I should see "mockpool"
And I should have a pool named "mockpool"
- When I follow "New Pool"
+ When I go to the pools page
+ And I follow "Filter View"
+ And I follow "New Pool"
Then I should be on the new pool page
And I should see "Create a new Pool"
When I fill in "pool_name" with "foopool"
@@ -90,22 +91,22 @@ Feature: Manage Pools
And I press "Save"
Then I should be on the pool page
And I should see "Pool added"
- And I should see "mockpool"
- And I should see "foopool"
And I should have a pool named "mockpool"
And I should have a pool named "foopool"
Scenario: Cannot delete default_pool
Given I am on the pools page
- When I check "default_pool" pool
+ When I follow "Filter View"
+ And I check "default_pool" pool
And I press "Destroy"
Then I should see "The default pool cannot be deleted"
And I should see "default_pool"
Scenario: Cannot delete default_pool by renaming it
Given I renamed default_pool to pool_default
- Given I am on the pools page
- When I check "pool_default" pool
+ And I am on the pools page
+ When I follow "Filter View"
+ And I check "pool_default" pool
And I press "Destroy"
Then I should see "The default pool cannot be deleted"
And I should see "pool_default"
diff --git a/src/features/step_definitions/deployment_steps.rb b/src/features/step_definitions/deployment_steps.rb
index eeb90c5..874b612 100644
--- a/src/features/step_definitions/deployment_steps.rb
+++ b/src/features/step_definitions/deployment_steps.rb
@@ -1,5 +1,5 @@
Given /^there is a deployment named "([^"]*)" belonging to "([^"]*)" owned by "([^"]*)"$/ do |deployment_name, deployable_name, owner_name|
- user = Factory(:user, :login => owner_name)
+ user = Factory(:user, :login => owner_name, :last_name => owner_name)
deployable = Deployable.create!(:name => deployable_name, :owner => user)
@deployment = Deployment.create!({:name => deployment_name, :pool => Pool.first, :owner => user, :deployable_id => deployable.id})
end
--
1.7.4
12 years, 11 months
[PATCH aeolus] remove pulp from aeolus-all dep
by Martyn Taylor
From: Martyn Taylor <mtaylor(a)redhat.com>
---
aeolus-all.spec.in | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/aeolus-all.spec.in b/aeolus-all.spec.in
index 5051813..7acf01a 100644
--- a/aeolus-all.spec.in
+++ b/aeolus-all.spec.in
@@ -18,7 +18,6 @@ Requires: qpid-cpp-server
Requires: rubygem(image_factory_connector)
Requires: mongodb-server
Requires: mod_ssl
-Requires: pulp
Requires: deltacloud-core
# FIXME: this Requires doesn't actually belong here, it belongs in
# deltacloud-core. We leave it in until deltacloud-core is fixed
--
1.7.4
12 years, 11 months