On 07/05/15 18:28, Tyler Wilson wrote:
Hello All,
Thank you for the replies! Will this patch be usable in Juno?
On Thu, May 7, 2015 at 3:18 AM, Pádraig Brady p...@draigbrady.com
mailto:p...@draigbrady.com wrote:
On 07/05/15 09:50, Sebastien Han wrote:
Actually the issue
On 07/05/15 09:50, Sebastien Han wrote:
Actually the issue is that the configdrive is store a file on the fs under
/var/lib/nova/instances/$uuid/config.drive
AFAIR the other problem is the format of that file that is not supported by
libvirt for the live migration.
I think you have to
On 21/04/15 21:37, Ian Cordasco wrote:
Also, isn’t sqlalchemy-migrate something we currently maintain (or a group
of OpenStack developers do it for OpenStack. Can’t we work with them to
add support for Python 3?
There seems to have been some work on that already:
On 19/01/15 20:41, Michael Still wrote:
Mostly.
qcow2 can do a copy on write layer, although it can be disabled IIRC.
So if COW is turned on, you get only the delta in the instance
directory when using qcow2.
Cheers,
Michael
On Tue, Jan 20, 2015 at 7:40 AM, Dmitry Guryanov
On 14/01/15 23:35, Yagmur Akbulut wrote:
Thanks for the reply. We are running Icehouse.
Is there a back port for this?
There is in RHOSP5 and maybe other productized versions.
I don't know of a publicly available backport.
Pádraig.
___
Mailing
On 12/01/15 19:42, Yagmur Akbulut wrote:
Hi all,
We are working on nova live-migration using Ceph. Before live-migration, Nova
does a check to see if the remote is on shared storage.
In order to make this test pass, we have patched Nova to always return True
in
On 09/04/2014 01:42 PM, Sahid Orentino Ferdjaoui wrote:
Hello,
I would like to request a FFE for 4 changesets to complete the
blueprint serial-ports.
Topic on gerrit:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/serial-ports,n,z
On 09/04/2014 12:58 PM, Nikola Đipanov wrote:
Hi team,
I am requesting the exception for the feature from the subject (find
specs at [1] and outstanding changes at [2]).
Some reasons why we may want to grant it:
First of all all patches have been approved in time and just lost the
gate
On 08/18/2014 03:38 PM, Julien Danjou wrote:
On Thu, Aug 14 2014, Yuriy Taraday wrote:
Hi Yuriy,
[…]
Looking forward to your opinions.
This looks like a good summary of the situation.
I've added a solution E based on pthread, but didn't get very far about
it for now.
In my
+1
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 06/13/2014 02:22 PM, Day, Phil wrote:
I guess the question I’m really asking here is: “Since we know resize down
won’t work in all cases,
and the failure if it does occur will be hard for the user to detect,
should we just block it at the API layer and be consistent across all
On 06/17/2014 11:47 AM, Mahardhika Gilang wrote:
Hi, i've got this warning in nova-compute.log
*Failed to close augeas aug_close: call launch before using this function**
**(in guestfish, don't forget to use the 'run' command)*
is that mean i have to install libguestfs?
thanks
Is this
On 06/17/2014 03:17 PM, Pádraig Brady wrote:
On 06/17/2014 11:47 AM, Mahardhika Gilang wrote:
Hi, i've got this warning in nova-compute.log
*Failed to close augeas aug_close: call launch before using this function**
**(in guestfish, don't forget to use the 'run' command)*
is that mean i have
On 05/28/2014 08:16 AM, Martin Geisler wrote:
Hi everybody,
I'm trying to get my feet wet with OpenStack development, so I recently
tried to submit some small patches. One small thing I noticed was that
some files used
# -*- encoding: utf-8 -*-
to specify the file encoding for both
On 05/26/2014 12:54 PM, Rakesh Sinha wrote:
Hi
I am aware that first instance launch over a Compute Node takes time because
it has to copy image from the Glance Server to the Compute Node.
Since the local copy is available over the Compute now so next time it
launches faster.
I want
On 01/15/2014 02:42 PM, Alexei Kornienko wrote:
If you are working on linux system following can help you:
dd if=/dev/urandom of=/dev/sda bs=4k
That's going to be slow.
The shred tool should be already installed on most Linux systems,
and uses an internal PRNG to write either zeros or random
On 12/26/2013 07:56 AM, cosmos cosmos wrote:
Hello.
My name is Rucia for Samsung SDS.
I had in truouble in volume deleting.
I am developing for supporting big data storage such as hadoop in lvm.
it use as a full disk io for deleting of cinder lvm volume because of dd the
high
On 12/30/2013 12:39 AM, Pádraig Brady wrote:
On 12/29/2013 08:12 AM, Day, Phil wrote:
Hi Folks,
As highlighted in the thread “minimal review period for functional changes”
I’d like to propose that change is https://review.openstack.org/#/c/63209/
is reverted because:
- It causes
On 11/02/2013 02:56 AM, Jeffrey Walton wrote:
On Fri, Nov 1, 2013 at 10:06 PM, David Hill david.h...@ubisoft.com wrote:
Hello Jeff,
I understand that but does that mean it HAS to be done right away?
I mean, performances for the rest of the VMs are sacrificed over security
concern
The full Havana package set is now available in the RDO repos,
for both Fedora 19 and el6 distros including RHEL, Centos and Scientific Linux
etc.
Instructions to get started with these repos are at:
http://openstack.redhat.com/QuickStart
In this release we have:
openstack-swift-1.10.0-2
On 10/17/2013 04:54 PM, Dolph Mathews wrote:
On Thu, Oct 17, 2013 at 10:31 AM, Thomas Goirand z...@debian.org wrote:
On 10/17/2013 09:11 PM, Monty Taylor wrote:
I understand what you are saying and I also understand your frustration.
However, OpenStack does not, as of yet, support SQLAlchemy
On 10/16/2013 02:05 PM, Thomas Goirand wrote:
Hi there,
It appears that in Debian, python-coverage provides the wrapper in
/usr/bin/python-coverage. I tried to push the current maintainer to
provide /usr/bin/coverage, but he doesn't agree. He believes that
coverage is just too generic to be
On 09/23/2013 06:48 AM, Thomas Goirand wrote:
On 09/23/2013 01:36 PM, Thomas Goirand wrote:
On 09/23/2013 11:04 AM, Pádraig Brady wrote:
OpenStack should be compatible with sqlalchemy 0.8.x at this stage,
or should be easily tweaked to be so.
My view as well.
sqlalchemy-migrate
On 09/23/2013 03:36 AM, Thomas Goirand wrote:
On 09/23/2013 05:43 AM, Monty Taylor wrote:
Since we now have at least some integration testing on our global
requirements list, I uploaded https://review.openstack.org/47745 to
see what breaks (though unit tests for individual projects are not
On 09/20/2013 10:47 PM, Michael Still wrote:
Before https://review.openstack.org/#/c/46867/ if file injection of a
mandatory file fails, nova just silently ignores the failure, which is
clearly wrong.
For reference, the original code you're adjusting is
https://review.openstack.org/#/c/18900
On 08/07/2013 06:54 PM, Monty Taylor wrote:
On 08/07/2013 12:53 PM, Joshua Harlow wrote:
I agree triple-o will help a lot here although I would disagree that
package rollback is an illusion. I would call it more of a hard
problem instead since nothing is really impossible :)
illusion
On 08/08/2013 02:10 PM, Monty Taylor wrote:
On 08/05/2013 02:03 PM, Dean Troyer wrote:
[Moving a discussion from https://review.openstack.org/40019 to the ML
to get a wider audience]
We've been around this block more than once so let's get it all
documented in one place and see where to
+1
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 07/08/2013 08:53 AM, Thomas Goirand wrote:
Hi,
Since python-sqlalchemy 0.8.2 has been uploaded to Sid, Quantum is
uninstallable there right now (see #715294).
I am wondering: what's wrong with sqlalchemy = 0.8, so that it is
written explicitly in the requirements that we shouldn't use
+1
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I notice on some projects like nova and quantum (I presume with milestone
proposed commits)
that the 2013.2.b1 tag was created on the now removed milestone-proposed branch.
Therefore `git describe` and `git log --decorate` etc. on master, ignore the
latest tag.
I was wondering if it would be
On 03/28/2013 11:12 AM, Alan Pevec wrote:
Hi all,
we have few open reviews for Keystone stable/folsom, which Adam or I
have submitted or approved, they were only missing second +2 and now
started expiring.
32 matches
Mail list logo
