Hear, hear!
Dan
On 08/21/2014 07:57 AM, Daniel P. Berrange wrote:
Tagged with '[nova]' but this might be relevant data / idea for other
teams too.
With my code contributor hat on, one of the things that I find most the
frustrating about Nova code review process is that a patch can get a +2
Just out of curiosity, what is the rational behind upping the number of
core sponsors for feature freeze exception to 3 if only two +2 are
required to merge? In Icehouse, IIRC, two core sponsors was deemed
sufficient.
Dan
On 09/02/2014 02:16 PM, Michael Still wrote:
Hi.
We're soon to hit
On 09/03/2014 07:31 AM, Gary Kotton wrote:
On 9/3/14, 12:50 PM, Nikola Đipanov ndipa...@redhat.com wrote:
On 09/02/2014 09:23 PM, Michael Still wrote:
On Tue, Sep 2, 2014 at 1:40 PM, Nikola Đipanov ndipa...@redhat.com
wrote:
On 09/02/2014 08:16 PM, Michael Still wrote:
Hi.
We're soon to
I would like to request a feature freeze exception for
LVM ephemeral storage encryption[1].
The spec[2] for which was approved early in the Juno release cycle.
This feature provides security for data at-rest on compute nodes. The
proposed feature protects user data from disclosure due
I would like to request a feature freeze exception for
LVM ephemeral storage encryption[1].
The spec[2] for which was approved early in the Juno release cycle.
This feature provides security for data at-rest on compute nodes. The
proposed feature protects user data from disclosure due
On 01/09/2014 06:14 PM, Brant Knudson wrote:
On Thu, Jan 9, 2014 at 12:21 PM, Mike Spreitzer mspre...@us.ibm.com
mailto:mspre...@us.ibm.com wrote:
Brant Knudson b...@acm.org mailto:b...@acm.org wrote on
01/09/2014 10:07:27 AM:
When I was starting out, I ran devstack (
I think this qualifies as a development question but please let me know
if I am wrong.
I have been trying to test instance migration in devstack by setting up
a multi-node devstack following directions at
http://devstack.org/guides/multinode-lab.html. I tested that indeed
there were multiple
I think this qualifies as a development question but please let me know
if I am wrong.
I have been trying to test instance migration in devstack by setting up
a multi-node devstack following directions at
http://devstack.org/guides/multinode-lab.html. I tested that indeed
there were multiple
been flushed to
disk before you kick off the migration.
The confirm resize step should be deleting the old data, but there may
be a bug in the lvm backend if this isn’t happening. Live(block)
migration will probably be a bit more intuitive.
Vish
On Jan 15, 2014, at 2:40 PM, Dan Genin daniel.ge
Raw backed instance migration also works so this appears to be an LVM issue.
On 01/16/2014 11:04 AM, Dan Genin wrote:
Thank you for replying, Vish. I did sync and verified that the file
was written to the host disk by mounting the LVM volume on the host.
When I tried live migration I got
open a bug and attach as much info as possible.
Vish
On Jan 16, 2014, at 8:04 AM, Dan Genin daniel.ge...@jhuapl.edu
mailto:daniel.ge...@jhuapl.edu wrote:
Thank you for replying, Vish. I did sync and verified that the file
was written to the host disk by mounting the LVM volume on the host
As a reviewee of Matt I vote
+1
On 11/23/2013 10:17 AM, Gary Kotton wrote:
This message has been archived. View the original item
Hello Joe,
Sorry to be bugging on what is probably a very busy day for you, but it
being the feature freeze and all, I just wanted to ask if there was any
chance of the LVM ephemeral storage encryption patch
https://review.openstack.org/#/c/40467/, that you -1'ed today, making
it into
Punishing benign users as a defense against (potentially) malicious
users sounds like a bad strategy. This should not be a zero-sum game.
On 10/28/2013 02:49 PM, Joshua Harlow wrote:
Sure, convergence model is great and likely how it has to be done.
Its just a question of what is that
Hello,
I would like to add to DevStack the ability to stand up Nova with LVM
ephemeral
storage. Below is a draft of the blueprint describing the proposed feature.
Suggestions on architecture, implementation and the blueprint in general
are very
welcome.
Best,
Dan
and not. This makes sense, as fewer code paths and less
interoperability complexity is a good thing.
That the same balance of concerns should apply in OpenStack, seems likely.
On Tue, Oct 21, 2014 at 7:59 AM, Dan Genin daniel.ge...@jhuapl.edu
mailto:daniel.ge...@jhuapl.edu wrote:
Hello
features cinder reconciling backend with the cinder db.
Creating a second vg sharing the same backend pv is easy and avoids
all such problems.
Duncan Thomas
On Oct 21, 2014 4:07 PM, Dan Genin daniel.ge...@jhuapl.edu
mailto:daniel.ge...@jhuapl.edu wrote:
Hello,
I would like to add
proposed features cinder reconciling backend with the cinder db.
Creating a second vg sharing the same backend pv is easy and avoids
all such problems.
Duncan Thomas
On Oct 21, 2014 4:07 PM, Dan Genin daniel.ge...@jhuapl.edu
mailto:daniel.ge...@jhuapl.edu wrote:
Hello,
I would
the same backend pv is easy and avoids
all such problems.
Duncan Thomas
On Oct 21, 2014 4:07 PM, Dan Genin daniel.ge...@jhuapl.edu
mailto:daniel.ge...@jhuapl.edu wrote:
Hello,
I would like to add to DevStack the ability to stand up Nova with
LVM ephemeral
storage. Below is a draft
On 10/28/2014 11:56 AM, Dean Troyer wrote:
On Tue, Oct 28, 2014 at 9:27 AM, Dan Genin daniel.ge...@jhuapl.edu
mailto:daniel.ge...@jhuapl.edu wrote:
So this brings us back to the original proposal of having separate
backing files for Cinder and Nova which Dean thought might take
too
mitigation approaches. I have
little understanding of what problems a shared Cinder-Nova volume group
would cause for Cinder testing. How hard would it be to make the tests
work with a shared volume group?
Dan
On 28 October 2014 14:27, Dan Genin daniel.ge...@jhuapl.edu wrote:
Duncan, I don't
around nova volumes fine when we come
to write our tests.
Sorry for the repeated circling on this, but I think I'm now happy.
Thanks
On 28 October 2014 17:53, Dan Genin daniel.ge...@jhuapl.edu wrote:
On 10/28/2014 11:56 AM, Dean Troyer wrote:
On Tue, Oct 28, 2014 at 9:27 AM, Dan Genin daniel.ge
On 10/28/2014 02:50 PM, John Griffith wrote:
On Tue, Oct 28, 2014 at 12:37 PM, Dan Genin daniel.ge...@jhuapl.edu
mailto:daniel.ge...@jhuapl.edu wrote:
Great, thank you, Duncan. I will then proceed with the shared
volume group.
Dan
On 10/28/2014 02:06 PM, Duncan Thomas
Thank you, that solved it.
Dan
On 08/09/2013 11:11 AM, Sean Dague wrote:
This should be addressed by the latest devstack, however because we
moved to oslo.config out of git, some install environments might still
have oslo.config 1.1.0 somewhere, that pip no longer sees (so can't
uninstall)
Attempting to submit code to Nova, I got the following error from Jenkins:
2013-08-21 17:23:55.604 | pep8 runtests: commands[0] | flake8
2013-08-21 17:23:55.615 | /home/jenkins/workspace/gate-nova-pep8$
/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8
2013-08-21 17:25:44.400 |
Hello Dmitry,
This is off the topic of original email but related to RBD.
Looking through the code of LibvirtDriver._get_instance_disk_info() I
noticed that it only returns data for disks with source file=... or
source dev=... but not source proto=... so RBD backed instances
would be
26 matches
Mail list logo
