We're still running on the 3.2.12-ish stack that I put in after the
first round of security holes came through. There's been several more
rounds and probably more to come, so we need to keep pulling in updates.
I just took a brief stab at updating to 3.2.12 proper, and a bunch of
tests exploded as usual. I don't have time at the moment to bang on it
myself, so if anybody wants to jump on it, you can be a hero.
After some discussion with a few folks from Imagefactory, Tim and
conductor about how to handle cascade deleting in Aeolus, we came up
with I think some reasonable amount of scope for each component. I've
included this below.
As a result, the image lifecycle management, relationships etc... shall
be handled not in factory but in Tim. As a first step to adding in this
functionality (particularly for cascade delete) I've created state
machine to highlight all possible states and transitions for Provider
and Target Images.
I'd like to get some feedback on the FSM I've included in the mail to
make sure it matches up with reality + is sensible.
Image Management Scope/Tasks:
* Will provide some method to delete a provider image
o This will* include the ability to register a callback
o This will* include the ability to pass in provider credential
o This will NOT* enforce referential integrity
o This wil NOT* add any validation
o This will NOT* support ordering of tasks added on the queue.
* Implement cascade deletion..
o This will enforce integrity and validation
o Potential Active Record cascade problems we may need to override
* Investigation into the handling of Deployables with regards to image
o Depends on the outcome of the RFC: Template Versioning and Rename
* Investigation into the handing and processing of failed deletions
(images in state FAILED_DELETE in Imagefactory)
+ Should we keep parents objects hanging around in conductor
+ Does/Should conductor archeive deletions
+ What are the implications in the Conductor UI
You can generate a jpeg graph of the state machine defined in both the target_image and provider_image class (NOTE they both use the same state machine) using the following rake command:
rake state_machine:draw FILE=../../app/models/tim/target_image.rb CLASS=Tim::TargetImage
rake state_machine:draw FILE=../../app/models/tim/provider_image.rb CLASS=Tim::ProviderImage
You can merge this Pull Request by running:
git pull https://github.com/mtaylor/tim state_machine
Or you can view, comment on it, or merge it online at:
-- Commit Summary --
* Added State Machine to target/provider images
-- File Changes --
M Gemfile (1)
A app/models/tim/fsm.rb (39)
M app/models/tim/provider_image.rb (2)
M app/models/tim/target_image.rb (2)
A db/migrate/20130211140935_add_state_to_provider_image_and_target_image.rb (6)
M test/dummy/db/schema.rb (2)
M tim.gemspec (4)
-- Patch Links --
Someone running a Cloud Engine demo instance was interested in displaying
a message on the login page displaying some information about the system.
Note that I am NOT proposing to merge this patch at this time; it's really
a one-off hack. I'm sending it out (a) so people can sanity-check it, and
(b) because I think it's a decent RFE that we might want to fold in upstream.
There's a second patch I'll send in a moment, that goes to to the vendor/converge-ui
checkout (from a separate repo). This is less of a disaster post-1.1, but this
is for 1.1.
Basically I am thinking we want mock builds to continue being a no op (like pre-tim conductor behaviour). In order for that to happen, the template os name needs to use FedoraMock or RHELMock. When originally discovering this and discussing with Dev, the line of thought was have tim update the os template name on the fly when mock target is requested otherwise mock builds actually build a full blown image which mock does not need or use.
Reply to this email directly or view it on GitHub: