next and next-plus-one release priorities (from Friday)
by Hugh O. Brock
Here's the slides we were looking at in planning on Friday -- should be
helpful in sprint planning.
--Hugh
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
== http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey
11 years, 5 months
The Cabal meetings ought to be public
by Tomas Sedovic
I didn't see this mentioned in any of the cabal-related e-mails,
apologies if it was.
These meetings are supposed to have influence over the direction of
Aeolus. As such, they should be public to provide transparency and hold
the members accountable.
Note that I'm content with a "read-only" format. If the goal is to
settle disputes and move things forward, having too many inputs would be
detrimental.
If the meetings are over IRC, this is easy. If we were to hold calls, I
would suggest google hangouts or something similar.
Thomas
PS: I do realise this is contrary to the meaning of the word "cabal".
Let's keep it anyway. It sounds better than "committee".
11 years, 5 months
Publicity Cabal Agenda items?
by Justin Clift
Hi all,
Looking for Agenda items for the initial meeting of
the Publicity Cabal.
Obvious one:
+ Cabal membership. We have more volunteers for
membership than fits in the "5-7 people" range
initially proposed.
We'll need to figure out if that range is still
ok, and/or maybe do some kind of vote thing to
get to the final initial membership. :)
Items's I'd like to propose:
+ Some of the items from the old initial
Community Planning etherpad might be useful:
http://etherpad-aeolusproject.rhcloud.com/p/Community_Planning
Let's look over it quickly and see if there are
items there we want to take up.
+ A little while ago I created a concept event
browser project on GitHub, so people can easily
select events they're interested in attending
visually.
https://github.com/justinclift/EventsMap
Should we put time into making this actually
functional? (and if so, Node.js may not be the
right language. Ruby/Rails is the common skill
set we have after all.)
What other items should be on the Agenda?
Regards and best wishes,
Justin Clift
--
Aeolus Cloud Evangelist
http://www.aeolusproject.org
11 years, 5 months
Justin now in Brno, Czech Republic for 2-3 months
by Justin Clift
Hi all,
Just a FYI for anyone not aware.
I'm working from Brno, Czech Republic now. Arrived here just over
a week ago, and will be here for 2-3 months (most likely).
*Way better* timezone to be in for this team than Australia. :)
Regards and best wishes,
Justin Clift
--
Aeolus Cloud Evangelist
http://www.aeolusproject.org
11 years, 5 months
RFC: frontend realms, deployments, and instances api
by Richard Su
Hi,
On the wiki we have preliminary versions of the request and responses we
are looking to implement for frontend realms, deployments, and instances
api. I will highlight a few points that may generate some discussions.
1. For frontend realms, when specifying the xml respresentation, users
will map directly to provider realms and providers. On the backend we'll
put each mapping into a backend realm target. But from a user's
perspective they don't need to worry about how things are actually
modelled in the backend.
https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Realms_-_F...
2. Once created, most deployment fields become read-only. The only two
that can be changed are name and state. For state, we will display an
available_states field indicating the possible transitions from the
current state. Users can PUT the entire xml deployment representation.
Changes to read-only fields will be ignored if it is something trivial
like a create_at, or will result in an error message if say a change was
made to associate with a different pool.
https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Deployments
3. Instances is similar to deployments in that only name and state can
be changed on the instance has been created. There is one additional
available_states called reboot. Putting an instance into the reboot
state will queue the reboot. From what I have gathered reboots happens
entirely on the cloud provider. From conductor's perspective the state
doesn't change and stays as running. The history will indicate that a
reboot had been queued at a particular time.
https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Instances
- Richard
11 years, 5 months
RuPy conference in Brno this Friday/weekend
by Hugh O. Brock
This weekend's RuPy conference in Brno strikes me as a great way for the
publicity cabal to get itself organized. If at all possible you guys
should meet today or tomorrow and plan out what we want to do there.
It might also be good, if we're going to be doing promotion, for the
website cabal to get the website front page up to date...
--Hugh
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
== http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey
11 years, 5 months
RESTful API Resources
by Martyn Taylor
Gentlemen,
As promised in yesterdays session, here is the REST guide written by
Geert Jansen. I've found this particularly useful it's well worth a read:
https://restful-api-design.readthedocs.org/en/latest/
Also worth looking over is the HTTP specification: Since our API is REST
over HTTP (which means sticking to the letter of the law of HTTP).
Lastly, It's well worth taking a look at Roy Fielding thesis chapter
where he outlines REST. I don't have a link but should be easily
"googlable".
Cheers
Martyn
11 years, 5 months
Concept/idea - proactive state change notification from oVirt/RHEV
by Justin Clift
Just as an idea, oVirt/RHEV has hooks available that can be called
when instance states change (and for various other events).
Nicely, these hooks can be written in any language. (Python hooks
are definitely around)
So, how about the idea of us creating hooks which get installed on
oVirt/RHEV hosts, and proactively notify us (or deltacloud) when
instances change state. So, we don't need to do polling.
Obviously it would have to be an optional approach, as it's an
intrusive measure for these hosts. But it should allow for low
latency state change notification and better scalability, for
these places that need it.
Other provider types (ie vSphere?) might also have hooks too
(unsure).
Interesting idea?
+ Justin
--
Aeolus Community Manager
http://www.aeolusproject.org
11 years, 5 months