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

https://review.openstack.org/#/c/93564/ has no sense without https://review.openstack.org/#/c/87573 +1 on merging DOC bugs you listed and these 2 EDP bugs Andrew. On Mon, Jun 2, 2014 at 11:08 PM, Sergey Lukjanov wrote: > /me proposing to backport: > > Docs: > > https://review.openstack.org/#/

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

correction: https://review.openstack.org/#/c/96621/ (Added validate_edp method to Plugin SPI doc) has no sense without https://review.openstack.org/#/c/87573 (Fix running EDP job on transient cluster) where validate_edp was introduced. Andrew. On Mon, Jun 2, 2014 at 11:34 PM, Andrew Lazarev wro

Re: [openstack-dev] [Horizon] Use of AngularJS

On Tue, Jun 03, 2014 at 07:49:04AM +0200, Radomir Dopieralski wrote: > On 06/02/2014 05:13 PM, Adam Nelson wrote: > > I think that you would use the PyPI version anyway: > > > > https://pypi.python.org/pypi/django-angular/0.7.2 > > > > That's how most of the other Python dependencies work, even i

Re: [openstack-dev] [Solum] PTL Candidacy Open

Anita Kuno writes: > On 05/27/2014 06:25 PM, Adrian Otto wrote: > >> Team, >> >> If you would like to declare a candidacy for PTL for Solum, you may send an >> email with the subject "[Solum] Solum PTL Candidacy” to this mailing list >> declaring your candidacy. Please respond with candidacy n

Re: [openstack-dev] [Fuel] Review blueprint specs on gerrit

Thanks Dmitry. I'm walking through one of the proposed designs: https://review.openstack.org/#/c/96429/, http://docs-draft.openstack.org/29/96429/4/check/gate-fuel-specs-docs/4590dac/doc/build/html/specs/5.1/access-control-master-node.html I've noticed a few things in the process which I'd propose

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

/me proposing to backport: Docs: https://review.openstack.org/#/c/87531/ Change IRC channel name to #openstack-sahara https://review.openstack.org/#/c/96621/ Added validate_edp method to Plugin SPI doc https://review.openstack.org/#/c/89647/ Updated architecture diagram in docs EDP: https://rev

[openstack-dev] [sahara] 2014.1.1 preparation

Hey folks, this Thu, June 5 is the date for 2014.1.1 release. We already have some back ported patches to the stable/icehouse branch, so, the question is do we need some more patches to back port? Please, propose them here. 2014.1 - stable/icehouse diff: https://github.com/openstack/sahara/compar

Re: [openstack-dev] [Nova] [Ironic] [Infra] Making Ironic vote as a third-party Nova driver

Howdy, Here is my first pass at allowing different voters for different pipelines. https://review.openstack.org/#/c/97391/2 Cheers, Josh Rackspace Australia On 5/30/14 3:30 AM, Devananda van der Veen wrote: On Wed, May 28, 2014 at 10:54 PM, Joshua Hesketh mailto:joshua.hesk...@rackspace.com>>

Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories

On 05/31/2014 11:13 PM, Jeremy Stanley wrote: > On 2014-05-29 20:55:01 + (+), Lyle, David wrote: > [...] >> There are several more xstatic packages that horizon will pull in that are >> maintained outside openstack. The packages added are only those that did >> not have existing xstatic pac

Re: [openstack-dev] [MagnetoDB] PTL elections

Only one candidate has been proposed for this position, so, due to the election process we have the MagnetoDB PTL for the Juno cycle. Congratulations to Ilya Sviridov! Elections doc updated - https://wiki.openstack.org/wiki/MagnetoDB/PTL_Elections_Juno Thanks. On Mon, May 26, 2014 at 4:16 PM, S

Re: [openstack-dev] [Horizon] Use of AngularJS

On 06/02/2014 05:13 PM, Adam Nelson wrote: > I think that you would use the PyPI version anyway: > > https://pypi.python.org/pypi/django-angular/0.7.2 > > That's how most of the other Python dependencies work, even in the > distribution packages. That is not true. As all components of OpenStack,

[openstack-dev] [Neutron] request for review

can anyone please review this small fix for ofagent? https://review.openstack.org/#/c/88224/ it's unfortunate a simple fix like this taking months to be merged. YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lis

Re: [openstack-dev] nova-compute rpc version

Hi Russell Below are the details... controller node... nova --version 2.17.0.122 nova-compute --version 2014.2 compute node. nova --version 2.17.0.122 nova-compute --version 2013.2.4 Can you help me what i need to change in order to achieve the desired functioonality. Thaks On Tue

Re: [openstack-dev] [Trove] Pluggable conductor manager

Sent that a little too quickly... This is to be more inline with the other services we have ie. taskmanager [1] that you can override if you see fit. We decided this was an oversight from the original creation and should be added. [1] https://github.com/openstack/trove/blob/master/trove/cmd/taskm

Re: [openstack-dev] [Trove] Pluggable conductor manager

This is to be more inline with the other services we have ie. taskmanager [1] that you can override if you see fit. On Mon, Jun 2, 2014 at 3:55 PM, Russell Bryant wrote: > On 06/02/2014 09:23 AM, boden wrote: > > On 4/28/2014 2:58 PM, Dan Smith wrote: > >>> I'd like to propose the ability to s

[openstack-dev] [gantt] scheduler sub-group meeting agenda 6/3

1) Forklift (tasks & status) 2) No-db scheduler discussion (BP ref - https://review.openstack.org/#/c/92128/ ) 3) Opens -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@list

Re: [openstack-dev] [all] HTTP REST API error status code for out of quota errors

On Mon, Jun 2, 2014 at 7:21 PM, Christopher Yeoh wrote: > Hi, > > There's been a few patches like this floating around recently which fix > the incorrect use of 413 as the http error code when a request fails > because of the requestor is out of quota. > > https://review.openstack.org/#/c/95671/

[openstack-dev] [Ironic] Cleaning up our bug list

Hi all! I'd like to draw attention to our list of open bugs: https://bugs.launchpad.net/ironic/+bugs And ask that, if you have a bug assigned to you, please ensure you're actively working on it. If you're not, please un-assign yourself from the bug so it becomes visible / available to others. Y

Re: [openstack-dev] [all] HTTP REST API error status code for out of quota errors

2014-06-03 9:21 GMT+09:00 Christopher Yeoh : > Hi, > > There's been a few patches like this floating around recently which fix the > incorrect use of 413 as the http error code when a request fails because of > the requestor is out of quota. > > https://review.openstack.org/#/c/95671/ > > Now 413 i

Re: [openstack-dev] [Heat] Short term scaling strategies for large Heat stacks

Excerpts from Steve Baker's message of 2014-06-02 14:37:25 -0700: > On 31/05/14 07:01, Zane Bitter wrote: > > On 29/05/14 19:52, Clint Byrum wrote: > > > >> update-failure-recovery > >> === > >> > >> This is a blueprint I believe Zane is working on to land in Juno. It > >> will

[openstack-dev] [all] HTTP REST API error status code for out of quota errors

Hi, There's been a few patches like this floating around recently which fix the incorrect use of 413 as the http error code when a request fails because of the requestor is out of quota. https://review.openstack.org/#/c/95671/ Now 413 is definitely wrong, but sometimes the change is made to 400

[openstack-dev] [neutron] blueprint ovs-firewall-driver: OVS implementation of security groups

Hi all, In the Neutron weekly meeting today[0], we discussed the ovs-firewall-driver blueprint[1]. Moving forward, OVS features today will give us "80%" of the iptables security groups behavior. Specifically, OVS lacks connection tracking so it won’t have a RELATED feature or stateful rules for

[openstack-dev] [nova] Bug Day on 6/4

Hi Folks - nova is going to have a bug day on Wednesday, 6/4. During that day we are asking people to take a break from feature work and help fix and/or review bugs for the day.We hang out on #openstack-bugday We admire our progress on http://status.openstack.org/bugday

[openstack-dev] [keystone] Create keystoneclient with existing token?

Hi all, Looking for some help with $subject: What I'm trying to do is take an existing token (a trust scoped token, which cannot be use to request another token), and initialize the auth_ref correctly in a keystoneclient object. The problem is keystoneclient always requests a new token, via the

Re: [openstack-dev] [Heat] Short term scaling strategies for large Heat stacks

Steve Baker wrote on 06/02/2014 05:37:25 PM: > > BTW You missed off another strategy that we have discussed in the > > past, and which I think Steve Baker might(?) be working on: retrying > > failed calls at the client level. > > > As part of the client-plugins blueprint I'm planning on implement

Re: [openstack-dev] [Heat] Short term scaling strategies for large Heat stacks

On 31/05/14 07:01, Zane Bitter wrote: > On 29/05/14 19:52, Clint Byrum wrote: > >> update-failure-recovery >> === >> >> This is a blueprint I believe Zane is working on to land in Juno. It >> will >> allow us to retry a failed create or update action. Combined with the >> separa

Re: [openstack-dev] [Solum] PTL Candidacy Open

On 05/27/2014 06:25 PM, Adrian Otto wrote: > Team, > > If you would like to declare a candidacy for PTL for Solum, you may send an > email with the subject "[Solum] Solum PTL Candidacy” to this mailing list > declaring your candidacy. Please respond with candidacy notices no later than > 00:00

Re: [openstack-dev] Your suggestions in the BP

Hi ya'll! Comments inline: On Sun, Jun 1, 2014 at 1:09 PM, Brandon Logan wrote: > Hi Eugene and Sam, > > On Sun, 2014-06-01 at 12:07 +0400, Eugene Nikanorov wrote: > > Hi Sam, > > > > Eugene, please comment on the migration process bellow. > > > > I think that closing down the

[openstack-dev] [Nova][Ceilometer] Need some advices for blueprint

Dear all, Due to our business model and we have various hardware platforms to support IaaS, so, we need more informations from hypervisors, such as cpu model name(more specifically, it would look like: "Intel E5-2630L" ) and memory frequency in order to give our customers more objective value

Re: [openstack-dev] [Trove] Pluggable conductor manager

On 06/02/2014 09:23 AM, boden wrote: > On 4/28/2014 2:58 PM, Dan Smith wrote: >>> I'd like to propose the ability to support a pluggable trove conductor >>> manager. Currently the trove conductor manager is hard-coded [1][2] and >>> thus is always 'trove.conductor.manager.Manager'. I'd like to see

Re: [openstack-dev] [nova] nova default quotas

On Mon, Jun 2, 2014 at 12:29 PM, Matt Riedemann wrote: > > > On 6/2/2014 12:53 PM, Joe Gordon wrote: > >> >> >> >> On Thu, May 29, 2014 at 10:46 AM, Matt Riedemann >> mailto:mrie...@linux.vnet.ibm.com>> wrote: >> >> >> >> On 5/27/2014 4:44 PM, Vishvananda Ishaya wrote: >> >> I’m not s

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

I think you should add the constraints you have. Realistically though, not every will be there, and thats fine. There are some folk we'll need there (e.g. I suspect I'm one of those, but maybe not!) My constraints are: - need to be in Sydney for the 1st-5th, remembering there is an international

Re: [openstack-dev] nova-compute rpc version

On 06/02/2014 08:20 AM, abhishek jain wrote: > |Hi > | > > | > I'm getting following error in nova-compute logs when trying to boot VM from > controller node onto compute node ... > > Specified RPC version, 3.23, not supported > > Please help regarding this. It sounds like you're using an ol

[openstack-dev] [oslo] blueprint priorities

Oslo team, I've updated the blueprints listed for juno for oslo [1] and oslo.messaging [2] based on the specs that have been submitted to the oslo-specs repository [3] and taken a stab at priorities for all of them. Please look over the list so we can discuss the priorities at the meeting this wee

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

Paul, I'm curious. Have you been able to update to a client using requests? Has it solved your problem? Carl On Thu, May 29, 2014 at 11:15 AM, Paul Ward wrote: > Yes, we're still on a code level that uses httplib2. I noticed that as > well, but wasn't sure if that would really > help here as

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

+1. After reading through this thread, I think that a blind --retries N could be harmful and unwise given the current API definition. Users that need a retry for an SSL error are going to get in to the habit of adding --retries N to all their calls and they'll end up in trouble because they reall

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

On 06/02/2014 01:05 PM, Sean Dague wrote: > On 06/02/2014 09:21 AM, Matthew Treinish wrote: > >>> The url for this is - http://goo.gl/g4aMjM >>> >>> (the long url is very long: >>> https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack%2Ftempest+OR+project%3Aopenstack-dev%2Fgren

Re: [openstack-dev] [solum] [mistral] [heat] keystone chained trusts / oauth

> 1. There doesn't seem to be any non-global way to prevent oauth accesskeys > from expiring.  We need delegation to last the (indefinite) lifetime of the > heat stack, so the delegatation cannot expire. > 2. Most (all?) of the oauth interfaces are admin-only.  I'm not clear if > this is a blocker,

Re: [openstack-dev] [Fuel] Backporting bugfixes to stable releases

Thanks Dmitry. Can we do #2 using new cool gerrit feature (thanks to Infra team!) ? - when patch is merged, button "Cherry Pick To" appears near Review button, you can easily choose branch by clicking on it? On Mon, Jun 2, 2014 at 12:33 PM, Dmitry Borodaenko wrote: > Our experience in backporti

Re: [openstack-dev] [Marconi] Adopt Spec

+1 – Requiring specs for every blueprint is going to make the development process very cumbersome, and will take us back to waterfall days. I like how the Marconi team operates now, with design decisions being made in IRC/ team meetings. So Spec might become more of an overhead than add value, gi

[openstack-dev] [Fuel] Backporting bugfixes to stable releases

Our experience in backporting leftover bugfixes from MOST 5.0 to 4.1 was not pleasant, primarily because too many backport commits had to be dealt with at the same time. We can do better next time if we follow a couple of simple rules: 1) When you create a new bug with High or Critical priority o

Re: [openstack-dev] [nova] nova default quotas

On 6/2/2014 12:53 PM, Joe Gordon wrote: On Thu, May 29, 2014 at 10:46 AM, Matt Riedemann mailto:mrie...@linux.vnet.ibm.com>> wrote: On 5/27/2014 4:44 PM, Vishvananda Ishaya wrote: I’m not sure that this is the right approach. We really have to add the old extension ba

Re: [openstack-dev] [Marconi] Kafka support and high throughput

Keith, Have you put HTTP protocol in front of Kafka, or are you using Kafka¹s native protocol? Can you also expand a little on your performance requirements? What does ³high throughput² mean to you in terms of the messaging patterns (# of producers and consumers, # of queues and queue partitions,

Re: [openstack-dev] [marconi] Removing Get and Delete Messages by ID

First of all, I think the removal of ³get message[s] by ID² is a great change, it moves Marconi APIs closer to a typical messaging semantics. However, I still see the ³list messages² API in the spec (https://wiki.openstack.org/wiki/Marconi/specs/api/v1.1#List_Messages). Is it the plan to leave this

Re: [openstack-dev] [Murano] [meetings] Murano bug scrub

Thanks for today's bug scrub meeting! The meeting minutes are available by the following links: Minutes: http://eavesdrop.openstack.org/meetings/murano_bug_scrub/2014/murano_bug_scrub.2014-06-02-17.02.html Minutes (text): http://eavesdrop.openstack.org/meetings/murano_bug_scrub/2014/murano_bug_sc

Re: [openstack-dev] [Nova]Passing flat_injected flag through instance metadata

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Then I think the answer to the original question is that this requires a new spec, unless one already exists? - -Ben On 06/02/2014 12:50 PM, Vishvananda Ishaya wrote: > We have discussed this a bunch in the past, and the right > implementation here i

Re: [openstack-dev] [nova] nova default quotas

On Thu, May 29, 2014 at 10:46 AM, Matt Riedemann wrote: > > > On 5/27/2014 4:44 PM, Vishvananda Ishaya wrote: > >> I’m not sure that this is the right approach. We really have to add the >> old extension back for compatibility, so it might be best to simply keep >> that extension instead of addin

Re: [openstack-dev] [Nova]Passing flat_injected flag through instance metadata

We have discussed this a bunch in the past, and the right implementation here is to put the network configuration in a standard format (json?) in both the config drive and metadata. cloud-init can be modified to read from that format and write out a proper /etc/network/interfaces (or appropriat

Re: [openstack-dev] [nova] nova default quotas

On Thu, May 29, 2014 at 5:45 AM, Day, Phil wrote: > > > > > *From:* Kieran Spear [mailto:kisp...@gmail.com] > *Sent:* 28 May 2014 06:05 > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [nova] nova default quotas > > > > Hi Joe, > > > > On 28/

Re: [openstack-dev] [Marconi] Adopt Spec

I’ve been in roles where enormous amounts of time were spent on writing specs, and in roles where specs where non-existent. Like most things, I’ve become convinced that success lies in moderation between the two extremes. I think it would make sense for big specs, but I want to be careful we use

Re: [openstack-dev] [Nova]Passing flat_injected flag through instance metadata

Hi, Thanks for getting back to me. The current flat_injected flag is set in the hypervisor nova.conf. The config drive data uses this flag to set the static network configuration. What I am trying to accomplish is to pass the flat_injected file through the instance metadata during the boot time an

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

On 06/02/2014 09:21 AM, Matthew Treinish wrote: >> The url for this is - http://goo.gl/g4aMjM >> >> (the long url is very long: >> https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack%2Ftempest+OR+project%3Aopenstack-dev%2Fgrenade+OR+project%3Aopenstack%2Fqa-specs%29+status%3A

[openstack-dev] [Mistral] Meeting minutes

Hi all, Thanks to all participants for visiting the Mistral meeting in #openstack-meeting today! The meeting minutes can be found by the following links: Minutes: http://eavesdrop.openstack.org/meetings/mistral_meeting/2014/mistral_meeting.2014-06-02-16.00.html Minutes (text): http://eavesdrop.o

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

On 05/30/2014 06:58 AM, Jaromir Coufal wrote: > On 2014/30/05 10:00, Thomas Spatzier wrote: >> Excerpt from Zane Bitter's message on 29/05/2014 20:57:10: >> >>> From: Zane Bitter >>> To: openstack-dev@lists.openstack.org >>> Date: 29/05/2014 20:59 >>> Subject: Re: [openstack-dev] [TripleO] [Ironic

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

On 06/02/2014 12:17 PM, Doug Hellmann wrote: > On Mon, Jun 2, 2014 at 6: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 at certain things. I spen

[openstack-dev] [Infra] Meeting Tuesday June 3rd at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is hosting our weekly meeting on Tuesday June 3rd, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interested in

Re: [openstack-dev] [Nova]Passing flat_injected flag through instance metadata

On 05/30/2014 05:29 PM, ebaysf, yvempati wrote: > Hello all, > I am new to the openstack community and I am looking for feedback. > > We would like to implement a feature that allows user to pass flat_injected > flag through instance metadata. We would like to enable this feature for > images th

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

On Mon, Jun 2, 2014 at 6: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 at certain things. I spent some time this > weekend working on a tool to ma

Re: [openstack-dev] [Cinder] Support LVM on a shared LU

Hi Deepak-san, Thank you for your comment. Please see following comments. >>1) There is a lof of manual work needed here.. like every time the new host >>added.. admin needs to do FC zoning to ensure that LU is visible by the host. Right. Compared to LVMiSCSI driver, proposed driver are needed

[openstack-dev] [barbican] Meeting Monday June 2nd at 20:00 UTC

Hi Everyone, The Barbican team is hosting our weekly meeting today, Monday June 2nd, at 20:00 UTC in #openstack-meeting-alt Meeting agenda is available here https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed to add agenda items. You can check this link http://time.is/0800

Re: [openstack-dev] [Horizon] Use of AngularJS

I think that you would use the PyPI version anyway: https://pypi.python.org/pypi/django-angular/0.7.2 That's how most of the other Python dependencies work, even in the distribution packages. -- Kili - Cloud for Africa: kili.io Musings: twitter.com/varud More Musings:

Re: [openstack-dev] [Horizon] Use of AngularJS

Hi, It seems there is an issue with the django-angular integration. The problem is it is not available in the Ubuntu/Fedora packages, and its developers are not planning to include it. What can I do in this case? Is there any workaround? Thanks! Veronica -- Message

Re: [openstack-dev] [Marconi] Kafka support and high throughput

Thanks for the responses Flavio, Roland. Some background on why I'm asking: we're using Kafka as the message queue for a stream processing service we're building, which we're delivering to our internal customers as a service along with OpenStack. We're considering building a high throughput i

[openstack-dev] [Marconi] Adopt Spec

Hello all, We are seeing more & more design questions in #openstack-marconi. It will be a good idea to formalize our design process a bit more & start using spec. We are kind of late to the party –so we already have a lot of precedent ahead of us. Thoughts? Malini

Re: [openstack-dev] [Barbican] KMIP support

Hello Robert, Nathan Reller has created a blueprint for this effort here: https://blueprints.launchpad.net/barbican/+spec/kmip-secret-store The first of several CRs to implement this feature is underway here: https://review.openstack.org/#/c/94710/ I'll defer to others regarding the open KMIP

Re: [openstack-dev] [UX] [Ironic] [Ceilometer] [Horizon] [TripleO] Nodes Management UI - designs

Very nicely done, seeing this stuff laid out is really useful. A few comments: = Page 3 = * Nit: The rocker switch for power is a bit odd to me since it looks like it can be toggled. * Can you show an example of a non-healthy node? Is it just an X instead of a check or are there different

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

On 06/02/2014 09:21 AM, Matthew Treinish wrote: > On Mon, Jun 02, 2014 at 06:57:04AM -0400, 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 at certain th

Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories

On Sat, May 31, 2014 at 09:13:35PM +, Jeremy Stanley wrote: > I'll admit that my Web development expertise is probably almost 20 > years stale at this point, so forgive me if this is a silly > question: what is the reasoning against working with the upstreams > who do not yet distribute needed

[openstack-dev] [Ironic] Proposal for shared review dashboard

Hi folks, Inspired by great work by Sean Dague [1], I have created a review dashboard for Ironic projects. Main ideas: Ordering: 0. Viewer's own patches, that have any kind of negative feedback 1. Specs 2. Changes w/o negative feedback, with +2 already 3. Changes that did not have any feedback fo

Re: [openstack-dev] New setuptools release seems to break some of the OS projects

Folks, setuptools 4.0.1 and 3.7.1 have been released - these should fix the issue. -- Dina On Mon, Jun 2, 2014 at 4:45 PM, Dina Belova wrote: > The newest setuptools has been removed from the gate mirror - the latest > there now is 3.6 - that *might* in the gate. > We'll see if it'll help. It

Re: [openstack-dev] [Trove] Pluggable conductor manager

On 4/28/2014 2:58 PM, Dan Smith wrote: I'd like to propose the ability to support a pluggable trove conductor manager. Currently the trove conductor manager is hard-coded [1][2] and thus is always 'trove.conductor.manager.Manager'. I'd like to see this conductor manager class be pluggable like no

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

On Mon, Jun 02, 2014 at 06:57:04AM -0400, 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 at certain things. I spent some time this > weekend working on a t

Re: [openstack-dev] [Fuel-dev] [Openstack-dev] New RA for Galera

Hi crew, Thank you for starting this topic. I've already performed the research and started blueprint. Since we changed our blueprint strategy, I made it in rst format and added it to Gerrit workflow. Feel free to participate. https://review.openstack.org/#/c/97191/ http://docs-draft.openstack.or

Re: [openstack-dev] New setuptools release seems to break some of the OS projects

The newest setuptools has been removed from the gate mirror - the latest there now is 3.6 - that *might* in the gate. We'll see if it'll help. It looks like there is first successful Neutron job there :) -- Dina On Mon, Jun 2, 2014 at 4:36 PM, Eoghan Glynn wrote: > > > > > Alex reported the bu

Re: [openstack-dev] New setuptools release seems to break some of the OS projects

> Alex reported the bug against setuptools > (https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation) > if you want to track progress. Thanks Doug, In the meantime, I'm wondering do we have any way of insulating ourselves against breakages like this? (along the

Re: [openstack-dev] New setuptools release seems to break some of the OS projects

Doug, thanks, will track this bug's solution there. On Mon, Jun 2, 2014 at 4:17 PM, Doug Hellmann wrote: > Alex reported the bug against setuptools > ( > https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation > ) > if you want to track progress. > > Doug > > On Mo

[openstack-dev] nova-compute rpc version

Hi I'm getting following error in nova-compute logs when trying to boot VM from controller node onto compute node ... Specified RPC version, 3.23, not supported Please help regarding this. Thanks Abhishek Jain ___ OpenStack-dev mailing list OpenSta

Re: [openstack-dev] New setuptools release seems to break some of the OS projects

Alex reported the bug against setuptools (https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation) if you want to track progress. Doug On Mon, Jun 2, 2014 at 8:07 AM, Dina Belova wrote: > Folks, o/ > > I did not find the appropriate discussion in the ML, so decided

Re: [openstack-dev] [Fuel-dev] [Openstack-dev] New RA for Galera

Vladimir, Wiadomość napisana przez Vladimir Kuklin w dniu 2 cze 2014, o godz. 13:49: > Bartosz, if you look into what Percona guys are doing - you will see here: > https://github.com/percona/percona-pacemaker-agents/blob/new_pxc_ra/agents/pxc_resource_agent#L516 > that they first try to use

[openstack-dev] New setuptools release seems to break some of the OS projects

Folks, o/ I did not find the appropriate discussion in the ML, so decided to start it myself - I see that new setuptools release seems to break at least some of the OpenStack gates and even more. Here is the bug: https://bugs.launchpad.net/ceilometer/+bug/1325514 It hits Tempest, Ceilometer and

Re: [openstack-dev] [Fuel-dev] [Openstack-dev] New RA for Galera

Bartosz, if you look into what Percona guys are doing - you will see here: https://github.com/percona/percona-pacemaker-agents/blob/new_pxc_ra/agents/pxc_resource_agent#L516 that they first try to use MySQL and then to get GTID from grastate.dat. Also, I am wondering if you are using cluster-wide a

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

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 at certain things. I spent some time this weekend working on a tool to make building custom dashboard urls much easier. My current

Re: [openstack-dev] [solum] [mistral] [heat] keystone chained trusts / oauth

Hi Angus, On Wed, May 28, 2014 at 12:56:52AM +, Angus Salkeld wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all > > During our Solum meeting it was felt we should make sure that all three > team are on the same page wrt $subject. > > I'll describe the use case we are tryin

Re: [openstack-dev] [Fuel-dev] [Openstack-dev] New RA for Galera

On 05/29/2014 02:06 PM, Bartosz Kupidura wrote: > Hello, > > > Wiadomość napisana przez Vladimir Kuklin w dniu 29 maj > 2014, o godz. 12:09: > >> may be the problem is that you are using liftetime crm attributes instead of >> 'reboot' ones. shadow/commit is used by us because we need transact

Re: [openstack-dev] [Horizon] Use of AngularJS

Hello, Seems to be a good idea, I will take a look at this package which seems to have a lot of features. The project seems pretty active, and I think it can be a good idea to dig into this kind of packages. - Original Message - From: "Veronica A Musso" To: openstack-dev@lists.opensta

Re: [openstack-dev] keystone

> After restarting keystone with the following command, > $service openstack-keystone restart > it is giving a message "Aborting wait for keystone to start". Could you > please help on what the problem could be? This is not an appropriate topic for the development mailing list, please open a quest

Re: [openstack-dev] [Murano] Murano API improvements

I think API need to be redesigned at some point. There is a blueprint for this: https://blueprints.launchpad.net/murano/+spec/api-vnext It seems reasonable to implement new API on new framework at once Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Mon, Jun 2, 2014 at 1

Re: [openstack-dev] [Fuel-dev] access-control-master-node

After some discussion on IRC we updated blueprint. Now it's available as review here https://review.openstack.org/#/c/96429/2 Nice looking version is here http://docs-draft.openstack.org/29/96429/3/check/gate-fuel-specs-docs/d5b32d5/doc/build/html/specs/5.1/access-control-master-node.html Blueprin

Re: [openstack-dev] [Murano] Murano API improvements

Let's follow the standard procedure. Both blueprints lack specification of implementation details. There also has to be someone willing to implement these blueprints in near feature. I'm not opposed to these ideas and I'd really like to see Pecan added during Juno, but we still need to follow the

Re: [openstack-dev] [FUEL][Design session 5.1] 28/05/2014 meeting minutes

Oh, my bad. Sorry, June 5th, of course. Thank you, Lukasz. On Fri, May 30, 2014 at 7:06 PM, Lukasz Oles wrote: > june 5th? > > > On Fri, May 30, 2014 at 4:33 PM, Vladimir Kuklin > wrote: > >> Guys, we gonna have a more extended design FUEL Library design meeting in >> IRC channel during regula

Re: [openstack-dev] [TripleO] Adding Tuskar to weekly IRC meetings agenda

On 2014/30/05 22:37, James Polley wrote: On 30 May 2014, at 8:13 pm, Jaromir Coufal wrote: Hi All, I would like to propose to add Tuskar as a permanent topic to the agenda for our weekly IRC meetings. It is an official TripleO's project, there happening quite a lot around it and we are ta

[openstack-dev] keystone

Hi, After restarting keystone with the following command, *$service openstack-keystone restart* it is giving a message "*Aborting wait for keystone to start*". Could you please help on what the problem could be? Thanks, Tizy ___ OpenStack-dev mailing li