Aeolus Team Leads
by Martyn Taylor
Gents,
We are stuck in a pattern where, after hours/days of frustrating debate, we create
delicate balances of agreement on topics only to have our consensus break
when a new point of view is interjected or another conversation
takes place. I really think it is time to add some layer of
leadership to the team. Our team is simply too large to act as a
democracy.
I realise that the Tech Cabal is an attempt to address the
aforementioned problems, but I do not feel that adding another sub-democracy
can help us in this issue. The Cabal has its advantages
when trying to solve integration/cross project problems, but I don't
think it helps us steer individual projects. I really think we need
technical leads that have the power to make decisions, or at the very least to
decide when debate is closed and carry forward ideas that have been agreed upon.
This is how the majority of projects both inside and outside of RedHat operate.
I'm not sure why we do not have this in Aeolus, but I'd be much
happier in my position if I had some clear direction on approach,
whether I agreed with that approach or not. Let me be clear and say
I don't expect Team Leads to simply make all and every decision
alone and dictate to the rest of the team. Rather, we need someone who
listens to all points of view and makes a decision and takes
responsibility for it.
How do you guys feel about this idea?
Would you be willing to give up some control for clear direction?
Regards,
Martyn
11 years, 3 months
RFC: Factory support for nested build requests
by Matt Wagner
Hi folks,
This email is to solicit input on a discussion that came up on IRC
tonight, with a proposal to have Image Factory allow us to request the
builds of child objects at the same time we are requesting the builds
for their parents.
Jan and I hit an issue tonight with submitting builds to Image
Factory. The problem is essentially caused by the fact that, in our
new (reimplemented) build_all method[1], we submit a request to build
a new image version, and the immediately commence building target
images.
This appears to typically work fine when building for a single
provider, but when there are multiple providers, this often causes the
build to fail, as we end up submitting the target_image builds before
the image_version build has completed.
In our discussion, we talked about the implementation of this. The
"right way" in Conductor would be to set up a background task to
handle this. We would submit a request to build an image version, and
then wait for a callback from Factory saying it was done. When it was
done, we would then submit tasks for each target image we wished to
build.
(We would have to do this eventually anyway, to allow us to
automatically push the image when we got a callback that the build had
completed. One-call build-and-push would help here, but this isn't
what we're talking about in this email.)
Ian proposed that this might be done in Factory itself:
<imcleod> matty_dubs: Would it be super-helpful to you to be able to
request child image types while the parent is still in progress?
Because we could do that. We'd have to add some polling internal to
factory, but it's not particularly onerous.
My gut is that this would make things significantly simpler, at least
on the Conductor side. We wouldn't need to worry about queuing tasks
to be sent upon receipt of callbacks. It also just feels
architecturally cleaner, to not have two applications that need to
know a lot about the inner workings of the other.
Ian is going to investigate a bit to get an estimate of how involved
this would be. But in the event that it's not too involved, I propose
that this would be the best course of action, versus us trying to
implement the same sort of thing in Conductor.
Do any of you folks have opinions on the matter?
-- Matt
[1]
https://github.com/aeolusproject/conductor/blob/tim-stable-rebased/src/ap...
-- specifically, line 95 does not wait
11 years, 3 months
State Transitions in ReST API
by Martyn Taylor
Gentlemen,
We discussed how to model state transitions in the ReST API in the Tech
Cabal and also offline for those who had particularly strong views. One
of the objections brought forward was how to distinguish between clients
(end users or applications) requesting state changes. For example: A
developer decides he wants to terminate his running instances and system
services that are used to notify conductor of when an instance has
changed state. For example db-o-matic wants to tell conductor that the
instance has now started.
After some deliberation offline between myself and sseago and without
objections from the Tech Cabal. We decided that the services and the
end users should access different APIs and we should not add complexity
into the end user API in order to support these system services.
With this behind us. We then were able to move forward to make a
decision on how to handle requests from a user to transition between
states. Like in the developer example above.
It was agreed that treating the State on an instance as simply an
attribute on the resource (and not an action) was more inline with the
ReST principal (Since adding actions breaks ReST principal of having a
unified interface - in our case the unified interface is defined by HTTP).
So, this now brings us to how we should represent these resources. I
think this is something that can and should be decided on list. I have
included below my opinion on how this should be represented, please add
in your own comments.
==
So in my opinion we should model a state machine as an independent
resource. When client wants to change the state of an instance, it
looks at the state machine to figure out what are the possible states I
can move to now. The instance can hold a reference to it's current
state and the state machine.
A simple example here: https://gist.github.com/4257951
Regards
Martyn
11 years, 3 months
RFC - API: Update of Provider Type
by Petr Blaho
Hi all,
after some good points during sprint planning session
I want to know every opinion about wether implement update action
for Provider Type resource or not.
The point is that updating Provider Type will mean changing of dependent
Providers too. We cannot predict how will API users modify Provider
Type. Change of Credential Definitions for that Provider Type could mean
that all Providers of that Provider Type should be modified/recreated.
And that is a problem.
To make a better idea why user should use Provider Type API imagine
a company with proprietary solution for managing VMs. They have
Deltacloud Driver for their solution and they need to tell Conductor
that Deltacloud has this Provider Type and how to work with it (which
Credential Definitions it has ...)
So, do you see a reason why build update action for Provider Type and
which issues should be addressed w/r/t modifying Provider Type -
Providers associations? Or should I work on other things and save time
implementing feature which probably will have no use at all?
IMHO I cannot imagine scenario where user needs to modify Provider Type
but maybe I am wrong.
--
Petr Blaho, pblaho(a)redhat.com
Software Engineer, CloudForms
11 years, 3 months
github issue labeling
by Martin Povolny
Hallo gentleman!
I would love to assign labels to github issues for Conductor.
Right now, I would love at least "bug", "feature". Maybe more labels if
more then one can be assigned to one issue: "grave", "minor".
Who has the powers to add labels? Can you add labels for me? Or can you
give me the power to add labels? Or even do we need to discuss what
labels to add?
Happy hacking!
--
Martin Povolny <mpovolny(a)redhat.com>
tel. +420777714458
11 years, 3 months
Reconciling names
by Angus Thomas
As discussed previously (
https://lists.fedorahosted.org/pipermail/aeolus-devel/2012-October/012923...
) there's a significant cost associated with the divergence of names
between Aeolus and Red Hat's Cloudforms.
The Aeolus community loses out in several ways:
- Users of Cloud Engine are using terminology which doesn't apply
upstream, putting a barrier between the Aeolus project and a good number
of the users of our software.
- As part of the productisation process, Red Hat translates all the
strings in Conductor into nine different languages.[1] If the use of
terms could be reconciled, Aeolus Conductor would immediately support
nine languages, rather than supporting one.
- The work required to maintain a separate set of terms for the Cloud
Engine product is tedious and error-prone and falls entirely on people
who are key contributors to Aeolus, and whose time could be better spent.
Several rounds of shuttle diplomacy between the Aeolus community and Red
Hat's product managers are now complete, and we have arrived at a final
set of
converged names. The final list is a significant set of changes from the
current set of names used in Cloudforms, in response to the feedback
from the Aeolus community.
Here's the list, current names on the left, and the new name on the right:
Image Template -> Component Outline
Deployable -> AppForm Blueprint
Deployment -> AppForm
Pool Family/Environment-> Cloud Environment
Pool -> Resource Zone
Provider -> Cloud Resource Provider
Hardware Profile -> Hardware Profile
Provider Realm -> Provider Realm
Frontend Realm -> Frontend Realm
Image -> Image
Assembly -> Assembly
Instance -> Instance
Catalog -> Catalog
Config Server -> Config Server
Please respond with +1 or objections.
If you're new to the party, and are wondering if some of the new names
could be changed, the answer is, "Probably not, at this stage". It has
taken several rounds of discussion to get to this point. I'd strongly
urge that we accept these names wholesale.
Of course, the applications will continue to evolve, and names may well
change in future, but we shouldn't miss this opportunity to reconcile
the Aeolus project's names with Cloudforms.
Please note that, as discussed in the Brno dev converence, we need to
use the final set of names everywhere:
- API
- CLI
- Controller names etc.
- Web UI
- Docs, Blogs, discussions
So, there is going to be work to do to fix the entire application to use
the correct names.
Angus
11 years, 3 months
Sprint review screencasts
by Jirka Tomasek
The Publicity Cabal has decided that it would be nice to record our
sprint review presentations.
We concluded that instead of recording whole sprint review call it would
be better to make
separate screencasts of the presented features. This approach makes each
feature introduction
shorter and noiseless.
I have made a few tests and making screencast is fairy simple on Fedora.
The recordmydesktop
utility is already installed, I just installed GUI version
gtk-recordmydesktop. Then I looked at
http://www.youtube.com/watch?v=rWHXbkpJjGk for a couple of configuration
advices. I prefer to
use 25fps as it gives more fluid experience. The video file then grows
quite big though, so set it
based on the length of your presentation. Screencast I did has four
minutes and video file has
been around 70mb. Only tweak I had to do is to lower my mic sensitivity
to avoid background
noise.
After you record the screencast, It is possible to upload it as it is or
if you want to do more editing
you need to use some video editor (Avidemux). If the video file is too
large, you can use HandBrake to
compress/convert it. Make sure that compressed video is still watchable:)
Here is my Username/Password recovery screencast:
http://www.youtube.com/watch?v=cur639p70Vs
I will put this guide also to our wiki.
11 years, 3 months
