[PATCH configure 0/1] Use conductor api for provider creation
by John Eckersberg
Make sure if testing this that you are testing against conductor from
master. The versions currently present in f17 updates/updates-testing
are missing some functionality of the providers api; specifically,
creating a new provider will redirect to the provider html view. The
version in master will return a 200, with the xml body containing the
newly created provider. Configure validates this response body, so
the old version will not work.
11 years, 9 months
RFC: Sprint summary emails
by Matt Wagner
Hi folks,
As I return from PTO and try to catch up, I wanted to propose an idea.
I think it'd be swell if, at the beginning of each sprint, we sent out
an email outlining what we hope to accomplish, with a little blurb on
each story, a quick estimate, and who (if anyone yet) is taking it. It
could also spell out the start and end dates, as well as any other
notable dates (code freeze, etc.) It would help people like me get up to
speed more quickly, but much more importantly, I think it would be
interesting to people monitoring Aeolus development but not necessarily
participating full-time.
Picking a random example from the backlog that I'm semi-familiar with,
we have #3499, which reads "As a user, I want a consistent, coherent UI"
with no further explanation. There's been other discussion of this, so I
happen to know what it means, but it's ultra-vague as published in
Redmine. It seems like it would be quite helpful if it got a blurb in a
beginning-of-sprint email like:
-------%<----------
#3499 - As a user, I want a consistent, coherent UI
We've been gathering a list of UI annoyances on the wiki:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/List_of_UI_Ann...
For this story, we plan to review that list and identify the "quick
fixes" that don't require much discussion/consideration, and then
implement them. This should make the Aeolus user experience much more
satisfying.
Jiri has volunteered to lead this; it is estimated at 13 points.
-------%<----------
Admittedly, writing this up for each story is a decent bit of work.
However, it's really nothing but a quick summary of what we discuss on
sprint planning calls. I think this would have two benefits:
1.) It would be very useful as far as making it clear what we are doing,
especially to outsiders. (It would have an incidental benefit for people
like me, that miss a sprint planning call, but that's not the primary
goal.)
2.) It would force us start to write decent descriptions for our tasks.
If people agree that this is useful, I'd be happy to take a stab at
writing it up next sprint during/after the planning call. What do you
think? And should Conductor/Infra emails be separate, or combined?
-- Matt
11 years, 9 months
Announcing the Aeolus Project blog!
by Matt Wagner
Hi folks,
I'm happy to announce that we now have a project blog, at
http://blog.aeolusproject.org
We hope to use it to share not only project announcements, but to
routinely post interesting news that's related, and updates on sprint
progress, new features, etc.
We would love additional contributors as well! Just message me or
Justin Clift with your preferred username and we'll set you up with an
account! Developers, you're encouraged to post often about what you're
working on. Community members and users, feel free to request an account
and post about how you use Aeolus or whatnot.
Note that it's also possible for us to syndicate RSS feeds from other
sites, if you have an existing blog and a category for Aeolus-related
content.
Check it out today! http://blog.aeolusproject.org
-- Matt
11 years, 9 months
Using pull requests on Aeolus
by Matt Wagner
Hi folks,
Don't throw any tomatoes just yet! We've been going back and forth about
using pull requests on GitHub for a long time. I'd like to propose that
we slowly try an experiment. We've had a few outside contributions come
in through pull requests, and it's worked just fine. At the same time,
there are people who are more comfortable with sending patches to the
list. So, even though it seems like it would be nice to have everyone
work the same way, it seems like the two options aren't mutually
exclusive.
I'm proposing that we allow people who want to use pull requests to try
it out. Send pull requests, and other people who want to try pull
requests can review them. If you don't like pull requests, don't use
them, and someone will review and push like we do today. If you're on
the fence, you can try it out, or not.
I don't love that this would cause us to split patch discussion across
two places, but I think it's worth it as an experiment. I think it will
help us iron out any kinks, and experiment with whether this is
something we want to go forward with. I don't think forcing everyone to
switch to pull requests (especially overnight) is a good idea, nor is
ignoring the subject because it's controversial. This gets things
moving, and I hope it will be like our Fedora vs. upstream gem thing,
where trying to support both ends up making us more robust, versus
needlessly distracting us.
I'd like to give this a try. Would anyone care to join me?
-- Matt
11 years, 9 months
Re: outline of pools api requests and responses
by Petr Blaho
On Tuesday, August 07, 2012 02:32:14 PM Martyn Taylor wrote:
On 08/07/2012 08:30 AM, Petr Blaho wrote:
On Monday, August 06, 2012 05:06:25 PM Richard Su wrote:
On 08/06/2012 07:59 AM, Dave Johnson wrote:
On Mon, 2012-08-06 at 09:44 -0400, Michael Orazi wrote:
----- Original Message -----
Hi Dave,
I started a wiki page here:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Pools
This is a rough outline. One of the things I'm wondering about is
whether the request data should be in xml or be in http parameters.
It
feels to me parameters may be easier to work with as you are
essentially
stuffing them into an array. It's not clear to me if there is a
rails
standard for xml or parameters. AWS uses parameters whereas RHEV REST
API uses xml.
Do you see an advantage of using one or the other? In the outline I
have
the requests written to use xml.
Thanks,
Richard
Adding Martyn & Jay to the cc list as they may have some insight into the broader RESTful api discussion/rails best practices, etc.
m
Hey Richard,
This is a great start for the story and I thank you for taking the time
to document this up front. The only "advantage" I can think of is
consistency with the provider/account api. It is using xml. And
correct me if I am wrong but I believe the image build/push calls do as
well?
-Dave
Being consistent is good. Right now, I don't think provider/account api
is xml based though. Supporting xml adds some overhead. The client has
to generate xml and the controller has to parse it. Posting query
parameters require fewer changes to existing controller logic.
Right now provider/account API uses XML.
There is really no overhead i controllers w/r/t amount of code written.
Just use --header "Content-Type: application/xml" in curl and rails translates
nodes and attributes to params hash.
This --header should be used whenever posting XML to rails app.
For pools. I think I'll set it up to do both. And then people can review
and weigh in on which way to go.
If there is no differencies in how parameters are nested (XML vs parameters)
theese can be both available at the same time with almost no effort.
This applies to request data. Adding support for these in response data too is a little trickier. For the reasons I posted on the list a while back on why we use templates.
adding Petr to the discussion.
- Richard
I just started wiki pages for Provider and Providr Accounts API - https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Providers , https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Provider_Accounts
Hey Richard. Great start on this. I've a couple of comments below in on form-data and your current doc.
I would avoid using x-ww-form-urlencoded for representing resources. XML and JSON allow you to create structured documents in a standard way. Trying to add things like nested resources using key/value pairs is difficult and would require us to create our own way of handling such things. This would mean that clients would also need to written specifically for our API. XML and JSON have a ton of support for marshalling and unmarshalling objects in plenty of languages. Representations in these are also much more readible than an enocded string these two alsooffer some form of typing for example, arrays. Since we already support XML in a number of areas of Conductor API and in the CLI. We should stick with this for the time being then maybe introduce JSON support later.
Also I noticed a few things with your documentation.
Why are you using url attribute. We use href (stolen from html spec) to point to resource locations in other parts of the API: see the original API doc I wrote a while back: https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Conductor_API
I'm not sure if rails requires it. But you should set the content-type header when sending data. In theory you could send XML and ask for JSON.
We should be using PUT verb for updates. The documentation says you are using POST. See spec: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
There is a mistake in some of the XML. The enabled element is not closed properly.
<pool id="1" url="https://localhost/conductor/api/pools/1">
<name>pool1name</name>
<pool_family id="1" url="https://localhost/conductor/api/pool_families/1">pool family 1 name</pool_family>
<quota></quota>
<enabled>true</name>
<deployments></deployments>
</pool>
Thanks
Martyn
Just CCed aeolus-devel list. I think this is quite interesting for all developers there.
--
With regards
Petr Blaho
11 years, 9 months
Bundler, aeolus-image gem from rubygems.org
by Jiří Stránský
Hi,
right now the latest aeolus-image gem on rubygems.org is 0.4, which is a
bit out of date and doesn't work fully with current Conductor from
master. This forced me to abandon "the Bundler way" and develop with
system gems.
I want to ask -- should/will we support Bundler development environment
setup?
I know our primary focus is compatibility with packaged gems, but I
think Bundler is nice for quick tinkering with dependencies without
actually touching system setup and might come in handy in some
situations. What do you guys think?
Best wishes,
Jirka
11 years, 9 months
Sprint Dates and Repo Freeze (changes for this sprint)
by steve linabery
Hi,
To hook in QE earlier in the sprint cycle, we will have an earlier code/repo freeze than in recent sprints.
Repo freeze is Wednesday, 15-August. That is several days earlier than our usual cut-off. So, be aware.
Demos will be the following Wednesday.
Thanks!
Steve Linabery
Software Engineer, Red Hat, Inc.
11 years, 9 months