On 11/08/2011 08:13 AM, Dan Wendlandt wrote:
On Tue, Nov 8, 2011 at 1:55 AM, Thierry Carrez thie...@openstack.org
mailto:thie...@openstack.org wrote:
There are two ways of doing this.
1. You can include the client code in the main core project, and produce
two tarballs
+1
On Nov 7, 2011, at 10:53 AM, Monty Taylor mord...@inaugust.com wrote:
Dealing with the client libraries has become a little bit of a tricky
subject, which is both lacking consistency and direction - but is kind
of essential to the project. (a service without a client library isn't
The dashboard (project Horizon) depends on these today to interact with the
REST API's to provide a user interface today.
-joe
On Nov 7, 2011, at 1:25 PM, Caitlin Bestler wrote:
Monty Taylor wrote:
OpenStack projects that need to depend on these will reference the git repo
of the project
Joeseph Heck wrote:
The dashboard (project Horizon) depends on these today to interact with the
REST API's to provide a user interface today.
That one wouldn't be a problem.
What would be a problem is if one of the referenced projecs, say swift, tried
to use python-daskboard-client.
So
Because it should be keystone's responsibility to test it's constant stream
of API changes, and abstract that away from it's consumers.
On Mon, Nov 7, 2011 at 3:25 PM, Caitlin Bestler caitlin.best...@nexenta.com
wrote:
Monty Taylor wrote:
OpenStack projects that need to depend on these will
On Tue, Nov 8, 2011 at 1:55 AM, Thierry Carrez thie...@openstack.orgwrote:
There are two ways of doing this.
1. You can include the client code in the main core project, and produce
two tarballs from it (one project, two release deliverables) much like
what we'll need to do for Horizon
John Dickinson wrote:
On Nov 8, 2011, at 10:54 AM, Thierry Carrez wrote:
With solution (2), if you look at the issue from Gerrit, GitHub,
Launchpad or Jenkins, those will be separate projects though. The fact
that they share the same PTL is not enough to make them one. For
example, they
On 11/08/2011 09:03 AM, John Dickinson wrote:
On Nov 8, 2011, at 10:54 AM, Thierry Carrez wrote:
With solution (2), if you look at the issue from Gerrit, GitHub,
Launchpad or Jenkins, those will be separate projects though. The
fact that they share the same PTL is not enough to make
Dealing with the client libraries has become a little bit of a tricky
subject, which is both lacking consistency and direction - but is kind
of essential to the project. (a service without a client library isn't
nearly as useful) At UDS this past week, Joe Heck, Jim Blair and I sat
down for a
In general, I support the idea of good, supported client libraries. I have a
few questions about this particular proposal.
1) Would a distinct python client (and the associated project) be required for
each core openstack project that exposes an API?
2) Why does the PPB need to vote? Actually,
+1
On Nov 7, 2011, at 10:53 AM, Monty Taylor mord...@inaugust.com wrote:
Dealing with the client libraries has become a little bit of a tricky
subject, which is both lacking consistency and direction - but is kind
of essential to the project. (a service without a client library isn't
Thanks for the summary on this topic, Monty. Comments inline
On Mon, 2011-11-07 at 10:53 -0800, Monty Taylor wrote:
Dealing with the client libraries has become a little bit of a tricky
subject, which is both lacking consistency and direction - but is kind
of essential to the project. (a
Monty Taylor wrote:
OpenStack projects that need to depend on these will reference the git repo
of the project in their
tools/pip-requires file. This should take care of depends for developers.
Normal installation depends
can be taken care of by distro packagers as usual.
Why would an
The dashboard (project Horizon) depends on these today to interact with the
REST API's to provide a user interface today.
-joe
On Nov 7, 2011, at 1:25 PM, Caitlin Bestler wrote:
Monty Taylor wrote:
OpenStack projects that need to depend on these will reference the git repo
of the project
On 11/07/2011 11:29 AM, John Dickinson wrote:
In general, I support the idea of good, supported client libraries. I
have a few questions about this particular proposal.
Good questions, as always. ...
1) Would a distinct python client (and the associated project) be
required for each core
Because it should be keystone's responsibility to test it's constant stream
of API changes, and abstract that away from it's consumers.
On Mon, Nov 7, 2011 at 3:25 PM, Caitlin Bestler caitlin.best...@nexenta.com
wrote:
Monty Taylor wrote:
OpenStack projects that need to depend on these will
On 11/07/2011 03:12 PM, John Dickinson wrote:
On Nov 7, 2011, at 4:23 PM, Monty Taylor wrote:
2) Why does the PPB need to vote? Actually, what would the PPB be
voting on (assuming the answer to #1 is no)?
Well, it would be effectively promoting several existing projects which
are
On Nov 7, 2011, at 4:23 PM, Monty Taylor wrote:
2) Why does the PPB need to vote? Actually, what would the PPB be
voting on (assuming the answer to #1 is no)?
Well, it would be effectively promoting several existing projects which
are managed in a few different places (rackspace, 4P, etc)
On Nov 7, 2011, at 4:23 PM, Monty Taylor wrote:
2) Why does the PPB need to vote? Actually, what would the PPB be
voting on (assuming the answer to #1 is no)?
Well, it would be effectively promoting several existing projects which
are managed in a few different places (rackspace, 4P, etc)
On 11/07/2011 03:12 PM, John Dickinson wrote:
On Nov 7, 2011, at 4:23 PM, Monty Taylor wrote:
2) Why does the PPB need to vote? Actually, what would the PPB be
voting on (assuming the answer to #1 is no)?
Well, it would be effectively promoting several existing projects which
are
20 matches
Mail list logo
