[openstack-dev] [openstack-sdk-php] Pending reviews

Hey folks, Could we get these two patches reviewed either today or tomorrow? The first is array syntax: https://review.openstack.org/#/c/94323 The second is removing the “bin” and “scripts” directories from top-level tree, as discussed in last week’s m

Re: [openstack-dev] [nova] AggregateMultiTenancyIsolation scheduler filter - bug, or new feature proposal?

On 9 June 2014 15:18, Belmiro Moreira 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 implemented the objective was to sche

[openstack-dev] [Containers] Notice: Containers Team meeting cancelled this week

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 mee

Re: [openstack-dev] [sahara] 2014.1.1 preparation

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 wrote: > All patches are n

Re: [openstack-dev] [openstack-sdk-php] Use of final and private keywords to limit extending

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 looking

Re: [openstack-dev] Promoting healing script to scheme migration script?

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 wrote: > On Mon, Jun 09, 2014, Jakub Libosvar wrote: > > I'd l

Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup

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): 2

Re: [openstack-dev] [marconi] Reconsidering the unified API model

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 t

Re: [openstack-dev] [oslo] oslo-specs approval process

On 09/06/14 20:59 -0400, Doug Hellmann wrote: On Mon, Jun 9, 2014 at 5:56 PM, Ben Nemec 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 normal 2 +2's or something e

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

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 wh

Re: [openstack-dev] use of the word certified

On Mon, 2014-06-09 at 20:14 -0400, Doug Hellmann wrote: > On Mon, Jun 9, 2014 at 6:11 PM, Eoghan Glynn 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.

[openstack-dev] [nova] Diagnostics spec

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

Re: [openstack-dev] [marconi] Reconsidering the unified API model

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”,

Re: [openstack-dev] [Neutron][ml2] Too much "shim rest proxy" mechanism drivers in ML2

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

Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context

Shall we continue this discussion? Itai On 6/9/14 8:54 PM, "Steve Gordon" wrote: >- Original Message - >> From: "Steve Gordon" >> To: "ITAI MENDELSOHN (ITAI)" , >>"OpenStack Development Mailing List (not for usage >> >> Just adding openstack-dev to the CC for now :). >> >> - Orig

[openstack-dev] [Neutron][ServiceVM] servicevm IRC meeting minutes (June 10 Tuesday 5:00(AM)UTC-)

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/ https://blueprints

Re: [openstack-dev] [Neutron][ml2] Too much "shim rest proxy" mechanism drivers in ML2

Hi Irena, Thanks for the very interesting perspective! On 10 June 2014 10:57, Irena Berezovsky 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 very interesting

Re: [openstack-dev] [nova] Diagnostics spec

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 wrote: > Hi, > Any chance of getting a review on https://review.openstack.o

Re: [openstack-dev] [horizon] mocking policy

+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" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Tuesday, June 10, 2014 5:58:0

Re: [openstack-dev] [marconi] Reconsidering the unified API model

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

Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup

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 ar

Re: [openstack-dev] [nova] AggregateMultiTenancyIsolation scheduler filter - bug, or new feature proposal?

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 change how the aggregate filters are working, more towards this direc

Re: [openstack-dev] [Cinder] DRBD integration as volume driver

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

Re: [openstack-dev] [Cinder] DRBD integration as volume driver

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 http://lists.openstack.org/cgi-bin/mailman/listinfo/

Re: [openstack-dev] [all] Gate still backed up - need assistance with nova-network logging enhancements

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 wrote: > Based on some back of envelope math the

Re: [openstack-dev] [nova] AggregateMultiTenancyIsolation scheduler filter - bug, or new feature proposal?

On 10 June 2014 12:11, John Garbutt 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 change how > th

[openstack-dev] [oslo][messaging] Further improvements and refactoring

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, oslo.messa

Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

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 ethe

Re: [openstack-dev] [marconi] Reconsidering the unified API model

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

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

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

Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring

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 wrote: > Hello, stackers! > > > Oslo.messaging is future of how different OpenStack componen

Re: [openstack-dev] [TripleO][Fuel] relationship btw TripleO and Fuel

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 shi

Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring

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 wrote: > Dina, Alexey, > > Do you

Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring

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 prod

Re: [openstack-dev] [marconi] Reconsidering the unified API model

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 productio

Re: [openstack-dev] [marconi] Reconsidering the unified API model

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 f

Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring

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 discussio

Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring

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 produ

Re: [openstack-dev] [Fuel] Using saltstack as orchestrator for fuel

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,

Re: [openstack-dev] use of the word certified

On 10 June 2014 09:33, Mark McLoughlin 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 politics - 'XX

Re: [openstack-dev] use of the word certified

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 wrote: >>> >>> Based on the discussion I'd like to propose these options: 1. Cinder-certified driver - This is an attempt to move the "

Re: [openstack-dev] [neutron] [driverlog] Tail-f CI and it's lack of running and it's DriverLog status

On Mon, Jun 9, 2014 at 9:22 PM, Luke Gorrie wrote: > Howdy Kyle, > > On 9 June 2014 22:37, Kyle Mestery 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 run for this CI setup was in A

Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring

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 now

Re: [openstack-dev] use of the word certified

On Tue, 2014-06-10 at 14:06 +0100, Duncan Thomas wrote: > On 10 June 2014 09:33, Mark McLoughlin 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 a

Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup

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: *

Re: [openstack-dev] [openstack-sdk-php] Transport Clients, Service Clients, and state

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 t

[openstack-dev] [NFV] Sub-team Meeting Reminder - Wednesday June 11 @ 1400 utc

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

Re: [openstack-dev] [neutron] [driverlog] Tail-f CI and it's lack of running and it's DriverLog status

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 t

Re: [openstack-dev] [openstack-sdk-php] Pending reviews

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: > > https://review.ope

Re: [openstack-dev] [nova] Proposal: Move CPU and memory allocation ratio out of scheduler

Response inline - Original Message - > From: "Alex Glikson" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Monday, June 9, 2014 3:13:52 PM > Subject: Re: [openstack-dev] [nova] Proposal: Move CPU and memory allocation > ratio out of scheduler > > >> So

Re: [openstack-dev] [qa] shared review dashboard proposal

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 a

[openstack-dev] [neutron] BPs and bugs for Juno-1

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 th

Re: [openstack-dev] use of the word certified

On 10 June 2014 15:07, Mark McLoughlin 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 tested it'?

Re: [openstack-dev] [NFV] - follow up on scheduling discussion

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 be

Re: [openstack-dev] [neutron] [driverlog] Tail-f CI and it's lack of running and it's DriverLog status

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 l

Re: [openstack-dev] [neutron] [driverlog] Tail-f CI and it's lack of running and it's DriverLog status

On Tue, Jun 10, 2014 at 10:15 AM, Ilya Shakhat 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 configured CI an

Re: [openstack-dev] [NFV] - follow up on scheduling discussion

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; Debo

Re: [openstack-dev] [NFV] - follow up on scheduling discussion

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 diffe

Re: [openstack-dev] [neutron] [driverlog] Tail-f CI and it's lack of running and it's DriverLog status

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

Re: [openstack-dev] [neutron] [driverlog] Tail-f CI and it's lack of running and it's DriverLog status

Hi Sean, On 10 June 2014 18:09, Collins, Sean 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 that does > work and has t

[openstack-dev] Fwd: Re: [openstack-tc] use of the word certified

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 To: openstack...@lists.openstack.org On 06/10/2014 09:53 AM, Sean Dague wrote: On 06/10/2014 09:14 AM, An

[openstack-dev] [oslo] versioning and releases

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

Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context

- Original Message - > From: "Stephen Wong" > To: "ITAI MENDELSOHN (ITAI)" , "OpenStack > Development Mailing List (not for usage > questions)" > > Hi, > > Perhaps I have missed it somewhere in the email thread? Where is the > use case => bp document we are supposed to do for this

Re: [openstack-dev] [Neutron][ml2] Too much "shim rest proxy" mechanism drivers in ML2

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 as

Re: [openstack-dev] [marconi] Reconsidering the unified API model

> 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

[openstack-dev] [requirements] Odd behavior from requirements checks

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: http://logs.openstac

Re: [openstack-dev] [openstack-tc] use of the word certified

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 at

Re: [openstack-dev] Fwd: Re: [openstack-tc] use of the word certified

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. A

Re: [openstack-dev] use of the word certified

On 06/10/2014 10:09 AM, Duncan Thomas wrote: > On 10 June 2014 15:07, Mark McLoughlin 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 cert

Re: [openstack-dev] Fwd: Re: [openstack-tc] use of the word certified

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? :)

Re: [openstack-dev] use of the word certified

On Tue, 2014-06-10 at 16:09 +0100, Duncan Thomas wrote: > On 10 June 2014 15:07, Mark McLoughlin 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. >

Re: [openstack-dev] nova-compute vfsguestfs

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 stuc

Re: [openstack-dev] [marconi] Reconsidering the unified API model

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, allowing

Re: [openstack-dev] [marconi] Reconsidering the unified API model

> 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 wit

Re: [openstack-dev] [neutron] [driverlog] Tail-f CI and it's lack of running and it's DriverLog status

Cool, Thanks. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat]Heat template parameters encryption

Hi Devs/All, Does any one have comments/objections for following interim solution? 1. Add a config option to enable/disable parameter encryption and set default value to disable 2. Encrypt parameters that were marked as hidden or encrypt all parameters IMO, when a template author marks a parameter

Re: [openstack-dev] [marconi] Reconsidering the unified API model

>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 these that fit that bill. Note that when I say ³multi-tenant²

Re: [openstack-dev] Fwd: Re: [openstack-tc] use of the word certified

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 stackalytic

Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

To elaborate on the case where containers get deleted while LBaaS still references it. We think that the following approach will do: * The end user can delete a container and leave a "dangling" reference in LBaaS. * It would be nice to allow adding meta data on the container so

Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

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 wrote:

[openstack-dev] [DriverLog] What to fix and when

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 has mostly been on the Cinder and Neutron driv

[openstack-dev] [marconi] RabbitMQ (AMQP 0.9) driver for Marconi

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 a

[openstack-dev] [TC] [Murano] Follow up on cross-project session

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" r

Re: [openstack-dev] [DriverLog] What to fix and when

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

Re: [openstack-dev] Fwd: Re: [openstack-tc] use of the word certified

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 accu

Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context

#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" wrote: > > - Original Message - >> From: "Stephen Wong" >> To: "ITAI MENDELSOHN (ITAI)" , >> "O

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

So, it looks like any sort of validation on Deletes in Barbican is going to be a no-go. I'd like to propose a third option, which might be the safest route to take for LBaaS while still providing some of the convenience of using Barbican as a central certificate store. Here is a diagram of the inte

Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context

- Original Message - > From: "Steve Gordon" > To: "Stephen Wong" > > - Original Message - > > From: "Stephen Wong" > > To: "ITAI MENDELSOHN (ITAI)" , > > "OpenStack Development Mailing List (not for usage > > questions)" > > > > Hi, > > > > Perhaps I have missed it somewh

Re: [openstack-dev] [horizon] Name proposals

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 didn'

Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas. He's advocating keeping a shadow copy of the private key that is owned by the LBaaS service so that incase a key is tampered with during an LB update migration etc we can still check with the shad

Re: [openstack-dev] [Neutron] Implementing new LBaaS API

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:2

Re: [openstack-dev] [TC] [Murano] Follow up on cross-project session

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 http://lists.openstack.org/

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

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

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

> In any case, it strikes me as misleading to have an explicit delete command > sent to Barbican not have the effect of making the key unusable in all other > contexts. It would be less surprising behavior, IMO, to have a deleted > barbican container result in connected load balancing services b

Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

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 th

Re: [openstack-dev] Fwd: Re: [openstack-tc] use of the word certified

On 06/10/2014 02:57 PM, Stefano Maffulli wrote: 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.

Re: [openstack-dev] [Horizon] [UX] Design for Alarming and Alarm Management

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 co

Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

Hi Evgeny, Comments inline. On Tue, Jun 10, 2014 at 4:13 AM, Evgeny Fedoruk 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. > > Other issues w

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

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

[openstack-dev] [Neutron][ML2] Modular L2 agent architecture

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 w

  1   2   >