Hi,
Matt and I have worked on Tim integration task last months, we kept this
stuff in separate branch to make sure we don't break everybody's setup
for too long time.
Although there are still some known issues pending for fix, I think it
would be better to merge the tim integration branch (tim-stable-rebased)
into master branch, it was successfully tested for all major provider
types we support in Conductor - ec2, rhevm, vsphere and newly added
support for openstack.
If you agree, I will merge it into master on Monday.
Here is short Howto for setting up new new Imagefactory and Conductor:
https://github.com/aeolusproject/conductor/wiki/Conductor-and-new-Imagefact…
List of known bugs/todos for Conductor:
https://github.com/aeolusproject/conductor/issues?labels=tim&page=1&state=o…
List of known bugs/todos for Tim:
https://github.com/aeolus-incubator/tim/issues?state=open
Jan
Aaron gave me a good idea yesterday. The script [1] which I whipped up
to demo deltacloud on fedora-devel [2] 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?
-Mo
[1] https://github.com/movitto/mycloud/blob/master/mycloud.rb
[2] http://lists.fedoraproject.org/pipermail/devel/2012-November/173298.html
I'm in the process of implementing the first user story, Delayed Launch,
per the Redmine page below [1]. 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...
---
User Story:
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
and instances.
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.
Views
- src/app/views/deployments/_launch_new.html.haml
- src/app/views/deployments/launch_time_params.html.haml
- src/app/views/deployments/_deployment_card_index.html.mustache
- src/app/views/deployments/show.html.haml
- src/app/views/instances/_instance_card.html.mustache
- src/app/views/deployments/_edit.html.haml
[1]
https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Scheduleddel…
Branch: refs/heads/master
Home: https://github.com/aeolus-incubator/tim
Commit: 2aa0d5a7e702216ffed998ddb63ade0d3bfbf1b2
https://github.com/aeolus-incubator/tim/commit/2aa0d5a7e702216ffed998ddb63a…
Author: Jason Guiditta <jguiditt(a)redhat.com>
Date: 2013-01-15 (Tue, 15 Jan 2013)
Changed paths:
R Gemfile.lock
M tim.gemspec
Log Message:
-----------
Relax Rails version requirement.
This should make it easier for the host app to update at will, instead
of forcing them to before they are ready. Also, general practice for
engines is to not have the lock file under version control. To this
point we have had it to simplify development, but as it is starting to
be an issue for others, this may be a good time to remove it.
Commit: 41e4db50aa9419cc75a2b2f09282554ad4b96ce5
https://github.com/aeolus-incubator/tim/commit/41e4db50aa9419cc75a2b2f09282…
Author: cwolferh <cwolfe(a)redhat.com>
Date: 2013-01-15 (Tue, 15 Jan 2013)
Changed paths:
R Gemfile.lock
M tim.gemspec
Log Message:
-----------
Merge pull request #96 from jguiditta/relax_rails_version
Relax Rails version requirement.
Verified that these changes play nicely with a aeolus-project/conductor/tim-stable-rebased "bundle install" when conductor's Gemfile points to a local tim gem.
Compare: https://github.com/aeolus-incubator/tim/compare/edff7f3a937b...41e4db50aa94
Hi,
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[1] 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'
capitalized.)
-- Matt
[1]
https://github.com/aeolusproject/aeolusproject.github.com/wiki/Writing-Styl…
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
security vulnerabilities.
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:
https://aeolusproject.org/contact.html#security-related
In essence:
1. Send security vulnerabilities here: aeolus-security(a)fedorahosted.org
2. if you want, GPG-encrypt the email using our public key:
https://aeolusproject.org/keys/aeolus-security-public-gpg-key.asc
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.
Thanks!
Thomas