-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
I was looking at
https://blueprints.launchpad.net/mistral/+spec/mistral-ceilometer-integration
and trying to figure out how to implement that.
I can see some problems:
- - at the moment the trust is created when you PUT the workbook definition
Over the last 7 days ceilometer unit test jobs have a 18% failure rate in the
gate queue [0], while we see expect to see some failures in integration
testing, unit tests should not be failing in the gate with such a high
frequency (and for so long).
It looks like these failures are due to
Hello Duncan,
The best thing to do with the code is push up a gerrit review! No need
to be shy, and you're very welcome to push up code before the
blueprint is in, it just won't get merged.
thank you for your encouragement!
I pushed another fix for Cinder last week (2 lines, allowing to
Hey folks,
Could we get these two patches reviewed either today or tomorrow? The first is
array syntax:
https://review.openstack.org/#/c/94323https://review.openstack.org/#/c/94323/5
The second is removing the “bin” and “scripts” directories from top-level tree,
as discussed in last week’s
On 9 June 2014 15:18, Belmiro Moreira moreira.belmiro.email.li...@gmail.com
wrote:
I would say that is a documentation bug for the
“AggregateMultiTenancyIsolation” filter.
Great, thanks. I've logged a bug for this:
https://bugs.launchpad.net/openstack-manuals/+bug/1328400
When this was
Team,
Due to a number of expected absences (DockerCon plenaries conflict with our
regularly scheduled meeting), we will skip our Containers Team Meeting this
week. Please accept my sincere apologies for the short notice. Our next
scheduled meeting is:
2014-06-17 2200 UTC
I look forward to
All patches merged now. Here is the launchpad page for the sahara
2014.1.1 release - https://launchpad.net/sahara/+milestone/2014.1.1
We're doing some final testing now and release tag will be pushed later today.
Thanks.
On Thu, Jun 5, 2014 at 4:34 PM, Sergey Lukjanov slukja...@mirantis.com
Regarding use of the final keyword and limiting extending in general, a few
thoughts below:
- While I found the blog post about final classes to be informative, I'd take
it with a grain of salt. The author bills himself as a consultant who works
with enterprise web applications. Briefly
Hi,
Here is a link to WIP healing script https://review.openstack.org/96438.
The idea on which it is based on is shown in this spec
https://review.openstack.org/95738.
Regards,
Ann
On Mon, Jun 9, 2014 at 7:07 PM, Johannes Erdfelt johan...@erdfelt.com
wrote:
On Mon, Jun 09, 2014, Jakub
Excerpts from Jaromir Coufal's message of 2014-06-08 16:44:58 -0700:
Hi,
it looks that there is no more activity on the survey for mid-cycle
dates so I went forward to evaluate it.
I created a table view into the etherpad [0] and results are following:
* option1 (Jul 28 - Aug 1): 27
On 09/06/14 19:31 +, Kurt Griffiths wrote:
Folks, this may be a bit of a bombshell, but I think we have been dancing
around the issue for a while now and we need to address it head on. Let me
start with some background.
Back when we started designing the Marconi API, we knew that we wanted
On 09/06/14 20:59 -0400, Doug Hellmann wrote:
On Mon, Jun 9, 2014 at 5:56 PM, Ben Nemec openst...@nemebean.com wrote:
Hi all,
While the oslo-specs repository has been available for a while and a
number of specs proposed, we hadn't agreed on a process for actually
approving them (i.e. the
Excerpts from Vijay Venkatachalam's message of 2014-06-09 21:48:43 -0700:
My vote is for option #2 (without the registration). It is simpler to start
with this approach. How is delete handled though?
Ex. What is the expectation when user attempts to delete a
certificate/container which
On Mon, 2014-06-09 at 20:14 -0400, Doug Hellmann wrote:
On Mon, Jun 9, 2014 at 6:11 PM, Eoghan Glynn egl...@redhat.com wrote:
Based on the discussion I'd like to propose these options:
1. Cinder-certified driver - This is an attempt to move the certification
to the project level.
2.
Hi,
Any chance of getting a review on https://review.openstack.org/84691.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Mon, 2014-06-09 at 19:31 +, Kurt Griffiths wrote:
Lately we have been talking about writing drivers for traditional
message brokers that will not be able to support the message feeds
part of the API. I’ve started to think that having a huge part of the
API that may or may not “work”,
Hi Luke,
Please see my comments inline.
BR,
Irena
From: Luke Gorrie [mailto:l...@tail-f.com]
Sent: Monday, June 09, 2014 12:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][ml2] Too much shim rest proxy
mechanism drivers in ML2
On 6
Shall we continue this discussion?
Itai
On 6/9/14 8:54 PM, Steve Gordon sgor...@redhat.com wrote:
- Original Message -
From: Steve Gordon sgor...@redhat.com
To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com,
OpenStack Development Mailing List (not for usage
Just adding
Meeting minutes of June 10
* Announcement
- started to create repos in stackforge
review is on-going
* nfv follow up
blueprints
- VLAN-aware-VLAN, l2-gateway, network-truncking
https://review.openstack.org/#/c/97714/
https://review.openstack.org/#/c/94612/
Hi Irena,
Thanks for the very interesting perspective!
On 10 June 2014 10:57, Irena Berezovsky ire...@mellanox.com wrote:
*[IrenaB] The DB access approach was previously used by OVS and
LinuxBridge Agents and at some point (~Grizzly Release) was changed to use
RPC communication.*
That is
We have stopped reviewing specs (at least that was the plan), to get
Juno-1 out the door before Thursday.
Hopefully on Friday, it will be full steam ahead with nova-specs reviews.
John
On 10 June 2014 09:44, Gary Kotton gkot...@vmware.com wrote:
Hi,
Any chance of getting a review on
+1 for the use of mock.
Is mox3 really needed? Or can we move our tests for python3 to mock, and use
this library for every tests for python3?
- Original Message -
From: David Lyle david.l...@hp.com
To: OpenStack Development Mailing List (not for usage questions)
On 10/06/14 09:48 +0100, Mark McLoughlin wrote:
On Mon, 2014-06-09 at 19:31 +, Kurt Griffiths wrote:
Lately we have been talking about writing drivers for traditional
message brokers that will not be able to support the message feeds
part of the API. I’ve started to think that having a huge
On 10/06/14 10:25, Clint Byrum wrote:
Excerpts from Jaromir Coufal's message of 2014-06-08 16:44:58 -0700:
Hi,
it looks that there is no more activity on the survey for mid-cycle
dates so I went forward to evaluate it.
I created a table view into the etherpad [0] and results are following:
So, I now tried to push the proof-of-concept driver to Gerrit,
and got this:
Downloading/unpacking dbus (from -r /home/jenkins/workspace/gate-
cinder-pep8/requirements.txt (line 32))
http://pypi.openstack.org/openstack/dbus/ uses an insecure transport
scheme (http). Consider using https if
Hrmpf, sent too fast again.
I guess https://wiki.openstack.org/wiki/Requirements is the link I was
looking for.
Sorry for the noise.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://review.openstack.org/99002 adds more logging to
nova/network/manager.py, but I think you're not going to love the
debug log level. Was this the sort of thing you were looking for
though?
Michael
On Mon, Jun 9, 2014 at 11:45 PM, Sean Dague s...@dague.net wrote:
Based on some back of
On 10 June 2014 12:11, John Garbutt j...@johngarbutt.com wrote:
There was a spec I read that was related to this idea of excluding
things that don't match the filter. I can't seem to find that, but the
general idea makes total sense.
As a heads up, the scheduler split means we are wanting to
Hello, stackers!
Oslo.messaging is future of how different OpenStack components communicate
with each other, and really I’d love to start discussion about how we can
make this library even better then it’s now and how can we refactor it make
more production-ready.
As we all remember,
Hi All,
Carlos, Vivek, German, thanks for reviewing the RST doc.
There are some issues I want to pinpoint final decision on them here, in ML,
before writing it down in the doc.
Other issues will be commented on the document itself.
1. Support/No support in JUNO
Referring to summit's
On Mon, Jun 09 2014, Doug Hellmann wrote:
We went with a single large storage API in ceilometer initially, but
we had some discussions at the Juno summit about it being a bad
decision because it resulted in storing some data like alarm
definitions in database formats that just didn't make
It looks like this has come full circle and we are back at the simplest case.
# Containers are immutable
# Changing a cert means creating a new container and, when ready, pointing
LBaaS at the new container
This makes a lot of sense to me, it removes a lot of handholding and keeps
Barbican and
Dina, Alexey,
Do you mind filing some spec(s) please?
http://markmail.org/message/yqhndsr3zrqcfwq4
http://markmail.org/message/kpk35uikcnodq3jb
thanks,
dims
On Tue, Jun 10, 2014 at 7:03 AM, Dina Belova dbel...@mirantis.com wrote:
Hello, stackers!
Oslo.messaging is future of how different
That's right, we (Fuel devs) are contributing to the TripleO. Our devs
contributes into all areas where overlap occurs, and these include TripleO,
Ironic and other projects.
As we work with the TripleO team, the Fuel team will continue to enhance
Fuel based on users demand. Since Fuel has been
Dims,
No problem with creating the specs, we just want to understand if the
community is OK with our suggestions in general :)
If so, I'll create the appropriate specs and we'll discuss them :)
Thanks
-- Dina
On Tue, Jun 10, 2014 at 3:31 PM, Davanum Srinivas dava...@gmail.com wrote:
Dina,
On 10/06/14 15:03 +0400, Dina Belova wrote:
Hello, stackers!
Oslo.messaging is future of how different OpenStack components communicate with
each other, and really I’d love to start discussion about how we can make this
library even better then it’s now and how can we refactor it make more
On 06/10/2014 09:48 AM, Mark McLoughlin wrote:
Perhaps the first point to get super clear on is why drivers for
traditional message brokers are needed. What problems would such drivers
address? Who would the drivers help? Would the Marconi team recommend
using any of those drivers for a
On 06/09/2014 08:31 PM, Kurt Griffiths wrote:
Lately we have been talking about writing drivers for traditional
message brokers that will not be able to support the message feeds part
of the API.
Could you elaborate a little on this point? In some sense of the term at
least, handling message
Hi,
Please find some answers inline.
Regards,
Alexei
On 06/10/2014 03:06 PM, Flavio Percoco wrote:
On 10/06/14 15:03 +0400, Dina Belova wrote:
Hello, stackers!
Oslo.messaging is future of how different OpenStack components
communicate with
each other, and really I'd love to start
On 06/10/2014 12:03 PM, Dina Belova wrote:
Hello, stackers!
Oslo.messaging is future of how different OpenStack components
communicate with each other, and really I’d love to start discussion
about how we can make this library even better then it’s now and how can
we refactor it make more
Interesting stuff.
Do you think that we can get rid of Astute at some point being purely
replaced by Salt?
And listening for the commands from Fuel?
Can you please clarify, does the suggested approach implies that we can
have both puppet SaltStack? Even if you ever switch to anything
different,
On 10 June 2014 09:33, Mark McLoughlin mar...@redhat.com wrote:
Avoiding dragging the project into those sort of politics is something
I'm really keen on, and why I think the word certification is best
avoided so we can focus on what we're actually trying to achieve.
Avoiding those sorts of
On 06/10/2014 04:33 AM, Mark McLoughlin wrote:
On Mon, 2014-06-09 at 20:14 -0400, Doug Hellmann wrote:
On Mon, Jun 9, 2014 at 6:11 PM, Eoghan Glynn egl...@redhat.com wrote:
Based on the discussion I'd like to propose these options:
1. Cinder-certified driver - This is an attempt to move the
On Mon, Jun 9, 2014 at 9:22 PM, Luke Gorrie l...@tail-f.com wrote:
Howdy Kyle,
On 9 June 2014 22:37, Kyle Mestery mest...@noironetworks.com wrote:
After talking with various infra folks, we've noticed the Tail-f CI
system is not voting anymore. According to some informal research, the
last
On 06/10/2014 03:59 PM, Gordon Sim wrote:
On 06/10/2014 12:03 PM, Dina Belova wrote:
Hello, stackers!
Oslo.messaging is future of how different OpenStack components
communicate with each other, and really I’d love to start discussion
about how we can make this library even better then it’s
On Tue, 2014-06-10 at 14:06 +0100, Duncan Thomas wrote:
On 10 June 2014 09:33, Mark McLoughlin mar...@redhat.com wrote:
Avoiding dragging the project into those sort of politics is something
I'm really keen on, and why I think the word certification is best
avoided so we can focus on what
On 2014/10/06 10:25, Clint Byrum wrote:
Excerpts from Jaromir Coufal's message of 2014-06-08 16:44:58 -0700:
Hi,
it looks that there is no more activity on the survey for mid-cycle
dates so I went forward to evaluate it.
I created a table view into the etherpad [0] and results are following:
Those are some good questions and I pondered them last night even
before I read your email.
Right now, if no transport layer is passed in a default one is used
for them. The don't make me think implementation is already there. If
you want to use something other than the default one than you need
Hi all,
Just a reminder that the next meeting of the NFV sub-team is scheduled for
Wednesday June 11 @ 1400 UTC in #openstack-meeting-alt.
Agenda:
* Review actions from last week
* russellb: NFV topic on ML
* russellb: #openstack-nfv setup
* bauzas: gerrit dashboard
* cdub: Review use
Howdy!
Here is a successful Sandbox test from right now:
https://review.openstack.org/#/c/99061/. I don't immediately see how to
list all historical sandbox tests. (The previous ones are from before the
Summit anyway.)
I enabled the CI for the openstack/neutron Gerrit feed now. Here is a
change
The reviews are in and they are both merged. Thanks for the reminder.
On Tue, Jun 10, 2014 at 3:12 AM, Jamie Hannaford
jamie.hannaf...@rackspace.com wrote:
Hey folks,
Could we get these two patches reviewed either today or tomorrow? The
first is array syntax:
Response inline
- Original Message -
From: Alex Glikson glik...@il.ibm.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Monday, June 9, 2014 3:13:52 PM
Subject: Re: [openstack-dev] [nova] Proposal: Move CPU and memory
On 06/09/2014 02:24 PM, Sean Dague wrote:
On 06/09/2014 01:38 PM, David Kranz wrote:
On 06/02/2014 06:57 AM, Sean Dague wrote:
Towards the end of the summit there was a discussion about us using a
shared review dashboard to see if a common view by the team would help
accelerate people looking
Neutron devs:
The list of targeted BPs and bugs for Juno-1 is here [1, as we
discussed in the team meeting yesterday [2]. Per discussion with ttx
today, of the 4 remaining BPs targeted for Juno-1, any which do not
have code in flight to be merged by EOD today will be re-targeted for
Juno-2. For
On 10 June 2014 15:07, Mark McLoughlin mar...@redhat.com wrote:
Exposing which configurations are actively tested is a perfectly sane
thing to do. I don't see why you think calling this certification is
necessary to achieve your goals.
What is certification except a formal way of saying 'we
Hi all,
I see that many of the use cases require information from different OS
components, e.g. networking, compute, and storage. One thing to think about is
where those constraints are written/stored and how the data the constraints
depend on is pulled together. The Congress project might
Hi!
Tail-f driver seems to be configured correctly. DriverLog will poll Gerrit
in the next 4 hours and update driver details screen.
Regarding green mark on summary screen - it is shown for those drivers that
have configured CI and CI ran at least once. But it doesn't take into
account when the
On Tue, Jun 10, 2014 at 10:15 AM, Ilya Shakhat ishak...@mirantis.com wrote:
Hi!
Tail-f driver seems to be configured correctly. DriverLog will poll Gerrit
in the next 4 hours and update driver details screen.
Regarding green mark on summary screen - it is shown for those drivers that
have
Hi Tim,
Agree, Congress is a good place to store the scheduling constraints.
Thanks,
Ramki
-Original Message-
From: Tim Hinrichs [mailto:thinri...@vmware.com]
Sent: Tuesday, June 10, 2014 8:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Norival Figueira;
Hi Tim,
In our current implementation of Smart (Solver) Scheduler, the constraints are
defined as pluggable modules (just like filter definitions in the filter
scheduler) and are pulled in together when necessary to solve the scheduling
decision. And regarding the data that we get from
On Tue, Jun 10, 2014 at 10:33:49AM EDT, Luke Gorrie wrote:
Howdy!
Here is a successful Sandbox test from right now:
https://review.openstack.org/#/c/99061/. I don't immediately see how to
list all historical sandbox tests. (The previous ones are from before the
Summit anyway.)
One of the
Hi Sean,
On 10 June 2014 18:09, Collins, Sean sean_colli...@cable.comcast.com
wrote:
One of the links that is posted in that review comment for the Tail-f
NCS Jenkins timed out for me.
http://egg.snabb.co:8080/job/jenkins-ncs/19/
I notice that there is another link included in that review
Sorry, replied to wrong ML...
Original Message
Subject: Re: [openstack-tc] [openstack-dev] use of the word certified
Date: Tue, 10 Jun 2014 11:37:38 -0400
From: Jay Pipes jaypi...@gmail.com
To: openstack...@lists.openstack.org
On 06/10/2014 09:53 AM, Sean Dague wrote:
On
As part of the push to release code from the oslo incubator in
stand-alone libraries, we have had several different discussions about
versioning and release schedules. This is an attempt to collect all of
the decisions we have made in those discussions and to lay out the
rationale for the approach
- Original Message -
From: Stephen Wong stephen.kf.w...@gmail.com
To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com, OpenStack
Development Mailing List (not for usage
questions) openstack-dev@lists.openstack.org
Hi,
Perhaps I have missed it somewhere in the email
Hi Luke,
Very impressive solution!
I do not think there is a problem to keep agent out of the tree in a short
term, but would highly recommend to put it upstream in a longer term.
You will benefit from quite valuable community review. And most important it
will allow to keep your code as much
What are 'message feeds' in the Marconi context, in more detail? And
what aspect of them is it that message brokers don't support?
Great question. When I say “feeds” I mean a “feed” in the sense of RSS or
Atom. People do, in fact, use Atom to implement certain messaging
patterns. You can think
I've been seeing failures from the requirements gating check on changes
proposed by the requirements bot. It's actually complaining that the
proposed changes don't match what's in global-requirements.txt, even
though they are textually identical. An example is here:
On 06/10/2014 12:32 PM, Sean Dague wrote:
On 06/10/2014 11:37 AM, Jay Pipes wrote:
On 06/10/2014 09:53 AM, Sean Dague wrote:
On 06/10/2014 09:14 AM, Anita Kuno wrote:
On 06/10/2014 04:33 AM, Mark McLoughlin wrote:
On Mon, 2014-06-09 at 20:14 -0400, Doug Hellmann wrote:
On Mon, Jun 9, 2014
Thanks Jay.
Whatever inaccuracies or errors you see with DriverLog, please file a bug
or an update request:
https://wiki.openstack.org/wiki/DriverLog#How_To:_Add_a_new_driver_to_DriverLog.
Also, we are more than happy to hear any suggestions on what information to
display and how to call what.
On 06/10/2014 10:09 AM, Duncan Thomas wrote:
On 10 June 2014 15:07, Mark McLoughlin mar...@redhat.com wrote:
Exposing which configurations are actively tested is a perfectly sane
thing to do. I don't see why you think calling this certification is
necessary to achieve your goals.
What is
Sorry, I do feel like it's kind of crazy and irresponsible to throw data
out there with something as wrong as 'OpenStack doesn't test QEMU' and
then follow that up with 'Oh, file a bug to fix it!'.
Then promote it to something as prominent as stackalytics.
I mean... guys... seriously? :)
On Tue, 2014-06-10 at 16:09 +0100, Duncan Thomas wrote:
On 10 June 2014 15:07, Mark McLoughlin mar...@redhat.com wrote:
Exposing which configurations are actively tested is a perfectly sane
thing to do. I don't see why you think calling this certification is
necessary to achieve your
Hi Rich
I'm able to solve the problem regarding PAPR in libguestfs on my powerpc
ubuntu.By default the libguestfs was configuring pseries machine and
afterwards I changed it to my original machine i.e ppce500 .The changes are
performed in ./src/guestfs-internal.h file.
However still my VM is
On 06/10/2014 05:27 PM, Kurt Griffiths wrote:
I think the crux of the issue is that Marconi follows the REST
architectural style. As such, the client must track the state of where it
is in the queue it is consuming (to keep the server stateless). So, it
must be given some kind of marker,
Will Marconi only support HTTP as a transport, or will it add other
protocols as well?
We are focusing on HTTP for Juno, but are considering adding a
lower-level, persistent transport (perhaps based on WebSocket) in the K
cycle.
Can anyone describe what is unique about the Marconi design with
Cool,
Thanks.
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 06/10/2014 01:00 PM, Sean Dague wrote:
Sorry, I do feel like it's kind of crazy and irresponsible to throw data
out there with something as wrong as 'OpenStack doesn't test QEMU' and
then follow that up with 'Oh, file a bug to fix it!'.
Then promote it to something as prominent as
Ok but we still need input from Stephen Balukoff and Jorge to see how this
will integrate with the API being proposed. I'm not sure if they were intending
to use the attributes your discussing as well as which object was going to
contain them.
On Jun 10, 2014, at 6:13 AM, Evgeny Fedoruk
I the last few days I attempted to implement a RabbitMQ (AMQP 0.9) storage
driver for Marconi. These are the take-aways from this experiment. High level,
it showed that current Marconi APIs *cannot* be mapped onto the AMQP 0.9
abstractions. In fact, currently it is not even possible to support
Hi community and TC members!
First a little bit of history:
Murano applied for incubation in February 2014 [1]. TC discussion [2]
finished the following resolution (quote from ttx):
Murano is slightly too far up the stack at this point to meet the
measured progression of openstack as a whole
On 06/10/2014 01:58 PM, Jay Pipes wrote:
Stackers,
OK, we are fully aware that there are problems with the early DriverLog
data that is shown in the dashboard. Notably, the Nova driver stuff is
not correct for the default virt drivers. We will work on fixing that ASAP.
Our focus to date
On 06/10/2014 10:39 AM, Jay Pipes wrote:
We've been begging for input on this
stuff at the board and dev list level for a while now.
And people are all ear now and leaving comments, which is good :) I
think adding a clear warning on stackalytics.com that the data from
DriverLog may not be
#5 is a good reference point for the type of apps we can encounter in NFV.
I guess it's a good idea to start with it.
Itai
Sent from my iPhone
On Jun 10, 2014, at 7:16 PM, Steve Gordon sgor...@redhat.com wrote:
- Original Message -
From: Stephen Wong stephen.kf.w...@gmail.com
To:
Hello everyone.
We have collected a fine number of name proposals for the library part
of Horizon, and now it is time to vote for them. I have set up a poll on
CIVS, and if you contributed to Horizon within the last year, you should
receive an e-mail with the link that lets you vote.
If you
Any core neutron people have a chance to give their opinions on this
yet?
Thanks,
Brandon
On Thu, 2014-06-05 at 15:28 +, Buraschi, Andres wrote:
Thanks, Kyle. Great.
-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com]
Sent: Thursday, June 05, 2014 11:27 AM
Ruslan Kamaldinov wrote:
Hi community and TC members!
[...]
Please only follow-up on -dev! This shall keep this thread consistent.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Adam--
Wouldn't the user see the duplicate key/cert copy in their barbican
interface, or are you proposing storing these secrets in a
not-assigned-to-the-tenant kind of way?
In any case, it strikes me as misleading to have an explicit delete command
sent to Barbican not have the effect of making
I responded in the other thread just now, but I did want to say:
The problem with a dangling reference is this might mean that the
associated Listener breaks at some random time after the barbican container
goes away. While this is intuitive and expected behavior if it happens
shortly after the
Here my feedback regarding the designs:
Page 2:
* I think that the admin would probably want to filter alarms per user,
project, name, meter_name, current_alarm_state(ok=alarm ready;
insufficient data = alarm not ready; alarm =alarm triggered), but we
don't have all that columns on
Hi Evgeny,
Comments inline.
On Tue, Jun 10, 2014 at 4:13 AM, Evgeny Fedoruk evge...@radware.com wrote:
Hi All,
Carlos, Vivek, German, thanks for reviewing the RST doc.
There are some issues I want to pinpoint final decision on them here, in
ML, before writing it down in the doc.
Doug: The reasons a LB might be reprovisioned are fairly important — mostly
around HA, for fail overs or capacity — exactly the times we're trying avoid a
failure.
Stephen: yes, I am talking about storing the copy in a non-tenant way (on the
tenant-id for the LBaaS Service Account, not visible
Following the discussions in the ML2 subgroup weekly meetings, I have added
more information on the etherpad [1] describing the proposed architecture
for modular L2 agents. I have also posted some code fragments at [2]
sketching the implementation of the proposed architecture. Please have a
look
What was discussed at yesterday's Neutron core meeting?
On Tue, Jun 10, 2014 at 3:38 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
Any core neutron people have a chance to give their opinions on this
yet?
Thanks,
Brandon
On Thu, 2014-06-05 at 15:28 +, Buraschi, Andres wrote:
Yep, I'd like to know here, too-- as knowing the answer to this unblocks
implementation work for us.
On Tue, Jun 10, 2014 at 12:38 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
Any core neutron people have a chance to give their opinions on this
yet?
Thanks,
Brandon
On Thu,
Hi Adam,
If nothing else, we could always write a garbage collector process which
periodically scans for shadow containers that are not in use by any
listeners anymore and cleans them up. I suppose that's actually not a
difficult problem to solve.
Anyway, yes, I'm liking your suggestion quite a
Doug: The reasons a LB might be reprovisioned are fairly important — mostly
around HA, for fail overs or capacity — exactly the times we're trying avoid
a failure.
Certainly the ticking time bomb is a bad idea, but HA seems cleaner to do in
the backend, rather than at the openstack API
Hi Yunhong Yongli,
In the routine _prepare_pci_devices_for_use(), it’s referring to
dev[‘hypervisor_name’]. I didn’t see code that’s setting it up, or the libvirt
nodedev xml includes hypervisor_name. Is this specific to Xen?
Another question is about the issue that was raised in this review:
Using processes to isolate tenants is certainly possible. There is a range
of isolation mechanisms that can be used, from VM level isolation
(basically a separate deployment of the broker per-tenant), to process
level isolation, to sub-process isolation. The higher the density the
lower the
On Tue, 2014-06-10 at 17:33 +, Janczuk, Tomasz wrote:
From my perspective the key promise of Marconi is to provide a
*multi-tenant*, *HTTP* based queuing system. Think an OpenStack equivalent
of SQS or Azure Storage Queues.
As far as I know there are no off-the-shelve message brokers out
1 - 100 of 127 matches
Mail list logo
