I don't currently know of a one size fits all solution here. There was talk at
the summit of having the cinder app respond to a SIGHUP signal and attempting
to reload config on this signal. Dynamic reloading is tricky business
(basically u need to unravel anything holding references to the old c
Is there a bug/bp tracking the overall cinder unit tests move from mox to
mock? Is this targeted to complete in IceHouse?
Thanks,
Subbu
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/o
On Thu, 2013-12-12 at 16:23 +, Justin Hammond wrote:
> I am a developer who is currently having troubles keeping up with the
> mailing list due to volume, and my inability to organize it in my client.
> I am nearly forced to use Outlook 2011 for Mac and I have read and
> attempted to implement
On 2013-12-13 23:43:09 +0800 (+0800), Maru Newby wrote:
> As per Anita's email, we're not to approve anything until the
> following tox fix merges: https://review.openstack.org/#/c/60825
[...]
Merged at 07:58 UTC today. Also, the gate is basically empty, so
those other changes will merge rather q
Hi Ronan,
Best advice I would give is start with the base driver class (
cinder.volume.driver.py) and the reference LVM driver (cinder
.volume.drivers.lvm.py). Those will give you a template of the interfaces,
args needed and return values.
Also jump in IRC at #openstack-cinder and we can chat mo
On Tuesday, December 10, 2013 2:59:19 AM, Ronen Angluster wrote:
Hello all!
we're developing a new storage appliance and per one of our customers
would like
to build a cinder driver.
i kept digging into the documentation for the past 2 weeks and could not
find anything that described the code
On Sat, 2013-12-14 at 10:52 -0500, Tzu-Mainn Chen wrote:
> > On Wed, 2013-12-11 at 17:48 +0100, Jiří Stránský wrote:
> >
> > > >> When you say python- clients, is there a distinction between the CLI
> > > >> and
> > > >> a bindings library that invokes the server-side APIs? In other words,
> > >
Hi Christopher,
Thanks again for your answering. :)
The issue I mentioned before, has already committed to Gerrit.
So if you have time, please see here:
https://review.openstack.org/#/c/62163/
P.S. Is it a good idea if I ask the contributor to participate in reviewing?
Any help will be apprecia
On 12/13/2013 01:13 PM, Clint Byrum wrote:
Excerpts from Dmitry Mescheryakov's message of 2013-12-13 12:01:01 -0800:
Still, what about one more server process users will have to run? I see
unified agent as library which can be easily adopted by both exiting and
new OpenStack projects. The need t
Excerpts from Sylvain Bauza's message of 2013-12-14 06:23:48 -0800:
> 2013/12/9 Clint Byrum
>
> > Excerpts from Fox, Kevin M's message of 2013-12-09 09:34:06 -0800:
> > > I'm thinking more generic:
> > >
> > > The cloud provider will provide one or more "suballocating" images. The
> > one Triple
On Sat, 2013-12-14 at 19:09 +0400, Eugene Nikanorov wrote:
> Hi Jay,
>
> Sure, that is understood. In fact such refactoring could be a big
> change so I'd split it to two or more patches.
> Hope this will not overlap with ongoing neutron API tests development.
Hehe, given the sheer number of new
> On Wed, 2013-12-11 at 17:48 +0100, Jiří Stránský wrote:
>
> > >> When you say python- clients, is there a distinction between the CLI and
> > >> a bindings library that invokes the server-side APIs? In other words,
> > >> the CLI is packaged as CLI+bindings and the UI as GUI+bindings?
> >
> > p
On Thu, 2013-12-12 at 15:22 +0100, Hugh O. Brock wrote:
> On Thu, Dec 12, 2013 at 03:11:14PM +0100, Ladislav Smola wrote:
> > Agree with this.
> >
> > Though I am an optimist, I believe that this time, we can avoid
> > calling multiple services in one request that depend on each other.
> > About
On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh wrote:
>
> On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann <
> doug.hellm...@dreamhost.com> wrote:
>
>> That covers routes. What about the properties of the inputs and outputs?
>>
>>
> I think the best way for me to describe it is that as the V3 AP
On Wed, 2013-12-11 at 17:48 +0100, Jiří Stránský wrote:
> >> When you say python- clients, is there a distinction between the CLI and
> >> a bindings library that invokes the server-side APIs? In other words,
> >> the CLI is packaged as CLI+bindings and the UI as GUI+bindings?
>
> python-tuskarcl
On Wed, 2013-12-11 at 09:32 -0500, Jay Dobies wrote:
> On 12/11/2013 07:33 AM, Jiří Stránský wrote:
> > 3) Keep tuskar-api and python-tuskarclient thin, make another library
> > sitting between Tuskar UI and all python-***clients. This new project
> > would contain the logic of using undercloud ser
Hi Jay,
Sure, that is understood. In fact such refactoring could be a big change so
I'd split it to two or more patches.
Hope this will not overlap with ongoing neutron API tests development.
Thanks,
Eugene.
On Sat, Dec 14, 2013 at 7:01 PM, Jay Pipes wrote:
> On Sat, 2013-12-14 at 15:26 +040
On Sat, 2013-12-14 at 15:26 +0400, Eugene Nikanorov wrote:
> Hi tempest folks,
>
> While adding new API tests for Neutron I found out that network client
> used in tempest could be improved in at least two ways:
> 1) code duplication between xml and json versions could be removed
> 2) client API c
2013/12/9 Clint Byrum
> Excerpts from Fox, Kevin M's message of 2013-12-09 09:34:06 -0800:
> > I'm thinking more generic:
> >
> > The cloud provider will provide one or more "suballocating" images. The
> one Triple O uses to take a bare metal node and make vm's available would
> be the obvious on
Hi Kevin,
2013/12/2 Fox, Kevin M
> Hi all,
>
> I just want to run a crazy idea up the flag pole. TripleO has the concept
> of an under and over cloud. In starting to experiment with Docker, I see a
> pattern start to emerge.
>
> * As a User, I may want to allocate a BareMetal node so that it i
On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
wrote:
> That covers routes. What about the properties of the inputs and outputs?
>
>
I think the best way for me to describe it is that as the V3 API core and
all the extensions
are written, both the routes and input and output parameters are from a
Hi tempest folks,
While adding new API tests for Neutron I found out that network client used
in tempest could be improved in at least two ways:
1) code duplication between xml and json versions could be removed
2) client API could be made more flexible and similar to real neutron
client API.
E.g.
22 matches
Mail list logo
