[PATCH] Fix 'vant' typo to 'want'
by Matt Wagner
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=718712
---
src/app/views/deployments/_header_show.haml | 2 +-
src/app/views/pools/_header_show.haml | 2 +-
src/app/views/providers/show.haml | 2 +-
src/app/views/users/show.haml | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/app/views/deployments/_header_show.haml b/src/app/views/deployments/_header_show.haml
index 511917c..3ee971b 100644
--- a/src/app/views/deployments/_header_show.haml
+++ b/src/app/views/deployments/_header_show.haml
@@ -5,5 +5,5 @@
.button-group
= pretty_filter_toggle(deployment_path(@deployment, :view => 'pretty'), deployment_path(@deployment, :view => 'filter'))
.button-group
- = button_to 'Delete', deployment_path(@deployment), :method => :delete, :confirm => "Are you sure you vant to delete this deployment?", :class => "button pill danger"
+ = button_to 'Delete', deployment_path(@deployment), :method => :delete, :confirm => "Are you sure you want to delete this deployment?", :class => "button pill danger"
.corner
diff --git a/src/app/views/pools/_header_show.haml b/src/app/views/pools/_header_show.haml
index f8d9f40..545387b 100644
--- a/src/app/views/pools/_header_show.haml
+++ b/src/app/views/pools/_header_show.haml
@@ -7,5 +7,5 @@
= link_to 'New Deployment', launch_new_deployments_path(:pool_id => @pool.id), :class => 'button primary', :id => 'new_deployment_button'
.button-group
= link_to 'Edit', edit_pool_path(@pool), :class => 'button pill', :id => 'edit_pool_button'
- = button_to 'Delete', pool_path(@pool), :method => :delete, :confirm => "Are you sure you vant to delete this pool?", :class => "button pill danger"
+ = button_to 'Delete', pool_path(@pool), :method => :delete, :confirm => "Are you sure you want to delete this pool?", :class => "button pill danger"
.corner
diff --git a/src/app/views/providers/show.haml b/src/app/views/providers/show.haml
index 9a2f428..0aa5d97 100644
--- a/src/app/views/providers/show.haml
+++ b/src/app/views/providers/show.haml
@@ -6,7 +6,7 @@
.button-group
= link_to 'Edit', edit_provider_path(@provider), :class => 'button pill'
= link_to "Test", provider_path(@provider, {:test_provider => true}), { :class => 'button' }
- = button_to 'Delete', provider_path(@provider), :method => :delete, :confirm => "Are you sure you vant to delete this provider?", :class => "button pill danger"
+ = button_to 'Delete', provider_path(@provider), :method => :delete, :confirm => "Are you sure you want to delete this provider?", :class => "button pill danger"
.corner
%section.content-section.provider
diff --git a/src/app/views/users/show.haml b/src/app/views/users/show.haml
index 95fcf7c..407be3e 100644
--- a/src/app/views/users/show.haml
+++ b/src/app/views/users/show.haml
@@ -5,7 +5,7 @@
= link_to 'New User', new_user_url, :class => 'button primary', :id => 'new_user_button'
.button-group
= link_to 'Edit', edit_user_path(@user), :class => 'button pill'
- = button_to 'Delete', user_path(@user), :method => :delete, :confirm => "Are you sure you vant to delete this user?", :class => "button pill danger"
+ = button_to 'Delete', user_path(@user), :method => :delete, :confirm => "Are you sure you want to delete this user?", :class => "button pill danger"
.corner
%section.content-section.user
--
1.7.4.4
12 years, 10 months
Image Factory RFEs
by Hugh O. Brock
A couple of imgfac feature requests made their way to me during the SA
training this week that I wanted to pass along in hopes they would
make their way into a release soon-ish:
1. The image list in the CLI returns a not-very-human-readable list of
UUIDs, and nothing else. I'm told that part of the reason for this is
that there *is* no other data to return about images, at least not
easily. So I would like to propose that we
a. Add the ability for the image owner to set Name and
Description metadata tags on images via the factory
or, b. Add the ability for the image owner to set arbitrary
tags on images via the factory
c. Have the factory return Name and Description metadata tags
in addition to image UUIDs
or, d. Have the factory return arbitrary tag values specified
in the --list call
e. And, finally, since images are in the warehouse in a tree
structure, we should provide an option to return the image
list formatted like a PS tree, so that users can easily see
the image hierarchy
2. The image factory depends on a config file that describes the
providers it can connect to and includes parameters for connecting to
them. Unfortunately when used in conjunction with Conductor this
implies that provider config has to be set in three places (Conductor,
DC Core, Factory). It would be great if Factory would provide an API
that lets Conductor pass parameters that override whatever is in its
config file so that an admin only has to set them on Conductor.
3. Right now when users build images and push them to rhev-m or
vmware, the only identification of the image in rhev-m or vmware is
the image UUID. Image factory should provide a way to push the image
name (see 1a. above) to rhev-m or vmware so that a human being has
some idea what was actually pushed.
If you guys could let me know if these features are implementable in
the relatively near future, I would appreciate it. Alternative
suggestions welcome.
Thanks,
--Hugh
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
== http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey
12 years, 10 months
#718325 - View deployable definition link
by Matt Wagner
Since the deployable definition is in a hidden form field already on the page, we do this with JavaScript. (This does mean that this will not work for users without JavaScript right now.)
-- Matt
12 years, 10 months
[PATCH conductor] UI for deleting deployables
by Tomas Sedovic
From: Tomas Sedovic <tsedovic(a)redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=711294
A deployable can be deleted only when all of its instances are stopped or in
the "create_failed" state.
This also removes UI for deleting instances directly.
---
src/app/controllers/deployments_controller.rb | 2 +-
src/app/controllers/instances_controller.rb | 22 ----------------------
src/app/models/deployment.rb | 2 +-
src/app/views/deployments/_header_show.haml | 2 ++
src/app/views/instances/_list.haml | 1 -
src/features/deployment.feature | 7 +++++++
src/features/instance.feature | 8 --------
src/spec/models/deployment_spec.rb | 18 ++++++++++++++++++
8 files changed, 29 insertions(+), 33 deletions(-)
diff --git a/src/app/controllers/deployments_controller.rb b/src/app/controllers/deployments_controller.rb
index 4140620..6fadb88 100644
--- a/src/app/controllers/deployments_controller.rb
+++ b/src/app/controllers/deployments_controller.rb
@@ -163,7 +163,7 @@ class DeploymentsController < ApplicationController
load_deployments
render :partial => 'list'
end
- format.html { redirect_to deployments_url }
+ format.html { redirect_to pools_url }
format.json { render :json => {:success => destroyed, :errors => failed} }
end
end
diff --git a/src/app/controllers/instances_controller.rb b/src/app/controllers/instances_controller.rb
index fa60438..004da1f 100644
--- a/src/app/controllers/instances_controller.rb
+++ b/src/app/controllers/instances_controller.rb
@@ -151,28 +151,6 @@ class InstancesController < ApplicationController
end
end
- def remove_failed
- notices = ""
- errors = ""
- Instance.find(params[:instance_selected]).each do |instance|
- begin
- require_privilege(Privilege::USE,instance)
- raise ActionError.new("remove failed cannot be performed on this instance.") unless
- instance.state == Instance::STATE_ERROR
- condormatic_instance_reset_error(instance)
- notices << "#{instance.name}: remove failed action was successfully queued."
- rescue Exception => err
- errors << "#{instance.name}: " + err + "<br/>"
- end
- end
- flash[:notice] = notices unless notices.blank?
- flash[:error] = errors unless errors.blank?
- respond_to do |format|
- format.html { redirect_to instances_path }
- format.json { render :json => {:success => notices, :errors => errors}, :status => :unprocessable_entity }
- end
- end
-
def can_create
respond_to do |format|
begin
diff --git a/src/app/models/deployment.rb b/src/app/models/deployment.rb
index ea78cd8..dae2f65 100644
--- a/src/app/models/deployment.rb
+++ b/src/app/models/deployment.rb
@@ -47,7 +47,7 @@ class Deployment < ActiveRecord::Base
belongs_to :pool
- has_many :instances
+ has_many :instances, :dependent => :destroy
belongs_to :realm
belongs_to :frontend_realm
diff --git a/src/app/views/deployments/_header_show.haml b/src/app/views/deployments/_header_show.haml
index a6ecc9c..511917c 100644
--- a/src/app/views/deployments/_header_show.haml
+++ b/src/app/views/deployments/_header_show.haml
@@ -4,4 +4,6 @@
#obj_actions.button-container
.button-group
= pretty_filter_toggle(deployment_path(@deployment, :view => 'pretty'), deployment_path(@deployment, :view => 'filter'))
+ .button-group
+ = button_to 'Delete', deployment_path(@deployment), :method => :delete, :confirm => "Are you sure you vant to delete this deployment?", :class => "button pill danger"
.corner
diff --git a/src/app/views/instances/_list.haml b/src/app/views/instances/_list.haml
index 085f977..eafa74b 100644
--- a/src/app/views/instances/_list.haml
+++ b/src/app/views/instances/_list.haml
@@ -1,6 +1,5 @@
- form_tag do
= restful_submit_tag 'Stop', 'stop', multi_stop_instances_path, 'GET', :class => 'button'
- = restful_submit_tag 'Remove failed', 'remove_failed', remove_failed_instances_path, 'GET', :class => 'button'
- if @hide_stopped
%b Stopped
instances are hidden:
diff --git a/src/features/deployment.feature b/src/features/deployment.feature
index 257fedc..9c72262 100644
--- a/src/features/deployment.feature
+++ b/src/features/deployment.feature
@@ -166,3 +166,10 @@ Feature: Manage Deployments
When I follow "Instances"
Then I should see "testdeployment"
+
+ Scenario: Delete a deployment
+ Given there is a deployment named "testdeployment" belonging to "testdeployable" owned by "testuser"
+ And I am on the pools page
+ When I follow "testdeployment"
+ And I press "Delete"
+ Then I should see "The deployment testdeployment was successfully deleted"
diff --git a/src/features/instance.feature b/src/features/instance.feature
index 4ae087a..4b1bed4 100644
--- a/src/features/instance.feature
+++ b/src/features/instance.feature
@@ -65,14 +65,6 @@ Feature: Manage Instances
Then I should get back a partial
And I should see "Name"
- Scenario: Remove failed instances
- Given there is a "mock1" failed instance
- And I am on the instances page
- When I check "mock1" instance
- And I press "Remove failed"
- Then I should be on the instances page
- And I should see "mock1: remove failed action was successfully queued"
-
Scenario: Stop instance
Given there is a "mock1" running instance
And I am on the instances page
diff --git a/src/spec/models/deployment_spec.rb b/src/spec/models/deployment_spec.rb
index bde2358..b7d9883 100644
--- a/src/spec/models/deployment_spec.rb
+++ b/src/spec/models/deployment_spec.rb
@@ -70,4 +70,22 @@ describe Deployment do
@deployment.properties.should be_a_kind_of(Hash)
@deployment.properties.should == {:created=>nil, :pool=>@deployment.pool.name, :owner=>"John Smith", :name=>@deployment.name}
end
+
+ it "should be removable under with stopped or create_failed instances" do
+ @deployment.save!
+ inst1 = Factory.create :mock_running_instance, :deployment_id => @deployment.id
+ inst2 = Factory.create :mock_running_instance, :deployment_id => @deployment.id
+
+ @deployment.should_not be_destroyable
+ @deployment.destroy.should == false
+
+ inst1.state = Instance::STATE_CREATE_FAILED
+ inst1.save!
+ inst2.state = Instance::STATE_STOPPED
+ inst2.save!
+
+ @deployment = Deployment.find((a)deployment.id)
+ @deployment.should be_destroyable
+ expect { @deployment.destroy }.to change(Deployment, :count).by(-1)
+ end
end
--
1.7.4.4
12 years, 10 months
Re: Imagefactory API
by Mark McLoughlin
Hi Martyn,
On Tue, 2011-07-05 at 05:20 -0400, Martyn Taylor wrote:
> Hi Mark,
>
> So, I'm working on the aeolus-image command line tool at the moment,
> and am wondering if you could give me some info (or point me towards
> some) on ImageFactory API. I'm trying to work out what is actually
> implemented and working, and what the calls look like.
No better reference than the code :-)
The build_image and push_image methods are implemented by
build_image_for_targets and push_image_to_providers in
BuildDispatcher.py. Feel free to prod me for more details if you
struggle to figure it out
> The commands I'm looking to implement:
These look like the suggested commands I wrote up a while back. They
were meant as examples, and are mostly convenience syntax on top of what
is already supported ... so you should probably consider dropping or
rethinking some of them
> aeolus-image push --build $build_id #push all target images for a build, to same providers as previously
Okay, push_image requires the image ID and providers list, so you'll
need to get those from iwhd
1) Get the image which the build is associated with
image_id=$(curl -s http://localhost:9090/builds/${build_id}/image)
2) Find the latest build of that image which was pushed:
latest_build=$(curl -s http://localhost:9090/images/${image_id}/latest_build)
3) Find the target images for that build
tmp=$(curl -s -d "\$build == \"${latest_build}\"" http://localhost:9090/target_images/_query)
n_target_images=$(echo -n $tmp | xmlstarlet sel -t -v "count(/objects/object/key)")
target_images=$(for i in $(seq ${n_target_images}); do echo -n $tmp | xmlstarlet sel -t -v "/objects/object[${i}]/key"; done)
4) Find the providers which those target images were pushed to
for ti in $target_images; do \
tmp=$(curl -s -d "\$target_image = \"${ti}\"" http://localhost:9090/provider_images/_query); \
n_provider_images=$(echo -n $tmp | xmlstarlet sel -t -v "count(/objects/object/key)"); \
for provider_image in $(for i in $(seq ${n_provider_images}); do echo -n $tmp | xmlstarlet sel -t -v "/objects/object[${i}]/key"; done); do \
echo $(curl -s http://localhost:9090/provider_images/$provider_image/provider); \
done \
done
> aeolus-image push --account $provider_account --build $build_id #ditto, using a specific provider account
Similar to above, but you only push to a specific provider
> aeolus-image push --image $image_id #push all the target images for the latest build
Similar to above, but using the latest unpushed build:
build_id=$(curl -s http://localhost:9090/images/${image_id}/latest_unpushed)
> aeolus-image build --image $image_id #rebuild the image template and targets from latest build
This is straightforward - just call build_image with the image ID, but
no build ID, targets or template and it will work
> aeolus-image delete --providerimage $provider_image # deletes a provider image
$> curl -X DELETE http://localhost:9090/provider_images/${provider_image}
> aeolus-image delete --targetimage $target_image # deletes a target image and its provider images
$> tmp=$(curl -s -d "\$target_image = \"${target_image}\"" http://localhost:9090/provider_images/_query)
$> n_provider_images=$(echo -n $tmp | xmlstarlet sel -t -v "count(/objects/object/key)")
$> for provider_image in $(for i in $(seq 2); do echo -n $tmp | xmlstarlet sel -t -v "/objects/object[${i}]/key"; done); do
$> curl -X DELETE http://localhost:9090/provider_images/${provider_image}
done
$> curl -X DELETE http://localhost:9090/target_images/${target_image}
> aeolus-image delete --build $build_id # deletes a build, updating latest/parent references as appropriate
You get the idea at this stage - delete all the provider images and
target images associated with the build, and then delete the build
However, you'll also want to:
1) If this ID is the same as latest_unpushed for the image, unset
latest_unpushed
2) If this ID is the same as latest_build for the image, set
latest_build to the parent build of this build
3) If any build references this build as its parent, update the
reference to point to the build's parent
Basically, image factory has what you need, but aeolus-image will need
to do a good bit more iwhd interaction to implement these commands
Cheers,
Mark.
12 years, 10 months
[PATCH configure] BZ 717967 - fix solr status reporting after service is stopped
by Richard Su
/etc/init.d/solr status was reporting "solr dead but subsys locked"
after aeolus-cleanup. Removed custom stop command and let service
do its thing so that /var/lock/subsys/solr is cleaned up properly.
---
recipes/aeolus/manifests/conductor.pp | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/recipes/aeolus/manifests/conductor.pp b/recipes/aeolus/manifests/conductor.pp
index d04f640..4687d32 100644
--- a/recipes/aeolus/manifests/conductor.pp
+++ b/recipes/aeolus/manifests/conductor.pp
@@ -121,7 +121,7 @@ class aeolus::conductor inherits aeolus {
package{"java-1.6.0-openjdk":
ensure => "installed" }
service{"solr":
- hasstatus => "false",
+ hasstatus => true,
pattern => "jetty.port=8983",
ensure => 'running',
enable => 'true',
@@ -229,9 +229,8 @@ class aeolus::conductor::disabled {
### stop solr search service
service{"solr":
- hasstatus => false,
- stop => "cd /usr/share/aeolus-conductor;RAILS_ENV=production /usr/bin/rake sunspot:solr:stop",
- pattern => "solr",
+ hasstatus => true,
+ enable => false,
ensure => 'stopped',
require => Service['aeolus-conductor']}
}
--
1.7.4.4
12 years, 10 months
BZ 717661 rev. 1
by Jan Provazník
Added second patch which makes provider account's create action cleaner.
12 years, 10 months
IWHD _acl/_owner spec v2
by Pete Zaitcev
This is how Image Warehouse will implement what was discussed in the
thread "Image permissions, round 2".
-- Pete
* Image Warehouse permissions *
v2 2011-07-01
= attributes specification
The iwhd can run without authorization at all (as is now) or with authorization
(and supporting authentication). It is the only transition mechanism. There
is no mechanism by which iwhd running with authorization presents a compatible
view to unauthenticated clients that are deployed currently.
Owners may provide "world" access, with an an ACL entry for "*". Authenticated
clients not explicitly listed are granted that access. Unauthenticated access
is special-cased: it has read and list access if allowed with entry '*', but
it never has write access (reason [1]).
The root, buckets, and objects may have an attribute _acl and _owner.
The _owner contains a name of the object owner (foo implies owner in all
examples below) (reason [2]). The _acl contains the following:
[
{ "name":"foo", "mode":"rwx" },
{ "name":"user1","mode":"rwx" },
{ "name":"user2","mode":"rw" },
{ "name":"user3","mode":"r" },
{ "name":"*", "mode":"r" }
]
In initial implementation, the attribute body literally contains
these data. In later implementation the list may be indexed internally.
Or, the contents of _acl can be looked up in Kerberos, LDAP, or other
component of FreeIPA. But it still looks like this when accessed through
iwhd REST API.
Users are user names that are delivered by Kerberos from IPA, or by
Basic or Digest auth, if we ever implement it. They are case-sensitive
and alphanumeric. Special characters are not allowed, except '*' and '@'.
When a root, bucket, or object is created, _owner is set. Root is set
from configuration, the rest is from API. Only the root user (_owner
of root) can change _owner. Also, an _acl is created that contains:
[ { "name":"foo", "mode":"rwx" } ]
Create and Delete are the same, with one exception: buckets owned
by someone else cannot be deleted even if the user is in _acl for
the root (e.g. can create buckets). So, 1777 /tmp semantics.
Metadata access permissions are the same as data, however _owner
can access metadata regardless of any permissions (reason [2]).
The x permission differs from r permission on root and buckets in
that it permits unfiltered access. A non-root user with r access
receives a list of his own buckets or objects (filtered list).
This is an expensive and contended operation, so there may be an
index of buckets that has _owner in actual bucket records (reason [4]).
Groups are postponed (reason [3]). We only reserve @-syntax for them.
= use model note
Mark made the following curious statement:
- Permissions on buckets - I don't think we need these. We are storing
all our objects in single buckets, so it's hard to see what we would
use these for.
We in iwhd believe that multi-tenancy is absolutely essential (same as
in CloudFS). If Conductor wants to dump everything into one bucket, we
do nothing to preclude that. However, our use model presupposes
that every tenant gets to create a number of buckets (plus a few
system buckets for shared images).
= performance impact (TBD - action zaitcev)
extra DB overhead per
- list bucket
- filtered list on root
- create/delete bucket
- create/delete object
- create object and set custom ACL
= checklist
+ non-unix; ACL; user==_owner
- default user: configurable, for transition period
-- rejected. just '*' and that's it
+ root user - can do chown; configurable name... owner of root object?
+ root object (permits to create buckets)
- write permission on bucket == delete on object.
-- delete on bucket - see 1777.
+ default ACL: create object&bucket adds built-in default ACL
-- no configurable _default like in POSIX 1.e
+ chown prohibited (except for root); owner always exists, req. for quota
- concurring access atomicity
<== ACL update is not atomic unless we add "modify" op (HTTP method?)
- group concept
-- postponed, but is necessary
+ permissions of metadata and data on the object
+ tenants own, create/delete/list isolated
-- however provider is root; tenants must encrypt if no trust provider
+ tenants metadata no leaks
= reasoning
[1] Why unauthenticated access cannot write even if "*:w"?
Because they cannot create "_owner". Maybe later we special-case write into
pre-existed object, and creation of new attributes. This is still not
compatible with iwhd in "without authorization" mode, because they cannot
write into buckets (== create objects).
[2] Why have _owner attribute at all? The initial _acl affords the same
permissions that _owner does, and we permit anyone with "w" to remove
permissions by updating _acl. This makes no sense!
Because of a couple of reasons (at least).
First, _owner provides a safety net, so users can restore permissions
or delete anything they created. Provider (root user) does not want to
field trivial help calls. Also, users are charged per byte, so it is
only fair to give them this control.
Second, although quotas checked incrementally and do not need _owner
normally, if a consistency checker has to recalculate quotas, it will
need _owner.
[3] Why no groups?
Because we want something working quickly. Anyone who deals with ACLs in
practical terms says that they are essential. Mark's memo says "for large
organizations, group permissions will also be needed." We plan on
adding groups as a syntax, e.g. entries in _acl will have '@' at the front,
then the accessor is matched against the group after '@', and if succeeds,
it is granted access described by bits. This seems compatible.
[4] Why have filtered access and a whole separate x bit?
The x permission is separate in order to prevent leaking of data and
metadata among tenants. We expect that next to nobody is going to
have it set, but we'll see. This is still under discussion as an
efficient implementation is being determined. We do not want any
requiest to list buckets to lock the whole DB and read 10,000,000
_acl attributes.
12 years, 10 months
