On Fri, 11 Oct 2013 08:27:54 -0700
Dan Smith d...@danplanet.com wrote:
Agreed, a stable virt driver API is not feasible or healthy at this
point, IMHO. However, it doesn't change that much as it is. I know
I'll be making changes to virt drivers in the coming cycle due to
objects and I have
+1 for me. And I am willing to be a volunteer.
2013/10/12 Joe Gordon joe.gord...@gmail.com
On Thu, Oct 10, 2013 at 4:47 AM, Vladik Romanovsky
vladik.romanov...@enovance.com wrote:
Hello everyone,
I have been recently working on a migration bug in nova (Bug #1233184).
I noticed that
Happy Saturday everyone,
Due to major issues detected in key features during RC1 testing, we just
published new Havana release candidates for OpenStack Compute (Nova)
and OpenStack Orchestration (Heat).
You can find RC2 tarballs and lists of fixed bugs at:
Really a good idea! It's painful for us to summit a patch, then waiting for
reviewing because of the time difference. It's more painful if we get a -1
after getting up. It's very appreciated that if someone could help, and we
can help others, too.
2013/10/12 Nikhil Manchanda nik...@manchanda.me
Hi,
Probably the last before Monday: due to various issues detected in RC1
testing, we just created a new Havana release candidate for OpenStack
Networking (Neutron).
You can find the RC2 tarball and the list of fixed bugs at:
https://launchpad.net/neutron/havana/havana-rc2
This is hopefully
On Sat, Oct 12, 2013 at 8:59 AM, Nick Maslov azp...@gmail.com wrote:
Hi,
I have following setup:
1) infrastructure node, IP in bond, hosting following KVM guests:
1.1) Postgres KVM guest
1.2) MQ KVM guest
1.3) DNS KVM guest
1.4) Control node with Nova API, Cinder API, Quantum Server,
If the idea is to gate with nova-extra-drivers this could lead to a
rather painful process to change the virt driver API. When all the
drivers are in the same tree all of them can be updated at the same
time as the infrastructure.
Right, and I think if we split those drivers out, then we do
From the user perspective, splitting off the projects seems to be focussing on
the ease of commit compared to the final user experience. An 'extras' project
without *strong* testing co-ordination with packagers such as SUSE and RedHat
would end up with the consumers of the product facing the
From the user perspective, splitting off the projects seems to be
focussing on the ease of commit compared to the final user
experience.
I think what you describe is specifically the desire that originally
spawned the thread: making the merging of changes to the hyper-v driver
faster by
FYI
On 10/10/13 9:43 PM, Russell Bryant rbry...@redhat.com wrote:
Greetings,
We already have more proposals for the Nova design summit track than
time slots. Please get your proposals in as soon as possible, and
ideally no later than 1 week from today - Thursday, October 17. At that
point we
Yup, it seems to be hypervisor specific. I have added in the Vmware support
following you correcting in the Vmware driver.
Thanks
Gary
From: Matt Riedemann mrie...@us.ibm.commailto:mrie...@us.ibm.com
Reply-To: OpenStack Development Mailing List
On 12.10.2013, at 20:04, Tim Bell tim.b...@cern.ch wrote:
From the user perspective, splitting off the projects seems to be focussing
on the ease of commit compared to the final user experience. An 'extras'
project without *strong* testing co-ordination with packagers such as SUSE
On 12.10.2013, at 20:22, Dan Smith d...@danplanet.com wrote:
From the user perspective, splitting off the projects seems to be
focussing on the ease of commit compared to the final user
experience.
I think what you describe is specifically the desire that originally
spawned the thread:
Hi folks,
I was wondering in general how providers can customize service features,
based on their capabilities (better or worse than reference). I could
create
a Summit session topic on this, but wanted to know if this is something
that
has already been addressed or if a different
There are reviews up now to add user accounts for the TripleO run
OpenStack reference cloud
(https://wiki.openstack.org/wiki/TripleO/TripleOCloud).
To be eligible for an account, you need to be a TripleO ATC, or have
some use case which the TripleO PTL considers worthwhile (e.g. just
ask :)).
To
From: Alessandro Pilotti [apilo...@cloudbasesolutions.com]
Sent: 12 October 2013 20:21
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Hyper-V] Havana status
1) All the drivers will still be part of Nova.
2) One official project
4) Periodically, code from the new project(s) must be merged into Nova.
Only Nova core reviewers will have obviously +2a rights here.
I propose to do it on scheduled days before every milestone, differentiated
per driver to distribute the review effort (what about also having Nova core
On Sat, Oct 12, 2013 at 12:21 PM, Alessandro Pilotti
apilo...@cloudbasesolutions.com wrote:
On 12.10.2013, at 20:22, Dan Smith d...@danplanet.com wrote:
From the user perspective, splitting off the projects seems to be
focussing on the ease of commit compared to the final user
Hi,
I just had a look at the python-swiftclient reviews in Gerrit and noticed that
Kui Shi and I are working on the same stuff, but I'm guessing Kui didn't see
that I had proposed a number of Python 3 changes from a few weeks ago. Now that
there are reviews and a web of dependent branches
Co-reviewing each other's patches and discussing changes in #openstack-swift
would be good ways to ensure that you are working in the same direction.
--John
On Oct 12, 2013, at 3:49 PM, Brian Curtin brian.cur...@rackspace.com wrote:
Hi,
I just had a look at the python-swiftclient reviews
On 13.10.2013, at 01:26, Joe Gordon
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:
On Sat, Oct 12, 2013 at 12:21 PM, Alessandro Pilotti
apilo...@cloudbasesolutions.commailto:apilo...@cloudbasesolutions.com wrote:
On 12.10.2013, at 20:22, Dan Smith
On 13.10.2013, at 01:09, Dan Smith d...@danplanet.com wrote:
4) Periodically, code from the new project(s) must be merged into Nova.
Only Nova core reviewers will have obviously +2a rights here.
I propose to do it on scheduled days before every milestone, differentiated
per driver to
On Oct 12, 2013, at 5:59 PM, John Dickinson m...@not.mn wrote:
Co-reviewing each other's patches and discussing changes in #openstack-swift
would be good ways to ensure that you are working in the same direction.
--John
Kui ended up abandoning his changes and I'm going to review them to
There is also a tempest patch now to ease some of the libvirt-specific
keys checked in the new diagnostics tests there:
https://review.openstack.org/#/c/51412/
To relay some of my concerns that I put in that patch:
I'm not sure how I feel about this. It should probably be more generic but
I
Have you read the docs about nova baremetal ? The questions you're
asking - about bootstrapping and about a baremetal agent - don't make
any sense to me ;)
These are the needed steps:
- install openstack
- build a deploy ramdisk and kernel
- put them in glance
- configure nova baremetal as
Thanks Dolph and Mark for the welcome and guidance,
Will get start based on the pointers.
-Mayank
On Fri, Oct 11, 2013 at 8:06 PM, Mark McClain mark.mccl...@dreamhost.comwrote:
On Oct 11, 2013, at 9:14 AM, Dolph Mathews dolph.math...@gmail.com
wrote:
On Friday, October 11, 2013, Mayank
Hi,
I agree with Matt here. This is not broad enough. One option is to have a
tempest class that overrides for various backend plugins. Then the test can be
haredednd for each driver. I am not sure if that is something that has been
talked about.
Thanks
Gary
From: Matt Riedemann
27 matches
Mail list logo
