Am 20.06.2015 um 01:59 schrieb John Griffith john.griffi...@gmail.com:
* The BaseVD represents the functionality we require from all drivers.
Yep
* The additional ABC classes represent features that are not required yet.
* These are represented by classes because some features require
On Mon, Jun 22, 2015 at 10:47:39AM EDT, Salvatore Orlando wrote:
I would probably start with something for enabling the L2 agent to process
features such as QoS and security groups, working on the OVS agent, and
then in a second step abstract a driver interface for communicating with
the data
On 06/22/2015 05:07 AM, Sean Dague wrote:
On 06/22/2015 04:33 AM, Robert Collins wrote:
You may have noticed the every repo has just been spammed with some
no-op changes where specifiers are re-ordered such as in
https://review.openstack.org/#/c/193973/1/test-requirements.txt
where
Thomas,
This may be of interest to you as well:
http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html
On Mon, Jun 22, 2015 at 12:57 PM, Davanum Srinivas dava...@gmail.com wrote:
Thomas,
here's a review for qpid
https://review.openstack.org/#/c/193804/
On 06/22/2015 01:15 PM, Michael Krotscheck wrote:
Having _just_ done this, a couple of suggestions.
- If the middleware is NOT optional - that is, it provides some kind of
a fundamental component or specification of the API, like ETag caching,
CORS, or DB Session management - then the
I'm sorry it does not work still with this commit:
https://review.openstack.org/#/c/181007/
I think this commit is for another feature, we does not use keystone like
idp. We use shibboleth like idp:
http://docs.openstack.org/developer/keystone/configure_federation.html
According to the next
I'm torn on this. Pedantically option A makes the most sense, but option B
gives us more control over the supporting modules. I like having OpenStack
CI run on vswitch and ceph rather than the typical github merge process.
On Mon, Jun 22, 2015 at 11:05 AM, Richard Raseley rich...@raseley.com
On Mon, 2015-06-22 at 18:10 +0100, Daniel P. Berrange wrote:
On Mon, Jun 22, 2015 at 11:10:40AM -0500, Kevin L. Mitchell wrote:
On Sat, 2015-06-20 at 21:35 +0100, Daniel P. Berrange wrote:
In general I would say that is an unsupported deployment scenario to
have other random virt guests
Thomas,
here's a review for qpid
https://review.openstack.org/#/c/193804/
-- dims
On Mon, Jun 22, 2015 at 12:42 PM, Thomas Goirand z...@debian.org wrote:
On 06/16/2015 03:22 PM, Sean Dague wrote:
FYI,
One of the things that came out of the summit for Devstack plans going
forward is to trim
On Mon, Jun 22, 2015 at 11:10:40AM -0500, Kevin L. Mitchell wrote:
On Sat, 2015-06-20 at 21:35 +0100, Daniel P. Berrange wrote:
In general I would say that is an unsupported deployment scenario to
have other random virt guests running on a nova compute node.
On the other hand, this is
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4983776e190c8dbc
how is the top pick not the author of the book of five rings [1]
-Clay
1. https://en.wikipedia.org/wiki/The_Book_of_Five_Rings
On Mon, Jun 22, 2015 at 7:07 AM, Monty Taylor mord...@inaugust.com wrote:
Hey all!
The M
Team,
I’d like to propose Lingxian Kong (xylan_kong) to Mistral core team.
Over the last ~6 months Lingxian showed really strong technical skills,
provided a series of very high quality reviews and has been very active in our
IRC channel. He also has a solid vision about Mistral future. His
Hi,
+1 for Lingxian!
On Mon, Jun 22, 2015 at 7:08 PM, Nikolay Makhotkin nmakhot...@mirantis.com
wrote:
Hi,
+1 for Lingxian!
--
Best Regards,
Nikolay
--
Best Regards,
Nikolay
__
OpenStack Development Mailing List
Thanks everyone for participating our meeting today.
Meeting minutes:
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-06-22-16.00.html
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-06-22-16.00.html
Meeting log:
On Sat, 2015-06-20 at 21:35 +0100, Daniel P. Berrange wrote:
In general I would say that is an unsupported deployment scenario to
have other random virt guests running on a nova compute node.
On the other hand, this is exactly how compute nodes themselves are
often deployed—a random guest on
On 06/22/2015 12:41 AM, Osanai, Hisashi wrote:
On Saturday, June 20, 2015 11:16 AM, Adam Young wrote:
What situations does a shared policy file require?
For example, there are policy files for Nova and Cinder and they have
same targets such as
context_is_admin, admin_or_owner and default.
A
Hi all,
The Third Party CI Working Group is meeting at the new time this week -
1700UTC Tuesday, June 23rd in #openstack-meeting.
The agenda for the meeting is here:
https://wiki.openstack.org/wiki/Meetings/ThirdParty
We will be working on the CI systems monitoring dashboard hosting spec and
Thanks John.
I’m also not sure what the future would be, but I’d say that it would be nice to
have a hybrid OpenStack cluster of both VM/App-Container flavor. And yes, it is
more about a unified model between Nova and Magnum.
Best, Peng
- Hyper -
I am currently hoping to build consensus (or seek clarity if I am the
only one with this question) about the appropriate scope for our 'Puppet
Modules' project.
The question in my mind is if we:
A) Only include those modules which represent a 1:1 mapping with other
OpenStack projects.
B)
On 06/22/2015 10:15 AM, Yaroslav Lobankov wrote:
Hello everyone,
I have some questions about the bug triage procedure for Tempest:
1. Some bugs in Tempest have status Fix committed. Should we move
statuses of these bugs to Fix released?
Yes, tempest doesn't have the kind of releases where Fix
On Mon, Jun 22, 2015 at 11:41:56AM -0400, David Kranz wrote:
On 06/22/2015 10:15 AM, Yaroslav Lobankov wrote:
Hello everyone,
I have some questions about the bug triage procedure for Tempest:
1. Some bugs in Tempest have status Fix committed. Should we move
statuses of these bugs to Fix
Hi all,
Lately I've been giving some thought to how we might enable easier
composability, and in particular how we can make it easier for folks to
plug in deeply nested optional extra logic, then pass data in via
parameter_defaults to that nested template.
Here's an example of the use-case I'm
Having _just_ done this, a couple of suggestions.
- If the middleware is NOT optional - that is, it provides some kind of a
fundamental component or specification of the API, like ETag caching, CORS,
or DB Session management - then the middleware should be added during the
app initialization
On 06/22/2015 10:40 AM, Dmitry Tantsur wrote:
On 06/22/2015 04:19 PM, Devananda van der Veen wrote:
Hi John,
Thanks for the excellent summary! I found it very helpful to get caught
up. I'd like to make sure I understand the direction ahc is going. A
couple questions...
Thanks for your
On 2015-06-22 21:05:11 +1000 (+1000), Michael Still wrote:
Sure, except where the thing isn't in pip... I just learned tonight
that the libosinfo thing in the review at the start of this thread is
a c library and some gobject black magic. I think we want it, but it
will never work as a pip
On 06/16/2015 03:22 PM, Sean Dague wrote:
FYI,
One of the things that came out of the summit for Devstack plans going
forward is to trim it back to something more opinionated and remove a
bunch of low use optionality in the process.
One of those branches to be trimmed is all the support
On 06/22/2015 12:19 PM, Steven Hardy wrote:
Hi all,
Lately I've been giving some thought to how we might enable easier
composability, and in particular how we can make it easier for folks to
plug in deeply nested optional extra logic, then pass data in via
parameter_defaults to that nested
On 06/22/15 20:10, Daniel P. Berrange wrote:
On Mon, Jun 22, 2015 at 11:10:40AM -0500, Kevin L. Mitchell wrote:
On Sat, 2015-06-20 at 21:35 +0100, Daniel P. Berrange wrote:
In general I would say that is an unsupported deployment scenario to
have other random virt guests running on a nova
I missed this one!, congratulations Rosella :-)
Anna Kamyshnikova mailto:akamyshnik...@mirantis.com
20 Jun 2015 11:55via Postbox
https://www.postbox-inc.com/?utm_source=emailutm_medium=sumlinkutm_campaign=reach
Congratulations Rossella!
Excerpts from Doug Hellmann's message of 2015-06-22 10:50:06 -0400:
Excerpts from Sean Dague's message of 2015-06-22 09:02:02 -0400:
On 06/22/2015 08:58 AM, Doug Hellmann wrote:
Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400:
In extracting the contract for RPC backends in
Hi all!
Recently murano team has recorded some demos describing features,
introduced in Kilo.
They can be found at murano wiki page [1].
Demo - is the easiest way to stay in touch with project news!
The list of updated demos:
- Importing Murano Packages from Murano Repository
Greetings all stackers,
I propose that we add Ruby Loo[1] to the automaton-core team.
Ruby has been actively contributing to automaton[2] for a while now,
both in helping make automaton better via reviews (she has been involved
from the start in helping sanity check that code) and helping get
On Thu, Jun 18, 2015 at 2:24 PM, Colleen Murphy coll...@gazlene.net wrote:
Now that we have the basic beaker-rspec framework set up in the modules
and working in infra's CI, we need to start making our testing aware of
Zuul dependencies. The infra team is facing similar challenges so it would
Hi everyone,
The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday June 23rd, at 19:00 UTC in #openstack-meeting
Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)
Everyone
From: Jay Dobies jason.dob...@redhat.com
To: openstack-dev@lists.openstack.org
Date: 22/06/2015 19:22
Subject: Re: [openstack-dev] [heat][tripleo]Recursive validation for
easier composability
On 06/22/2015 12:19 PM, Steven Hardy wrote:
Hi all,
Lately I've been giving some thought to
+1
On Mon, Jun 22, 2015 at 2:55 PM, Doug Hellmann d...@doughellmann.com wrote:
Excerpts from Joshua Harlow's message of 2015-06-22 10:59:27 -0700:
Greetings all stackers,
I propose that we add Ruby Loo[1] to the automaton-core team.
Ruby has been actively contributing to automaton[2] for a
On 06/22/2015 04:19 PM, Devananda van der Veen wrote:
Hi John,
Thanks for the excellent summary! I found it very helpful to get caught
up. I'd like to make sure I understand the direction ahc is going. A
couple questions...
Let me add my $0.5 :)
I see that ahc is storing its information in
On 06/22/2015 10:36 AM, Davanum Srinivas wrote:
Sean,
Can we please add a bit about what things in devstack can they assume
to be available when their script is running (example: can they use
stuff from functions-common without actually sourcing it?)
Sure, the answer is that
Excerpts from Sean Dague's message of 2015-06-22 09:02:02 -0400:
On 06/22/2015 08:58 AM, Doug Hellmann wrote:
Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400:
In extracting the contract for RPC backends in devstack (to have most of
them live in plugins) one bit of an edge
On 22/06/15 09:02 AM, Sean Dague wrote:
On 06/22/2015 08:58 AM, Doug Hellmann wrote:
Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400:
In extracting the contract for RPC backends in devstack (to have most of
them live in plugins) one bit of an edge case was discovered.
On 22/06/15 15:11, Daniel P. Berrange wrote:
On Mon, Jun 22, 2015 at 11:28:35AM +0100, neil.jer...@metaswitch.com wrote:
It seems like we're possibly stuck now on the VIF plugin script spec [1];
there being core comments in apparently conflicting directions. I wonder if
it's still feasible
I see Kyle's point that this is not something in-scope for liberty at this
stage.
However, on the other hand I would rather avoid having multiple agents on
the compute node performing various tasks in an un-coordinated way (well,
actually relying on neutron-server coordination).
QoS is an
Hi,
I see that ahc is storing its information in swift. That's clever, but if
Ironic provided a blob store for each node, would that be better?
I can try to answer that. The initial implementation was doing that
but, AHC collect a fine-grained amount of data, e.g:
* it runs benchmark on all
Hi Devananda,
The git history appears to be squashed [1], and most files don't have an
attribution header [2], and none of the headers refer to the company who
appears to be behind this (Huawei). What's the rationale for these
inconsistencies, and who is actually
Excerpts from Michael Still's message of 2015-06-22 21:05:11 +1000:
Sure, except where the thing isn't in pip... I just learned tonight
that the libosinfo thing in the review at the start of this thread is
a c library and some gobject black magic. I think we want it, but it
will never work as
Excerpts from Joshua Harlow's message of 2015-06-22 10:59:27 -0700:
Greetings all stackers,
I propose that we add Ruby Loo[1] to the automaton-core team.
Ruby has been actively contributing to automaton[2] for a while now,
both in helping make automaton better via reviews (she has been
Hi! Just as an FYI, we use this for a dashboard:
https://github.com/rackerlabs/onmetal-dashboard
That might be useful when moving forward with using Horizon or the
ironic-dashboard project.
Mario
On Thu, Jun 18, 2015 at 7:43 PM, niuzhenguo niuzhen...@huawei.com wrote:
Hi Thai Q Tran,
On 06/22/2015 03:27 PM, Monty Taylor wrote:
On 06/22/2015 02:49 PM, Doug Hellmann wrote:
We have quite a long list of patches to the openstack/requirements
repository, many of which are straightforward changes to increase the
minimums for libraries we develop within the community (meaning we
On Mon, Jun 22, 2015 at 2:43 PM, Doug Hellmann d...@doughellmann.com
wrote:
Excerpts from Sean Dague's message of 2015-06-22 13:30:44 -0400:
On 06/22/2015 01:15 PM, Michael Krotscheck wrote:
Having _just_ done this, a couple of suggestions.
- If the middleware is NOT optional - that
Hi Everyone,
I'd like to propose we add Jordan Pittier (jordanP) to the tempest core team.
Jordan has been a steady contributor and reviewer on tempest over the past few
cycles and he's been actively engaged in the Tempest community. Jordan has had
one of the higher review counts on Tempest for
+1
Lingxian, keep up with the good work. :D
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
On 6/22/2015 4:32 PM, Russell Bryant wrote:
On 06/22/2015 05:23 PM, Matt Riedemann wrote:
The check-tempest-dsvm-cells job has been in nova's check queue since
January as non-voting and has been stable for a couple of weeks now, so
before it's regressed melwitt proposed a change to making it
+1 :-)
2015年6月23日(火) 5:24 Matthew Treinish mtrein...@kortar.org:
Hi Everyone,
I'd like to propose we add Jordan Pittier (jordanP) to the tempest core
team.
Jordan has been a steady contributor and reviewer on tempest over the past
few
cycles and he's been actively engaged in the Tempest
+1 :)
On 2015年6月23日(火) at 5:30 Matthew Treinish mtrein...@kortar.org wrote:
Hi Everyone,
I'd like to propose we add Jordan Pittier (jordanP) to the tempest core
team.
Jordan has been a steady contributor and reviewer on tempest over the past
few
cycles and he's been actively engaged in
Hi,
A brief update on the issue that sparked this thread:
A little over a week ago, bug [1] was filed. The gist of that was that the
switch to pymysql unveiled a number of latent race conditions that made
Neutron unstable.
To try and nip these in the bud, the Neutron team filed a number of
not a core myself, apologies if this is spamming, but +1. Jordan's been
a great help.
On 22/06/15 04:23 PM, Matthew Treinish wrote:
Hi Everyone,
I'd like to propose we add Jordan Pittier (jordanP) to the tempest core team.
Jordan has been a steady contributor and reviewer on tempest over the
Anyway, if you want to print t-shirts once legal is cleared, here's a
vintage football idea [1].
Little and pointless trivia fact: Como calcio was sponsored for a few years
in the 80s by Mita copiers - now known as Kyocera.
Salvatore
[1]
The check-tempest-dsvm-cells job has been in nova's check queue since
January as non-voting and has been stable for a couple of weeks now, so
before it's regressed melwitt proposed a change to making it voting and
gating on nova changes [1].
I raised a concern in that change that the
On 06/22/2015 05:23 PM, Matt Riedemann wrote:
The check-tempest-dsvm-cells job has been in nova's check queue since
January as non-voting and has been stable for a couple of weeks now, so
before it's regressed melwitt proposed a change to making it voting and
gating on nova changes [1].
I
On 06/22/15 at 04:23pm, Matt Riedemann wrote:
The check-tempest-dsvm-cells job has been in nova's check queue since
January as non-voting and has been stable for a couple of weeks now,
so before it's regressed melwitt proposed a change to making it
voting and gating on nova changes [1].
I
On Mon, Jun 22, 2015 at 2:27 PM Adam Young ayo...@redhat.com wrote:
On 06/20/2015 10:28 AM, Flavio Percoco wrote:
As promissed: https://review.openstack.org/#/c/193804/
Cheers,
You can't deprecate a driver without providing a viable alternative.
Right now, QPID is the only driver
Hi Richard,
On 06/22/2015 01:05 PM, Richard Raseley wrote:
I am currently hoping to build consensus (or seek clarity if I am the
only one with this question) about the appropriate scope for our 'Puppet
Modules' project.
The question in my mind is if we:
A) Only include those modules
On 23/06/15 06:49, Thomas Spatzier wrote:
From: Jay Dobies jason.dob...@redhat.com
To: openstack-dev@lists.openstack.org
Date: 22/06/2015 19:22
Subject: Re: [openstack-dev] [heat][tripleo]Recursive validation for
easier composability
On 06/22/2015 12:19 PM, Steven Hardy wrote:
Hi all,
On Mon, 22 Jun 2015, Sean Dague wrote:
Could we deprecate the use of tranport_url in ceilometermiddleware and
move to an actual oslo.config file somewhere instead? That would bring
it in line with the rest of the RPC configuration for services, and
ensure that all connections in a cluster have
bindep looks quite cool, and I think would do what I am after here.
That's especially true if we use its profiles support. I like the idea
that we can hand some form of documentation to distros that verifies
that they've noticed all the dependancies we've added in a given
release cycle.
Cheers,
On 6/22/2015 4:38 PM, Matt Riedemann wrote:
On 6/22/2015 4:32 PM, Russell Bryant wrote:
On 06/22/2015 05:23 PM, Matt Riedemann wrote:
The check-tempest-dsvm-cells job has been in nova's check queue since
January as non-voting and has been stable for a couple of weeks now, so
before it's
I'm
On Mon, Jun 22, 2015 at 8:19 AM John Trowbridge tr...@redhat.com wrote:
On 06/22/2015 10:40 AM, Dmitry Tantsur wrote:
On 06/22/2015 04:19 PM, Devananda van der Veen wrote:
Hi John,
Thanks for the excellent summary! I found it very helpful to get caught
up. I'd like to make sure I
Dear PTLs, cross-project liaisons and other interested parties:
We have a cross-project meeting tomorrow (June 23rd) at 21:00 UTC,
with the following agenda:
- Team announcements (horizontal, vertical, diagonal)
- Return request-id to caller (use thread local to store request-id)
- Main use
On 22/06/15 06:39 PM, Chris Dent wrote:
On Mon, 22 Jun 2015, Sean Dague wrote:
Could we deprecate the use of tranport_url in ceilometermiddleware and
move to an actual oslo.config file somewhere instead? That would bring
it in line with the rest of the RPC configuration for services, and
Oh - one more thing. If ahc-tools depends on data gathered by
enovance/hardware, then I'm not sure it makes sense to import one to
openstack/ without the other.
-Deva
On Mon, Jun 22, 2015 at 5:08 PM Devananda van der Veen
devananda@gmail.com wrote:
I'm
On Mon, Jun 22, 2015 at 8:19 AM
+1 :)
On Tue, Jun 23, 2015 at 5:23 AM, Matthew Treinish mtrein...@kortar.org
wrote:
Hi Everyone,
I'd like to propose we add Jordan Pittier (jordanP) to the tempest core
team.
Jordan has been a steady contributor and reviewer on tempest over the past
few
cycles and he's been actively
Hi,
This is a reminder that we’ll have a team meeting today at 16.00 UTC at
#openstack-meeting.
Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Liberty-1 status
BP:
https://blueprints.launchpad.net/mistral/+spec/mistral-explicit-task-parameters
It seems like we're possibly stuck now on the VIF plugin script spec [1];
there being core comments in apparently conflicting directions. I wonder if
it's still feasible for a version of this to land during Liberty?
[1] https://review.openstack.org/#/c/162468/
I plan to reread everyone's
Hi,
I'm using the designate stable/kilo and BIND9.
After new Bind9 server created,
how should I set the existing domain information to new BIND9 server?
(Is there this setting function in Designate?)
Could you please advise me for it?
Best Regards,
Kenichiro Matsuda.
On 06/22/2015 06:37 AM, Michael Still wrote:
Hi,
https://review.openstack.org/#/c/149625 made me think about optional
requirements for nova. Some hypervisor drivers have requirements that
are either only needed for their driver, or are optional to their
driver. Examples include the ironic
On 22/06/15 11:28, neil.jer...@metaswitch.com wrote:
It seems like we're possibly stuck now on the VIF plugin script spec [1];
there being core comments in apparently conflicting directions. I wonder if
it's still feasible for a version of this to land during Liberty?
[1]
Sure, except where the thing isn't in pip... I just learned tonight
that the libosinfo thing in the review at the start of this thread is
a c library and some gobject black magic. I think we want it, but it
will never work as a pip dependancy. So, I think something human
readable is still
Davanum,
Can we also use SIGHUP signal tool instead of for these restarts?
Regards,
Sergey.
On 22 June 2015 at 13:12, Davanum Srinivas dava...@gmail.com wrote:
Michał,
we are adding that reread config to oslo.service, there's a test
version on pypi 0.1.0 (API not yet stable) that you can
At the moment, We have reload config files in place:
https://github.com/openstack/oslo.service/blob/master/oslo_service/service.py#L487
there are patches against Nova and Neutron where we are looking at how
this works and what else we can do.
-- dims
On Mon, Jun 22, 2015 at 7:21 AM, Sergey
Hi,
https://review.openstack.org/#/c/149625 made me think about optional
requirements for nova. Some hypervisor drivers have requirements that
are either only needed for their driver, or are optional to their
driver. Examples include the ironic driver depending on the ironic
client, and the
Hi,
I've subscribed this list just now, so I didn't read your answer before
today.
I'm gonna explain better what I sould do.
I know that Ceilometer collects statics about the network state, but as far
as I know, those are related to the virtual network.
I'm putting an ovs managed by an SDN
On 06/22/2015 05:28 AM, John Garbutt wrote:
On 22 June 2015 at 00:14, Michael Still mi...@stillhq.com wrote:
As an aside, do we think that exposing the exact version of a server
process is safe from a security perspective?
During discussions in the Nova API meeting, it was noted that while
Michael,
We talked about it in Vancouver in the context of oslo.messaging:
https://etherpad.openstack.org/p/YVR-oslo-optional-dependencies
Consensus was:
optional dependencies should be specified with extras in setup.cfg;
conditional ones via markers.
Robert is driving towards making this real:
Thanks Kevin!,
Kevin Benton mailto:blak...@gmail.com
20 Jun 2015 01:01via Postbox
https://www.postbox-inc.com/?utm_source=emailutm_medium=sumlinkutm_campaign=reach
As I understand it, it just allows other rules to be written that
specifically target pxe requests. So just enabling it won't
Thanks everybody! I will do my best!
On 06/21/2015 03:56 AM, Paul Michali wrote:
Congratulations Rossella! Great addition to the team!
On Sat, Jun 20, 2015 at 12:13 PM Miguel Lavalle mig...@mlavalle.com
mailto:mig...@mlavalle.com wrote:
Complimenti per il nuovo lavoro!
On Fri, Jun 19,
Am 20.06.2015 um 02:34 schrieb Knight, Clinton clinton.kni...@netapp.com:
Funny you should mention needing all of the CG methods...
A VD group (ConsistencyGroupVD) was added to contain the 4 CG methods from
Juno. Then more CG methods were added to VolumeDriver in Kilo, but they
weren’t
(Noting that its kind of late where I am).
Sean, I totally agree that we should fix uname. Let's get on that.
Michael
On Mon, Jun 22, 2015 at 8:52 PM, Sean Dague s...@dague.net wrote:
On 06/22/2015 05:28 AM, John Garbutt wrote:
On 22 June 2015 at 00:14, Michael Still mi...@stillhq.com wrote:
Hi to all,
Please, be informed that the plugin certification schedule is shifted due
to the Fuel GA date [1].
*This means the following:*
if you've sent your plugin targeted at 6.1 for certification, it will be
tested using GA, but not Release Candidates.
If you have any further questions
In extracting the contract for RPC backends in devstack (to have most of
them live in plugins) one bit of an edge case was discovered.
https://github.com/openstack-dev/devstack/blob/master/lib/swift#L388
The connection to the RPC mechanism from ceilometermiddleware inside of
swift uses a
On Sun, Jun 21, 2015 at 07:18:10PM +0300, Joe Gordon wrote:
On Fri, Jun 19, 2015 at 12:55 PM, Peng Zhao p...@hyper.sh wrote:
Hi, all,
I would like to propose nova-hyper driver:
https://blueprints.launchpad.net/nova/+spec/nova-hyper.
- What is Hyper?
Put simply, Hyper is a
On 22 June 2015 at 09:18, Sahid Orentino Ferdjaoui
sahid.ferdja...@redhat.com wrote:
On Sun, Jun 21, 2015 at 07:18:10PM +0300, Joe Gordon wrote:
On Fri, Jun 19, 2015 at 12:55 PM, Peng Zhao p...@hyper.sh wrote:
Hi, all,
I would like to propose nova-hyper driver:
On 22 June 2015 at 00:14, Michael Still mi...@stillhq.com wrote:
As an aside, do we think that exposing the exact version of a server
process is safe from a security perspective?
During discussions in the Nova API meeting, it was noted that while we
do expose the exact API version, we are not
Michał,
we are adding that reread config to oslo.service, there's a test
version on pypi 0.1.0 (API not yet stable) that you can try and see if
it works for you.
thanks,
dims
On Mon, Jun 22, 2015 at 5:40 AM, Jastrzebski, Michal
michal.jastrzeb...@intel.com wrote:
Hello,
I wanted to start
On 06/19/2015 08:18 PM, Alec Hothan (ahothan) wrote:
Do we have a good understanding of what is expected of zmq wrt rabbitMQ?
Like in what part of the bell curve or use cases would you see it? Or
indirectly, where do we see RabbitMQ lacking today that maybe ZMQ could
handle better?
I have
this is a reflection of the discussion I just had on #openstack-infra; it's
about (re-)using the central CI infrastructure for our Open-Source DRBD
driver too.
As this is done now, I'd like to discuss a few points.
First of all -- thanks to everybody involved; if you happen to find someone
Hi,
We made great progress on porting Glance to Python 3. tox -e py34 now
pass with a subset of tests and there is a non-voting py34 check job. I
propose to make the py34 gate voting to avoid Python 3 regressions:
https://review.openstack.org/194048
Make gate-glance-python34 voting
When the
On 06/20/2015 02:14 AM, Devananda van der Veen wrote:
Almost all of our discussions so far on this topic have left something
out, which Monty pointed out to me last week. I'm following up now
because E_TRAVEL...
tldr;
What we're versioning here are API's, not packages. It's not a question
of
Hi,
Le 18/06/2015 15:44, Thomas Goirand a écrit :
As per the subject line, we already have Python 3.5 in Debian (AFAICT,
from Debian Experimental, in version beta 2). As a consequence, we're
already running (unit) tests using Python 3.5. Some have failures: I
could see issues in
Thanks Kevin!,
Kevin Benton mailto:blak...@gmail.com
20 Jun 2015 01:01via Postbox
https://www.postbox-inc.com/?utm_source=emailutm_medium=sumlinkutm_campaign=reach
As I understand it, it just allows other rules to be written that
specifically target pxe requests. So just enabling it won't
You may have noticed the every repo has just been spammed with some
no-op changes where specifiers are re-ordered such as in
https://review.openstack.org/#/c/193973/1/test-requirements.txt
where
sphinx=1.1.2,!=1.2.0,!=1.3b1,1.3
-
sphinx!=1.2.0,!=1.3b1,1.3,=1.1.2
Whats happening is that the
1 - 100 of 135 matches
Mail list logo
