$ rally verify https://github.com/openstack/nova start
As one of end-users of Rally, I dislike such construction, because I don't
want to remember links to repos, they are too long for me:)
On Wed, Mar 11, 2015 at 12:49 PM, Aleksandr Maretskiy
amarets...@mirantis.com wrote:
The idea is
On Wed, Mar 11, 2015, at 05:59 AM, Sean Dague wrote:
Galera Upstream Testing
---
The majority of deploys run with Galera MySQL. There was a question
about whether or not we could get that into upstream testing pipeline
as that's the common case.
It should be possible
I would think a on v2 extension is needed
for v2.1 , mircoversion is a way but not very sure it's needed.
Best Regards!
Kevin (Chen) Ji 纪 晨
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building,
All,
I will sponsor this.
Patch just needs to be rebased.
Jay
On 03/11/2015 10:20 AM, Tom Barron wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I hereby solicit a feature freeze exception for the NFS backup review [1].
Although only about 140 lines of non-test code, this review
I think part of the problem is that we’re still relying on distribution
packaged dependencies. If you look earlier in the logs for:
http://logs.openstack.org/51/146651/15/check/check-grenade-dsvm/2485c9e/log
s/grenade.sh.txt.gz#_2015-03-11_00_58_45_129 you’ll see that
“python-unittest2” is being
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I hereby solicit a feature freeze exception for the NFS backup review [1].
Although only about 140 lines of non-test code, this review completes
the implementation of the NFS backup blueprint [2]. Most of the
actual work for this blueprint was a
Hi,
I'm working on bug #1420848 which addresses the issue that doing a
service-disable followed by a service-enable against a down compute node
will result in the compute node going up for a while, possibly causing delays
to operations that try to schedule on that compute node.
The
I don’t have any solution just chiming in that I see the same error with
devstack pulled from master on a new ubuntu trusty VM created last night.
'pip install —upgrade wheel’ indicates:
Requirement already up-to-date: wheel in /usr/local/lib/python2.7/dist-packages
Haven’t gotten it cleared
On 03/02/2015 06:24 PM, Jay Pipes wrote:
On 02/25/2015 06:41 AM, Daniel P. Berrange wrote:
On Wed, Feb 25, 2015 at 02:08:32PM +, Gary Kotton wrote:
I understand that this is a high or critical bug but I think that
we need to discuss more on it and try have a more robust model.
What I'm
Here is a compromise option. The pluggable IPAM will be optionally enabled
in Kilo. We could introduce the restriction, but only when pluggable IPAM
is enabled. Support for having a tenant with overlapping IP space, along
with pluggable IPAM would wait until Liberty, when we can fully implement
On 3/12/15, 12:46 AM, Carl Baldwin c...@ecbaldwin.net wrote:
When talking with external IPAM to get a subnet, Neutron will pass
both the cidr as the primary identifier and the subnet_id as an
alternate identifier. External systems that do not allow overlap can
Recall that IPAM driver
Thanks Sean for writing up this report, greatly appreciated.
Comments inline.
Le 11/03/2015 13:59, Sean Dague a écrit :
The last couple of days I was at the Operators Meetup acting as Nova
rep for the meeting. All the sessions were quite nicely recorded to
etherpads here -
It's really fine to create backports, even of other people's commits,
as long as you don't do it too early (and thus make it possible to
forget to update backports in line with newer patch sets of the master
commit and land inconsistent implementations to different release
series) and don't mangle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vulnerable clients allow a TLS protocol downgrade (FREAK)
- ---
### Summary ###
Some client-side libraries, including un-patched versions of OpenSSL,
contain a vulnerability which can allow a man-in-the-middle (MITM) to
force a TLS version downgrade.
The only reason this came up yesterday is because we wanted Solums 'app create'
behavior to be consistent with other openstack services.
However, if heat has a unique stack name constraint and glance\nova don't, then
the argument of consistency does not hold.
I'm still of the opinion that we
On 03/11/2015 12:53 PM, Sylvain Bauza wrote:
Reporting on Scheduler Fails
Apparently, some time recently, we stopped logging scheduler fails
above DEBUG, and that behavior also snuck back into Juno as well
(https://etherpad.openstack.org/p/PHL-ops-nova-feedback
On 12 March 2015 at 10:09, Sean Dague s...@dague.net wrote:
On 03/11/2015 11:26 AM, Clark Boylan wrote:
On Wed, Mar 11, 2015, at 05:59 AM, Sean Dague wrote:
Galera Upstream Testing
---
The majority of deploys run with Galera MySQL. There was a question
about whether or
I'd prefer to go with 1400 UTC unless there's a majority for 1500UTC.
P.S. It's my feeling that ML announcements and conversations are not effective
when taking poll from wider audience so we'd discuss this a bit more in the
next meeting and merge the votes.
Thanks,
-Nikhil
Dev, thanks for bringing up the item about Heat enforcing unique stack names..
My mistake on thinking it supported non-unique stack names. I remember it
working early on, but probably got changed/fixed somewhere along the way.
My argument in IRC was one based on consistency with
On 3/12/15, 2:33 AM, Carl Baldwin c...@ecbaldwin.net wrote:
John,
I think our proposals fit together nicely. This thread is about
allowing overlap within a pool. I think it is fine for an external
IPAM driver to disallow such overlap for now. However, the reference
implementation must
On 03/11/2015 01:21 PM, Tim Bell wrote:
Reporting on Scheduler Fails
Apparently, some time recently, we stopped logging scheduler
fails above DEBUG, and that behavior also snuck back into
Juno as well
(https://etherpad.openstack.org/p/PHL-ops-nova-feedback
On Wed, Mar 11, 2015 at 1:16 PM, Weidong Shao weidongs...@gmail.com wrote:
the url is encoded in the object hash! This somehow entangles the data
storage/validity with its account and makes it difficult to migrate the
data. I guess it is too late to debate on the design of this. Do you know
On 03/11/2015 11:26 AM, Clark Boylan wrote:
On Wed, Mar 11, 2015, at 05:59 AM, Sean Dague wrote:
Galera Upstream Testing
---
The majority of deploys run with Galera MySQL. There was a question
about whether or not we could get that into upstream testing pipeline
as
-Original Message-
From: Jeremy Stanley [mailto:fu...@yuggoth.org]
Sent: 11 March 2015 20:40
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Avoiding regression in project governance
On 2015-03-11 19:06:21 + (+), Tim Bell
On Wed, Mar 11, 2015 at 2:54 PM, John Belamaric jbelama...@infoblox.com wrote:
I was proposing that the reference driver not support it either, and we
only handle that use case via the non-pluggable implementation in Kilo,
waiting until Liberty to handle it in the pluggable implementation.
On Wed, Mar 11, 2015, at 01:47 PM, Mike Bayer wrote:
Hello Cinder -
I’d like to note that for issue
https://bugs.launchpad.net/oslo.db/+bug/1417018, no solution that
actually
solves the problem for Cinder is scheduled to be committed anywhere. The
patch I proposed for oslo.db is on hold,
Discussed in the weekly meeting, plenty of sponsors, agreed to try to get
it through today
On 11 March 2015 at 18:48, Jay S. Bryant jsbry...@electronicjungle.net
wrote:
All,
I will sponsor this.
Patch just needs to be rebased.
Jay
On 03/11/2015 10:20 AM, Tom Barron wrote:
-BEGIN
On 03/11/2015 03:37 PM, Mike Bayer wrote:
Mike Perez thin...@gmail.com wrote:
On 11:49 Wed 11 Mar , Walter A. Boring IV wrote:
We have this patch in review currently. I think this one should
'fix' it no?
Please review.
https://review.openstack.org/#/c/163551/
Looks like it to
Hi Solum team,
In yesterday's team meeting the question of whether Solum should enforce unique
app name constraint
within a tenant came up.
As a recollection, in Solum one can create an 'app' using:
solum app create --plan-file plan-file --name app-name
Currently Solum does support
-Original Message-
From: Sylvain Bauza [mailto:sba...@redhat.com]
Sent: 11 March 2015 17:53
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] readout from Philly Operators Meetup
Thanks Sean for writing up this report, greatly
On Mon, Mar 9, 2015 at 12:27 PM, Weidong Shao weidongs...@gmail.com wrote:
I noticed swauth project is not actively maintained. In my local testing,
swauth did not work after I upgraded swift to latest.
Hrm... I think gholt would be open to patches/support, I know of a number
of deployers of
On Wed, Mar 11, 2015 at 12:49 AM, Nurit Vilosny nur...@mellanox.com wrote:
Hi ,
I would like to ask for a CI permission to start commenting on Nova branch.
Mellanox is engaged in pci pass-through features for quite some time now.
We have an operating Neutron CI for ~2 years, and since
On Wed, Mar 4, 2015 at 1:42 PM, Kyle Mestery mest...@mestery.com wrote:
I'd like to propose that we add Ihar Hrachyshka to the Neutron core
reviewer team. Ihar has been doing a great job reviewing in Neutron as
evidence by his stats [1]. Ihar is the Oslo liaison for Neutron, he's been
doing a
On Tue, Mar 10, 2015, at 05:50 PM, Douglas Mendizabal wrote:
Thanks for the insight, other Doug. :) It appears that this is in part
due to the fact that Tempest has not yet updated to oslo_log and is still
using incubator oslo.log. Can someone from the Tempest team chime in on
what the
Congratulations Ihar!
Edgar
From: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, March 11, 2015 at 1:54 PM
To: OpenStack
Joshua Harlow harlo...@outlook.com wrote:
I've also got the following up:
https://review.openstack.org/#/c/162781/
Which tries the force file descriptors to be closed; although I'm unsure
where the tempest results went (and am rechecking that); maybe it breaks so
badly that tempest
On 2015-03-11 19:06:21 + (+), Tim Bell wrote:
[...]
I think we can make this work. Assuming more than N (to my mind
5 or so) deployments report they are using project X, we can say
that this is used in production/POC/... and the number of
nodes/hypervisors/etc.
This makes it
On Tue, 2015-03-10 at 15:23 -0700, James E. Blair wrote:
The holy grail of this system would be the suitable for production
deployment tag, but no one has figured out how to define it yet.
Are crazy ideas welcome in this phase?
I start with 2 below:
Preface: an idea circulates about visually
On Wed, Mar 11, 2015 at 5:59 AM, Sean Dague s...@dague.net wrote:
The last couple of days I was at the Operators Meetup acting as Nova
rep for the meeting. All the sessions were quite nicely recorded to
etherpads here - https://etherpad.openstack.org/p/PHL-ops-meetup
There was both a
We have this patch in review currently. I think this one should 'fix'
it no?
Please review.
https://review.openstack.org/#/c/163551/
Walt
On 03/11/2015 10:47 AM, Mike Bayer wrote:
Hello Cinder -
I’d like to note that for issue
https://bugs.launchpad.net/oslo.db/+bug/1417018, no solution
On 11:49 Wed 11 Mar , Walter A. Boring IV wrote:
We have this patch in review currently. I think this one should
'fix' it no?
Please review.
https://review.openstack.org/#/c/163551/
Looks like it to me. Would appreciate a +1 from Mike Bayer before we push this
through. Thanks for
The Keystone development community would like to announce the release of
keystonemiddleware 1.5.0.
This release can be installed from the following locations:
* http://tarballs.openstack.org/keystonemiddleware
* https://pypi.python.org/pypi/keystonemiddleware
Detailed changes in this
I've also got the following up:
https://review.openstack.org/#/c/162781/
Which tries the force file descriptors to be closed; although I'm unsure
where the tempest results went (and am rechecking that); maybe it breaks
so badly that tempest doesn't even run?
-Josh
Mike Bayer wrote:
Hello
On 11 March 2015 at 04:27, Fredy Neeser fredy.nee...@solnet.ch wrote:
7: br-ex.1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state
UNKNOWN group default
link/ether e0:3f:49:b4:7c:a7 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.14/24 brd 192.168.1.255 scope global br-ex.1
John,
I think our proposals fit together nicely. This thread is about
allowing overlap within a pool. I think it is fine for an external
IPAM driver to disallow such overlap for now. However, the reference
implementation must support it for backward compatibility and so my
proposal will
-Original Message-
From: Stefano Maffulli [mailto:stef...@openstack.org]
Sent: 11 March 2015 03:16
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Avoiding regression in project governance
On Tue, 2015-03-10 at 15:23 -0700, James E. Blair wrote:
The holy grail
On Tue, Mar 10, 2015, at 10:16 PM, Stefano Maffulli wrote:
On Tue, 2015-03-10 at 15:23 -0700, James E. Blair wrote:
The holy grail of this system would be the suitable for production
deployment tag, but no one has figured out how to define it yet.
Are crazy ideas welcome in this phase?
On 3/10/15, 12:22 AM, Bohai (ricky) bo...@huawei.com wrote:
Hi, stackers
I try to use the Kolla Images and pull them down from docker hub.
I found the size of the image is bigger than what I thought(for example,
the images of docker conductor service is about 1.4GB).
Is it possible to get a
On 11:20 Wed 11 Mar , Tom Barron wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I hereby solicit a feature freeze exception for the NFS backup review [1].
This was granted by the community in the Cinder IRC meeting this morning (sorry
raw log is only available due to irc bot
I've filed a bug here:
https://bugs.launchpad.net/neutron/+bug/1430984
I've outlined the path I'd like to take in the bug description.
- Original Message -
+1 on avoiding changes that break rolling upgrade.
Rolling upgrade has been working so far (at least from my perspective), and
While looking at some other problems yesterday [1][2] I stumbled across
this feature change in Juno [3] which adds a config option
allow_duplicate_networks to the [neutron] group in nova. The default
value is False, but according to the spec [4] neutron allows this and
it's just exposing a
I agree that we should pursue an implementation that allows for duplicate
names, as I think that use case makes sense. I manage several application
deployments that run different concurrent versions of the same application
during blue/green and canary deployment, and I routinely use duplicate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I also agree wilcards do not look solid, and without clear use cases
with reasonable demand from operators, it's better to avoid putting
ourselves into position of supporting the feature for eternity.
We had cases of immature API design rushed into
On 11 March 2015 at 18:21, Robert Collins robe...@robertcollins.net wrote:
...
Since there was no debate on the compat thing, I've thrown up an
etherpad to start the discussion.
https://etherpad.openstack.org/p/ironic-client-ux
Thanks Rob. Michael Davies has a spec [1] that discusses how a
On Wed, Mar 11, 2015 at 4:07 PM, Ihar Hrachyshka ihrac...@redhat.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2015 07:48 PM, Joe Gordon wrote:
Out of sync Quotas --
https://etherpad.openstack.org/p/PHL-ops-nova-feedback L63
The quotas code is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2015 06:54 PM, Kyle Mestery wrote:
On Wed, Mar 4, 2015 at 1:42 PM, Kyle Mestery mest...@mestery.com
mailto:mest...@mestery.com wrote:
I'd like to propose that we add Ihar Hrachyshka to the Neutron
core reviewer team. Ihar has been
My concern is that we are introducing new objects in Neutron that are
scoped to a tenant and we don't have anything else like that right now. For
example, I can create 100 3-tier topologies (router + 3 subnets/networks)
with duplicated names, CIDRs, etc between all of them and it doesn't matter
if
This has been settled and we're not moving forward with it for Kilo. I agree
tenants are an administrative concept, not a networking one so using them for
uniqueness doesn't really make sense.
In Liberty we are proposing a new grouping mechanism, as you call it,
specifically for the purpose of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Should we target it for Kilo? It does not seem right to allow it
slipping into the next release while we know there are operators
relying on the feature.
On 03/11/2015 08:42 PM, Assaf Muller wrote:
I've filed a bug here:
Big +2 on both those, but will leave it up to Alan make the final call
Cheers
On Wed, Mar 11, 2015 at 3:42 PM, Ihar Hrachyshka ihrac...@redhat.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2015 12:21 PM, Alan Pevec wrote:
Hi,
next Icehouse stable point release
On 11 March 2015 at 10:56, Matt Riedemann mrie...@linux.vnet.ibm.com
wrote:
While looking at some other problems yesterday [1][2] I stumbled across
this feature change in Juno [3] which adds a config option
allow_duplicate_networks to the [neutron] group in nova. The default
value is False,
On 11/03/15 12:46 +0100, Ihar Hrachyshka wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2015 12:21 PM, Alan Pevec wrote:
Hi,
next Icehouse stable point release 2014.1.4 has been slipping last
few weeks due to various gate issues, see Recently closed section
in
Hello Folks,
As a follow up of [0] I was working on a proposal for adding the same
sharing capabilities to servicechain constructs. While thinking about the
use cases for doing this, a question came to my mind: How should I deal
with this improvement from a process perspective?
I'm not sure
FWIW I agree with #3 and #4 but not #1 and #2. Spelling is an easy
enough thing to get right and speaks to the quality standard to which
the product is held even in commit messages and comments (consider the
'broken window theory'). Of course everyone makes mistakes (I am a
terrible speller)
On 11/03/15 23:49 +, Kuvaja, Erno wrote:
I'd prefer 1400 as well. But A Foolish Consistency is the Hobgoblin of Little
Minds
Either work for me, as long as someone pings me :P
Flavio
- Erno
-Original Message-
From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com]
Sent:
In summary, we have decided to use the usage notification events emitted by
heat (http://tinyurl.com/oultjm5). This should allow us to detect stack action
completions, and errors (with reasons) which should be enough for a Bay
implementation that does not need to poll. Stack timeouts can be
On Wed, 2015-03-11 at 17:59 -0500, Ed Leafe wrote:
The longer we try to be both sides of this process, the longer we will
continue to have these back-and-forths about stability vs. innovation.
If I understand correctly your model, it works only for users/operators
who decide to rely on a vendor
Hi everyone,
Just a quick reminder that the weekly OpenStack QA team IRC meeting will be
tomorrow Thursday, March 12th at 17:00 UTC in the #openstack-meeting
channel.
The agenda for tomorrow's meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
Anyone is welcome to
On 8 March 2015 at 13:12, Devananda van der Veen
devananda@gmail.com wrote:
Hi folks,
Recently, I've been thinking more of how users of our python client
will interact with the service, and in particular, how they might
expect different instances of Ironic to behave.
We added several
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2015 12:21 PM, Alan Pevec wrote:
Hi,
next Icehouse stable point release 2014.1.4 has been slipping last
few weeks due to various gate issues, see Recently closed section
in https://etherpad.openstack.org/p/stable-tracker for details.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2015 02:40 PM, Jeremy Stanley wrote:
I think we can make this work. Assuming more than N (to my mind
5 or so) deployments report they are using project X, we can say
that this is used in production/POC/... and the number of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2015 07:48 PM, Joe Gordon wrote:
Out of sync Quotas --
https://etherpad.openstack.org/p/PHL-ops-nova-feedback L63
The quotas code is quite racey (this is kind of a known if you look
at the bug tracker). It was actually
One of my peers mentioned that people talked about dnsmasq scale problems at
paris summit. So what was the scale problems? Currently, there is one dnsmasq
instance for each subnet. And pool management and allocation seemed to be done
at neutron. Thus dnsmasq is light-weighted. So if
On 03/11/2015 08:10 AM, Robert Collins wrote:
The wheel has been removed from PyPI and anyone installing testtools
1.7.0 now will install from source which works fine.
I noticed the centos7 job failed with the source version.
The failing job was [1] where the back-trace looks like ~45 songs on
On 12 March 2015 at 12:07, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2015 07:48 PM, Joe Gordon wrote:
Out of sync Quotas --
https://etherpad.openstack.org/p/PHL-ops-nova-feedback L63
The quotas code is quite racey
I'd prefer 1400 as well. But A Foolish Consistency is the Hobgoblin of Little
Minds
- Erno
-Original Message-
From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com]
Sent: 11 March 2015 20:40
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re:
On 12 March 2015 at 12:37, Ian Wienand iwien...@redhat.com wrote:
On 03/11/2015 08:10 AM, Robert Collins wrote:
The wheel has been removed from PyPI and anyone installing testtools
1.7.0 now will install from source which works fine.
I noticed the centos7 job failed with the source version.
The easy way to scale it is to just launch more dhcp agents. The scaling
issue arises when a single dhcp agent is managing thousands of dnsmasq
instances and interfaces.
On Wed, Mar 11, 2015 at 4:07 PM, Wanjing Xu wanjing...@hotmail.com wrote:
One of my peers mentioned that people talked about
On 03/04/2015 09:33 AM, Danny Al-Gaaf wrote:
Am 04.03.2015 um 15:18 schrieb Csaba Henk:
Hi Danny,
- Original Message -
From: Danny Al-Gaaf danny.al-g...@bisect.de
To: Deepak Shetty dpkshe...@gmail.com
Cc: OpenStack Development Mailing List (not for usage questions)
Also, can
https://review.openstack.org/#/c/163647https://review.openstack.org/#/c/163647/2
be considered. all it does is move code from the accepted nfs.py to posix.py
as described in the approved spec. This enables all posix complient file
systems to be used, such as lustre instead of just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2015 06:34 PM, Gabriel Bezerra wrote:
Em 10.03.2015 14:24, Carl Baldwin escreveu:
Neutron currently does not enforce the uniqueness, or
non-overlap, of subnet cidrs within the address scope for a
single tenant. For example, if a tenant
I can see how to do a v2 extension following the example given for
extended_services.py and extended_services_delete.py. That seems to be working now.
I'm not at all clear on how to go about doing the equivalent for v2.1. Does
that use the api/openstack/compute/plugins/v3/ subdirectory?
On 11 Mar 2015, at 11:59 pm, Sean Dague s...@dague.net wrote:
Nova Rolling Upgrades
-
Most people really like the concept, couldn't find anyone that had
used it yet because Neutron doesn't support it, so they had to big
bang upgrades anyway.
I couldn’t make it to
Hi all,
Following the code reviews lately I've noticed that we (the fan club seems to
be growing on weekly basis) have been growing culture of nitpicking [1] and
bikeshedding [2][3] over almost every single change.
Seriously my dear friends, following things are not worth of -1 vote if even
a
Alex,
* rally plugin should be a part of project (for example, located in
functional tests directory)
There are 2 issues with such solution:
1) If rally didn't load plugin, command rally verify project won't
exist
2) Putting some strange Rally plugin to source of other projects will be
Hi-
Regarding the CI offline mails, I previously received an email from Anita.
Please find the summary below.
Please set your account listing to down on this page:
https://wiki.openstack.org/wiki/ThirdPartySystems
Following these instructions: If your system is going down or having problems,
Hi ,
I would like to ask for a CI permission to start commenting on Nova branch.
Mellanox is engaged in pci pass-through features for quite some time now.
We have an operating Neutron CI for ~2 years, and since the pci pass-through
features are part of Nova as well, we would like to start
On 09/03/15 15:54, Doug Hellmann wrote:
Not everyone realizes that many of the distros run our tests against the
packages they build, too. So our tool choices trickle downstream beyond
our machines and our CI environment. In this case, because the tool is a
linter, it seems like the
The ci runs: `cp -r contrib/tempest/tempest /opt/stack/tempest` so all you
need to do is add you're file and it will get copied into tempest.
Aaron
On Tue, Mar 10, 2015 at 10:31 AM, Wong, Hong hong.w...@hp.com wrote:
Hi Aaron,
I just want to confirm how CI is running the congress tempest
Hi Devs,
As another alternative we can use start/stop API’s instead of shelve/unshelve
the instance.
Following is the details of start/stop and shelve/unshelve on the basis of
cpu/memory/disk released and fast respawning.
API’S: start/stop
cpu/memory released: No
Disk released: No
Fast
[resent with a clarification of what [6] is doing towards EoM]
OK, I looked at the devstack patch
[6] Configure mtu for ovs with the common protocols
but no -- it doesn't do the job for the VLAN-based separation
of native and encapsulated traffic, which I'm using in [1] for
a clean
Hello OpenStackers!
To meet the requirement of an officially elected PTL, we're running elections
for the Group Based Policy (GBP) PTL for Kilo and Liberty cycles. Schedule and
policies are fully aligned with official OpenStack PTLs elections.
You can find more information in the
The idea is great, but IMHO we can move all project-specific code out of
rally, so:
* rally plugin should be a part of project (for example, located in
functional tests directory)
* use {project url} instead of {project name} in rally verify command,
example:
$ rally verify
OK, I looked at the devstack patch
[6] Configure mtu for ovs with the common protocols
but no -- it doesn't do the job for the VLAN-based separation
of native and encapsulated traffic, which I'm using in [1] for
a clean (correct MTUs ...) VXLAN setup with single-NIC compute nodes.
As shown
On Wed, Mar 11, 2015 at 09:01:04AM +, ELISHA, Moshe (Moshe) wrote:
Hey,
Can someone please share the current status of the Autoscaling signals to
allow parameter passing for UserData blueprint -
https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters.
Hi,
next Icehouse stable point release 2014.1.4 has been slipping last few
weeks due to various gate issues, see Recently closed section in
https://etherpad.openstack.org/p/stable-tracker for details.
Branch looks good enough now to push the release tomorrow (Thursdays
are traditional release
2015-03-10 23:21 GMT+08:00 Hongbin Lu hongbin...@gmail.com:
Hi Adrian,
On Mon, Mar 9, 2015 at 6:53 PM, Adrian Otto adrian.o...@rackspace.com
wrote:
Magnum Team,
In the following review, we have the start of a discussion about how to
tackle bay status:
On Wed, Mar 11, 2015 at 7:01 PM, ELISHA, Moshe (Moshe)
moshe.eli...@alcatel-lucent.com wrote:
Hey,
Can someone please share the current status of the “Autoscaling signals to
allow parameter passing for UserData” blueprint -
Hey,
Can someone please share the current status of the Autoscaling signals to
allow parameter passing for UserData blueprint -
https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters.
We have a very concrete use case that require passing parameters on scale out.
What is the best
Hi,
Not 100% sure that I understand. This is for the BP¹s and specs that were
approved for Kilo. Bug fixes if I understand are going to be reviewed
until the release of Kilo.
Is launchpad not a sufficient source for highlighting bugs?
Thanks
Gary
On 3/11/15, 2:13 PM, John Garbutt
1 - 100 of 135 matches
Mail list logo
