Can we make November 1 the day OpenStack works end-to-end?

Jason Guiditta jguiditt at redhat.com
Mon Oct 1 15:18:48 UTC 2012


On 01/10/12 10:26 -0400, Hugh Brock wrote:
>On Mon, Oct 01, 2012 at 10:22:26AM -0400, Jason Guiditta wrote:
>> On 01/10/12 09:45 -0400, Matt Wagner wrote:
>> >Hi folks,
>> >
>> >I've been thinking some more about OpenStack and the fact that it's
>> >still not working end-to-end in Aeolus. A lot of people have done a lot
>> >of work to get individual components working, but it's still not all
>> >integrated.
>> >
>> >It's been something we've been trying to do for six months, and one of
>> >the few bits of community feedback we've had. The situation is frankly
>> >kind of frustrating.
>> >
>> >So I'd like to propose that we draw an arbitrary line in the sand and
>> >say that, one month from today, on November 1 (a Thursday), we will have
>> >OpenStack working end-to-end and all requisite components released. Does
>> >that seem feasible? To my knowledge, that means that we will need to:
>> >
>> >1.) See that Deltacloud 1.0.4 is released.
>> >2.) See that Image Factory 1.2 is released.
>>
>> I'll defer to Ian and Steve here, but I think, bug fixes aside, they
>> consider 1.2 done.  If you mean 'will it have an rpm' by that date, I
>> have no clue (though you can certainly build the rpm from source if
>> you want to abandon a 'working' current version).
>>
>> >3.) Implement IME, or if that won't be ready by November 1, update
>> >aeolus-image-rubygem to work with Image Factory 1.2.
>> >
>> Integration here is already planned, and will take (conservatively) 2
>> sprints, which puts us at about mid-november.  If you are running from
>> source/upstream only, I think you should have something fairly
>> workable, but likely not 100% done, by that time.  Upgrading
>> aeolus-image as it exists now to work with the new factory (which
>> really should be called 2.0, not 1.2, it is so different) would be an
>> exercise in futility.  All the iwhd functionality is moved into
>> factory proper, and the data structure is different as well, so there
>> is no way it would work, sorry.
>>
>> >While this feels a little bit like an aggressive schedule, this is
>> >something that's already been 6 months in the making. I really think we
>> >need to get this wrapped up soon. Does this seem like a workable plan to
>> >everyone?
>> >
>> >-- Matt
>>
>> I appreciate your frustration, but the work to make this happen is
>> well underway, and arbitrary deadlines, as always, will not make that
>> happen any faster.  If you wish to help make sure it is a smooth
>> transition, I would invite you to build and test both the new version
>> of factory[1], as well as IME[2].  Submit issue for IME on github, and
>> Martyn or I will do our best to address them asap.  For factory, I am
>> not sure what their process is for issues these days - they do use pull
>> requests, so I suspect they would see any issue posted to github as
>> well. We have a lot of examples on the IME README on how to call the
>> api, and the setup uses rvmrc if you choose - otherwise, create your
>> own gemset and follow the directions there, I think it shoudl be
>> relatively painless.  If there are pain points, or missing steps,
>> pull
>> requests are gladly accepted. Note that we also have an integration
>> plan[3] that was worked through with jan and scott, which you are
>> welcome to peruse and contribute to. Most or all of these tasks were
>> added by jan to redmine, though on the ime side we will likely port
>> them over as we experiment with using github issues more.
>>
>> [1] https://github.com/aeolusproject/imagefactory
>> [2] https://github.com/aeolus-incubator/image-management-engine/
>> [3]
>> http://etherpad-aeolusproject.rhcloud.com/p/aeolus_conductor_integration
>>
>> Thanks for continuing to push this forward, I think we are closing in
>> on some very good feature improvements here.
>
>Thanks for the detailed analysis Jay.
>
>I'll defer to you guys on the date estimates, but I *would* like to have
>"working Openstack" coincide with a proper upstream release of
>Aeolus. Maybe we could even call it 1.0? Let's start talking about it
>now though...
>
>--Hugh
>
For the record, at the end of every development sprint, we
theoretically have a release upstream (provided we remember to tag it
in git).  Github provides us with tarballs for any tagged revision in
git history[1]. So, if all goes exceedingly swimmingly, the upstream
release 2 sprints from now should pretty much be what you are asking
for.

Whether this openstack support is what constitutes a 1.0 release in the
eyes of the upstream community is another question, and I do not have
the answer.  This may be a good place for another line in the sand
(though not date related).  Perhaps it would make sense to list at
some fairly high level, what our goals are for conductor to be
considered 'feature complete' for a 1.0 release.  If we have that, it
is a simple decision when to use that particular number.  Creating
such a list is quite a task though, and sure to be fraught with debate
(or lack of response, depending who brings it up), which is why we
seem to have no such thing at this time.

-j

[1] https://github.com/aeolusproject/conductor/tags



More information about the aeolus-devel mailing list