On 17 Jan 2014, at 22:00, Jamie Lennox jamielen...@redhat.com wrote:
(I don't buy the problem with large amounts of dependencies, if you have a
meta-package you just have one line in requirements and pip will figure the
rest out.)
+1
Renat Akhmerov
@ Mirantis Inc.
On 17 Jan 2014, at 22:06, Robert Collins robe...@robertcollins.net wrote:
On 17 January 2014 09:22, Renat Akhmerov rakhme...@mirantis.com wrote:
Since it’s pretty easy to get lost among all the opinions I’d like to
clarify/ask a couple of things:
Keeping all the clients physically
On Jan 21, 2014, at 10:54 AM, Renat Akhmerov
rakhme...@mirantis.commailto:rakhme...@mirantis.com wrote:
On 17 Jan 2014, at 22:00, Jamie Lennox
jamielen...@redhat.commailto:jamielen...@redhat.com wrote:
(I don't buy the problem with large amounts of dependencies, if you have a
meta-package
On 18 Jan 2014, at 07:48, Sean Dague s...@dague.net wrote:
I also think auto generated clients have a lot of challenges in the same
way that full javascript pages in browsers have. If you screw up in a
subtle way you can just completely disable your clients from connecting
to your server
On 01/21/2014 11:54 AM, Renat Akhmerov wrote:
On 17 Jan 2014, at 22:00, Jamie Lennox jamielen...@redhat.com
mailto:jamielen...@redhat.com wrote:
(I don't buy the problem with large amounts of dependencies, if you
have a meta-package you just have one line in requirements and pip
will
Hello,
I would like to end this requirements talk cause it doesn't make any sense
in term of python clients.
Initially the discussion was about many clients projects with separate
requirements VS single client project with single requirements list.
At that moment we should have stop and actually
I would like to propose to use this thread to gather and discuss software
requirements that our clients should meet.
Later we'll summarize all the requirements and use them during our work of
improving the clients.
By reaching listed requirements we'll be able to evaluate the success of
our
On Jan 21, 2014, at 12:19 PM, Alexei Kornienko
alexei.kornie...@gmail.commailto:alexei.kornie...@gmail.com wrote:
Hello,
I would like to end this requirements talk cause it doesn't make any sense in
term of python clients.
Initially the discussion was about many clients projects with separate
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Wednesday, 22 January, 2014 4:35:39 AM
Subject: Re: [openstack-dev] a common client library
I would like to propose to use this thread to gather and discuss software
requirements that our
It is when most openstack clouds don’t just run keystone. Or nova, or
swift. Or when each client acts, smells and behaves differently. It matters
a LOT when you’re trying to write applications on top of a mature openstack
deployment.
I still don't understand the problem here. Installed packages
On Jan 21, 2014, at 12:59 PM, Alexei Kornienko
alexei.kornie...@gmail.commailto:alexei.kornie...@gmail.com wrote:
It is when most openstack clouds don’t just run keystone. Or nova, or swift.
Or when each client acts, smells and behaves differently. It matters a LOT
when you’re trying to write
On 21 Jan 2014, at 09:07, Jesse Noller jesse.nol...@rackspace.com wrote:
Do you use any other platform than Linux? Even donald - one of the python
packaging leads and PyPI leads said this is a bad end-user experience for
consumers of openstack clouds.
That fact that someone (even very
On 21 Jan 2014, at 09:40, Sean Dague s...@dague.net wrote:
On 01/21/2014 11:54 AM, Renat Akhmerov wrote:
On 17 Jan 2014, at 22:00, Jamie Lennox jamielen...@redhat.com
mailto:jamielen...@redhat.com wrote:
(I don't buy the problem with large amounts of dependencies, if you
have a
+1 for opening new threads regarding specific questions.
On 21 Jan 2014, at 11:54, Renat Akhmerov rakhme...@mirantis.com wrote:
On 21 Jan 2014, at 09:40, Sean Dague s...@dague.net wrote:
On 01/21/2014 11:54 AM, Renat Akhmerov wrote:
On 17 Jan 2014, at 22:00, Jamie Lennox
On 01/19/2014 11:50 PM, Jesse Noller wrote:
On Jan 19, 2014, at 5:37 PM, Jamie Lennox jamielen...@redhat.com
mailto:jamielen...@redhat.com wrote:
On Sat, 2014-01-18 at 09:13 -0500, Doug Hellmann wrote:
I like the idea of a fresh start, but I don't think that's
incompatible with the other
To: OpenStack Development Mailing List (not for usage
questions) openstack-dev@lists.openstack.org
Sent: Saturday, 18 January, 2014 4:00:58 AM
Subject: Re: [openstack-dev] a common client library
On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft
)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Sent: Saturday, 18 January, 2014 4:00:58 AM
Subject: Re: [openstack-dev] a common client library
On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft
don...@stufft.iomailto:don...@stufft.io wrote:
On Jan 16, 2014
To: OpenStack Development Mailing List (not for usage questions)
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] a common client library
On Jan 16, 2014, at 4:59 PM, Renat Akhmerov rakhme...@mirantis.com
mailto:rakhme...@mirantis.com wrote:
On 16 Jan 2014
- Original Message -
From: Jonathan LaCour jonathan-li...@cleverdevil.org
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Saturday, 18 January, 2014 4:00:58 AM
Subject: Re: [openstack-dev] a common client library
On Thu, Jan 16
:58 AM
Subject: Re: [openstack-dev] a common client library
On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft
don...@stufft.iomailto:don...@stufft.io wrote:
On Jan 16, 2014, at 4:06 PM, Jesse Noller
jesse.nol...@rackspace.commailto:jesse.nol...@rackspace.com
wrote:
On Jan 16
jonathan-li...@cleverdevil.org
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Saturday, 18 January, 2014 4:00:58 AM
Subject: Re: [openstack-dev] a common client library
On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft don...@stufft.io
On 01/18/2014 01:06 AM, Robert Collins wrote:
On 17 January 2014 09:22, Renat Akhmerov rakhme...@mirantis.com wrote:
Since it’s pretty easy to get lost among all the opinions I’d like to
clarify/ask a couple of things:
Keeping all the clients physically separate/combining them in to a single
On Jan 18, 2014, at 12:58 AM, Robert Collins robe...@robertcollins.net wrote:
Out of interest - whats the overhead of running tls compression
against compressed data? Is it really noticable?
The overhead doesn’t really matter much as you want TLS
Compression disabled because of CRIME anyways.
On Jan 18, 2014, at 9:58 AM, Jesse Noller jesse.nol...@rackspace.com wrote:
On Jan 18, 2014, at 12:00 AM, Jamie Lennox jamielen...@redhat.com wrote:
I can't see any reason that all of these situations can't be met.
We can finally take the openstack pypi namespace, move keystoneclient -
On 19 January 2014 04:48, Sean Dague s...@dague.net wrote:
On 01/18/2014 01:06 AM, Robert Collins wrote:
Launchpadlib which builds on wadllib did *exactly* that. It worked
fairly well with the one caveat that it fell into the ORM trap - just
in time lookups for everything with crippling
Keeping them separate is awesome for *us* but really, really, really
sucks for users trying to use the system.
I agree. Keeping them separate trades user usability for developer
usability, I think user usability is a better thing to strive for.
I don't understand how multiple independent
It seems we have two target audiences here. Developers who work on
OpenStack and developers who write apps to use it. In the long run I think
we need to optimize for both of these groups.
If we want developers to write applications to use OpenStack in python we
likely need a common python SDK.
On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft don...@stufft.io wrote:
On Jan 16, 2014, at 4:06 PM, Jesse Noller jesse.nol...@rackspace.com
wrote:
On Jan 16, 2014, at 2:22 PM, Renat Akhmerov rakhme...@mirantis.com
wrote:
Since it’s pretty easy to get lost among all the opinions I’d like
On Thu, Jan 16, 2014 at 5:42 PM, Jesse Noller jesse.nol...@rackspace.comwrote:
On Jan 16, 2014, at 4:59 PM, Renat Akhmerov rakhme...@mirantis.com
wrote:
On 16 Jan 2014, at 13:06, Jesse Noller jesse.nol...@rackspace.com
wrote:
Since it’s pretty easy to get lost among all the opinions
On 17 Jan 2014, at 10:04, Jonathan LaCour jonathan-li...@cleverdevil.org
wrote:
pip install openstack
That would be awesome :)
Renat Akhmerov
@ Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
From: Jesse Noller [jesse.nol...@rackspace.com]
Sent: Thursday, January 16, 2014 5:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] a common client library
On 17 January 2014 06:39, Mark Washenberger
mark.washenber...@markwash.net wrote:
There's a few more items here that are needed for glance to be able to work
with requests (which we really really want).
1) Support for 100-expect-continue is probably going to be required in
glance as well as
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Saturday, 18 January, 2014 4:00:58 AM
Subject: Re: [openstack-dev] a common client library
On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft don...@stufft.io wrote:
On Jan 16, 2014
On 17 January 2014 06:57, Mark Washenberger
mark.washenber...@markwash.net wrote:
Just throwing this out there because it seems relevant to client design.
As we've been looking at porting clients to using v2 of the Images API, its
seems more and more to me that including the *server* version
On 17 January 2014 08:03, Alexei Kornienko alexei.kornie...@gmail.com wrote:
Hello Joe,
2)Another option would be to follow waterfall process and create a solid
library interface before including it to all client projects. However such
approach this period can take unknown amount of time and
On 17 January 2014 09:22, Renat Akhmerov rakhme...@mirantis.com wrote:
Since it’s pretty easy to get lost among all the opinions I’d like to
clarify/ask a couple of things:
Keeping all the clients physically separate/combining them in to a single
library. Two things here:
In case of
On 15/01/14 21:35 +, Jesse Noller wrote:
On Jan 15, 2014, at 1:37 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote:
Several people have mentioned to me that they are interested in, or actively working on,
code related to a common client library -- something meant to be reused
Hi
Once a common library is in place, is there any intention to (or resistance
against) collapsing the clients into a single project or even a single command
(a la busybox)?
(I'm thinking reduced load for packagers, simpler installation for users, etc)
Cheers,
--
Chris Jones
On 15 Jan 2014,
On Jan 16, 2014, at 2:09 AM, Flavio Percoco fla...@redhat.com wrote:
On 15/01/14 21:35 +, Jesse Noller wrote:
On Jan 15, 2014, at 1:37 PM, Doug Hellmann doug.hellm...@dreamhost.com
wrote:
Several people have mentioned to me that they are interested in, or
actively working on,
On Jan 16, 2014, at 5:42 AM, Chris Jones
c...@tenshu.netmailto:c...@tenshu.net wrote:
Hi
Once a common library is in place, is there any intention to (or resistance
against) collapsing the clients into a single project or even a single command
(a la busybox)?
(I'm thinking reduced load for
On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones c...@tenshu.net wrote:
Once a common library is in place, is there any intention to (or
resistance against) collapsing the clients into a single project or even a
single command (a la busybox)?
that's what openstackclient is here for
On Jan 16, 2014, at 5:53 AM, Chmouel Boudjnah
chmo...@enovance.commailto:chmo...@enovance.com wrote:
On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones
c...@tenshu.netmailto:c...@tenshu.net wrote:
Once a common library is in place, is there any intention to (or resistance
against) collapsing the
On Jan 16, 2014, at 9:07 AM, Joe Gordon
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:
On Thu, Jan 16, 2014 at 9:45 AM, Jesse Noller
jesse.nol...@rackspace.commailto:jesse.nol...@rackspace.com wrote:
On Jan 16, 2014, at 5:53 AM, Chmouel Boudjnah
On Jan 16, 2014, at 9:26 AM, Justin Hammond
justin.hamm...@rackspace.commailto:justin.hamm...@rackspace.com wrote:
I'm not sure if it was said, but which httplib using being used (urllib3
maybe?). Also I noticed many people were talking about supporting auth
properly, but are there any
On 01/16/2014 05:25 PM, Jesse Noller wrote:
On Jan 16, 2014, at 9:07 AM, Joe Gordon joe.gord...@gmail.com
mailto:joe.gord...@gmail.com wrote:
On Thu, Jan 16, 2014 at 9:45 AM, Jesse Noller
jesse.nol...@rackspace.com mailto:jesse.nol...@rackspace.com wrote:
On Jan 16, 2014, at 5:53
On Thu, 2014-01-16 at 09:03 +0100, Flavio Percoco wrote:
On 15/01/14 21:35 +, Jesse Noller wrote:
On Jan 15, 2014, at 1:37 PM, Doug Hellmann doug.hellm...@dreamhost.com
wrote:
Several people have mentioned to me that they are interested in, or
actively working on, code related to
On Thu, Jan 16, 2014 at 4:37 PM, Jesse Noller jesse.nol...@rackspace.comwrote:
Can you detail out noauth for me; and I would say the defacto httplib in
python today is python-requests - urllib3 is also good but I would say from
a *consumer* standpoint requests offers more in terms of usability
On Thu, Jan 16, 2014 at 9:37 AM, Jesse Noller jesse.nol...@rackspace.comwrote:
On Jan 16, 2014, at 9:26 AM, Justin Hammond justin.hamm...@rackspace.com
wrote:
I'm not sure if it was said, but which httplib using being used (urllib3
maybe?). Also I noticed many people were talking about
I'm not sure if it was said, but which httplib using being used (urllib3
maybe?). Also I noticed many people were talking about supporting auth
properly, but are there any intentions to properly support 'noauth'
(python-neutronclient, for instance, doesn't support it properly as of
this writing)?
On Thu, Jan 16, 2014 at 8:45 AM, Jesse Noller jesse.nol...@rackspace.comwrote:
After speaking with people working on OSC and looking at the code base in
depth; I don’t think this addresses what Chris is implying: OSC wraps the
individual CLIs built by each project today, instead of the
On Wed, Jan 15, 2014 at 4:35 PM, Jesse Noller jesse.nol...@rackspace.comwrote:
On Jan 15, 2014, at 1:37 PM, Doug Hellmann doug.hellm...@dreamhost.com
wrote:
Several people have mentioned to me that they are interested in, or
actively working on, code related to a common client library --
On Jan 16, 2014, at 9:54 AM, Alexei Kornienko
alexei.kornie...@gmail.commailto:alexei.kornie...@gmail.com wrote:
On 01/16/2014 05:25 PM, Jesse Noller wrote:
On Jan 16, 2014, at 9:07 AM, Joe Gordon
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:
On Thu, Jan 16, 2014 at 9:45 AM,
My prioritization of noauth is rooted in the fact that we're finding that
the current pattern of hitting auth to validate a token is not scaling
well. Out current solution to this scale issue is:
- use noauth when possible between the services
- use normal auth for public services
- provide a
On Thu, Jan 16, 2014 at 9:54 AM, Alexei Kornienko
alexei.kornie...@gmail.com wrote:
Knowing usual openstack workflow I'm afraid that #1,#2 with a waterfall
approach may take years to be complete.
And after they'll be approved it will become clear that this architecture
is already outdated.
On Thu, 2014-01-16 at 10:06 -0600, Dean Troyer wrote:
On Thu, Jan 16, 2014 at 9:37 AM, Jesse Noller
jesse.nol...@rackspace.com wrote:
On Jan 16, 2014, at 9:26 AM, Justin Hammond
justin.hamm...@rackspace.com wrote:
I'm not sure if it was said, but which httplib using
On Thu, Jan 16, 2014 at 5:23 PM, Jay Pipes jaypi...@gmail.com wrote:
Right, but requests supports chunked-transfer encoding properly, so
really there's no reason those clients could not move to a
requests-based codebase.
We had that discussion for swiftclient and we are not against it but
On Thu, Jan 16, 2014 at 10:25 AM, Jesse Noller
jesse.nol...@rackspace.comwrote:
On Jan 16, 2014, at 9:07 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Thu, Jan 16, 2014 at 9:45 AM, Jesse Noller
jesse.nol...@rackspace.comwrote:
On Jan 16, 2014, at 5:53 AM, Chmouel Boudjnah
On 01/16/2014 06:15 PM, Jesse Noller wrote:
On Jan 16, 2014, at 9:54 AM, Alexei Kornienko
alexei.kornie...@gmail.com mailto:alexei.kornie...@gmail.com wrote:
On 01/16/2014 05:25 PM, Jesse Noller wrote:
On Jan 16, 2014, at 9:07 AM, Joe Gordon joe.gord...@gmail.com
On Thu, Jan 16, 2014 at 10:23 AM, Jay Pipes jaypi...@gmail.com wrote:
Right, but requests supports chunked-transfer encoding properly, so
really there's no reason those clients could not move to a
requests-based codebase.
Absolutely...it was totally me chickening out at the time why they
On Thu, Jan 16, 2014 at 8:06 AM, Dean Troyer dtro...@gmail.com wrote:
On Thu, Jan 16, 2014 at 9:37 AM, Jesse Noller
jesse.nol...@rackspace.comwrote:
On Jan 16, 2014, at 9:26 AM, Justin Hammond justin.hamm...@rackspace.com
wrote:
I'm not sure if it was said, but which httplib using being
On Wed, Jan 15, 2014 at 7:53 PM, Alexei Kornienko
alexei.kornie...@gmail.com wrote:
I did notice, however, that neutronclient is
conspicuously absent from the Work Items in the blueprint's Whiteboard.
It will surely be added later. We already working on several things in
parallel and we will
On Thu, Jan 16, 2014 at 12:03 AM, Flavio Percoco fla...@redhat.com wrote:
On 15/01/14 21:35 +, Jesse Noller wrote:
On Jan 15, 2014, at 1:37 PM, Doug Hellmann doug.hellm...@dreamhost.com
wrote:
Several people have mentioned to me that they are interested in, or
actively working on,
On Thu, Jan 16, 2014 at 12:07 PM, Alexei Kornienko
alexei.kornie...@gmail.com wrote:
On 01/16/2014 06:15 PM, Jesse Noller wrote:
On Jan 16, 2014, at 9:54 AM, Alexei Kornienko alexei.kornie...@gmail.com
wrote:
On 01/16/2014 05:25 PM, Jesse Noller wrote:
On Jan 16, 2014, at 9:07 AM,
On Jan 16, 2014, at 11:39 AM, Mark Washenberger
mark.washenber...@markwash.netmailto:mark.washenber...@markwash.net wrote:
On Thu, Jan 16, 2014 at 8:06 AM, Dean Troyer
dtro...@gmail.commailto:dtro...@gmail.com wrote:
On Thu, Jan 16, 2014 at 9:37 AM, Jesse Noller
Hello Joe,
continuous refactoring and syncing across 22+ repositories sounds like
a nightmare, one that I would like to avoid.
You are right this is not easy.
However I have several reasons to do that:
The hardest part is to bring basic stuff in sync across all projects
(That's what we are
On Thu, Jan 16, 2014 at 2:03 PM, Alexei Kornienko
alexei.kornie...@gmail.com wrote:
Hello Joe,
continuous refactoring and syncing across 22+ repositories sounds like a
nightmare, one that I would like to avoid.
You are right this is not easy.
However I have several reasons to do that:
On Jan 16, 2014, at 2:36 PM, Joe Gordon joe.gord...@gmail.com wrote:
2) major overhaul of client libraries so they are all based off a common base
library. This would cover namespace changes, and possible a push to move CLI
into python-openstackclient
This seems like the biggest win to
: [openstack-dev] a common client library
Hello Joe,
continuous refactoring and syncing across 22+ repositories sounds like a
nightmare, one that I would like to avoid.
You are right this is not easy.
However I have several reasons to do that:
The hardest part is to bring basic stuff in sync
On Thu, Jan 16, 2014 at 8:40 PM, Donald Stufft don...@stufft.io wrote:
On Jan 16, 2014, at 2:36 PM, Joe Gordon joe.gord...@gmail.com wrote:
2) major overhaul of client libraries so they are all based off a common
base library. This would cover namespace changes, and possible a push to
move
Since it’s pretty easy to get lost among all the opinions I’d like to
clarify/ask a couple of things:
Keeping all the clients physically separate/combining them in to a single
library. Two things here:
In case of combining them, what exact project are we considering? If this list
is limited to
On Thu, Jan 16, 2014 at 2:22 PM, Renat Akhmerov rakhme...@mirantis.comwrote:
- Keeping all the clients physically separate/combining them in to a
single library. Two things here:
- In case of combining them, what exact project are we considering?
If this list is limited to
On Jan 16, 2014, at 4:06 PM, Jesse Noller jesse.nol...@rackspace.com wrote:
On Jan 16, 2014, at 2:22 PM, Renat Akhmerov rakhme...@mirantis.com wrote:
Since it’s pretty easy to get lost among all the opinions I’d like to
clarify/ask a couple of things:
Keeping all the clients
On Jan 16, 2014, at 3:22 PM, Renat Akhmerov rakhme...@mirantis.com wrote:
Has anyone ever considered an idea of generating a fully functional REST
client automatically based on an API specification (WADL could be used for
that)? Not sure how convenient it would be, it really depends on a
On 16 Jan 2014, at 12:36, Dean Troyer dtro...@gmail.com wrote:
I've already written a POC for solum and some other things to demonstrate how
to add additional projects simply by installing the python-*client package.
https://github.com/dtroyer/python-oscplugin is a trivial example.
On 16 Jan 2014, at 13:06, Jesse Noller jesse.nol...@rackspace.com wrote:
Since it’s pretty easy to get lost among all the opinions I’d like to
clarify/ask a couple of things:
Keeping all the clients physically separate/combining them in to a single
library. Two things here:
In case of
On Jan 16, 2014, at 4:59 PM, Renat Akhmerov
rakhme...@mirantis.commailto:rakhme...@mirantis.com wrote:
On 16 Jan 2014, at 13:06, Jesse Noller
jesse.nol...@rackspace.commailto:jesse.nol...@rackspace.com wrote:
Since it’s pretty easy to get lost among all the opinions I’d like to
clarify/ask
On Jan 16, 2014, at 8:42 PM, Jesse Noller jesse.nol...@rackspace.com wrote:
On Jan 16, 2014, at 4:59 PM, Renat Akhmerov rakhme...@mirantis.com wrote:
On 16 Jan 2014, at 13:06, Jesse Noller jesse.nol...@rackspace.com wrote:
Since it’s pretty easy to get lost among all the opinions I’d
Ok, I think most of the reasoning you’ve said makes sense. So for a
non-incubated project we’re going to have separate clients and then get them
integrated into this single client once the project itself gets incubated? Or
it’s going to happen when the project gets integrated into core os
On Jan 16, 2014, at 8:36 PM, Renat Akhmerov
rakhme...@mirantis.commailto:rakhme...@mirantis.com wrote:
Ok, I think most of the reasoning you’ve said makes sense. So for a
non-incubated project we’re going to have separate clients and then get them
integrated into this single client once the
On Jan 15, 2014, at 1:37 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote:
Several people have mentioned to me that they are interested in, or actively
working on, code related to a common client library -- something meant to
be reused directly as a basis for creating a common library
Hi Doug,
Count me in. Climate is currently working on delivering its first
python-climateclient but it would be great if we could leverage any olso
lib for this.
-Sylvain
2014/1/15 Doug Hellmann doug.hellm...@dreamhost.com
Several people have mentioned to me that they are interested in, or
On Wed, Jan 15, 2014 at 1:37 PM, Doug Hellmann
doug.hellm...@dreamhost.comwrote:
Several people have mentioned to me that they are interested in, or
actively working on, code related to a common client library -- something
meant to be reused directly as a basis for creating a common library
Great idea, fully support it. We’re interested in that too. One specific thing
that was mentioned is the ability to mock auth service seems to be very useful
for some test scenarios, we came across that recently.
Renat Akhmerov
@ Mirantis Inc.
On 15 Jan 2014, at 14:07, Sylvain Bauza
On Jan 15, 2014, at 4:55 PM, Renat Akhmerov
rakhme...@mirantis.commailto:rakhme...@mirantis.com wrote:
Great idea, fully support it. We’re interested in that too. One specific thing
that was mentioned is the ability to mock auth service seems to be very useful
for some test scenarios, we
On Wed, Jan 15, 2014 at 5:39 PM, Dean Troyer dtro...@gmail.com wrote:
On Wed, Jan 15, 2014 at 1:37 PM, Doug Hellmann
doug.hellm...@dreamhost.com wrote:
Several people have mentioned to me that they are interested in, or
actively working on, code related to a common client library --
Doug Hellmann doug.hellm...@dreamhost.com writes:
Several people have mentioned to me that they are interested in, or
actively working on, code related to a common client library -- something
meant to be reused directly as a basis for creating a common library for
all of the openstack clients
I did notice, however, that neutronclient is
conspicuously absent from the Work Items in the blueprint's Whiteboard.
It will surely be added later. We already working on several things in
parallel and we will add neutronclient soon.
I would love to see a bit more detail on the structure of the
On Jan 15, 2014, at 6:16 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote:
On Wed, Jan 15, 2014 at 5:39 PM, Dean Troyer dtro...@gmail.com wrote:
On Wed, Jan 15, 2014 at 1:37 PM, Doug Hellmann doug.hellm...@dreamhost.com
wrote:
Several people have mentioned to me that they are
88 matches
Mail list logo
