Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

Adding one more renaming last day - murano-api repo to murano (https://review.openstack.org/95085). On Fri, May 23, 2014 at 9:41 AM, Sergey Lukjanov wrote: > For specs repo renaming old github links will still work due to the > github feature that makes a redirect while renaming project in one >

Re: [openstack-dev] Glance

Do you have a loadbalancer or something that limits the request time in the path? That would be my guess, you probably need to raise the request_termination_timeout. Best, Aaron On Thu, May 22, 2014 at 10:59 PM, Tizy Ninan wrote: > Hi, > > We have an openstack deployment (Havana on CentOS) i

[openstack-dev] Glance

Hi, We have an openstack deployment (Havana on CentOS) in HA mode with nova-network service deployed using Mirantis Fuel v4.0 . When uploading images with large filesize (more than 1 GB) from dashboard, after upload is done the dashboard is showing "504 Gateway Timeout". What could be the problem?

Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

For specs repo renaming old github links will still work due to the github feature that makes a redirect while renaming project in one organization. On Fri, May 23, 2014 at 4:16 AM, Jeremy Stanley wrote: > On 2014-05-21 23:52:14 -0700 (-0700), Clint Byrum wrote: >> You didn't also ask them to sub

Re: [openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

Thanks Carl, for pitching in for us. As Carl said, this is the last detail that is being worked out. Wuhogning, I am requesting Rajeev and Mike(CC'ed) who are working in DVR SNAT to post the document into to the blueprint link here, so that you can take a look. https://blueprints.launchpad.net

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

Hi Armando: Those are good points. I will let Bob Kukura chime in on the specifics of how we intend to do that integration. But if what you see in the prototype/PoC was our final design for integration with Neutron core, I would be worried about that too. That specific part of the code (events/not

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

+1 I agree. Lets focus on client SSL Termination at LB for Juno release. Thanks, Vivek From: , German mailto:german.eichber...@hp.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Thursday, May 22, 2014 at 12:53 PM To

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

Thanks to everyone who participated in the Group Policy meeting [1] earlier today. A lot of good discussion that hopefully will continue with participation from the larger community. I wanted to first make a comment about how the Group Policy work was received outside the Neutron community and the

Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

Hi Just wanted to comment on some points below inline. /Alan -Original Message- From: A, Keshava [mailto:keshav...@hp.com] Sent: May-22-14 2:25 AM To: Kyle Mestery; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at desig

Re: [openstack-dev] [NFV][Neutron] Link to patch/review for allowing instances to receive vlan tagged traffic

Yes that’s the one Yi, thanks ;-) /Alan From: Yi Sun [mailto:beyo...@gmail.com] Sent: May-22-14 2:56 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Alan Kavanagh; Balázs Gibizer Subject: Re: [openstack-dev] [NFV][Neutron] Link to patch/review for allowing instances to rec

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

On 22 May 2014 13:59, Mandeep Dhami wrote: > > Maru's concerns are that: > 1. It is large > 2. It is complex > > And Armando's related concerns are: > 3. Could dev/review cycles be better spent on refactoring > 4. If refactored neutron was available, would a simpler option become more > viable Th

Re: [openstack-dev] [Neutron] reservation of fixed ip

Well, for a use case we had in mind we were trying to figure out how to simply get an IP address on a subnet. We essentially want to use such an address internally by the controller and make sure it is not used for a port that gets created on a network with that subnet. In this use case, an interf

[openstack-dev] [QA] Tempest Blueprint Cleanup

Hi Everyone, As part of moving to the new blueprint review process with the qa-specs repo [1] I'm going to do a purge of the current tempest blueprint list. I'm planning to do this next Thursday, the 29th, sometime before the QA meeting. This is really just an exercise to cleanup and prioritize t

Re: [openstack-dev] [qa] Issue in Tempest API's tests when running with nosetest command?

Yes, Issue is in nose. I do not like nose due to these kind of assumption for test running :). There is no reason of using nose, I just ran that and counter this issue. I totally agree on your point not to spent time to fix these kind of issue. As you mentioned. may be blocking nose would be good

Re: [openstack-dev] [QA] Tempest Release Naming

On Fri, May 23, 2014 at 01:01:42AM +, Jeremy Stanley wrote: > On 2014-05-22 20:40:16 -0400 (-0400), Sean Dague wrote: > > Given that we're not really going to have major / minor bumps at this > > point (more a continous roll), I might argue that we should just go > > Firefox on it and bump the

Re: [openstack-dev] [qa] Issue in Tempest API's tests when running with nosetest command?

On Fri, May 23, 2014 at 09:34:35AM +0900, GHANSHYAM MANN wrote: > Tempest API’s XML test will run with 1 test failure when run with Nosetest. > When we run the tempest with nosetest command (ex -nosetest –v > ./tempest/api/compute/test_xyz.py), it run *BaseComputeTest > ::create_test_server & creat

Re: [openstack-dev] [sahara] Deleting cluster in sahara horizon, 500 Error occured in nova.

Thanks for your helping. But in our system, the problem is that: If using the nova cli, this libvirt problem not occurred. But in deleting cluster of the sahara , this problem occurred. That if our problem. Can it influence the step on deleting cluster in the process to destroy vm of libvir

Re: [openstack-dev] [Mistral] Cleaning up configuration settings

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/05/14 05:00, W Chan wrote: > Renat, > > I want to avoid having to explicitly import the mistral.config module in > order > to have configuration loaded properly. The problem with the way > mistral.config > is coded is that we have to use im

Re: [openstack-dev] [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

I plan on attending. -bryan On Thu, May 22, 2014 at 10:48 AM, Jarret Raim wrote: > All, > > There was some interest at the Summit in semi-combining the mid-cycle meet > ups for Barbican, Keystone and the OSSG as there is some overlap in team > members and interest areas. The current dates being

Re: [openstack-dev] [QA] Tempest Release Naming

On 2014-05-22 20:40:16 -0400 (-0400), Sean Dague wrote: > Given that we're not really going to have major / minor bumps at this > point (more a continous roll), I might argue that we should just go > Firefox on it and bump the integer on every release. [...] Marvellously pragmatic. If you need min

Re: [openstack-dev] [QA] Tempest Release Naming

On 05/22/2014 08:33 PM, Jeremy Stanley wrote: > On 2014-05-22 18:33:34 -0400 (-0400), Matthew Treinish wrote: > [...] >> I'd like to stick with one scheme and not decide to change it >> later on. I figured I should bring this out to a wider audience to >> see if there were other suggestions or opin

[openstack-dev] [qa] Issue in Tempest API's tests when running with nosetest command?

Tempest API’s XML test will run with 1 test failure when run with Nosetest. When we run the tempest with nosetest command (ex -nosetest –v ./tempest/api/compute/test_xyz.py), it run *BaseComputeTest ::create_test_server & create_test_server_group *functions also as test with any of the API tests. B

Re: [openstack-dev] [QA] Tempest Release Naming

On 2014-05-22 18:33:34 -0400 (-0400), Matthew Treinish wrote: [...] > I'd like to stick with one scheme and not decide to change it > later on. I figured I should bring this out to a wider audience to > see if there were other suggestions or opinions before I pushed > out the tag, especially becaus

[openstack-dev] [keystone] No templated service catalog for V3?

Hi, I notice that the templated catalog doesn't support the V3 API*. This is a blocker for us, particularly for Heat since it uses V3 internally. We could switch to the SQL backend, but I'm sure others are affected by this too. Is it hard to fix? Cheers, Kieran * https://bugs.launchpad.net/keys

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

On 2014-05-21 14:57:06 -0700 (-0700), James E. Blair wrote: [...] > Joshua Hesketh has been reviewing a truly impressive number of infra > patches for quite some time now. He has an excellent grasp of how the > CI system functions, no doubt in part because he runs a copy of it and > has been doing

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

On 2014-05-21 14:42:16 -0700 (-0700), James E. Blair wrote: [...] > Sergey has been an extremely valuable member of infra-core for some time > now, providing reviews on a wide range of infrastructure projects which > indicate a growing familiarity with the large number of complex systems > that mak

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

OK. On Thu, May 22, 2014 at 5:13 PM, Maru Newby wrote: > > On May 22, 2014, at 4:35 PM, Mandeep Dhami > wrote: > > > > each patch needs to receive core reviewer attention and that > subsequent patches incorporate their feedback. > > > > At least two core neutron members were involved in creati

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

On 2014-05-21 14:31:24 -0700 (-0700), James E. Blair wrote: [...] > Nikita, thank you very much for your work! Absolutely! I am wholeheartedly in favor of this proposal. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Neutron] Introducing task oriented workflows

Hi Salvatore Thank you for your posting this. IMO, this topic shouldn't be limited for Neutron only. Users wants consistent API between OpenStack project, right? In Nova, a server has task_state, so Neutron should do same way. 2014-05-22 15:34 GMT-07:00 Salvatore Orlando : > As most of you pr

Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

On 2014-05-21 23:52:14 -0700 (-0700), Clint Byrum wrote: > You didn't also ask them to subscribe to the users and/or operators > mailing lists? I would think at least one of those two lists would be > quite important for users to stay in the loop about the effort. [...] It's also worth noting that

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

On May 22, 2014, at 4:35 PM, Mandeep Dhami wrote: > > each patch needs to receive core reviewer attention and that subsequent > > patches incorporate their feedback. > > At least two core neutron members were involved in creating the PoC, and at > least two more cores were involved in reviews

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

> each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback. At least two core neutron members were involved in creating the PoC, and at least two more cores were involved in reviews at various times. In addition to them, senior developers from at l

[openstack-dev] Gate and Skipped Tests

I noticed recently that some tests are being skipped in the Nova gate. Some will always be skipped, but others are conditional. In particular the ZooKeeper driver tests are being skipped because an underlying python module is missing. It seems to me that we should want no tests to be conditional

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

On 05/22/2014 07:03 PM, Maru Newby wrote: On May 22, 2014, at 1:59 PM, Mandeep Dhami wrote: Maru's concerns are that: 1. It is large 2. It is complex As per the discussion in the irc meeting today, I hope it is clear now that eventual size and complexity are not real issue. Rather, I am con

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

On May 22, 2014, at 1:59 PM, Mandeep Dhami wrote: > > Maru's concerns are that: > 1. It is large > 2. It is complex As per the discussion in the irc meeting today, I hope it is clear now that eventual size and complexity are not real issue. Rather, I am concerned at how we get there. I ke

Re: [openstack-dev] [Neutron] Core API refactoring

OK On Thu, May 22, 2014 at 7:36 AM, Collins, Sean < sean_colli...@cable.comcast.com> wrote: > On Wed, May 21, 2014 at 10:47:16PM EDT, Mandeep Dhami wrote: > > The update from Sean seem to suggest to me that we needed blueprints only > > if the public API changes, and not for design changes that

Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project

Hello, Just to make sure I understand: 1.) I’m assuming that you can dilettante which policies apply to specific VM’s within a group (Is this correct?). With regards to DENY permissions, they are handled specially. In such a case, all other VM’s are provided with ALLOW permissions for that r

Re: [openstack-dev] [Neutron][QoS] Weekly IRC Meeting?

Hi, I am interested in the meeting but cannot participate (it's 3:00am). I will check the meeting log later. BTW, where do you begin a discussion ? I thought you countinue work in Icehose. Or do you argue from the beginning of the API definition ? Thanks. Itsuro Oda (oda-g) On Wed, 21 May 201

[openstack-dev] [Neutron] Introducing task oriented workflows

As most of you probably know already, this is one of the topics discussed during the Juno summit [1]. I would like to kick off the discussion in order to move towards a concrete design. Preamble: Considering the meat that's already on the plate for Juno, I'm not advocating that whatever comes out

[openstack-dev] [QA] Tempest Release Naming

Hi Everyone, So I was preparing to push the first tag as part of the move to a world with a branchless tempest and was trying to figure out the naming convention we should be using. The only complexity here is that we are targeting to do 4 releases a year that coincide with the OpenStack releases

[openstack-dev] [TripleO] CI needs YOU

Ahoy there, TripleO interested parties. In the last few months, we've gotten a relatively robust, though not nearly complete, CI system for TripleO. It is a bit unorthodox, as we have a strong desire to ensure PXE booting works, and that requires us running in our own cloud. We have this working,

Re: [openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

Hi, I found this message in my backlog from when I was at the summit. Sorry for the delay in responding. The "default SNAT" or "dynamic SNAT" use case is one of the last details being worked in the DVR subteam. That may be why you do not see any code around this in the patches that have been sub

Re: [openstack-dev] [Neutron] reservation of fixed ip

If an IP is reserved for a tenant, should the tenant need to explicitly ask for that specific IP to be allocated when creating a floating ip or port? And it would pull from the regular pool if a specific IP is not requested. Or, does the allocator just pull from the tenant's reserved pool wheneve

Re: [openstack-dev] [TripleO] Use of environment variables in tripleo-incubator

For everyone's awareness, Alexis proposed a spec related to this: https://review.openstack.org/#/c/94910 -Ben On 05/20/2014 05:05 PM, James Polley wrote: > I spoke to JP offline and confirmed that the link to 85418 should have been > a link to https://review.openstack.org/#/c/88252 > > I think t

Re: [openstack-dev] [Openstack-docs] [Heat][Documentation] Heat template documentation

On 23/05/14 08:56, Anne Gentle wrote: > > > > On Tue, May 20, 2014 at 6:42 PM, Steve Baker > wrote: > > On 21/05/14 02:31, Doug Hellmann wrote: >> On Fri, May 16, 2014 at 2:10 PM, Gauvain Pocentek >> >> wrote: >>>

Re: [openstack-dev] Manual VM migration

Hi, Thanks for response and sharing script. Can i use this script with devstack based cloud platform.? Actually Live Migration is available between inter-cluster. so that why i was talking about the suspend/pause the VM before migration. Regards On Thu, May 22, 2014 at 8:45 PM, Diego Parri

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

Maru's concerns are that: 1. It is large 2. It is complex And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable Let me address them in that order. 1. Re: It is large Group po

Re: [openstack-dev] [Openstack-docs] [Heat][Documentation] Heat template documentation

On Tue, May 20, 2014 at 6:42 PM, Steve Baker wrote: > On 21/05/14 02:31, Doug Hellmann wrote: > > On Fri, May 16, 2014 at 2:10 PM, Gauvain > Pocentek > wrote: > > Le 2014-05-16 17:13, Anne Gentle a écrit : > > > On Thu, May 15, 2014 at 10:34 AM, Gauvain > Pocentek > wrote: > > > Hello,

Re: [openstack-dev] Link to patch/review for allowing instances to receive vlan tagged traffic

Hi Steven More than happy to help out here: The BP in question is this, patches have been submitted 3 weeks ago by Erik Moe: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms https://review.openstack.org/#/c/92541/ This is a generic feature a lot of Telco traffic nodes have and eve

Re: [openstack-dev] NFV BoF at design summit

+1 I believe the main point is not to confuse what we is need on the Hypervisor and networking but focus on what we need Openstack to support to be a robust and reliable system, for example most systems aim for 5 9's due to various requirements but what they really want to aim for us "predictab

Re: [openstack-dev] [NFV][Neutron] Link to patch/review for allowing instances to receive vlan tagged traffic

The associated neutron specs: https://review.openstack.org/94612 On Thu, May 22, 2014 at 8:55 PM, Yi Sun wrote: > Is this the one? > https://review.openstack.org/#/c/92541/ > > > On Thu, May 22, 2014 at 11:04 AM, Steve Gordon wrote: > >> Hi Alan/Balazs, >> >> In one of the NFV BoF sessions in

Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

I've published all renaming changes, here is an etherpad [1] with the list of them. All of the changes are in one chain to avoid merge conflicts, oslo-specs renaming is the last one in chain if we'll decide to keep it as is. [1] https://etherpad.openstack.org/p/repo-renaming-2014-05-23 Thanks. O

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

Hi Sam, I totally agree - this will definitely reduce our scope and increase the chance of getting this in. I am still (being influenced by Unix methodology) thinking that we should explore service chaining more for that. As I said earlier, re-encryption feels more like a VPN type thing than a

Re: [openstack-dev] [oslo] specs & blueprints for juno

On Tue, May 20, 2014 at 9:28 AM, Doug Hellmann wrote: > We agreed just before the summit that we wanted to participate in the > specs repository experiments for this cycle. The repository is set up > [1] and I've just posted a review for an updated template [2] that > includes some sections added

Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested

On Thu, May 22, 2014 at 4:48 AM, Lucas Alvares Gomes wrote: > On Thu, May 22, 2014 at 1:03 AM, Devananda van der Veen > wrote: >> I'd like to bring up the topic of drivers which, for one reason or another, >> are probably never going to have third party CI testing. >> >> Take for example the iBoo

Re: [openstack-dev] [Mistral] Cleaning up configuration settings

Renat, I want to avoid having to explicitly import the mistral.config module in order to have configuration loaded properly. The problem with the way mistral.config is coded is that we have to use importutils otherwise we get pep8 error if we simply insert "from mistral import config". An exampl

Re: [openstack-dev] [NFV][Neutron] Link to patch/review for allowing instances to receive vlan tagged traffic

Is this the one? https://review.openstack.org/#/c/92541/ On Thu, May 22, 2014 at 11:04 AM, Steve Gordon wrote: > Hi Alan/Balazs, > > In one of the NFV BoF sessions in Atlanta one of you (I assume one of you > anyway!) noted in the etherpad [1] (line 89) that Ericsson had submitted a > patch to

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

I would second Maru's concerns, and I would also like to add the following: We need to acknowledge the fact that there are certain architectural aspects of Neutron as a project that need to be addressed; at the summit we talked about the core refactoring, a task oriented API, etc. To me these item

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

Hi Everone, I would like to defer addressing client authentication and back-end-server authentication for a 2nd phase - after Juno. This means that from looking on https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7 , under the "SSL/TLS Termination capabilities", not addressing 2.2 and 3. I t

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

On May 22, 2014, at 11:03 AM, Maru Newby wrote: > At the summit session last week for group-based policy, there were many > concerns voiced about the approach being undertaken. I think those concerns > deserve a wider audience, and I'm going to highlight some of them here. > > The primary co

Re: [openstack-dev] [TripleO] Haproxy configuration options

That depends on your security requirements. If HAProxy is proxying requests to multiple servers and you terminate the SSL at HAProxy, then you will be sending the request unencrypted from one server to another. I am not at all opposed to adding the capabilities to configure HAProxy to terminate

Re: [openstack-dev] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

On Thu, May 22, 2014 at 9:48 AM, Jarret Raim wrote: > All, > > There was some interest at the Summit in semi-combining the mid-cycle meet > ups for Barbican, Keystone and the OSSG as there is some overlap in team > members and interest areas. The current dates being considered are: > > Mon, July 7

Re: [openstack-dev] [Neutron] reservation of fixed ip

Hello, Thanks for answears and info about this project - I will take a look on that for sure :) For me now reservation of fixed ips is enough and I don't know what else can be reserved in neutron. Floating IP you can now assign to tenant and this is some kind of reservation. Maybe someone else wil

[openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

At the summit session last week for group-based policy, there were many concerns voiced about the approach being undertaken. I think those concerns deserve a wider audience, and I'm going to highlight some of them here. The primary concern seemed to be related to the complexity of the approach

[openstack-dev] [NFV][Neutron] Link to patch/review for allowing instances to receive vlan tagged traffic

Hi Alan/Balazs, In one of the NFV BoF sessions in Atlanta one of you (I assume one of you anyway!) noted in the etherpad [1] (line 89) that Ericsson had submitted a patch to Neutron which would allow instances to use tagged vlan traffic. Do you happen to have a link handy to the review for this

Re: [openstack-dev] [Neutron] reservation of fixed ip

Hello Dnia Wed, 21 May 2014 23:51:48 +0100 Salvatore Orlando napisał: > In principle there is nothing that should prevent us from > implementing an IP reservation mechanism. > > As with anything, the first thing to check is literature or "related > work"! If any other IaaS system is implementi

Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested

On Thu, May 22, 2014 at 9:05 AM, Dan Prince wrote: > - Original Message - > > From: "Devananda van der Veen" > > [...] > > interface. However, I also don't expect the author to provide a full > > third-party CI environment, and as such, we should not claim the same > level > > of test cov

[openstack-dev] [Fuel] Hard code freeze 5.0 announcement

Stackers, according to https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze, we call for a HCF. It will take some time to switch all required CI infrastructure to handle both stable/5.0 (which was just created), and master branches. Since now, master is open for merges of everything deferred to

Re: [openstack-dev] [Neutron] reservation of fixed ip

Hi, I'm agree with Pablo. We've looked at Neutron resource reservations some time ago. But we can't decide which resources should be reserved and this question has been delayed. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2014-05-22 10:00 GMT-07:00 Fuente,

Re: [openstack-dev] [Neutron] reservation of fixed ip

Hi, I'm part of a project that aims to manage Reservations on OpenStack. Maybe this could be implemented on it. The name of the project is Blazar (ex Climate). Currently we have two reservation plugins: one for physical host reservations and other for virtual instances reservation. We are p

Re: [openstack-dev] [TripleO] Haproxy configuration options

On Thu, May 22, 2014, at 08:51 AM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) wrote: > > HAProxy SSL termination is not a viable option when HAProxy is used to > proxy traffic between servers. If HAProxy terminates the SSL it will then > proxy the traffic unencrypted to any other server across

Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

BTW I'm working on preparing all changes for this renaming session. On Thu, May 22, 2014 at 8:05 PM, Doug Hellmann wrote: > On Thu, May 22, 2014 at 10:16 AM, James E. Blair > wrote: >> Thierry Carrez writes: >> >>> James E. Blair wrote: openstack/oslo-specs -> openstack/common-libraries-s

Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

On Thu, May 22, 2014 at 1:52 AM, Clint Byrum wrote: > Excerpts from Tom Fifield's message of 2014-05-21 21:39:22 -0700: >> On 22/05/14 11:06, Kyle Mestery wrote: >> > On Wed, May 21, 2014 at 5:06 PM, Tom Fifield wrote: >> >> On 22/05/14 05:48, James E. Blair wrote: >> >>> >> >>> Tom Fifield writ

Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

On Thu, May 22, 2014 at 10:16 AM, James E. Blair wrote: > Thierry Carrez writes: > >> James E. Blair wrote: >>> openstack/oslo-specs -> openstack/common-libraries-specs >> >> I understand (and agree with) the idea that -specs repositories should >> be per-program. >> >> That said, you could argue

Re: [openstack-dev] [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

On 05/22/2014 07:48 AM, Jarret Raim wrote: > All, > > There was some interest at the Summit in semi-combining the mid-cycle meet > ups for Barbican, Keystone and the OSSG as there is some overlap in team > members and interest areas. The current dates being considered are: > > Mon, July 7 - Bar

Re: [openstack-dev] [TripleO] Haproxy configuration options

HAProxy SSL termination is not a viable option when HAProxy is used to proxy traffic between servers. If HAProxy terminates the SSL it will then proxy the traffic unencrypted to any other server across a network. However, since SSL termination and SSL re-encryption are now features of the curre

Re: [openstack-dev] Manual VM migration

Hi Naveed, I don't think it's a good idea to suspend/pause. If you want to keep the state of the VM then have a look at the live migration capabilities of KVM. Our script is very simple and works for any VM without attached block storage. Here goes the little script. Keep in mind it's something v

Re: [openstack-dev] [TripleO] Haproxy configuration options

Created spec https://review.openstack.org/#/c/94907/ I think it is WIP still, but would be nice to hear some comments/opinions On Thu, May 22, 2014 at 1:59 AM, Robert Collins wrote: > On 18 May 2014 08:17, Miller, Mark M (EB SW Cloud - R&D - Corvallis) > wrote: > > We are considering the follo

Re: [openstack-dev] Manual VM migration

Yep, wrong order. You are right. Thanks! -- Diego Parrilla *CEO* *www.stackops.com | * diego.parri...@stackops.com | +34 91 005-2164 | skype:diegoparrilla On Wed, May 21, 2014 at 11:53 PM, CARVER, PAUL wrote: > Are you sure steps 1 and

Re: [openstack-dev] [Mistral] Cleaning up configuration settings

I tend to disagree with the whole idea. Not sure 100% though yet. Could you please explain the point of scattering configuration all over the code? In my opinion, we’re mixing different application concerns. With the current approach I always know where to look at in order to find all my configu

Re: [openstack-dev] [Murano] BP Review for J1

Dmitry, we actually need to move meeting to another day, since not all people from our core team is yet returned from OpenStack Summit. BP Review for milestone 1 of Juno release will be held on Tuesday, June 3 at 15:00 UTC. I hope it works for you too. On Thu, May 22, 2014 at 12:44 PM, Dmitry wr

Re: [openstack-dev] Extending nova models

Actually, that line you linked to about IMPL is a bit misleading. In this case, under the hood IMPL is really just the sqlalchemy implementation of the Nova db api at https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2404. In Nova we don't "insert a row in to a table" per

[openstack-dev] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

All, There was some interest at the Summit in semi-combining the mid-cycle meet ups for Barbican, Keystone and the OSSG as there is some overlap in team members and interest areas. The current dates being considered are: Mon, July 7 - Barbican Tue, July 8 - Barbican Wed, July 9 - Barbican / Keyst

Re: [openstack-dev] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

On Thu, May 22, 2014 at 10:48 AM, Jarret Raim wrote: > > This should make travel a bit easier for everyone as people won't need Hey Jarret, I'm going to be at the Keystone meetup for sure, but I'm also thinking about going to the Barbican meetup too. -- David blog: http://www.traceback.org tw

Re: [openstack-dev] [heat] [neutron] [trove] [swift] Uniform name for logger in projects

(Adding relevant projects to subject. Hope I didn't miss any.) Heat, Neutron, Trove, and Swift devs, Do we want to change all instances of "logger" variable names to "LOG" (like most OpenStack projects use) and enforce that via the hacking rules? Regards, Jason On Wed, May 21 2014, Sergey Kra

Re: [openstack-dev] [Neutron] Core API refactoring

On Wed, May 21, 2014 at 10:47:16PM EDT, Mandeep Dhami wrote: > The update from Sean seem to suggest to me that we needed blueprints only > if the public API changes, and not for design changes that are internal to > neutron. There was no statement in my e-mail that made that suggestion. My e-mail

Re: [openstack-dev] [Storyboard] [UX] Atlanta Storyboard UX Summary

Sean Dague writes: > It's worth noting, most (>90%) of OpenStack developers aren't trying to > land or track features across projects. And realistically, in my > experience working code into different repositories, the blueprint / bug > culture between projects varies widely (what requires and ar

Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

Thierry Carrez writes: > James E. Blair wrote: >> openstack/oslo-specs -> openstack/common-libraries-specs > > I understand (and agree with) the idea that -specs repositories should > be per-program. > > That said, you could argue that "oslo" is a shorthand for "common > libraries" and is the cod

Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested

- Original Message - > From: "Devananda van der Veen" > To: "OpenStack Development Mailing List" > Sent: Wednesday, May 21, 2014 8:03:15 PM > Subject: [openstack-dev] [Ironic] handling drivers that will not be > third-party tested > > I'd like to bring up the topic of drivers which,

[openstack-dev] VM performance of Openstack launched over Esxi

Hi, I am using Openstack Havana Setup with Esxi as Compute Node. I launch two VMs with identical configuration over the Esxi -> one via Openstack and other manually via vSphere Client. VM launched over Esxi manually via vSphere Client performs better than one via Openstack over Esxi. I am talkin

Re: [openstack-dev] [neutron] Proposed changes to core team

On 5/21/14, 4:59 PM, Kyle Mestery wrote: Neutron cores, please vote +1/-1 for the proposed addition of Carl Baldwin to Neutron core. +1 -Bob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailm

Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

- Original Message - > From: "Kevin Benton" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Thursday, May 22, 2014 2:48:37 AM > Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit > > >3. OpenStack itself should ( its own Compute Node/L3

Re: [openstack-dev] [TripleO] Spec Template Change Proposal

Merging a few of the replies into a single response: > I like all of this plan, except for the name "Overview". To me, "Overview" suggests a high-level summary rather than being "one of the beefier sections of a spec". Something like "Detail" or "Detailed overview" (because the low-level detai

Re: [openstack-dev] [Openstack] [Keystone] Help extending Keystone JSON documents with custom attributes, safe?

To be a bit more succinct, if I PATCH existing Keystone JSON documents (projects, roles, users, etc) with my own custom JSON attributes, can I expect this to be a safe practice? Meaning, I'd like to add my own custom attributes and be able to query them back at a later time when I look up the

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

On 05/21/2014 05:57 PM, James E. Blair wrote: > 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

On 05/21/2014 05:42 PM, James E. Blair wrote: > 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] [UX] OpenStack UX - IRC meeting

Thanks for the reminder, it's very interesting for Sahara. P.S. /me adding Chad directly (he's working on sahara@horizon). On Mon, May 19, 2014 at 4:12 PM, Jaromir Coufal wrote: > Hello everybody interested in UX, > > for one more time, I am reminding that there is ongoing survey for times > whi

Re: [openstack-dev] [gate] failing postgres jobs

Thanks for the confirmation. On Wed, May 21, 2014 at 12:18 AM, Nikhil Manchanda wrote: > Yes, this issue is fixed now that 94315 is merged. > > > On Tue, May 20, 2014 at 3:38 PM, Sergey Lukjanov > wrote: >> >> As I see, the 94315 merged atm, is the issue fixed? >> >> >> On Tuesday, May 20, 2014,

Re: [openstack-dev] [relmgt] Proposed Juno release schedule

Thierry Carrez wrote: > At the Design Summit last week we discussed the Juno release schedule > and came up with the following proposal: > > https://wiki.openstack.org/wiki/Juno_Release_Schedule > > The main reported issue with it is the presence of the US labor day > weekend just before juno-3 (

Re: [openstack-dev] [oslo] strutils: enhance safe_decode() and safe_encode()

On 21/05/14 11:32 -0400, Doug Hellmann wrote: On Thu, May 15, 2014 at 11:41 AM, Victor Stinner wrote: Hi, The functions safe_decode() and safe_encode() have been ported to Python 3, and changed more than once. IMO we can still improve these functions to make them more reliable and easier to us

  1   2   >