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

2014-05-29 Thread Joshua Hesketh
On 5/29/14 8:52 AM, James E. Blair wrote: Devananda van der Veen devananda@gmail.com writes: Hi all! This is a follow-up to several summit discussions on how-do-we-deprecate-baremetal, a summary of the plan forward, a call to raise awareness of the project's status, and hopefully gain

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

2014-05-29 Thread James Polley
Thanks for putting this together Jaromir! August 1 may be a problem for those of us from Australia - it's the day of the OpenStack miniconf at Pycon-AU. I don't know if any of us intended to go to that, but if we did we'd need to leave no later than the 4:40pm flight on July 30 in order to make

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

2014-05-29 Thread Tihomir Trifonov
Hi Gabriel, thanks for joining the conversation. It is a quite old discussion that was also discussed at the Atlanta design summit, and it seems that the moment this to happen had finally come. It is always nice to hear the opinion of a real Django core developer. Just a follow-up from the

Re: [openstack-dev] [neutron] BPs for Juno-1

2014-05-29 Thread mar...@redhat.com
On 28/05/14 17:57, Kyle Mestery wrote: On Wed, May 28, 2014 at 12:41 AM, mar...@redhat.com mandr...@redhat.com wrote: On 27/05/14 17:14, Kyle Mestery wrote: Hi Neutron developers: I've spent some time cleaning up the BPs for Juno-1, and they are documented at the link below [1]. There are

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

2014-05-29 Thread Robert Collins
Is there any wiggle room on those dates? As James Polley says, PyCon AU (and the Openstack miniconf, which I'm organising with JHesketh) overlap significantly - and I can't be in two places at once. However July 21-25th would be totally doable :) -Rob On 28 May 2014 23:05, Jaromir Coufal

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-05-29 Thread Clark, Robert Graham
Just chiming in with a side-note. I always liked the idea of Postern for things like this though the crypto geek in me always worries about making key retrieval too easy for developers, bad things happen down that road. The OSSG can help with overall secure design and would be happy to consult

Re: [openstack-dev] Recommended way of having a project admin

2014-05-29 Thread Ajaya Agrawal
Hi All, The reason I ask this question in openstack-dev is there is a lot of confusion going around other projects moving to keystone v3. Would it be a problem if I use keystone v3 api for authenticating and point other services to use keystone v2 with keystone v3 token? The main issue here is

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

2014-05-29 Thread Flavio Percoco
On 28/05/14 17:01 +, Kurt Griffiths wrote: Crew, as discussed in the last team meeting, I have updated the API v1.1 spec to remove the ability to get one or more messages by ID. This was done to remove unnecessary complexity from the API, and to make it easier to support different types of

Re: [openstack-dev] [Nova] [Neutron] heal_instance_info_cache_interval - Can we kill it?

2014-05-29 Thread Day, Phil
Could we replace the refresh from the period task with a timestamp in the network cache of when it was last updated so that we refresh it only when it’s accessed if older that X ? From: Aaron Rosen [mailto:aaronoro...@gmail.com] Sent: 29 May 2014 01:47 To: Assaf Muller Cc: OpenStack Development

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

2014-05-29 Thread Bogdan Dobrelya
On 05/27/14 16:44, Bartosz Kupidura wrote: Hello, Responses inline. Wiadomość napisana przez Vladimir Kuklin vkuk...@mirantis.com w dniu 27 maj 2014, o godz. 15:12: Hi, Bartosz First of all, we are using openstack-dev for such discussions. Second, there is also Percona's RA for

[openstack-dev] [Neutron]net-create fail without definite segmentation_id

2014-05-29 Thread Xurong Yang
Hi, stackers if i define provider when creating network, but no segmentation_id, net-create fail. why not allocate segmentation_id automatically? ~$ neutron net-create test --provider:network_type=vlan --provider:physical_ network=default Invalid input for operation: segmentation_id required for

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

2014-05-29 Thread Jaromir Coufal
Hey Mainn, mostly it is driven by following requirements: https://etherpad.openstack.org/p/ironic-ui plus what you already know from Tuskar point of view - which is simply monitoring, monitoring, monitoring :) Hope it helps -- Jarda On 2014/29/05 05:51, Tzu-Mainn Chen wrote: Hi Jarda,

[openstack-dev] Selecting more carefully our dependencies

2014-05-29 Thread Thomas Goirand
Hi everyone, Recently, wrapt was added as a dependency. The Python module suffers from obvious design issues, like for example: - Lack of Python 3.4 support - Broken with Python 3.2 - Upstream sources in src instead of wrapt so then running py.test doesn't work unless you do ln -s src wrapt, and

Re: [openstack-dev] Designate Incubation Request

2014-05-29 Thread Thierry Carrez
Sean Dague wrote: I honestly just think we might want to also use it as a time to rethink our program concept. Because all our programs that include projects that are part of the integrated release are 1 big source tree, and maybe a couple of little trees that orbit it (client and now specs

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

2014-05-29 Thread Jaromir Coufal
Hi James, that's a good point. I just restructured the etherpad so that there are 3 sections: one is for July 28 - Aug 1, second is for July 21-25 and third one is for those who want to attend but can't make it within suggested dates. So I would like to encourage everybody who is willing to

Re: [openstack-dev] [nova] bug status and our 1st Bug Day for Juno

2014-05-29 Thread Kashyap Chamarthy
On Thu, May 29, 2014 at 04:29:34AM +, Tracy Jones wrote: Hi Folks - I spoke with Michael at the summit about bug management for Juno. Other than tagging the untagged bugs each week, I'm try to do that (and some triage/root-cause analysis for libvirt/QEMU/KVM-based bugs and would like to

[openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

2014-05-29 Thread Xurong Yang
Hi, Folks, When we configure VXLAN range [1,16M], neutron-server service costs long time and cpu rate is very high(100%) when initiation. One test base on postgresql has been verified: more than 1h when VXLAN range is [1, 1M]. So, any good solution about this performance issue? Thanks, Xurong

Re: [openstack-dev] Designate Incubation Request

2014-05-29 Thread Sean Dague
On 05/29/2014 05:26 AM, Thierry Carrez wrote: Sean Dague wrote: I honestly just think we might want to also use it as a time to rethink our program concept. Because all our programs that include projects that are part of the integrated release are 1 big source tree, and maybe a couple of

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

2014-05-29 Thread Radomir Dopieralski
On 05/28/2014 10:03 PM, Gabriel Hurley wrote: It's sort of a silly point, but as someone who would likely consume the split-off package outside of the OpenStack context, please give it a proper name instead of django_horizon. The module only works in Django, the name adds both clutter and

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

2014-05-29 Thread Vladimir Kuklin
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 transactional behaviour in some cases. if you turn crm_shadow off, then you will experience problems with multi-state resources and location/colocation/order

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

2014-05-29 Thread ZZelle
Hi, vxlan network are inserted/verified in DB one by one, which could explain the time required https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/type_vxlan.py#L138-L172 Cédric On Thu, May 29, 2014 at 12:01 PM, Xurong Yang ido...@gmail.com wrote: Hi, Folks,

[openstack-dev] [nova] Nova API meeting

2014-05-29 Thread Christopher Yeoh
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] [UX] [Ironic] [Ceilometer] [Horizon] [TripleO] Nodes Management UI - designs

2014-05-29 Thread Lucas Alvares Gomes
On Wed, May 28, 2014 at 10:18 PM, Jaromir Coufal jcou...@redhat.com wrote: Hi All, There is a lot of tags in the subject of this e-mail but believe me that all listed projects (and even more) are relevant for the designs which I am sending out. Nodes management section in Horizon is being

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

2014-05-29 Thread Bartosz Kupidura
Hello, Wiadomość napisana przez Vladimir Kuklin vkuk...@mirantis.com 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 transactional behaviour in some cases. if you

Re: [openstack-dev] [nova] Question about addit log in nova-compute.log

2014-05-29 Thread Murray, Paul (HP Cloud)
Comment inline at bottom of message... -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 06 May 2014 18:44 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Question about addit log in nova-compute.log On 05/06/2014 01:37 PM, Jiang, Yunhong

Re: [openstack-dev] [Neutron]net-create fail without definite segmentation_id

2014-05-29 Thread Henry Gessau
On 5/29/2014 4:41 AM, Xurong Yang wrote: Hi, stackers if i define provider when creating network, but no segmentation_id, net-create fail. why not allocate segmentation_id automatically? ~$ neutron net-create test --provider:network_type=vlan --provider:physical_network=default Invalid

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Alexander Ignatov
On 28 May 2014, at 20:02, Sergey Lukjanov slukja...@mirantis.com wrote: Hey folks, it's a small wrap-up for the topic Sahara subprojects releasing and versioning that was discussed partially on summit and requires some more discussions. You can find details in [0]. common We'll

Re: [openstack-dev] Mahout-as-a-service [sahara]

2014-05-29 Thread Matthew Farrellee
On 05/28/2014 12:37 PM, Dat Tran wrote: Hi everyone, I have a idea for new project: Mahout-as-a-service. Main idea of this project: - Install OpenStack - Deploying OpenStack Sahara source - Deploying Mahout on Sahara OpenStack system. - Construction of the API. Through web or mobile interface,

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Matthew Farrellee
On 05/29/2014 07:23 AM, Alexander Ignatov wrote: On 28 May 2014, at 20:02, Sergey Lukjanov slukja...@mirantis.com wrote: sahara-image-elements We're agreed that some common parts should be merged into the diskimage-builder repo (like java support, ssh, etc.). The main issue of keeping

Re: [openstack-dev] [sahara] summit wrap-up: backward compat

2014-05-29 Thread Alexander Ignatov
On 28 May 2014, at 17:14, Sergey Lukjanov slukja...@mirantis.com wrote: 1. How should we handle addition of new functionality to the API, should we bump minor version and just add new endpoints? Agree with most of folks. No new versions on adding new endpoints. Semantic changes require new

Re: [openstack-dev] Policy for linking bug or bp in commit message

2014-05-29 Thread Ihar Hrachyshka
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 28/05/14 23:03, Nachi Ueno wrote: Hi folks OK, so it looks like this is consensus in the community, Link bug or bp for most of commit Exception for not linking bug: (1) Infra sync (2) minor fix. (typo, small code refactor, fix doc

Re: [openstack-dev] [Neutron][Flavors] Flavor framework implementation questions

2014-05-29 Thread mar...@redhat.com
On 29/05/14 00:48, Eugene Nikanorov wrote: Hi, I have two questions that previously were briefly discussed. Both of them still cause discussions within advanced services community, so I'd like to make final clarification in this email thread. 1. Usage of Service Type Framework I think

Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

2014-05-29 Thread Samuel Bercovici
+1 to Carlos. In addition, there should be possible for LBaaS (It might only be just the LBaaS drivers) to get the information including the private key back so that the backend can use it. This means that a trusted communication channel between the driver and Barbican needs to be established

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

2014-05-29 Thread Day, Phil
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/05/2014, at 11:21 AM, Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com

Re: [openstack-dev] Designate Incubation Request

2014-05-29 Thread Mac Innes, Kiall
On Thu, 2014-05-29 at 11:26 +0200, Thierry Carrez wrote: Back to the topic, the tension here is because DNS is seen as a network thing and therefore it sounds like it makes sense under Networking. But programs are not categories or themes. They are teams aligned on a mission statement. If the

Re: [openstack-dev] Designate Incubation Request

2014-05-29 Thread Mac Innes, Kiall
On Thu, 2014-05-29 at 08:00 +0930, Michael Davies wrote: On Thu, May 29, 2014 at 4:22 AM, Sean Dague s...@dague.net wrote: I would agree this doesn't make sense in Neutron. I do wonder if it makes sense in the Network program. I'm getting suspicious of the programs for projects model if

Re: [openstack-dev] [sahara] summit wrap-up: backward compat

2014-05-29 Thread Sergey Lukjanov
Bunch of responses/thoughts: API I'm ok that semantics additions could be done in one API version w/o increasing minor version. I like the idea to keep only major API versions starting from the next API version. RE backward compat period, for now 1-2 cycles is ok. Images Agreed that we

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Sergey Lukjanov
Re sahara-image-elements we found a bunch of issues that we should solve and that's why I think that keeping current releasing is still the best option. - we should test it better and depend on stable diskimage-builder version The dib is now published to pypi, so, we could make

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Matthew Farrellee
On 05/29/2014 09:59 AM, Trevor McKay wrote: below, sahara-extra sahara-extra Keep it as is, no need to stop releasing, because we're not publishing anything to pypi. No real need for tags. Even if we keep the repo for now, I think we could simplify a little bit. The edp-examples could be

Re: [openstack-dev] [Neutron]net-create fail without definite segmentation_id

2014-05-29 Thread ZZelle
Hi, The blueprint let admins provide some provider attributes and let neutron the remaining attributes. The blueprint specification and associated implementation are under reviews[1]. [1] https://review.openstack.org/#/q/topic:bp/provider-network-partial-specs,n,z On Thu, May 29, 2014 at 1:23

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Sergey Lukjanov
client We have separated launchpad project for client and we're publishing client releases to it. extra I'm neutral about moving job examples and API samples between sahara and extra ui tests if we'll be able to remove sahara-dashboard before good integration tests for our pages will be

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Trevor McKay
below, sahara-extra On Wed, 2014-05-28 at 20:02 +0400, Sergey Lukjanov wrote: Hey folks, it's a small wrap-up for the topic Sahara subprojects releasing and versioning that was discussed partially on summit and requires some more discussions. You can find details in [0]. common We'll

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Michael McCune
- Original Message - sahara-extra Keep it as is, no need to stop releasing, because we're not publishing anything to pypi. No real need for tags. Even if we keep the repo for now, I think we could simplify a little bit. The edp-examples could be moved to the Sahara repo.

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Michael McCune
- Original Message - Re sahara-image-elements we found a bunch of issues that we should solve and that's why I think that keeping current releasing is still the best option. - we should test it better and depend on stable diskimage-builder version The dib is now published to pypi,

Re: [openstack-dev] [sahara] summit wrap-up: backward compat

2014-05-29 Thread Sergey Lukjanov
So, it looks like we have an agreement on all question. There is only one technical question - keeping release images means that we need to keep the whole matrix of images: plugin X version X OSy [X root-passwdord]. I'll take a look on total size of them and ability to publish them on OS infra.

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Matthew Farrellee
On 05/29/2014 10:15 AM, Michael McCune wrote: - Original Message - Re sahara-image-elements we found a bunch of issues that we should solve and that's why I think that keeping current releasing is still the best option. - we should test it better and depend on stable

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Michael McCune
- Original Message - the image-elements is too unstable to be used by anyone but an expert at this point. imho we should make sure the experts produce working images first, it's what our users will need in the first place, then make the image generation more stable. +1 mike

Re: [openstack-dev] [sahara] summit wrap-up: backward compat

2014-05-29 Thread Matthew Farrellee
On 05/29/2014 10:22 AM, Sergey Lukjanov wrote: So, it looks like we have an agreement on all question. There is only one technical question - keeping release images means that we need to keep the whole matrix of images: plugin X version X OSy [X root-passwdord]. I'll take a look on total size

Re: [openstack-dev] [neutron] BPs for Juno-1

2014-05-29 Thread Tomoe Sugihara
Hello Neutron core team, We have three specs[1][2][3] submitted last week, for which have gotten +1s from non core contributors. It would be great if core devs could review them and give us some feedback. (I noticed that I didn't include links to gerrit reviews in launchpad BPs and just fixed

Re: [openstack-dev] [sahara] summit wrap-up: backward compat

2014-05-29 Thread Alexander Ignatov
On 29 May 2014, at 18:43, Matthew Farrellee m...@redhat.com wrote: i do not think we should release any images that have a root password set (essentially a backdoor). for K we should deprecate the hadoop1 versions and thus significantly cut the size of the new image artifact. Agree

Re: [openstack-dev] [Neutron][Flavors] Flavor framework implementation questions

2014-05-29 Thread Gary Duan
Hi, Marios, STF stands for 'service type framework'. It's the current way to dispatch calls to different drivers based on 'provider' attribute of the LBaaS service instance. Firewall and VPN implementations were not upstreamed as we want to move to Flavor Framework. I think the flavor framework

Re: [openstack-dev] [sahara] summit wrap-up: subprojects

2014-05-29 Thread Chad Roberts
I agree with this. No real sense in leaving image generation up to novice users at this point. +1 - Original Message - From: Michael McCune mimcc...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, May 29,

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

2014-05-29 Thread Paul Ward
Well, for my specific error, it was an intermittent ssl handshake error before the request was ever sent to the neutron-server. In our case, we saw that 4 out of 5 resize operations worked, the fifth failed with this ssl handshake error in neutronclient. I certainly think a GET is safe to

Re: [openstack-dev] [all] Hide CI comments in Gerrit

2014-05-29 Thread Yuriy Taraday
On Tue, May 27, 2014 at 6:07 PM, James E. Blair jebl...@openstack.orgwrote: I wonder if it would be possible to detect them based on the presence of a Verified vote? Not all CIs always add a vote. Only 3 or so of over 9000 Neutron's CIs put their +/-1s on the change. -- Kind regards,

[openstack-dev] [Horizon] Use of AngularJS

2014-05-29 Thread Musso, Veronica A
Hello, During the last Summit the use of AngularJS in Horizon was discussed and there is the intention to do a better use of it in the dashboards. I think this blueprint could help https://blueprints.launchpad.net/horizon/+spec/django-angular-integration, since it proposes the integration of

Re: [openstack-dev] Policy for linking bug or bp in commit message

2014-05-29 Thread Yuriy Taraday
On Wed, May 28, 2014 at 3:54 AM, Joe Gordon joe.gord...@gmail.com wrote: On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno na...@ntti3.com wrote: (2) Avoid duplication of works I have several experience of this. Anyway, we should encourage people to check listed bug before writing patches.

Re: [openstack-dev] [Horizon][Tuskar-UI] Location for common dashboard code?

2014-05-29 Thread Lyle, David
I think this falls inline with other items we are working toward in Horizon, namely more pluggable components on panels. I think creating a directory in openstack_dashboard for these reusable components makes a lot of sense. And usage should eventually moved to there. I would suggest something as

Re: [openstack-dev] [Horizon][Tuskar-UI] Location for common dashboard code?

2014-05-29 Thread Lyle, David
We are in the process of removing the redundancy between Project and Admin by using RBAC to allow sharing of one code base for multiple roles. This is a WIP. David On 5/28/14, 1:53 PM, Tzu-Mainn Chen tzuma...@redhat.com wrote: Hi Doug, Thanks for the response! I agree with you in the cases

Re: [openstack-dev] Specifying file encoding

2014-05-29 Thread Martin Geisler
Ryan Brady rbr...@redhat.com writes: Would you want to merge the patches that simply remove the unneeded lines and then let me followup with patches that remove © along with the then unnecessary coding lines? If I was in your position, I'd update the patches that remove lines to include all

[openstack-dev] [QA][Infra] Mid-Cycle Meet-up

2014-05-29 Thread Matthew Treinish
Hi Everyone, So we'd like to announce to everyone that we're going to be doing a combined Infra and QA program mid-cycle meet-up. It will be the week of July 14th in Darmstadt, Germany at Deutsche Telekom who has graciously offered to sponsor the event. The plan is to use the week as both a time

Re: [openstack-dev] Policy for linking bug or bp in commit message

2014-05-29 Thread Nachi Ueno
I like the idea 2014-05-29 8:33 GMT-07:00 Yuriy Taraday yorik@gmail.com: On Wed, May 28, 2014 at 3:54 AM, Joe Gordon joe.gord...@gmail.com wrote: On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno na...@ntti3.com wrote: (2) Avoid duplication of works I have several experience of this. Anyway,

Re: [openstack-dev] [neutron] BPs for Juno-1

2014-05-29 Thread Edgar Magana Perdomo (eperdomo)
I will take them! Edgar From: Tomoe Sugihara to...@midokura.commailto:to...@midokura.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 29, 2014 at 7:57 AM To: OpenStack

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

2014-05-29 Thread YAMAMOTO Takashi
as per discussions on l3 subteem meeting today, i started a bgp speakers comparison wiki page for this bp. https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison Artem, can you add other requirements as columns? as one of ryu developers, i'm naturally biased to ryu bgp. i appreciate if

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

2014-05-29 Thread Armando M.
Hi Paul, Just out of curiosity, I am assuming you are using the client that still relies on httplib2. Patch [1] replaced httplib2 with requests, but I believe that a new client that incorporates this change has not yet been published. I wonder if the failures you are referring to manifest

Re: [openstack-dev] Designate Incubation Request

2014-05-29 Thread Zane Bitter
On 29/05/14 05:26, Thierry Carrez wrote: Sean Dague wrote: I honestly just think we might want to also use it as a time to rethink our program concept. Because all our programs that include projects that are part of the integrated release are 1 big source tree, and maybe a couple of little

Re: [openstack-dev] [infra] Nominating Nikita Konovalov for storyboard-core

2014-05-29 Thread James E. Blair
jebl...@openstack.org (James E. Blair) writes: Nikita Konovalov has been reviewing changes to both storyboard and storyboard-webclient for some time. He is the second most active storyboard reviewer and is very familiar with the codebase (having written a significant amount of the server

Re: [openstack-dev] [keystone] Redesign of Keystone Federation

2014-05-29 Thread Morgan Fainberg
I agree that there is room for improvement on the Federation design within Keystone. I would like to re-iterate what Adam said that we are already seeing efforts to fully integrate further protocol support (OpenID Connect, etc) within the current system. Lets be sure that whatever redesign work

Re: [openstack-dev] [infra] Nominating Joshua Hesketh for infra-core

2014-05-29 Thread James E. Blair
jebl...@openstack.org (James E. Blair) writes: The Infrastructure program has a unique three-tier team structure: contributors (that's all of us!), core members (people with +2 ability on infra projects in Gerrit) and root members (people with administrative access). Read all about it here:

Re: [openstack-dev] [infra] Nominating Sergey Lukjanov for infra-root

2014-05-29 Thread James E. Blair
jebl...@openstack.org (James E. Blair) writes: The Infrastructure program has a unique three-tier team structure: contributors (that's all of us!), core members (people with +2 ability on infra projects in Gerrit) and root members (people with administrative access). Read all about it here:

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

2014-05-29 Thread Paul Ward
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 it seems like an ssl thing itself. But... who knows?? I'm not sure how consistently we can recreate this, but if we can, I'll try using that patch to use requests and

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

2014-05-29 Thread Devananda van der Veen
On Wed, May 28, 2014 at 11:42 PM, Robert Collins robe...@robertcollins.netwrote: Is there any wiggle room on those dates? As James Polley says, PyCon AU (and the Openstack miniconf, which I'm organising with JHesketh) overlap significantly - and I can't be in two places at once. However July

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

2014-05-29 Thread Devananda van der Veen
Hi Jaromir, I agree that the midcycle meetup with TripleO and Ironic was very beneficial last cycle, but this cycle, Ironic is co-locating its sprint with Nova. Our focus needs to be working with them to merge the nova.virt.ironic driver. Details will be forthcoming as we work out the exact

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

2014-05-29 Thread Mike Spreitzer
Devananda van der Veen devananda@gmail.com wrote on 05/29/2014 01:26:12 PM: Hi Jaromir, I agree that the midcycle meetup with TripleO and Ironic was very beneficial last cycle, but this cycle, Ironic is co-locating its sprint with Nova. Our focus needs to be working with them to

Re: [openstack-dev] [keystone] Redesign of Keystone Federation

2014-05-29 Thread Brad Topol
+1! Excellent summary and analysis Morgan! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg morgan.fainb...@gmail.com To: OpenStack Development Mailing List

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

2014-05-29 Thread Devananda van der Veen
On Wed, May 28, 2014 at 10:54 PM, Joshua Hesketh joshua.hesk...@rackspace.com wrote: On 5/29/14 8:52 AM, James E. Blair wrote: Devananda van der Veen devananda@gmail.com writes: Hi all! This is a follow-up to several summit discussions on how-do-we-deprecate-baremetal, a summary of

Re: [openstack-dev] Selecting more carefully our dependencies

2014-05-29 Thread Joshua Harlow
Hi thomas, Since I'm the one that added wrapt to the requirements list I thought it would be appropriate for me to respond :) So looking over the pull request it seems like there was agreement that the issues will be fixed and the adjustments will occur (that seems to be the case last time I

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

2014-05-29 Thread Matt Riedemann
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 adding a new way to do it. Vish On May 27, 2014, at 1:31 PM, Cazzolato,

Re: [openstack-dev] [infra] Nominating Joshua Hesketh for infra-core

2014-05-29 Thread Sergey Lukjanov
And /me is no longer the new guy :) On Thu, May 29, 2014 at 9:05 PM, James E. Blair jebl...@openstack.org wrote: jebl...@openstack.org (James E. Blair) writes: The Infrastructure program has a unique three-tier team structure: contributors (that's all of us!), core members (people with +2

Re: [openstack-dev] [keystone] Redesign of Keystone Federation

2014-05-29 Thread Tim Bell
A further vote to maintain compatibility . One of the key parts to a good federation design is to be using it in the field and encountering real life problems. Production sites expect stability of interfaces and functions. If this cannot be reasonably ensured, the federation function

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

2014-05-29 Thread Armando M.
mishandling of SSL was the very reason why I brought that change forward; so I wouldn't rule it out completely ;) A. On 29 May 2014 19:15, Paul Ward wpw...@us.ibm.com 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

Re: [openstack-dev] [keystone] Redesign of Keystone Federation

2014-05-29 Thread Dolph Mathews
On Thu, May 29, 2014 at 12:59 PM, Tim Bell tim.b...@cern.ch wrote: A further vote to maintain compatibility . One of the key parts to a good federation design is to be using it in the field and encountering real life problems. Production sites expect stability of interfaces and

[openstack-dev] [Murano] A new version of python-muranoclient (0.5.2) is to be released

2014-05-29 Thread Timur Sufiev
Hi there! Recently we've changed the way application packages are paginated in murano-dashboard (AppCatalog and Package Definitions panels) - adopting the Glance approach with generators and 'next_marker' property. This change concerns all 3 murano components - murano-api [1], python-muranoclient

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

2014-05-29 Thread Zane Bitter
On 29/05/14 13:33, Mike Spreitzer wrote: Devananda van der Veen devananda@gmail.com wrote on 05/29/2014 01:26:12 PM: Hi Jaromir, I agree that the midcycle meetup with TripleO and Ironic was very beneficial last cycle, but this cycle, Ironic is co-locating its sprint with Nova. Our

Re: [openstack-dev] [nova][neutron][mysql] IMPORTANT: MySQL Galera does *not* support SELECT ... FOR UPDATE

2014-05-29 Thread Robert Collins
I just bent Jay's ear on IRC about this for a bit... On 21 May 2014 05:07, Jay Pipes jaypi...@gmail.com wrote: We are one of those operators that use Galera for replicating our mysql databases. We used to see issues with deadlocks when having multiple mysql writers in our mysql cluster. As a

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

2014-05-29 Thread Anita Kuno
On 05/28/2014 08:54 AM, Radomir Dopieralski wrote: Hello, we plan to finally do the split in this cycle, and I started some preparations for that. I also started to prepare a detailed plan for the whole operation, as it seems to be a rather big endeavor. You can view and amend the plan at

[openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships for Pools and Listeners

2014-05-29 Thread Samuel Bercovici
Before solving everything, I would like first to itemize the things we should solve/consider. So pleas focus first on what is it that we need to pay attention for and less on how to solve such issues. Follows the list of items: · Provisioning status/state o Should it only be on the

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

2014-05-29 Thread Gabriel Hurley
Forgive me if I'm misunderstanding, but those all look like repositories that are strictly tracking upstreams. They're not maintained by the Horizon/OpenStack developers whatsoever. Is this intentional/necessary? - Gabriel -Original Message- From: Anita Kuno

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

2014-05-29 Thread Anita Kuno
On 05/29/2014 03:45 PM, Gabriel Hurley wrote: Forgive me if I'm misunderstanding, but those all look like repositories that are strictly tracking upstreams. They're not maintained by the Horizon/OpenStack developers whatsoever. Is this intentional/necessary? - Gabriel The permissions

[openstack-dev] [Barbican][Heat] Reviews requested for Barbican resources

2014-05-29 Thread Randall Burt
Hello Barbican devs. I was wondering if we could get some of you to weigh in on a couple of reviews for adding Barbican support in Heat. We seem to be churning a bit around current and future features supported by the resources and could use some expert opinions. Blueprint:

Re: [openstack-dev] [Barbican][Heat] Reviews requested for Barbican resources

2014-05-29 Thread John Wood
Hello Randall, We'll take a look at these CRs for sure, thanks. Thanks, John From: Randall Burt [randall.b...@rackspace.com] Sent: Thursday, May 29, 2014 3:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev]

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

2014-05-29 Thread Kevin Benton
Httplib2 does very little directly with ssl other than a wrap_socket call. Unless requests has special ssl error handling and retry logic, it will be exposed to the same set of underlying errors from the ssl library so a retry that at least catches socket and ssl errors is a good idea. On May 29,

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

2014-05-29 Thread Lyle, David
The idea here is to decouple 3rd party static files from being embedded in the Horizon repo. There are several reasons for this move. With embedded 3rd party static files upgrading the static files is cumbersome, versions can be difficult to track and updates can be difficult to synchronize. This

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

2014-05-29 Thread Anita Kuno
On 05/29/2014 04:55 PM, Lyle, David wrote: The idea here is to decouple 3rd party static files from being embedded in the Horizon repo. There are several reasons for this move. With embedded 3rd party static files upgrading the static files is cumbersome, versions can be difficult to track and

Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as input any consideration ?

2014-05-29 Thread Carl Baldwin
Keshava, How much of a problem is routing prefix fragmentation for you? Fragmentation causes routing table bloat and may reduce the performance of the routing table. It also increases the amount of information traded by the routing protocol. Which aspect(s) is (are) affecting you? Can you

[openstack-dev] [Glance] [Heat] Glance Metadata Catalog for Capabilities and Tags

2014-05-29 Thread Tripp, Travis S
Hello everyone! At the summit in Atlanta we demonstrated the Graffiti project concepts. We received very positive feedback from members of multiple dev projects as well as numerous operators. We were specifically asked multiple times about getting the Graffiti metadata catalog concepts into

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

2014-05-29 Thread Clint Byrum
Hello! I am writing to get some brainstorming started on how we might mitigate some of the issues we've seen while deploying large stacks on Heat. I am sending this to the dev list because it may involve landing fixes rather than just using different strategies. The problems outlined here are

[openstack-dev] [Neutron] How about deprecate cfg.CONF.allow_overlapping_ips?

2014-05-29 Thread Nachi Ueno
Hi folks Today, we are can change allow overlapping ips or not by configuration. This has impact of database design, and actually, this flag complicate the implementations. Whey we have this flag is a historical reason. This was needed when many OS don't support namespaces, however Most of OS

Re: [openstack-dev] [tripleO] Should #tuskar business be conducted in the #tripleo channel?

2014-05-29 Thread James Slagle
On Thu, May 29, 2014 at 12:25 PM, Anita Kuno ante...@anteaya.info wrote: As I was reviewing this patch today: https://review.openstack.org/#/c/96160/ It occurred to me that the tuskar project is part of the tripleo program:

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

2014-05-29 Thread Mike Spreitzer
Clint Byrum cl...@fewbar.com wrote on 05/29/2014 07:52:07 PM: I am writing to get some brainstorming started on how we might mitigate some of the issues we've seen while deploying large stacks on Heat. I am sending this to the dev list because it may involve landing fixes rather than just

[openstack-dev] [TripleO][CI] reduced capacity, rebuilding hp1 region

2014-05-29 Thread Robert Collins
Hi, the HP1 tripleo test cloud region has been systematically failing and rather than flogging it along we're going to strip it down and bring it back up with some of the improvements that have happened over the last $months, as well as changing the undercloud to deploy via Ironic and other

  1   2   >