You can run many c-bak processes on one node, which will get fed round
robin, so you should see fairly linear speedup in the many backups case
until you run out of CPUs.
Parallelising a single backup was something I attempted, but python makes
it extremely difficult so there's no useful
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Duncan Thomas
nection
> information.
>
> So I agree, it's not a blockRebase operation, just a change in the
> volume that is used.
>
> Regards,
> Gorka.
>
> __
> OpenStack Development Mailing List (not for usage
ports a range of connectors, and there has never been any
opposition in principle to supporting more.
I suggest looking at the RDB support in cinder as an example of a
strongly supported native attachment method.
--
Duncan Thomas
__
le, etc. It
always feels like a very second-class position to me.
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
ht
Met with Jay, looking at alternatives
On 2 Mar 2018 6:26 pm, "Duncan Thomas" <duncan.tho...@gmail.com> wrote:
> I'm in the pub now, and they are closing down
>
> On 2 Mar 2018 5:48 pm, "Jay S. Bryant" <jungleb...@gmail.com> wrote:
>
>> Iva
I'm in the pub now, and they are closing down
On 2 Mar 2018 5:48 pm, "Jay S. Bryant" wrote:
> Ivan,
>
> I sent another note but will also respond in this thread.
>
> Yes, they will serve us tonight. It is a somewhat limited menu but I
> stopped to look at it and it still
So I guess my question here is why is being RESTful good? Sure it's (very,
very loosely) a standard, but what are the actual advantages? Standards
come and go, what we want most of all is a good quality, easy to use API.
I'm not saying that going RESTful is wrong, but I don't see much discussion
-12-04 19:36 GMT+08:00 Duncan Thomas <duncan.tho...@gmail.com>:
>> Why remove something that works and people are using?
>
> Yes, removing it will make noise.
>
>>
>> If polster can be set up to do the job, then great, but there's no
>> rush to remove the
tack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
But the filtering requirements are going to be different for different
front ends, and we can't hope to catch them all. Trying to do any filtering
at the cinder/nova API level just provides a false sense of security -
horizon and other UI *have* to get their escaping right. If you put
incomplete
On 15 November 2017 at 11:15, Matt Keenan wrote:
> On 13/11/17 22:51, Nikhil Komawar wrote:
>
> I think it will a rather hard problem to solve. As swift store can be
> configured to store objects in different configurations. I guess the next
> question would be, what is
I'm not sure there's a general agreement about removing the fixed key
manager code in future. It serves several purposes, testing being the most
significant one, though it also covers some people's usecase from a
security PoV too where something better might not be worth the complexity
trade off.
ubject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opensta
bscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 25 May 2017 12:33 pm, "Lee Yarwood" <lyarw...@redhat.com> wrote:
On 25-05-17 11:38:44, Duncan Thomas wrote:
> On 25 May 2017 at 11:00, Lee Yarwood <lyarw...@redhat.com> wrote:
> > This has also reminded me that the plain (dm-crypt) format really needs
> >
o last
> minute objections I'm going to move forward with deprecating this format
> in os-brick this cycle.
What is the reasoning for this? There are plenty of people using it, and
you're going to break them going forward if you remove i
On 23 May 2017 4:51 am, "Matt Riedemann" wrote:
Is this really something we are going to have to deny at least once per
release? My God how is it that this is the #1 thing everyone for all time
has always wanted Nova to do for them?
Is it entirely unreasonable to turn
, maybe the answer is to put
that logic in a new service, that talks to those four, and provides a
nice simple API, while allowing the cinder, nova etc APIs to remove
things like internal retries?
--
Duncan Thomas
__
OpenStack D
rd definitions is that your standards rarely match the next
guy's standards, and since some of these are entirely irrelevant to
many storage topologies, you're likely going to need an API to
discover what is relevant to a specific system
On 5 May 2017 at 23:45, Chris Friesen wrote:
> On 05/05/2017 02:04 PM, John Griffith wrote:
>> I'd love some detail on this. What falls over?
> It's been a while since I looked at it, but the main issue was that with LIO
> as the iSCSI server there is no automatic
penstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...
end might be one way to solve the problem.
>
> By the way, How about another way that we could import volume
> size with float value? such as: 2.5G, 3.4G?
>
> Did community consider about it in the begin?
>
>
> 2017-04-07 20:16 GMT+08:00 Duncan Thomas <duncan.tho...@gmail.com&
volumes, so it only
> support the 1 and 2.
>
> Is there any suggestion that how Cinder can support them?
>
>
> Thanks
> Wangxiyuan
>
> 2017-04-08 8:49 GMT+08:00 Matt Riedemann <mriede...@gmail.com>:
>>
>> On 3/27/2017 9:59 AM, Duncan Thomas wrote:
&
tions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Duncan Thomas
__
OpenStack Development Mailing List (not for
cepts no liability for any damage caused
> by any virus transmitted by this email. www.wipro.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org
t;>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/
On 9 Mar 2017 18:22, "Jay Pipes" wrote:
>
> On 03/09/2017 01:06 PM, Dmitry Tantsur wrote:
>>
>> On 03/09/2017 06:57 PM, Clint Byrum wrote:
>>>
>>> Excerpts from Ben Swartzlander's message of 2017-03-09 11:23:31 -0500:
>>
>>
>>>
>>>
>>> Combine that with the lower cost and
___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
--
Duncan Thomas
___
______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
--
Duncan Thomas
__
It's a pretty terrible secrets-as-a-service product at
the moment. Fixing it is not trivial.
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstac
To give a totally different prospective on why somebody might dislike
Barbican (I'm one of those people). Note that I'm working from pretty hazy
memories so I don't guarantee I've got everything spot on, and I am without
a doubt giving a very one sided view. But hey, that's the side I happen to
On 12 December 2016 at 16:35, Ash wrote:
> I tend to agree with you, Sean. Also, if there's a concern that some
> project has changed its license, then just create a fork. In the case of
> this previously GPL code, it will at least be re-distributable. In the end,
> I
tely a obstacle, and
in some cases (like customers who want a fully offline/airgapped install)
an insurmountable one.
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
a firm conclusion.
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
g?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@l
B schema to look a particular way for a specific version
> of the Glance service software.
>
Cinder services can run N+-1 versions in a mixed manner, all talking to the
same database, no conductor required.
--
Duncan Thomas
_
usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
--
Duncan Thomas
__
OpenStack Development Maili
going to discuss it, how can we be there to influence that discussion?
I've got to agree entirely here. I am mostly interested in cinder stuff,
but I've interest and a stake in specific nova and glance topics... getting
in
On 22 September 2016 at 00:23, John Griffith
wrote:
>
> Yes, that is a sizeable chunk of the solution. The remaining components
> are how to coordinate with Nova (compute nodes) and figuring out if we just
> use c-vol as is, or if we come up with some form of a paired
On 20 September 2016 at 16:24, Nikita Konovalov
wrote:
> Hi,
>
> From Sahara (and Hadoop workload in general) use-case the reason we used
> BDD was a complete absence of any overhead on compute resources
> utilization.
>
> The results show that the LVM+Local target
cussion this time.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> ________
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsub
Writing a sensible test for this api is rather tricky, since it is intended
to clean up one very specific error condition, and has few guarantees about
the state it leaves the system in. It is provided as a tool to allow the
system administrator to clean up certain faults and situations without
On 13 September 2016 at 06:44, Ben Swartzlander <b...@swartzlander.org>
wrote:
> On 09/09/2016 11:12 AM, Duncan Thomas wrote:
>
>> I don't care so much whether your CLI or API proxy in open or closed
>> source, but I really do care if I can create a distribut
On 9 September 2016 at 17:22, Ben Swartzlander <b...@swartzlander.org> wrote:
On 09/08/2016 04:41 PM, Duncan Thomas wrote:
>
> Despite the fact I've appeared to be slightly disagreeing with John in
>> the IRC discussion on this subject, you've summarised my concern
freely distribute them. I'm not aware of any tools
currently required by cinder where this is not the case, but a few of us
are in the process of auditing this to make sure we understand the
situation before we clarify our rules.
--
Duncan Thomas
_
gt;
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/lis
solution
> also understood it?
>
>
Thank you for the explanation. Some times it is best to state the
apparently obvious just so that everybody is on the same page.
There are some pieces in cinder that attempt to work around some of these
limitations already, added with the recent H/A
On 31 August 2016 at 18:54, Joshua Harlow <harlo...@fastmail.com> wrote:
> Duncan Thomas wrote:
>
>> On 31 August 2016 at 11:57, Bogdan Dobrelya <bdobre...@mirantis.com
>> <mailto:bdobre...@mirantis.com>> wrote:
>>
>> I agree that RPC desi
On 31 August 2016 at 11:57, Bogdan Dobrelya wrote:
> I agree that RPC design pattern, as it is implemented now, is a major
> blocker for OpenStack in general. It requires a major redesign,
> including handling of corner cases, on both sides, *especially* RPC call
>
eekly meeting, please
> reply the mail.
>
>
>
> Best Regards
>
> Chaoyi Huang ( joehuang )
>
> __________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ
On 08/08/2016 02:28 PM, Ihar Hrachyshka wrote:
> > Duncan Thomas wrote:
> >
> >> On 8 August 2016 at 21:12, Matthew Treinish
> >> wrote:
> >> Ignoring all that, this is also contrary to how we perform testing in
> >> OpenStack.
> >>
There's so much misinformation in that email I barely know where to start.
There is nothing stopping out of tree drivers for cinder, and a few have
existed, though they don't seem to stick around. The driver is just a
python class referenced in the config file.
Turning a removed driver into an
parent project (e.g. a pip release), then finally you
can merge the cinder change.
To turn the question around, what is the downside of loosing the tag? Are
people going to suddenly stop deploying cinder? That seems rather unlikely.
Nobody has yet given a singl
tell, we (the cinder team) are
better off shrugging about the tags and carrying on as we are.
On 12 Aug 2016 15:54, "Sean Dague" <s...@dague.net> wrote:
> On 08/12/2016 08:40 AM, Duncan Thomas wrote:
> > On 12 Aug 2016 15:28, "Thierry Carrez" <thie...@openstack
Is there some docs for it somewhere? Or some quick way of telling that
we've done it and gotten it right?
On 12 Aug 2016 08:17, "Andreas Jaeger" wrote:
> On 08/12/2016 04:25 AM, Robert Collins wrote:
> > On 11 Aug 2016 3:13 PM, "Ben Swartzlander" >
On 12 Aug 2016 15:28, "Thierry Carrez" <thie...@openstack.org> wrote:
>
> Duncan Thomas wrote:
> I agree that leaving broken drivers in tree is not significantly better
> from an operational perspective. But I think the best operational
> experience would be to ha
ly sucks that yes, a release could come out and that driver no longer
> exists, and that's no good.
>
>
> BUT on the other hand, it's not much worse to find that the code has been
> all but abandoned and no longer works anyway. I don't think either
> scenario is a good one. It highlig
unctional tests would
> be
> *entirely* 3rd party.
>
> Yours Tony.
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.o
>
But is it more of a disaster (for the consumers) than zero testing, zero
review, scattered around the internet if-you're-lucky-with-a-good-wind
you'll maybe get the right patch set? Because that's where we are right
now, and vendors, distributors and the cinder core team are all saying it's
a di
3+ cycles), what positive suggestions can people make?
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
+1 from me
Sound like the best solution to at least part of the problem that was
causing people to want to pull the drivers out of tree
On 6 Aug 2016 18:49, "Philipp Marek" wrote:
> > I want to propose
> > we officially make a change to our stable policy to call out
On 1 August 2016 at 18:14, Adrian Otto wrote:
> I am struggling to understand why we would want to remove projects from
> our big tent at all, as long as they are being actively developed under the
> principles of "four opens". It seems to me that working to disqualify
Looks like either you've got an intermittent network problem or the cinder
api service is restarting. Anything enlightening in the cinder-api log?
On 28 Jul 2016 16:41, "varun bhatnagar" wrote:
Hello Steve,
Thanks a lot for such a quick response.
Yes the IP is
On 20 July 2016 at 19:57, James Bottomley <
james.bottom...@hansenpartnership.com> wrote:
>
> OK, I accept your analogy, even though I would view currency as the
> will to create and push patches.
>
> The problem you describe: getting the recipients to listen and accept
> your patches, is also a
ent Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi
I would, once again, love to attend.
If you find that other cores apply and you'd rather have a new face, I
would be very understanding of the situation.
Regards
--
Duncan Thomas
On 13 June 2016 at 11:06, Wang, Shane <shane.w...@intel.com> wrote:
> Hi, OpenStackers,
>
&
aplane implementations (i.e. the go
one, maybe something ceph based, etc) to sit outside of the openstack
umbrella. This is the model nearly every other openstack service has.
--
Duncan Thomas
__
OpenStack Development Maili
any
open bugs that disagree), is it time to dump the LVM-thick support
completely?
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --
> Regards, Markus Zoeller (markus_z)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http:
On 23 Apr 2016 14:26, "Jay Pipes" wrote:
> On 04/23/2016 03:18 PM, Mike Perez wrote:
>> How about extending a volume? A volume is a resource and can be extended
in
>> Cinder today.
>
>
> Yep, understood :) I recognize some resource amounts can be modified for
some resource
On 19 April 2016 at 23:42, Michał Dulko wrote:
> On 04/18/2016 09:17 AM, Ramakrishna, Deepti wrote:
> > Hi Michal,
> >
> > This seemed like a good idea when I first read it. What more, the server
> code for extension listing [1] does not do any authorization, so it can be
spel and expect to be reworked if it proves necessary.
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstac
ailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
--
Duncan Thomas
__
Op
ou use the same
> volume (at least the disk UUID will be the same).
>
> On Mon, Apr 11, 2016 at 2:39 PM, Duncan Thomas <duncan.tho...@gmail.com>
> wrote:
>
>> You can't just change the contents of a volume under the instance though
>> - at the very least you nee
to know whether the topic have been discussed or have other
>>> recommendations to us?
>>>
>>>
>>>
>>>Thanks
>>>
>>>
>>>
>>> __
>>> OpenStack
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
--
Duncan Thomas
__
subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.open
t; nova here [1]. The cinder use of it for volume migration was added here
> >> [2].
> >>
> >> Looking at the cinder volume API for migrate_volume_completion, it
> >> expects the source (old) volume to have migration_status set [3].
> >>
> >> So
listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mail
Advanced users who want anonymous volumes can always hit the API
> directly with curl or whatever SDK.
>
> On Sun, Mar 27, 2016 at 4:44 PM, Duncan Thomas <duncan.tho...@gmail.com>
> wrote:
>
>> I think it is worth fixing the client to actually match the API, yes. The
>
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
--
Duncan Thomas
__
OpenStack Development Mailing List (not for u
- I wouldn't
suggest taking it as anything other than a PoC to be honest. Certainly it
should not be cargo-culted into another project in its present state.
--
Duncan Thomas
__
OpenStack Development Mailing List (no
indicating that
these tests should get closer scrutiny. This does not remove reviewer
judgement from the equation, just provides a helpful prod that there's
something to be considered.
--
Duncan Thomas
__
OpenStack Development Mailin
ind of thinking and communication needed often doesn't
fit into slots and sessions, and really needs the bandwidth of face to face
time.
I now think the cinder mid-cycle is more valuable for many devs, and much
cheaper, than the foundation events. I don't see that this proposal wi
ng missing to be a serious bug
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
there? There's no way
that's a sensible API design.
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 20 Feb 2016 00:21, "Walter A. Boring IV" wrote:
> Not that I'm adding much to this conversation that hasn't been said
already, but I am pro v2 API, purely because of how painful and long it's
been to get the official OpenStack projects to adopt the v2 API from v1.
I
Sorry, can you give an example of the exact command you are using, please?
On 5 Feb 2016 22:45, "Fox, Kevin M" wrote:
> We've been using the upload image from http url for a long time and when
> we upgraded to liberty we noticed it broke because the client's defaulting
> to
Actually, keeping track of changed blocks on cinder volumes would make the
cinder incremental backup substantially more efficient... Something could
push them into cinder at detach time, and an api call for cinder to pull
them at live backup time, and cinder backup can do the rest... Not sure of
so live backup
(internally via a snapshot) merged last cycle.
I can see a place for other backup solutions, I just want to make the
existing ones clear.
--
Duncan Thomas
__
OpenStack Development Mailing List (not for
nder. This isn't the
> initial priority for Ekko though, but it is good information to have. Thank
> you for your comments!
>
Always interested in better ways to solve backup.
--
Duncan Thomas
__
OpenStack Devel
d over the old json, or
create a new one. Either way, the bulk data does not need to be touched.
--
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-
JSON file (it's a dead simple format) and perhaps
an import for the same. That would allow cinder backup and Ekko to exchange
data where desired. I'm not sure if this is possible, but I'd certainly
suggest looking at it.
Thanks for ke
+1
He's been doing great work, and is a pleasure to work with.
On 29 Jan 2016 19:05, "Sean McGinnis" wrote:
> Patrick has been a strong contributor to Cinder over the last few
> releases, both with great code submissions and useful reviews. He also
> participates
On 29 Jan 2016 19:37, "Michał Dulko" wrote:
>
> Resolution on this matter from the Cinder mid-cycle is that we're fine
> as long as we safely fail in case of upgrade conducted in an improper
> order. And it seems we can implement that in a simple way by raising an
>
nnection().
>>
>>
> That would be ideal but I don't know if cinder is storing this information
> in the database like nova is in the nova
> block_device_mappings.connection_info column.
>
This is being discussed for cinder, since it is useful for implementi
I guess my wisdom would be 'why'? What does this enable you to do that you
couldn't do with similar ease with the formats we have and are people
trying to do that frequently.
We've seen in cinder that image formats have a definite security surface to
them, and with glance adding arbitrary
On 5 January 2016 at 18:55, Ryan Rossiter
wrote:
> This is definitely good to know. Are you planning on setting up something
> off to the side of o.vo within that holds a dictionary of all values for a
> release? Something like:
>
> {‘liberty’: {‘volume’: ‘1.3’, …},
;> []
>>>>
>>>> >>> volumes[0].id
>>>>
>>>> u'e8be1df5-64fb-43fa-aacd-9bebba17fba5'
>>>>
>>>> >>> volumes[0].volume_type
>>>>
>>>> u'iscsi_1'
>>>>
>>>>
>>>>
>>>
1 - 100 of 413 matches
Mail list logo