Aaron gave me a good idea yesterday. The script  which I whipped up
to demo deltacloud on fedora-devel  could be used to very quickly
test out templates on the cloud. (without having to wait for the long
image building process which takes lots of time and bandwidth)
The tool is pretty basic, it just sets up a cloud environment via
deltacloud with some extra info added to the tdl (the added fields do
not overlap w/ the existing tdl ones, so the templates can still be used
with oz / imagefactory as is), and runs a ssh loop to process the tdl.
The nice thing is I can simplify it even further very easily by removing
that ssh loop and simply using oz to process the tdl on the running
cloud instance. Essentially this would mean mycloud (the name can be
changed) is the simplest unification of deltacloud and oz
To prevent confusion, I propose we name these templates w/ the extended
cloud data, "extended tdls", or etdl's for short.
This would give deltacloud another use case and would make building and
testing templates for various purposes very simple and easy. Thoughts?
I'm in the process of implementing the first user story, Delayed Launch,
per the Redmine page below . I've pulled out the relevant section of
the page for quick reference below. I'm also adding what views I
believe will be edited along the way. I figure soliciting comments and
suggestions before getting too far is a good idea...
1. As a user I want to launch a deployment at a specified time.
Delayed_job can be used for this (we already have it integrated). It
could work as follows:
1. a user sets launch time on a deployment launch page
2. after checking permissions (same as for common launching),
deployment+instances objects are created in conductor's DB (both
deployment and instances stay in 'NEW' state)
3. we check if match is found at this point, if not, warning is
displayed to user, but he is allowed to continue in delayed launch
4. launch request is queued in delayed_job queue with appropriate delay
(delay = current time - launch time set by user)
5. delayed_job invokes launch request which: checks again permissions,
finds a match and launches the deployment. If match is not found,
deployment is not deleted but failed status is set both for deployment
Deployment model in conductor would be extended with attribute
"launch_at", this attribute would be set for delayed launches and would
be displayed in UI.
Deployments which are waiting for launch can be deleted, in such case
delayed_job's job should be removed from queue -> another "job_id"
attribute would be needed for keeping this id.
Deployments which are waiting for launch can have their launch time
edited. One of two scenario's would occur then:
1. Update the delay of the job in the queue of delayed_job
2. Duplicate the request currently queued in delayed_job, issue a new
request to delayed_job and delete the original request.
Both of these scenarios would also require a "job_id" attribute be
created to keep the delayed_job id.
After repeatedly struggling with whether it was 'OpenStack' or
'Openstack', I decided to look it up. It occurred to me that this was
not the only name out there that I sometimes struggled with, so I
started a wiki page collecting this information.
Note that my intention is just to have a reference we can consult when
we're not sure, not to try to criticize anyone who has ever typed one of
these (often seemingly erratically capitalized) things incorrectly or
anything of the sort.
Please feel free to update the page with other content as needed, but
please, please, please make sure what you're adding is unquestionably
accurate. (I've tried to add links to official sources showing the
usage where possible.)
Of note, there are some upstream things I'm not sure about:
* I usually write 'Image Factory', but I see that imgfac.org writes the
name as 'imagefactory'. In conversations we often say 'Factory'. Is
'imagefactory' the proper spelling and capitalization?
* Tim? tim? TIM? I've seen all three used. Is one definitely correct?
(Oh, and for the record -- it turns out it's 'OpenStack', with the 'S'
While it's in spirit of free and open source software to publicly report
bugs as soon as they're discovered, it's not the best thing to do with
The common practice between security researchers is to notify the
developers in confidence, give them a reasonable time to fix the bug and
then release the details to public. This is called "responsible disclosure".
It helps to minimise the risks of actual exploits happening.
We have a specific process for reporting security-related issues,
documented on our Contact Us page:
1. Send security vulnerabilities here: aeolus-security(a)fedorahosted.org
2. if you want, GPG-encrypt the email using our public key:
Please keep this in mind when you discover a new security issue. It will
only become more serious as our user base and downstream grows.