64fb-43fa-aacd-9bebba17fba5'
>>>>
>>>> >>> volumes[0].volume_type
>>>>
>>>> u'iscsi_1'
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Pradip
>>>>
>>>>
>
The current plan is not to use a conductor, and to pin object versions to
to current version before starting a rolling upgrade. This means version
downgraded will be done on the sender side before sending I think. I need
to look more closely at the patches again to be honest.
On 5 Jan 2016 00:41, "
rvices, Inc.
>
> *Rethink Possible*
>
>
>
> Email: ds6...@att.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
t, Timur?
>>
>> While it's possible to add this, I'm not sure how much time it's
>> actually going to save in the DB query time to get the quota information
>> for a tenant.
>>
>> Anyway, it's an API change so it would require a spec for nova which
>> mean
I believe the code that needs fixing is in cinder backup itself, rather
than (or as well as) the client, since the client will only initiate the
operation, it will not be around for later when the token expires.
Cinder backup is also potentially a place where keystone trusts can be
fruitfully empl
to fix).
I'm just starting a week's vacation, but I'll push up a tempest test for
this case when I get back if nobody else has, then we can see which CIs
fail and start raising bugs.
--
Duncan Thomas
__
OpenStack
On 3 December 2015 at 11:14, Li, Xiaoyan wrote:
> Just to clear the data operations cinder needs to touch plaintext data are:
> 1) Create volume from glance image
> 2) Create glance image from volume
> 3) Retype encrypted volumes. That is to change a volume from unencrypted
> to encrypted, or
(such as creating lots of bootable volumes at once) I'd be
resistant to anything that makes it worse to solve a cosmetic issue.
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
isk (the
common case I think), and those who have enhanced security requirements.
--
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
?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.openst
ic that has
been bounced around a lot on IRC/email then I get more worried, regardless
of the organisation(s) of the cores who merged it. No amount of rules will
fix that though, only discussion and trust of cores. Giving them a rule to
stand
wrote:
> > On 11/20/2015 10:19 AM, Daniel P. Berrange wrote:
> > >On Fri, Nov 20, 2015 at 02:45:15PM +0200, Duncan Thomas wrote:
> > >>Brick does not have to take over the decisions in order to be a useful
> > >>repository for the code. The motivation for th
> 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
Brick does not have to take over the decisions in order to be a useful
repository for the code. The motivation for this work is to avoid having
the dm setup code copied wholesale into cinder, where it becomes difficult
to keep in sync with the code in nova.
Cinder needs a copy of this code since i
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
f interest to note that volume snapshots have always worked on
attached volumes, and as of liberty, the backup operation now supports a
--force=True option that does a backup of a live volume (via an internal
snapshot, so it should be crash consi
> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailm
Hi Folks
The Cinder team is trying to plan our mid-cycle meetup again.
Can anybody interested in attending please fill out this quick survey to
help with planning, please?
https://www.surveymonkey.com/r/Q5FZX68
Closing date is 11th November.
Thanks
--
--
Duncan Thomas
stack.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-re
mal gerrit process. Referencing the name of the CI in the commit
message makes reviewer's lives easier so is worth doing. If you post a
review now, again you will be in very good shape to get back in M.
Hope this helps.
--
Duncan Thomas
On 3 November 2015 at 11:43, Eduard Matei
wrote:
>
asily make API changes
> like this which are otherwise backward incompatible since you're changing
> the response.
>
> [1] https://review.openstack.org/#/c/209917/
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> ________
The deprecated API will be removed in some future release, though the date
for that is not know. It is not advised to code against a deprecated API
for this reason, and any existing code that operates against a deprecated
API should be updated where possible.
That said, the deprecated code in ques
I think option 2 is the better one, and we can just call it something else
other than capabilities. Available_services or similar
On 16 Oct 2015 11:05, "Ramakrishna, Deepti"
wrote:
> Hi,
>
>
>
> We need a way to let Horizon know about the presence of cinder-backup
> service so that it can enable
I think disabling it by default in early M should help shake out any
remaining issues - we can decide if we actually release that way later.
I'm against actually removing the V1 code however
On 29 Sep 2015 15:56, "Ivan Kolodyazhny" wrote:
> First of all, I would like to say thank you for the fee
Cinder provides a block storage abstraction to a vm. Manila provides a
filesystem abstraction. The two are very different, and complementary. I
see no reason why the nfs related cinder drivers should be removed based on
the existence or maturity of manila - manila is not going to suddenly start
pro
I can definitely see your logic, but we've a history in cinder of vendors
trying to cram drivers in at the last minute which we very much wanted to
stop dead. I might suggest that the second milestone, rather than the first
might be a better one to dedicate to driver reviews...
An interesting thin
On 28 September 2015 at 12:35, Sylvain Bauza wrote:
> About the maintenance burden, I also consider that patching clients is far
> more easier than patching an API unless I missed something.
>
>
I think I very much disagree there - patching a central installation is
much, much easier than getting
The trouble with putting more intelligence in the clients is that there are
more clients than just the one we provide, and the more smarts we require
in the clients, the more divergence of functionality we're likely to see.
Also, bugs and slowly percolating bug fixes.
On 28 Sep 2015 11:27, "Sylvain
On 26 September 2015 at 07:04, Joshua Harlow wrote:
> Maybe there should be a 'warm' project or something ;)
>
> Or we can call it 'bbs' for 'building block service' (obviously not
> bulletin board system); ask said service to build a set of blocks into well
> defined structures and let it figure
ficial to come together and figure out what sort of
> workloads the Nova API is intending to provide.
>
>
>
>> -James
>>
>
> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscrib
Hi
I thought I was late on this thread, but looking at the time stamps, it is
just something that escalated very quickly. I am honestly surprised an
cross-project interaction option went from 'we don't seem to understand
this' to 'deprecation merged' in 4 hours, with only a 12 hour discussion on
t
move cinder forward. We've
a great technical team, so I want to enable them to do more, while keeping
on top of scope creep and non-standardisation enough to enable cinder to be
what I and many others would like it be.
I hope this helps people with their decision.
3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
>
> ___
> Openstack-i18n mailing list
> openstack-i...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>
--
--
Duncan Thomas
___
On 18 Sep 2015 05:13, "Jim Rollenhagen" wrote:
> FWIW, in Ironic, we added the public_endpoint config to fix the bug
> quickly, but we'd really prefer to support both that and the
> secure_proxy_ssl_header option. It would use public_endpoint if it is
> set, then fall back to the header config, t
not
sure if we can fix it without breaking people's existing configs but I
think it is worth trying. I'll add it to the list of things to talk about
briefly in Tokyo.
--
Duncan Thomas
__
OpenStack Development Maili
On 16 Sep 2015 20:42, "yang, xing" wrote:
> On 9/16/15, 1:20 PM, "Eric Harney" wrote:
> >This sounds like a good idea, I'm just not sure how to structure it yet
> >without creating a very confusing set of config options.
>
> I’m thinking we could have a prefix with vendor name for this and it a
der, without
requiring pacemaker.
Thank you for your consideration.
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscr
>>
>>
>> --
>> Best Wishes For You!
>>
>> __________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:un
> 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
_
On 5 Sep 2015 05:47, "Adam Young" wrote:
> Then let my Hijack:
>
> Policy is still broken. We need the pieces of Dynamic policy.
>
> I am going to call for a cross project policy discussion for the upcoming
summit. Please, please, please all the projects attend. The operators have
made it clear
Mike is on vacation at the moment, somebody else will evaluate in his stead
Hi Mike,
I think the first mail was sent only on openstack-dev. We have had already
over
a week of reliable results on the Microsoft Cinder CI on all three jobs, we
have
an updated set of results available at [1].
Please
with things, and why has communication been so poor with
> the Cloud Base solutions team?
> >>
> >>[1] -
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openstack.org%2fpipermail%2fthird-party-announce%2f2015-July%2f000249.html&data=01%7c01%7chabd
Except your failure domain includes the cinder volume service, independent
of the resiliency of you backend, so if they're all on one node then you
don't really have availability zones.
I have historically strongly espoused the same view as Ben, though there
are lots of people who want fake availa
+1
On 17 Aug 2015 18:51, "Ivan Kolodyazhny" wrote:
> +1.
>
> Gorka, Thanks for your contribution!
>
> Regards,
> Ivan Kolodyazhny,
> Web Developer,
> http://blog.e0ne.info/,
> http://notacash.com/,
> http://kharkivpy.org.ua/
>
> On Sat, Aug 15, 2015 at 6:25 AM, John Griffith
> wrote:
>
>>
>>
>>
That's a bug! I'm not aware of anybody working on it, and I don't see any
old bugs open for it. A suitable fix would be very welcome
On 12 Aug 2015 14:54, "Li, Xiaoyan" wrote:
> Hi all,
>
> Currently when cinder creates a volume with an encrypted volume type from
> an image(which is unencrypted)
Does restoring a volume online make any logical sense? Generally operating
systems don't like it when a mounted volume changes contents, and a
restore, being a slow sequential write is likely to be even worse. Since
you have to unmount anyway, attaching a new volume should not be an issue.
Just be
nd being stolen without fencing is frankly scary and
begging for data corruption unless we're very careful. I'd rather use a
persistent lock (e.g. a db record change) and manual recovery than a lock
timeout that might cause corruption.
--
Duncan Thomas
___
of Gorka's patch can
certainly be used to fix a few of the API races we have, and can do so with
rather nice, elegant, easy to understand code, so I think the whole process
has been productive whatever the H/A outcome.
--
Duncan Thomas
__
essed, and
imthusiastic about moving forward on this for the first time in a while.
Appreciated.
--
Duncan Thomas
On 27 July 2015 at 22:35, Gorka Eguileor wrote:
> Hi all,
>
> I know we've all been looking at the HA Active-Active problem in Cinder
> and trying our best to figure ou
r-volume node, could we
>>> have different AZ for each backend? So that we can specify each backend as
>>> a AZ and create volume in this AZ.
>>>
>>> Regards,
>>> Wang Hao
>>>
>>>
>>> __
>>> Open
_
> 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/l
It sounds like the extra specs you configured are not selective enough. Can
you post up your 3 cinder.conf files from the c-vol nodes, and the commands
used to create the volume type, please?
On 13 Jul 2015 08:00, "Eduard Matei" wrote:
> Hi,
>
> Forgot to mention, indeed we configured extra_specs
Ah, I apologise, I missed the but where it defaults to force=true. I
withdraw the objection.
I've no strung feelings about the change either way, in that case.
On 10 Jul 2015 10:58, "Gorka Eguileor" wrote:
> On Fri, Jul 10, 2015 at 10:28:06AM +0300, Duncan Thomas wrote:
>
That is a semantic change to the api that will break anybody who has
tooling expecting the current behavior. Since there are perfectly sensible
uses of the current behavior, that is not a good thing.
On 10 Jul 2015 07:33, "hao wang" wrote:
> Cinder now doesn't check the existing resource when use
k.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...@li
It was discussed on the mailing list, and at the weekly meeting. Mike had
had no response on the issue from the listed contact email, and the CI was
reporting failure for every patch for two months
On 3 Jul 2015 17:33, "Silvan Kaiser" wrote:
> Hello!
> I just found the following commit in the cin
covery, without breaking
normal usage.
On 30 Jun 2015 19:28, "John Griffith" wrote:
>
>
> On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas
> wrote:
>
>> We already have an environment variable for version... 'auto'?
>> On 30 Jun 2015 07:57, "John Gr
We already have an environment variable for version... 'auto'?
On 30 Jun 2015 07:57, "John Griffith" wrote:
>
>
> On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant > wrote:
>
>> I too would prefer option 2. Would rather do the pack ports than remove
>> the functionality.
>>
>> Jay
>>
>> On Wed, Jun 24
On 29 June 2015 at 18:18, Joshua Harlow wrote:
> Duncan Thomas wrote:
>
>> Do we know what is so hated about the glance task API? Tasks and entity
>> queues give the required exclusion, if you accept that tasks can fail if
>> previous tasks in the queue can cause thin
LOCKED' or ...)
>
> Dulko, Michal wrote:
>
>> That’s right, it might be painful. V3 API implememtation would be also a
>> hard, because then we would need different manager behavior for requests
>> from V2 and V3… So maybe we need some config flag with deprecation
>
On 29 June 2015 at 15:23, Dulko, Michal wrote:
> There’s also some similar situations when we actually don’t lock on
> resources. For example – a cgsnapshot may get deleted while creating a
> consistencygroup from it.
>
>
>
> From my perspective it seems best to have atomic state changes and
>
un, Jun 28, 2015 at 5:07 AM, Joshua Harlow
> wrote:
>
>> John Griffith wrote:
>>
>>>
>>>
>>> On Sat, Jun 27, 2015 at 11:47 AM, Joshua Harlow >> <mailto:harlo...@outlook.com>> wrote:
>>>
>>> Duncan Thomas w
We are working on some sort of distributed replacement for the locks in
cinder, since file locks are limiting our ability to do HA. I'm afraid
you're unlikely to get any traction until that work is done.
I also have a concern that some backend do not handle load well, and so
benefit from the curre
ending on how this node is firewalled (drop packets .v. send reset), an
attempt to connect to this URL can take a long time to timeout.
I *think* we can get the desired behaviour by looking at the entry in the
catalogue, and if it has a trailing version number then don't do discovery,
but I might
The problem there is that it takes (significant) time for the connection
attempt to time out - every cinder command taking several minutes is not
acceptable.
Obviously this depends on the network setup of the cloud - I can only talk
about the case we saw
On 24 Jun 2015 00:25, "Jeremy Stanley" wro
BC can go away. I'll see if I can
make a start.
--
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 17 June 2015 at 15:36, Dmitry Guryanov wrote:
> On 06/17/2015 02:14 PM, Duncan Thomas wrote:
>
>> On 17 June 2015 at 00:21, Matt Riedemann > <mailto:mrie...@linux.vnet.ibm.com>> wrote:
>>
>> The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume
On 17 June 2015 at 00:21, Matt Riedemann wrote:
> The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all very
> similar.
>
> I want to extract a common base class that abstracts some of the common
> code and then let the sub-classes provide overrides where necessary.
>
> As part of
enstack.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...@
I don't think you need an entry per driver, you need an entry per
connection type - iSCSI, FC, DRDB, CEPH being the ones I can think of off
the top of my head
On 10 Jun 2015 16:57, "Matt Riedemann" wrote:
> While investigating/discussing bug 1463525 [1] I remembered how little I
> know about what
a transfer to a diff tenant ?
>
>
Cinder doesn't seem to have any concept analogous to a share network from
what I can see; the cinder transfer commands are for moving a volume
between tenants, which is a different thi
> Unsubscribe:
>> *openstack-dev-requ...@lists.openstack.org?subject:unsubscribe*
>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
>> <http://lists.openstack.org/cgi-bin/mailman/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/mailman/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/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
https://bugs.launchpad.net/cinder/+bug/1454244
>
> 2. “VolumeNotFound” exception error message should be consistent
> across all APIs
>
>
>
> Please suggest.
>
>
>
> Thanks
>
> *From:* Duncan Thomas [mailto:duncan.tho...@gmail.com]
> *Sent:* 26
age 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 Li
er code to Python 3:
>
> https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:py3,n,z
>
> Duncan Thomas rejected one of my patch:
> "As commented on https://review.openstack.org/#/c/185411/ I'd really like
> to be convinced that there's an end in sight
There doesn't seem to be an existing tempest test for this.
I suggest writing the test so that it looks if there are two volume types
defined, and if so uses them. Ideally you should test migration to and from
lvm. There is offline migration (volume is available) and online migration
(volume is at
+1 without hesitation
On 22 May 2015 16:36, "Mike Perez" wrote:
> This is long overdue, but it gives me great pleasure to nominate Sean
> McGinnis for
> Cinder core.
>
> Reviews:
> https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z
>
> Contributions:
> https://review.openstack.org
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: ope
LETE,
that's what it means above about being more RFC compliant - nothing in the
RFC prohibits this that I can spot, it's just a loose convention.
--
Duncan Thomas
__
OpenStack Development Mailing Lis
In the case of cinder, there is a proposal to add it in, since it makes
some of the versioning work easier
On 8 May 2015 15:08, "Dulko, Michal" wrote:
> Hi,
>
> I wonder why nova-api or cinder-api aren't present service group API of
> each project:
>
> mdulko:devstack/ (master) $ cinder service-l
>
Seems like the right approach to me. In some cases, the cinder API will
need to return more info first. I suggest raising bugs for any situations
that are hard to detect, and we can work from there...
--
Duncan Thomas
__
O
gt; Thank you for your reply. Could you please let me know the procedure
>> needed for the driver to be readded to Liberty? Specifically, will you be
>> the one who upload the revert patchset, or it is the driver maintainer's
>> responsibility?
>>
>> Diem.
>>
>>
>>
>
> __
> 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
On 28 April 2015 at 21:59, Kevin Benton wrote:
>
> The concern is that having broken drivers out there that claim to work
> with an OpenStack project end up making the project look bad. It's similar
> to a first time Linux user experiencing frequent kernel panics because they
> are using hardware
of these is a death-knell for Cinder.
I don't follow Neutron closely enough that I can comment on how this
might/might not affect them.
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage
Can you please investigate and comment here on this thread as to why your
CI is failing for all patches? If this is not resolved, your driver will
not be re-added, and ignoring requests to investigate CI failures will
increase the chances of your driver being removed in future, without
notice. Sett
the driver, please do let me know.
>>
>> Thank you,
>> Diem.
>>
>
>
> __
> OpenStack Development Mailing List (
ubscribe
> 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?sub
Yogesh
> *CloudByte Inc.* <http://www.cloudbyte.com/>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http:
unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lis
__
> 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 11 Apr 2015 02:04, "Jeremy Stanley" wrote:
>
> On 2015-04-11 01:28:51 +0300 (+0300), Duncan Thomas wrote:
> [...]
> > We will not be merging any drivers without stable 3rd party CI in
> > future
> [...]
>
> For clarity, hopefully this is "stable
On 11 Apr 2015 02:04, "Jeremy Stanley" wrote:
>
> On 2015-04-11 01:28:51 +0300 (+0300), Duncan Thomas wrote:
> [...]
> > We will not be merging any drivers without stable 3rd party CI in
> > future
> [...]
>
> For clarity, hopefully this is "stable
On 10 Apr 2015 21:02, "Joshua Huber" wrote:
> A couple questions:
>
> 1) When is it appropriate to submit the driver for review? Is
> 3rd-party CI a prerequisite?
We will not be merging any drivers without stable 3rd party CI in future,
so it is a requirement. You can submit the driver for initi
since the workflow is, user does something. It
> breaks with "error notify admin" then admin needs to figure out why...
> ideally there needs to be a field for why in the db, and the dashboard can
> show it to admins?
>
> Thanks,
> Kevin
>
> --
On 8 April 2015 at 20:34, Chris Dent wrote:
> On Wed, 8 Apr 2015, Sandy Walsh wrote:
>
> Yes. It would be so good to pull apart the state-machine that is Nova and
>> just emit completed actions via notifications. Then, have something like
>> TaskFlow externalize the orchestration. Do away with R
t per user if we want to be paranoid? (Just throwing it out
> there as an option since we're already using it...)
>
>
> Chris
>
> __
> OpenStack Development Mailing List (not for usage questions)
> U
uestions)
> 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 (n
As discussed on IRC, this was a config problem, and any of the newer links
(with 8080 in them) should work. Thanks to Liu for following through on
this.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscrib
GB file to
>> swift compare to backup of 50 GB to swift?
>>
>>
>>
>> *From:* Duncan Thomas [mailto:duncan.tho...@gmail.com]
>> *Sent:* Wednesday, April 01, 2015 6:13 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subjec
101 - 200 of 435 matches
Mail list logo
