[openstack-dev] [nova] [neutron] Specs for K release

Hi, is it already possible to submit specs (nova & neutron) for the K release? Would be great for getting early feedback and tracking comments. Or should I just commit it to the juno folder? Thanks, Andreas ___ OpenStack-dev mailing list OpenStack-de

[openstack-dev] [nova] Nova API meeting

Hi, Just a reminder that the weekly Nova API meeting is being held tomorrow Friday UTC . We encourage cloud operators and those who use the REST API such as SDK developers and others who and are interested in the future of the API to participate. In other timezones the meeting is at: EST

Re: [openstack-dev] [nova] [neutron] Specs for K release

You could just make the kilo folder in your commit and then rebase it once Kilo is open. On Thu, Aug 28, 2014 at 12:07 AM, Andreas Scheuring < scheu...@linux.vnet.ibm.com> wrote: > Hi, > is it already possible to submit specs (nova & neutron) for the K > release? Would be great for getting early

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On 08/27/2014 05:52 PM, Doug Hellmann wrote: > > On Aug 27, 2014, at 11:14 AM, Flavio Percoco wrote: > >> On 08/27/2014 04:31 PM, Sean Dague wrote: >>> So this change came in with adding glance.store - >>> https://review.openstack.org/#/c/115265/5/lib/glance, which I think is a >>> bad direction

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On 08/27/2014 09:18 PM, James E. Blair wrote: > Sean Dague writes: > >> On 08/27/2014 11:14 AM, Flavio Percoco wrote: >>> On 08/27/2014 04:31 PM, Sean Dague wrote: >>> 1. Do a partial rename and then complete it after the glance migration >>> is done. If I'm not missing anything, we should be abl

Re: [openstack-dev] [nova] [neutron] Specs for K release

I think it's ok to submit specs for Kilo - mostly because it would be a bit pointless submitting them for Juno! Salvatore On 28 August 2014 09:26, Kevin Benton wrote: > You could just make the kilo folder in your commit and then rebase it once > Kilo is open. > > > On Thu, Aug 28, 2014 at 12:0

Re: [openstack-dev] [zaqar] [marconi] Removing GET message by ID in v1.1 (Redux)

On 08/27/2014 06:33 PM, Nataliia Uvarova wrote: > I doesn't support the idea of removing this endpoint, although it > requires some efforts to maintain. > > First of all, because of the confusion among users, that it could bring. > The href to message is returned in many cases, and was seen as can

Re: [openstack-dev] [nova] [neutron] Specs for K release

Thanks for your feedback. So I will create a branch for my bp, add the kilo folder and commit it together with my spec. To get sphinx running I also had to make changes to the toc tree in nova-specs/doc/source/index.rst I will also commit this change within my branch, right? thanks, Andreas

[openstack-dev] [Zaqar] Early proposals for design summit sessions

Greetings, I'd like to join the early coordination effort for design sessions. I've shamelessly copied Doug's template for Oslo into a new etherpad so we can start proposing sessions there. https://etherpad.openstack.org/p/kilo-zaqar-summit-topics Flavio -- @flaper87 Flavio Percoco __

[openstack-dev] [Zaqar] Early proposals for design summit sessions

Greetings, I'd like to join the early coordination effort for design sessions. I've shamelessly copied Doug's template for Oslo into a new etherpad so we can start proposing sessions there. https://etherpad.openstack.org/p/kilo-zaqar-summit-topics Flavio -- @flaper87 Flavio Percoco __

Re: [openstack-dev] [nova] [neutron] Specs for K release

Only if you think a sphinx compile is necessary for the review. On Thu, Aug 28, 2014 at 1:14 AM, Andreas Scheuring < scheu...@linux.vnet.ibm.com> wrote: > Thanks for your feedback. > > So I will create a branch for my bp, add the kilo folder and commit it > together with my spec. > > To get sphi

Re: [openstack-dev] [nova] refactoring of resize/migrate

Jay Pipes wrote on 08/27/2014 08:57:08 PM: > From: Jay Pipes > To: openstack-dev@lists.openstack.org > Date: 08/27/2014 08:59 PM > Subject: Re: [openstack-dev] [nova] refactoring of resize/migrate > > On 08/27/2014 06:41 AM, Markus Zoeller wrote: > > The review of the spec to blueprint "hot-res

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by "send_arp_for_ha" config. By checking the man page of arping, you can find the "arping -A" we us

Re: [openstack-dev] [nova] Configuring libivrt VIF driver

On Thu, Aug 28, 2014 at 06:45:58AM +0300, Itzik Brown wrote: > > On 27/08/2014 17:06, Daniel P. Berrange wrote: > >On Tue, Aug 26, 2014 at 05:02:10PM +0300, Itzik Brown wrote: > >>Hi, > >> > >>Following the conversation [1]: > >>My understanding was that the way to use out of the tree vif_driver i

[openstack-dev] [TripleO] Heat AWS WaitCondition's count

Hi all, the AWS::CloudFormation::WaitCondition resource in Heat allows to update the 'count' property, although in real AWS this is prohibited ( https://bugs.launchpad.net/heat/+bug/1340100). My question is does TripleO still depends on this behavior of AWS WaitCondition in any way? I want to be

Re: [openstack-dev] [nova] Is the BP approval process broken?

On Thu, Aug 28, 2014 at 01:04:57AM +, Dugger, Donald D wrote: > I'll try and not whine about my pet project but I do think there > is a problem here. For the Gantt project to split out the scheduler > there is a crucial BP that needs to be implemented ( > https://review.openstack.org/#/c/89893

[openstack-dev] [Nova]libvirt: connect_volume scans all LUNs, it will be very slow with a large number of volumes.RE: [OpenStack][Nova]May be performance issues of connect_volume in Nova

Hi, All I’ve reported a bug related to this mail: https://bugs.launchpad.net/nova/+bug/1362513 From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: Wednesday, August 27, 2014 1:12 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [OpenStack][Nova]Ma

[openstack-dev] [murano] Murano documentation needs improvement

Hi, All! I'd like to keep an attention to Murano documentation. Documentation is really important and leaves the impression of the whole project since it's a first thing with what user or developer faced. So we need to concentrate on it's improvement. I prepared an etherpad

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On 27/08/14 16:31, Sean Dague wrote: [snip] > In python 2.7 (using pip) namespaces are a bolt on because of the way > importing modules works. And depending on how you install things in a > namespace will overwrite the base __init__.py for the top level part of > the namespace in such a way that

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On 28/08/14 12:41, Radomir Dopieralski wrote: > On 27/08/14 16:31, Sean Dague wrote: > > [snip] > >> In python 2.7 (using pip) namespaces are a bolt on because of the way >> importing modules works. And depending on how you install things in a >> namespace will overwrite the base __init__.py for

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On 08/28/2014 12:50 PM, Radomir Dopieralski wrote: > On 28/08/14 12:41, Radomir Dopieralski wrote: >> On 27/08/14 16:31, Sean Dague wrote: >> >> [snip] >> >>> In python 2.7 (using pip) namespaces are a bolt on because of the way >>> importing modules works. And depending on how you install things i

Re: [openstack-dev] [oslo.messaging] Request to include AMQP 1.0 support in Juno-3

On 08/27/2014 03:35 PM, Ken Giusti wrote: > Hi All, > > I believe Juno-3 is our last chance to get this feature [1] included > into olso.messaging. > > I honestly believe this patch is about as low risk as possible for a > change that introduces a whole new transport into oslo.messaging. The > p

Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes

I would like to add a question to John's list - Original Message - > From: "John Schwarz" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Tuesday, August 26, 2014 2:22:33 PM > Subject: Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax > addit

Re: [openstack-dev] [nova] [neutron] Specs for K release

How to do we handle specs that have slipped through the cracks and did not make it for Juno? /Alan From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: August-28-14 9:48 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] [neutron] Specs f

Re: [openstack-dev] [nova] [neutron] Specs for K release

On Thu, Aug 28, 2014 at 11:51:32AM +, Alan Kavanagh wrote: > How to do we handle specs that have slipped through the cracks > and did not make it for Juno? Rebase the proposal so it is under the 'kilo' directory path instead of 'juno' and submit it for review again. Make sure to keep the Chang

Re: [openstack-dev] [oslo] Launchpad tracking of oslo projects

Thierry Carrez wrote: > Doug Hellmann wrote: >> This makes sense to me, so let’s move ahead with your plan. OK, this is now done: Project group @ https://launchpad.net/oslo Oslo incubator: https://launchpad.net/oslo-incubator oslo.messaging: https://launchpad.net/oslo.messaging General blueprint

Re: [openstack-dev] [all] gate debugging

David Kranz wrote: > On 08/27/2014 03:43 PM, Sean Dague wrote: >> On 08/27/2014 03:33 PM, David Kranz wrote: >>> Race conditions are what makes debugging very hard. I think we are in >>> the process of experimenting with such an idea: asymetric gating by >>> moving functional tests to projects, mak

[openstack-dev] [sahara] team meeting Aug 28 1800 UTC

Hi folks, We'll be having the Sahara team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20140828T18 -- Sincerely yours, Sergey Lukjanov

[openstack-dev] [Fuel] Goals for 5.1.1 & 6.0

Hi Fuelers, while we are busy with last bugs which block us from releasing 5.1, we need to start thinking about upcoming releases. Some of you already started POC, some - specs, and I see discussions in ML and IRC. >From overall strategy perspective, focus for 6.0 is: - OpenStack Juno release

[openstack-dev] [Neutron][third-party] Midokura Third-Party CI Status

Hello, today we realised that the Midokura third party jenkins was down and didn't vote for new patches. Apologies. Lucas (who is in charge of this) is in vacations and I'm fighting another wars... Now it should work again as expected, although we have cleaned the queue to don't overload our ser

Re: [openstack-dev] [oslo.messaging] Request to include AMQP 1.0 support in Juno-3

On Thu, 2014-08-28 at 13:24 +0200, Flavio Percoco wrote: > On 08/27/2014 03:35 PM, Ken Giusti wrote: > > Hi All, > > > > I believe Juno-3 is our last chance to get this feature [1] included > > into olso.messaging. > > > > I honestly believe this patch is about as low risk as possible for a > > c

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

James Polley wrote: >>> Point of clarification: I've heard PTL=Project Technical Lead >>> and PTL=Program Technical Lead. Which is it? It is kind of >>> important as OpenStack grows, because the first is responsible >>> for *a* project, and the second is responsibl

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Hi Nikola, Firstly, thanks for waiting for me to respond and sorry I was absent for the last couple of weeks. The extensible resource tracker bp deals with two distinct information flows: 1. information about resources that is passed from the compute node to the scheduler, 2. information about r

[openstack-dev] What's Up Doc? Aug 28, 2014

_Operators midcycle meetup report _ I went to the Operators midcycle meetup this week. Nice work Gauvain on the automation of the New, Changed, and Deprecated configuration options -- at the Operators Midcycle Meetup yesterday they asked for it and lo and behold, it was already there! Nice. The di

Re: [openstack-dev] [nova] [neutron] Specs for K release

For nova we haven't gotten around to doing this, but it shouldn't be a big deal. I'll add it to the agenda for today's meeting. Michael On Thu, Aug 28, 2014 at 2:07 AM, Andreas Scheuring wrote: > Hi, > is it already possible to submit specs (nova & neutron) for the K > release? Would be great fo

[openstack-dev] [neutron] Juno-3 BP Review Meeting Minutes

See below. As discussed in the meeting, lets focus on the medium/high priority BPs this week and try to merge them before FF next week. Thanks to all who attended! Kyle Minutes: http://eavesdrop.openstack.org/meetings/neutron_juno_3_bp_review/2014/neutron_juno_3_bp_review.2014-08-28-13.01.html

Re: [openstack-dev] [nova] [neutron] Specs for K release

On Thu, Aug 28, 2014 at 8:30 AM, Michael Still wrote: > For nova we haven't gotten around to doing this, but it shouldn't be a > big deal. I'll add it to the agenda for today's meeting. > > Michael > For Neutron, I have not gone through and removed specs which merged and haven't made it yet. I'll

Re: [openstack-dev] [zaqar] [marconi] Juno Performance Testing (Round 1)

On 08/26/2014 05:41 PM, Kurt Griffiths wrote: * uWSGI + gevent * config: http://paste.openstack.org/show/100592/ * app.py: http://paste.openstack.org/show/100593/ Hi Kurt! Thanks for posting the benchmark configuration and results. Good stuff :) I'm curious

[openstack-dev] [nova]"instance_info_cache_update" method has been removed

Hello All, I can see that "instance_info_cache_update" method has been removed in version 1.59 in the file nova/conductor/rpcapi.py of the Juno-2 code. Please let me know How can I update the "instance-info-cache table" by making rpc call from nova in the Juno-2 code. Thanks Praveen. __

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by "send_arp_for_ha" config. By checking the man page of arping, you can find the "arping -A" we u

Re: [openstack-dev] [neutron] static IP & DHCP

Hello Sanjivini, How are trying to do it? Creating a port with static ip: $ neutron port-create --fixed-ip subnet_id=,ip_address=10.0.0.100 and then deploy a vm with this port, should work: $ nova boot --flavor 1 --image --nic port-id= test_vm Please note that this is an usage question and t

Re: [openstack-dev] [Openstack][TripleO] What if undercloud machines down, can we reboot overcloud machines?

It is not a big worry but it would have been better if overcloud nodes to be independent of undercloud except being a manager. Think the use case where: 1. nova has three region, geographically apart 2. geographical area hosting undercloud gets doomed 3. all region of nova gets affected as they ca

[openstack-dev] Raising priority for Dynamic Routing

I would like to ask you consider to raise priority from low to medium (I completely understand this is not a high priority feature) the BGP Dynamic Routing feature (https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing). The feature has just 3 patches. * https://review.openstack.org/

[openstack-dev] [Neutron] Raising priority for Dynamic Routing

Sorry, I forgot to tag the subject. On 28 August 2014 16:24, Jaume Devesa wrote: > I would like to ask you consider to raise priority from low to medium (I > completely > understand this is not a high priority feature) the BGP Dynamic Routing > feature > (https://blueprints.launchpad.net/neutron

[openstack-dev] [Fuel] Maintenance mode for patching

All, I'm not sure if it deserves to be mentioned in our documentation, this seems to be a common practice. If an administrator wants to patch his environment, he should be prepared for a temporary downtime of OpenStack services. And he should plan to perform patching in advance: choose a time with

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On 08/27/2014 04:28 PM, Kevin Benton wrote: What are you talking about? The only reply was from me clarifying that one of the purposes of the incubator was for components of neutron that are experimental but are intended to be merged. Right. The special unicorns. > In that case it might not m

[openstack-dev] Design sessions for Neutron LBaaS. What do we want/need?

LBaaS team, As we discussed in the Weekly LBaaS meeting this morning we should make sure we get the design sessions scheduled that we are interested in. We currently agreed on the following: * Neutron LBaaS. we want to schedule 2 sessions. I am assuming that we want to go over status and also th

[openstack-dev] [Neutron][LBass] Design sessions for Neutron LBaaS. What do we want/need?

With a corrected Subject. Susanne On Thu, Aug 28, 2014 at 10:49 AM, Susanne Balle wrote: > > LBaaS team, > > As we discussed in the Weekly LBaaS meeting this morning we should make > sure we get the design sessions scheduled that we are interested in. > > We currently agreed on the following: >

Re: [openstack-dev] [UX] [Horizon] [Heat] Merlin project (formerly known as cross-project UI library for Heat/Mistral/Murano/Solum) plans for PoC and more

Hello, Drago! I'm extremely interested in learning more about your HOT graphical builder. The screenshots you had attached look gorgeous! Yours visual representation of Heat resources is much more concise and simple than I had drawn in Merlin PoC mock-ups [1]. On the other hand I have some suspici

Re: [openstack-dev] [Openstack][TripleO] What if undercloud machines down, can we reboot overcloud machines?

So I think the thing to keep in mind here is that your overcloud nodes are OpenStack _instances_ in TripleO. Would you would expect to start a VM in Nova, shut off all of the OpenStack services, and still be able to reboot that VM successfully? Maybe if you had static networking, but I highly dou

[openstack-dev] [sahara] Notes on developing Sahara Spark EDP to work with swift:// paths

Hi folks, I've updated this etherpad with notes from an investigation of Spark/Swift and the hadoop-openstack plugin carried in the sahara-extra repo. Following the notes there, I was able to access swift:// paths from Spark jobs on a Spark standalone cluster launched from Sahara and then f

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

>Right. The special unicorns. Repeating this without defining it isn't helping anything. >b) The experimental piece of code intends to replace whole-hog a large chunk of Neutron's existing codebase, or: In the DVR example I gave this is is the only relevant reason. Regardless of how well the int

[openstack-dev] [all] Gerrit Downtime on August 30, 2014

Hi, Gerrit will be unavailable starting at 1600-1630 UTC on Saturday, August 30, 2014 to rename the glance.store project to glancestore. I apologize for the late notice, however, in another thread on the -dev list, you'll find the rationale for executing this change swiftly. Thanks, Jim __

Re: [openstack-dev] [ironic] [neutron] make mac address updatable - port status for ironic servers

Right, so the question now is whether there are plans to change this. It doesn't seem desirable to be showing DOWN status when things are functional, so I'm nervous about relying on this behavior to allow mac address update to work. If future plans involved ironic providing port status, and di

Re: [openstack-dev] [all] Gerrit Downtime on August 30, 2014

On 08/28/2014 05:39 PM, James E. Blair wrote: > Hi, > > Gerrit will be unavailable starting at 1600-1630 UTC on Saturday, > August 30, 2014 to rename the glance.store project to glancestore. I went with glance_store Hope that's fine! Thanks a lot for addressing this so quickly. Flavio -- @fla

Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters

Hi Mathieu, please see my comments below. On Wed, 2014-08-27 at 16:13 +0200, Mathieu Rohon wrote: > hi irena, > > in the proposal of andreas you want to enforce the non-promisc mode > per l2-agent? yes, kind of. We're currently not yet sure how to figure out the right interface for the registr

[openstack-dev] [neutron] VPNaaS pending state handling

https://bugs.launchpad.net/neutron/+bug/1355360 I'm working on this vpn vendor bug and am looking for guidance on the approach. I'm also relatively new to neutron development so bear with some newbie gaffs :) The problem reported in this bug, in a nutshell, is the policies in the neutron vpn db a

Re: [openstack-dev] [Spam] Re: [Openstack][TripleO] [Ironic] What if undercloud machines down, can we reboot overcloud machines?

Excerpts from Jyoti Ranjan's message of 2014-08-27 21:20:19 -0700: > I do agree but it create an extra requirement for Undercloud if we high > availability is important criteria. Because of this, undercloud has to be > there 24x7, 365 days and to make it available we need to have HA for this > also

Re: [openstack-dev] [all] Gerrit Downtime on August 30, 2014

Flavio Percoco writes: > On 08/28/2014 05:39 PM, James E. Blair wrote: >> Hi, >> >> Gerrit will be unavailable starting at 1600-1630 UTC on Saturday, >> August 30, 2014 to rename the glance.store project to glancestore. > > I went with glance_store > > Hope that's fine! Even better! > Thanks a

[openstack-dev] [oslo] change to deprecation policy in the incubator

Before Juno we set a deprecation policy for graduating libraries that said the incubated versions of the modules would stay in the incubator repository for one full cycle after graduation. This gives projects time to adopt the libraries and still receive bug fixes to the incubated version (see

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On Aug 28, 2014, at 10:45 AM, Jay Pipes wrote: > On 08/27/2014 04:28 PM, Kevin Benton wrote: >> What are you talking about? The only reply was from me clarifying that >> one of the purposes of the incubator was for components of neutron that >> are experimental but are intended to be merged. >

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On Aug 28, 2014, at 6:41 AM, Radomir Dopieralski wrote: > On 27/08/14 16:31, Sean Dague wrote: > > [snip] > >> In python 2.7 (using pip) namespaces are a bolt on because of the way >> importing modules works. And depending on how you install things in a >> namespace will overwrite the base __i

Re: [openstack-dev] [sahara] Notes on developing Sahara Spark EDP to work with swift:// paths

Hi, In case this is helpful for you, this is the patch i submitted to Spark about Swift and Spark integration ( about to be merged ) https://github.com/apache/spark/pull/1010 I sent information about this patch to this mailing list about two months ago. All the best, Gil. From: Trevor M

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On 08/28/2014 12:22 PM, Doug Hellmann wrote: > > On Aug 28, 2014, at 6:41 AM, Radomir Dopieralski > wrote: > >> On 27/08/14 16:31, Sean Dague wrote: >> >> [snip] >> >>> In python 2.7 (using pip) namespaces are a bolt on because of the way >>> importing modules works. And depending on how you in

Re: [openstack-dev] [all] gate debugging

On Aug 27, 2014, at 5:56 PM, Sean Dague wrote: > On 08/27/2014 05:27 PM, Doug Hellmann wrote: >> >> On Aug 27, 2014, at 2:54 PM, Sean Dague wrote: >> >>> Note: thread intentionally broken, this is really a different topic. >>> >>> On 08/27/2014 02:30 PM, Doug Hellmann wrote:> On Aug 27,

Re: [openstack-dev] [nova] [neutron] Specs for K release

On Thu, Aug 28, 2014 at 6:53 AM, Daniel P. Berrange wrote: > On Thu, Aug 28, 2014 at 11:51:32AM +, Alan Kavanagh wrote: >> How to do we handle specs that have slipped through the cracks >> and did not make it for Juno? > > Rebase the proposal so it is under the 'kilo' directory path > instead

Re: [openstack-dev] [all] gate debugging

On Thu, Aug 28, 2014 at 11:48 AM, Doug Hellmann wrote: > In my case, a neutron call failed. Most of the other services seem to have > a *-api.log file, but neutron doesn’t. It took a little while to find the > API-related messages in screen-q-svc.txt (I’m glad I’ve been around long > enough to kn

Re: [openstack-dev] [Spam] Re: [Openstack][TripleO] [Ironic] What if undercloud machines down, can we reboot overcloud machines?

On August 28, 2014 8:58:11 AM PDT, Clint Byrum wrote: >Excerpts from Jyoti Ranjan's message of 2014-08-27 21:20:19 -0700: >> I do agree but it create an extra requirement for Undercloud if we >high >> availability is important criteria. Because of this, undercloud has >to be >> there 24x7, 365 d

Re: [openstack-dev] [sahara] Notes on developing Sahara Spark EDP to work with swift:// paths

Gil, thanks! I'll take a look. Trevor On Thu, 2014-08-28 at 19:31 +0300, Gil Vernik wrote: > Hi, > > In case this is helpful for you, this is the patch i submitted to > Spark about Swift and Spark integration ( about to be merged ) > https://github.com/apache/spark/pull/1010 > > I sent in

Re: [openstack-dev] [sahara] Notes on developing Sahara Spark EDP to work with swift:// paths

hi Gil, that's cool about the patch to Spark, has there been any talk about upgrading that patch to include Keystone v3 operations? - Original Message - > Hi, > > In case this is helpful for you, this is the patch i submitted to Spark > about Swift and Spark integration ( about to be me

Re: [openstack-dev] [nova] [neutron] Specs for K release

On 08/28/2014 12:50 PM, Michael Still wrote: On Thu, Aug 28, 2014 at 6:53 AM, Daniel P. Berrange wrote: On Thu, Aug 28, 2014 at 11:51:32AM +, Alan Kavanagh wrote: How to do we handle specs that have slipped through the cracks and did not make it for Juno? Rebase the proposal so it is und

Re: [openstack-dev] [all] gate debugging

On 08/28/2014 12:48 PM, Doug Hellmann wrote: > > On Aug 27, 2014, at 5:56 PM, Sean Dague wrote: > >> On 08/27/2014 05:27 PM, Doug Hellmann wrote: >>> >>> On Aug 27, 2014, at 2:54 PM, Sean Dague wrote: >>> Note: thread intentionally broken, this is really a different topic. On 08/

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

I have another question about incubator proposal, for CLI and GUI. Do we imply that the incubator feature will need to branch python-neutron client, Horizon, and or Nova ( if changes are needed)? On Tue, Aug 26, 2014 at 7:09 PM, James E. Blair wrote: > Hi, > > After reading https://wiki.opens

Re: [openstack-dev] [nova] [neutron] Specs for K release

+1 I agree that this is a good idea. Regards, Mandeep On Thu, Aug 28, 2014 at 10:13 AM, Jay Pipes wrote: > On 08/28/2014 12:50 PM, Michael Still wrote: > >> On Thu, Aug 28, 2014 at 6:53 AM, Daniel P. Berrange >> wrote: >> >>> On Thu, Aug 28, 2014 at 11:51:32AM +, Alan Kavanagh wro

Re: [openstack-dev] [sahara] Notes on developing Sahara Spark EDP to work with swift:// paths

Hi Michael, I have an update to this patch with temp auth authentication also, but it's not yet submitted. I am not aware of v3 support. All the best, Gil. From: Michael McCune To: "OpenStack Development Mailing List (not for usage questions)" Date: 28/08/2014 08:14 PM Subject:

Re: [openstack-dev] [UX] [Horizon] [Heat] Merlin project (formerly known as cross-project UI library for Heat/Mistral/Murano/Solum) plans for PoC and more

Timur, Composable entities can be a real need for Heat if provider templates (which allow templates to be used as a resource, with a template’s parameters and outputs becoming properties and attributes, respectively) are to be included in the app. A provider template resource, since it is a templa

Re: [openstack-dev] [oslo.messaging] Request to include AMQP 1.0 support in Juno-3

On Aug 28, 2014, at 8:36 AM, Mark McLoughlin wrote: > On Thu, 2014-08-28 at 13:24 +0200, Flavio Percoco wrote: >> On 08/27/2014 03:35 PM, Ken Giusti wrote: >>> Hi All, >>> >>> I believe Juno-3 is our last chance to get this feature [1] included >>> into olso.messaging. >>> >>> I honestly belie

Re: [openstack-dev] [all] gate debugging

On Aug 28, 2014, at 1:00 PM, Dean Troyer wrote: > On Thu, Aug 28, 2014 at 11:48 AM, Doug Hellmann wrote: > In my case, a neutron call failed. Most of the other services seem to have a > *-api.log file, but neutron doesn’t. It took a little while to find the > API-related messages in screen-q-

Re: [openstack-dev] [all] gate debugging

On Aug 28, 2014, at 1:17 PM, Sean Dague wrote: > On 08/28/2014 12:48 PM, Doug Hellmann wrote: >> >> On Aug 27, 2014, at 5:56 PM, Sean Dague wrote: >> >>> On 08/27/2014 05:27 PM, Doug Hellmann wrote: On Aug 27, 2014, at 2:54 PM, Sean Dague wrote: > Note: thread intentiona

Re: [openstack-dev] [all] Design Summit reloaded

On 08/27/2014 11:34 AM, Doug Hellmann wrote: On Aug 27, 2014, at 8:51 AM, Thierry Carrez wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply s

Re: [openstack-dev] [all] gate debugging

On Thu, Aug 28, 2014 at 10:17 AM, Sean Dague wrote: > On 08/28/2014 12:48 PM, Doug Hellmann wrote: > > > > On Aug 27, 2014, at 5:56 PM, Sean Dague wrote: > > > >> On 08/27/2014 05:27 PM, Doug Hellmann wrote: > >>> > >>> On Aug 27, 2014, at 2:54 PM, Sean Dague wrote: > >>> > Note: thread in

[openstack-dev] [CEILOMETER] Trending Alarm

Hello, everyone! I want to have an alarm that is triggered by some kind of trend. For example, an alarm that is triggeredwhen the CPU utilization is growing steadly (for example, has grown approximately 10% per 5 minutes, where the percentage and time window would be parameters, but then I wo

Re: [openstack-dev] [all] gate debugging

On Thu, Aug 28, 2014 at 12:44 PM, Doug Hellmann wrote: > I usually use the functions for editing ENABLED_SERVICES. Is it still > common to edit the variable directly? > > Not generally. It was looking at it in log files to see what was/was not enabled where I started to think about that. The de

Re: [openstack-dev] [all] gate debugging

On 08/28/2014 01:48 PM, Doug Hellmann wrote: > > On Aug 28, 2014, at 1:17 PM, Sean Dague wrote: > >> On 08/28/2014 12:48 PM, Doug Hellmann wrote: >>> >>> On Aug 27, 2014, at 5:56 PM, Sean Dague wrote: >>> On 08/27/2014 05:27 PM, Doug Hellmann wrote: > > On Aug 27, 2014, at 2:54 PM,

Re: [openstack-dev] [all] gate debugging

On 08/28/2014 02:07 PM, Joe Gordon wrote: > > > > On Thu, Aug 28, 2014 at 10:17 AM, Sean Dague > wrote: > > On 08/28/2014 12:48 PM, Doug Hellmann wrote: > > > > On Aug 27, 2014, at 5:56 PM, Sean Dague > wrote: > > > >> On 0

Re: [openstack-dev] [all] gate debugging

On Thu, Aug 28, 2014 at 5:17 AM, Thierry Carrez wrote: > David Kranz wrote: > > On 08/27/2014 03:43 PM, Sean Dague wrote: > >> On 08/27/2014 03:33 PM, David Kranz wrote: > >>> Race conditions are what makes debugging very hard. I think we are in > >>> the process of experimenting with such an ide

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On 2014-08-28 08:31:26 -0700 (-0700), Kevin Benton wrote: [...] > DVR completely changed the reference L3 service plugin, which > lives in the main tree.  > > A well-defined, versioned internal API would not have helped any > of the issues I brought up. [...] Except, perhaps, insofar as that (in

[openstack-dev] Launch of a instance failed

Hi i am deploying a devstack juno on ubuntu 14.04 server virtual machine. After installation,when i am trying to launch a instance,its failed. I am getting "host not found" error. Below is part of /opt/stack/logs/screen/screen-n-cond.log Below is ther error 2014-08-28 23:44:59.448 ERROR nova.sche

Re: [openstack-dev] [all] Design Summit reloaded

On 08/28/2014 01:58 PM, Jay Pipes wrote: > On 08/27/2014 11:34 AM, Doug Hellmann wrote: >> >> On Aug 27, 2014, at 8:51 AM, Thierry Carrez >> wrote: >> >>> Hi everyone, >>> >>> I've been thinking about what changes we can bring to the Design >>> Summit format to make it more productive. I've heard

Re: [openstack-dev] [Mistral] Workflow on-finish

Is there an example somewhere that I can reference on how to define this special task? Thanks! On Wed, Aug 27, 2014 at 10:02 PM, Renat Akhmerov wrote: > Right now, you can just include a special task into a workflow that, for > example, sends an HTTP request to whatever you need to notify abou

Re: [openstack-dev] [nova] Is the BP approval process broken?

On Thu, Aug 28, 2014 at 2:40 AM, Daniel P. Berrange wrote: > On Thu, Aug 28, 2014 at 01:04:57AM +, Dugger, Donald D wrote: > > I'll try and not whine about my pet project but I do think there > > is a problem here. For the Gantt project to split out the scheduler > > there is a crucial BP th

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

Yes, in theory all of the plugins should be removable from the core neutron repo. So then it would only need to be responsible for the APIs, db models, etc. However, IIRC there are no plans to move any reference plugins from the tree. On Thu, Aug 28, 2014 at 11:20 AM, Jeremy Stanley wrote: > On

Re: [openstack-dev] [Octavia] Using Nova Scheduling Affinity and AntiAffinity

Brandon I am not sure how ready that nova feature is for general use and have asked our nova lead about that. He is on vacation but should be back by the start of next week. I believe this is the right approach for us moving forward. We cannot make it mandatory to run the 2 filters but we can say

Re: [openstack-dev] [all] Design Summit reloaded

On 08/28/2014 02:21 PM, Sean Dague wrote: On 08/28/2014 01:58 PM, Jay Pipes wrote: On 08/27/2014 11:34 AM, Doug Hellmann wrote: On Aug 27, 2014, at 8:51 AM, Thierry Carrez wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more pro

Re: [openstack-dev] [Neutron][LBass] Design sessions for Neutron LBaaS. What do we want/need?

Hi Susanne-- Regarding the Octavia sessions: I think we probably will have enough to discuss that we could use two design sessions. However, I also think that we can probably come to conclusions on whether Octavia should become a part of Neutron Incubator right away via discussion on this mailin

Re: [openstack-dev] Design sessions for Neutron LBaaS. What do we want/need?

Let's use a different email thread to discuss if Octavia should be part of the Neutron incubator project right away or not. I would like to keep the two discussions separate. Susanne On Thu, Aug 28, 2014 at 10:49 AM, Susanne Balle wrote: > > LBaaS team, > > As we discussed in the Weekly LBaaS

Re: [openstack-dev] [Neutron][LBass] Design sessions for Neutron LBaaS. What do we want/need?

Let's use a different email thread to discuss if Octavia should be part of the Neutron incubator project right away or not. I would like to keep the two discussions separate. Susanne On Thu, Aug 28, 2014 at 3:20 PM, Stephen Balukoff wrote: > Hi Susanne-- > > Regarding the Octavia sessions:

Re: [openstack-dev] [all] Design Summit reloaded

On 08/28/2014 03:06 PM, Jay Pipes wrote: > On 08/28/2014 02:21 PM, Sean Dague wrote: >> On 08/28/2014 01:58 PM, Jay Pipes wrote: >>> On 08/27/2014 11:34 AM, Doug Hellmann wrote: On Aug 27, 2014, at 8:51 AM, Thierry Carrez wrote: > Hi everyone, > > I've been thinking

Re: [openstack-dev] [all] Design Summit reloaded

On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez wrote: > Hi everyone, > > I've been thinking about what changes we can bring to the Design Summit > format to make it more productive. I've heard the feedback from the > mid-cycle meetups and would like to apply some of those ideas for Paris, > with

Re: [openstack-dev] [Octavia] Octavia VM image design

I agree with Michael. We need to use the OpenStack tooling. Sahara is encountering some of the same issues we are as they are building up their hadoop VM/clusters. See http://docs.openstack.org/developer/sahara/userdoc/vanilla_plugin.html http://docs.openstack.org/developer/sahara/userdoc/diskim

  1   2   >