Signed-off-by: Steven Dake <sdake(a)redhat.com>
man/oz-install.1 | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/man/oz-install.1 b/man/oz-install.1
index b497813..7cf0077 100644
@@ -70,9 +70,14 @@ will undefine the libvirt guest with the same name or UUID and delete
the diskimage, so it should be used with caution.
-Use a timeout value of \fBtimeout\fR for installation, rather than the
-oz default. This can be useful if you know you have slower storage
-and want to wait longer for the installation to timeout.
+Terminate the installation of the guest image in \fBtimeout\fR seconds
+rather then the default of 1200 seconds. This value can be increased in the
+case of slow storage or multiple oz-install operations on the same machine
+consuming the disk bandwidth.
+Please note there is a separate termination action that occurs if 300 seconds
+elapses before any data is written to the VM image. This timer value is not
Customize the image after installation. This generally installs
Fix for https://www.aeolusproject.org/redmine/issues/1510
This should work and shouldn't break any new tests, but I didn't test it on
providers that actually get affected by this as I don't have access to them.
Ian, please take a look at it and let me know if it solves the problem.
While testing aeolus I've found that aeolus is mainly conceived for
stateless instances (https://www.aeolusproject.org/redmine/issues/1059).
Will additional functionalities for stateful images be added in aeolus?.
I guess support for stateful instances would require:
- Differentiate between stopped and deleted (or terminated).
- Being able to re-start an stopped instance.
- Being able to delete an stopped instance (to destroy the underlying vm)
- Being able to modify an existing instance (for example, assigning a
different hardware profile)
I think statefull instances will be mainly required in private clouds
using RHEV or VMware providers, i.e.
As deltacloud support both start/stop/destroy vms, I guess this is
doable, is it in current roadmap plan?
Providing a formal deffinition of the XML for an API, makes using the API, in particular creating and maintaining client applications that utilise the API much simpler, and far clearer for a developer.
There are an array of tools that provide class generation, and automatic marshalling and unmarshalling of objects, generated straight from a formally defined XML Document, for ruby, this project looks to offer these functions: https://github.com/rubyjedi/soap4r .
In my experience writing Java and Android clients, I have found that the time spent creating an XSD or other formal XML definition, repays 10 fold in development time, and also makes keeping clients up to date alot simpler. For DC Client I ended up writing my own: https://github.com/mtaylor/deltacloud-tools/blob/master/DeltaCloudClient/...
But, I think it would be better as a whole to adopt this approach from the start. It would not only benefit the creation of the CLI but also anyone else who needs to utilise these APIs
deltacloud-devel mailing list
Currently most linux distributions that use dbus store a UUID in
/var/lib/dbus/machine_id. In our pacemaker-cloud work test tools, we
must manipulate this file via oz image creation to match a value we know
Q1. Is this file freshly created on each image creation/cloning process?
If not, it should be, because Matahari uses this information to uniquely
identify a host. If it is copied exactly to each new image, that
creates a problem (all hosts appear the same to matahari).
Q2. If/when it is created by image factory, will it be stored in a
database or other storage medium?
In pacemaker-cloud we need to have a mapping from image->internal id id
so that we know which VM maps to which deployable HA configuration.
If we wait on this point until after our 1.0 release, we could end up
with a bunch of images in the field that have either the same machine id
or are not mapped in any way that allows us to provide HA functionality.
This patch adds the ability to manage config server connections within
conductor. The concept is that a user should be able to add and manage a config
server connection for each provider account.
The overview of changes are:
* updated the provider account "show" view to allow the user to add, edit,
delete, and test a config server connection
* added config server model, controller, and views
* added spec and cucumber tests for the config server feature
Chatting to Justin yesterday, I suggested we come up with a list of the
top 5 features for the next release
The idea is that these would be the features we'd concentrate on
polishing off for the release and then promote heavily in the release
announcement with demos etc.
My attempt is below. What am I missing? Any thoughts on the idea?
1) New UI design!
- Complete new theme
- Design & Deploy, Monitor and Administer tabs
- Pretty View and Filter View
- Monitor UI
- "Launch Deployable" and deployments UI
2) RHEV-M, VMWare vSphere and CondorCloud support:
- Available as provider types in conductor
- Image build/upload support
- Audrey config server IP used to get addresses of RHEV-M VMs
3) Deployable concept:
- Launch multiple instances using a deployable definition which
lists the images to use
- Stop all the instances in a deployment in one click
4) aeolus-image CLI:
- Build an image from a template
- Push it to multiple providers
- Import an image
- List images available for use in deployables
5) Reduced complexity:
- Template creation and image building UI removed
- condor_refreshd, the condor classad plugin, warehouse sync,
image factory connector and delayed job daemons all removed
I was getting this error when running 'rake db:migrate' with sqlite:
SQLite3::SQLException: Cannot add a NOT NULL column with default value NULL: ALTER TABLE "deployables" ADD "uuid" varchar(255) NOT NULL
To avoid the warning, we can add the column as nullable and then change
it to non-null later.
Presumably this would fail if we ran the migration on a DB containing
any data in the deployables table, but this is unlikely. To avoid it,
we could do e.g.
Deployable.all.each do |deployable|
deployable.uuid = "" if deployable.uuid.nil?
deployable.xml = "" if deployable.xml.nil?
but that seems like overkill given the situation, especially since the
default values don't make any sense.
.../migrate/20110207100800_update_deployables.rb | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/db/migrate/20110207100800_update_deployables.rb b/src/db/migrate/20110207100800_update_deployables.rb
index 4414560..ff87bed 100644
@@ -2,13 +2,16 @@ class UpdateDeployables < ActiveRecord::Migration
change_table :deployables do |t|
t.integer :lock_version, :default => 0
- t.string :uuid, :null => false
- t.binary :xml, :null => false
+ t.string :uuid
+ t.binary :xml
t.boolean :uploaded, :default => false
+ change_column :deployables, :uuid, :string, :null => false
+ change_column :deployables, :xml, :string, :null => false
create_table :assemblies_deployables, :id => false do |t|
t.integer :assembly_id, :null => false
t.integer :deployable_id, :null => false