Re: [openstack-dev] [Openstack-operators] Scheduler proposal

On 10/08/2015 01:37 AM, Clint Byrum wrote: Excerpts from Maish Saidel-Keesing's message of 2015-10-08 00:14:55 -0700: Forgive the top-post. Cross-posting to openstack-operators for their feedback as well. Ed the work seems very promising, and I am interested to see how this evolves. With my o

Re: [openstack-dev] We should move strutils.mask_password back into oslo-incubator

On 08/10/15 16:49, Doug Hellmann wrote: Excerpts from Matt Riedemann's message of 2015-10-07 14:38:07 -0500: Here's why: https://review.openstack.org/#/c/220622/ That's marked as fixing an OSSA which means we'll have to backport the fix in nova but it depends on a change to strutils.mask_pass

Re: [openstack-dev] [fuel] Nominate Svetlana Karslioglu for fuel-docs core

+1 Svetlana, thank you for your contribution, and looking forward to working with you on the Fuel documentation improvement! Best, Olga On Thu, Oct 8, 2015 at 11:13 AM, Alexander Adamov wrote: > +1 to Svetlana's nomination. > > On Tue, Sep 29, 2015 at 4:58 AM, Dmitry Borodaenko < > dborodae...@

Re: [openstack-dev] [magnum] New Core Reviewers

Thanks everyone! It is my pleasure to be a magnum core reviewer. Let's make magnum better together. Thanks Wanghua On Wed, Oct 7, 2015 at 1:19 AM, Vilobh Meshram < vilobhmeshram.openst...@gmail.com> wrote: > Thanks everyone! > > I really appreciate this. Happy to join Magnum-Core :) > > We have

[openstack-dev] What's Up, Doc? 9 Oct 2015

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, We're hurtling head first to Liberty, with only about a week left to go. I've been working on Summit preparations, and making sure we're ready to go when the time hits. This week, I'm working on Release Notes, keeping an eye on the fina

Re: [openstack-dev] [congress] Symantec's security group management policies

It's a very good example to show how to draft the customize cloud policy in OpenStack deployment, thank you Su :-) Some my comments had been added into the google doc. 2015-10-09 4:23 GMT+08:00 Su Zhang : > Hello, > > I've implemented a set of security group management policies and already > pu

Re: [openstack-dev] [magnum] Document adding --memory option to create containers

We should reserve time at the next summit to discuss putting together a detailed user guide, laying down a skeleton so contributors can start filling in different parts. Otherwise as we observe, everything is falling into the quick start guide. Ton Ngo, From: "Qiao,Liyong" To: openstack-d

Re: [openstack-dev] [ironic] Nominating two new core reviewers

My +2 for both jlvillal and vdrok .. Thanks a lot for all your work in Ironic and welcome to ironic-core. Cheers :) On Fri, Oct 9, 2015 at 3:17 AM, Jim Rollenhagen wrote: > Hi all, > > I've been thinking a lot about Ironic's core reviewer team and how we might > make it better. > > I'd like to

Re: [openstack-dev] Error Installing KILO release on powerpc

On 10/8/2015 12:38 PM, Rahul Arora wrote: Hi Team I am trying to run Openstack KILO release on my powerpc platform.I am able to cross compile all the KILO related packages using yocto framework.But while running the following command i am getting below error messages. keystone-manage db_sync

Re: [openstack-dev] [devstack] A few questions on configuring DevStack for Neutron

On 10/8/2015 11:38 AM, Sean M. Collins wrote: Please see my response here: http://lists.openstack.org/pipermail/openstack-dev/2015-October/076251.html In the future, do not create multiple threads since responses will get lost Maybe a dumb question, but couldn't people copy the localrc fro

Re: [openstack-dev] Requests + urllib3 + distro packages

On 10/8/2015 7:57 PM, Monty Taylor wrote: On 10/08/2015 08:39 PM, Robert Collins wrote: This is a bugbear that keeps cropping up and biting us. I'm hoping we can figure out a permanent fix. The problem that occurs is the result of a few interacting things: - requests has very very specific

Re: [openstack-dev] Scheduler proposal

On 8 October 2015 at 13:28, Ed Leafe wrote: > On Oct 8, 2015, at 1:38 PM, Ian Wells wrote: > > Truth be told, storing that data in MySQL is secondary to the correct > functioning of the scheduler. > > I have no problem with MySQL (well, I do, but that's not relevant to this > discussion). My iss

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

Hi Ihar, Thank you for starting this thread. Here is what on top of my mind for Mitaka: I will be busy with work centered around networking-sfc project. Networking-sfc is a sub project of Neutron (part of the Neutron Stadium), which provides a service function chain API and related functionalit

Re: [openstack-dev] [magnum] Document adding --memory option to create containers

+1, we can add more detail explanation information of --memory in magnum CLI instead of quick start. Eli. On 2015年10月09日 07:45, Vikas Choudhary wrote: In my opinion, there should be a more detailed document explaining importance of commands and options. Though --memory is an important attribut

Re: [openstack-dev] Requests + urllib3 + distro packages

On 10/08/2015 08:39 PM, Robert Collins wrote: This is a bugbear that keeps cropping up and biting us. I'm hoping we can figure out a permanent fix. The problem that occurs is the result of a few interacting things: - requests has very very specific versions of urllib3 it works with. So specifi

Re: [openstack-dev] [devstack] A few questions on configuring DevStack for Neutron

On 10/08/2015 07:13 PM, Christopher Aedo wrote: On Thu, Oct 8, 2015 at 9:38 AM, Sean M. Collins wrote: Please see my response here: http://lists.openstack.org/pipermail/openstack-dev/2015-October/076251.html In the future, do not create multiple threads since responses will get lost Yep, th

[openstack-dev] Requests + urllib3 + distro packages

This is a bugbear that keeps cropping up and biting us. I'm hoping we can figure out a permanent fix. The problem that occurs is the result of a few interacting things: - requests has very very specific versions of urllib3 it works with. So specific they aren't always released yet. - Linux vend

Re: [openstack-dev] [Fuel] py.test vs testrepository

Folks, Since we’ve reached the consensus here I’d like to invite you to review the patch [1] that replaces py.test with testr without making debuging or running specific tests harder. Please also note that it has a dependency which needs to be reviewed and merged first one. 1. https://review.o

Re: [openstack-dev] [magnum] Document adding --memory option to create containers

In my opinion, there should be a more detailed document explaining importance of commands and options. Though --memory is an important attribute, but since objective of quickstart is to get user a minimum working system within minimum time, it seems better to skip this option in quickstart. -Vika

Re: [openstack-dev] [devstack] A few questions on configuring DevStack for Neutron

On Thu, Oct 8, 2015 at 9:38 AM, Sean M. Collins wrote: > Please see my response here: > > http://lists.openstack.org/pipermail/openstack-dev/2015-October/076251.html > > In the future, do not create multiple threads since responses will get > lost Yep, thank you Sean - saw your response yesterday

Re: [openstack-dev] FW: [Fuel] 8.0 Region name support / Multi-DC

Adam, fuel does support multiple PXE networks via the nodegroup/multiple clusters feature, however in the geo-diverse case this would receive limited use as it's mostly useful for a spine and leaf network topology. As you noted, in the geo-diverse case you would typically deploy an env for the key

Re: [openstack-dev] [neutron][testing][all] fixtures 1.4.0 breaking py34 jobs

On 9 October 2015 at 01:10, Ihar Hrachyshka wrote: > Hi all, > > just a heads up that today fixtures 1.4.0 broke neutron py34 gate [1] and we > needed to patch some logging code to overcome it [2]. The failures were > triggered by a patch that started to raise logging exceptions for incorrect >

Re: [openstack-dev] [fuel] PTL & Component Leads elections

Voting period ended and so we have an officially selected Fuel PTL - DB. Congrats! Poll results & details - http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_b79041aa56684ec0 Let's start proposing candidates for the component lead positions! On Wed, Sep 30, 2015 at 8:47 PM, Sergey

Re: [openstack-dev] [ironic] Nominating two new core reviewers

Hi, On Thu, Oct 8, 2015 at 10:47 PM, Jim Rollenhagen wrote: > Hi all, > > I've been thinking a lot about Ironic's core reviewer team and how we might > make it better. > > I'd like to grow the team more through trust and mentoring. We should be > able to promote someone to core based on a good k

[openstack-dev] [Fuel] Plugins related functionality in Fuel Client

Folks, it’s time to speak about Fuel Plugins and the way they are managed. Currently we have some methods in Fuel Client that allow to install, remove and do some other things to plugins. Everything looks great except that functionality requires Fuel Client to be installed on a master node and

Re: [openstack-dev] [ironic] Nominating two new core reviewers

Looking forward to more cores!!! On 8 October 2015 at 17:47, Jim Rollenhagen wrote: > Hi all, > > ... I'd like to nominate Vladyslav Drok (vdrok) for the core team. His reviews > have been super high quality, and the quantity is ever-increasing. He's > also started helping out with some smaller

Re: [openstack-dev] [tc] naming N and O releases nowish

On 9 October 2015 at 00:53, Sean Dague wrote: > On 10/08/2015 06:59 AM, Daniel P. Berrange wrote: >> On Wed, Oct 07, 2015 at 02:57:59PM +0200, Thierry Carrez wrote: >>> Sean Dague wrote: We're starting to make plans for the next cycle. Long term plans are getting made for details that wo

[openstack-dev] [all][elections] Magum PTL Election Conclusion and Results

Hello all, Voting has now closed in the Magnum PTL election. Thanks again to Adrian and Hongbin for running. Please join me in extending congratulations Adrian in retaining is role as PTL. The results can be seen here: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_306b9309f2f39e38

[openstack-dev] [all][api] New API Guidelines Ready for Cross Project Review

Hi All, The following API guidelines are ready for cross project review. They will be merged on Oct. 16 if there's no further feedback. 1. Adds an API documentation guideline document https://review.openstack.org/#/c/214817/ 2. Add http400 for nonexistent resource https://review.openstack.org/#

[openstack-dev] [ironic] Nominating two new core reviewers

Hi all, I've been thinking a lot about Ironic's core reviewer team and how we might make it better. I'd like to grow the team more through trust and mentoring. We should be able to promote someone to core based on a good knowledge of *some* of the code base, and trust them not to +2 things they d

Re: [openstack-dev] [kolla] Backport policy for Liberty

On 9 October 2015 at 08:47, Steven Dake (stdake) wrote: > Kolla operators and developers, > > The general consensus of the Core Reviewer team for Kolla is that we should > embrace a liberal backport policy for the Liberty release. An example of > liberal -> We add a new server service to Ansible,

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

Daniel, In which time zone are you located? Thanks for volunteering. Edgar From: Daniel Mellado Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Thursday, October 8, 2015 at 8:06 AM To: "openstack-dev@lists.openstack.org"

Re: [openstack-dev] Error Installing KILO release on powerpc

On Thu, Oct 08, 2015 at 11:08:06PM +0530, Rahul Arora wrote: > Hi Team > > I am trying to run Openstack KILO release on my powerpc platform.I am able > to cross compile all the KILO related packages using yocto framework.But > while running the following command i am getting below error messages.

[openstack-dev] [Murano] py26 support in python-muranoclient

Hello, I am wondering if there is any near-term plan for removing the py26 support from the client project (python-muranoclient). For the tosca support blueprint python-muranoclient will become dependent on tosca-parser project and expect tosca-parser to support py26 (it currently does not supp

Re: [openstack-dev] [Security] Introducing Killick PKI

Very lightweight, automatic certificate security policy enforcement. Doug > On 8 Oct 2015, at 18:48, Adam Young wrote: > >> On 10/08/2015 12:50 PM, Chivers, Doug wrote: >> Hi All, >> >> At a previous OpenStack Security Project IRC meeting, we briefly discussed a >> lightweight traditional PK

Re: [openstack-dev] [nova-compute][nova][libvirt] Extending Nova-Compute for image prefetching

I think I'd rephrase your definition of pre-fetched to be honest -- something more like "images on this hypervisor node without a currently running instance". So, your operations would become: - trigger an image prefetching - list unused base images (and perhaps when they were last used) - dele

Re: [openstack-dev] 答复: [Congress] Tokyo sessions

Rui is right. Below I expanded on the short description Rui provided above. Discussions with external teams: OPNFV, Monasca Integration with other projects: congress gating (nova, neutron, etc.), devstack plugin, keystone Distributed architecture and additional features for M Tim On Wed, Oct 7

Re: [openstack-dev] Scheduler proposal

On Oct 8, 2015, at 1:38 PM, Ian Wells wrote: >> You've hit upon the problem with the current design: multiple, and >> potentially out-of-sync copies of the data. > > Arguably, this is the *intent* of the current design, not a problem with it. It may have been the intent, but that doesn't mean

[openstack-dev] [congress] Symantec's security group management policies

Hello, I've implemented a set of security group management policies and already put them into our usecase doc. Let me know if you guys have any comments. My policies is called "Security Group Management " You can find the use case doc at: https://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMR

Re: [openstack-dev] [magnum] Document adding --memory option to create containers

Adrian, I agree with Steve, otherwise it’s hard to find balance what should go to quick start guide (e.g. many operators worry about cpu or I/O instead of memory). Also I belve auto-scalling deserve it’s own detail document. — Egor From: Adrian Otto mailto:adrian.o...@rackspace.com>> Reply-To:

Re: [openstack-dev] [magnum] Document adding --memory option to create containers

Steve, I agree with the concept of a simple quickstart doc, but there also needs to be a comprehensive user guide, which does not yet exist. In the absence of the user guide, the quick start is the void where this stuff is starting to land. We simply need to put together a magnum reference docu

Re: [openstack-dev] [magnum] Document adding --memory option to create containers

+1 Anything with default values should be ignored in the quickstart guide. -Murali From: Steven Dake (stdake) Sent: Thursday, October 8, 2015 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Docum

Re: [openstack-dev] [magnum] Document adding --memory option to create containers

Quickstart guide should be dead dead dead dead simple. The goal of the quickstart guide isn’t to tach people best practices around Magnum. It is to get a developer operational to give them that sense of feeling that Magnum can be worked on. The goal of any quickstart guide should be to encour

[openstack-dev] [kolla] Backport policy for Liberty

Kolla operators and developers, The general consensus of the Core Reviewer team for Kolla is that we should embrace a liberal backport policy for the Liberty release. An example of liberal -> We add a new server service to Ansible, we would backport the feature to liberty. This is in breaking

Re: [openstack-dev] Scheduler proposal

On 8 October 2015 at 09:10, Ed Leafe wrote: > You've hit upon the problem with the current design: multiple, and > potentially out-of-sync copies of the data. Arguably, this is the *intent* of the current design, not a problem with it. The data can never be perfect (ever) so go with 'good enou

Re: [openstack-dev] Scheduler proposal

On 7 October 2015 at 22:17, Chris Friesen wrote: > On 10/07/2015 07:23 PM, Ian Wells wrote: > >> >> The whole process is inherently racy (and this is inevitable, and >> correct), >> >> > Why is it inevitable? > It's inevitable because everything takes time, and some things are unpredictable. Th

Re: [openstack-dev] [tripleo] python-tripleoclient has unknown requirement

On Thu, Oct 8, 2015 at 10:55 AM, Andreas Jaeger wrote: > Current requirements job fails on python-tripleoclient with: > 'ipaddress' is not in global-requirements.txt > > Could you get the requirement in global-requirements or replace it, please? I've submitted a patch for global-requirements.txt:

Re: [openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

> From: "Sean M. Collins" ... > > On Tue, Oct 06, 2015 at 11:25:03AM EDT, Mike Spreitzer wrote: > > [Sorry, but I do not know if the thundering silence is because these > > questions are too hard, too easy, grossly off-topic, or simply because > > nobody cares.] > > You sent your first e-mail

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

Please count me in (Pacific time zone). On Thu, Oct 8, 2015 at 10:36 AM, Duarte, Adolfo wrote: > I’m in > > > > *From:* Somanchi Trinath [mailto:trinath.soman...@freescale.com] > *Sent:* Thursday, October 08, 2015 4:19 AM > *To:* OpenStack Development Mailing List (not for usage questions); > o

Re: [openstack-dev] [Security] Introducing Killick PKI

On 10/08/2015 12:50 PM, Chivers, Doug wrote: Hi All, At a previous OpenStack Security Project IRC meeting, we briefly discussed a lightweight traditional PKI using the Anchor validation functionality, for use in internal deployments, as an alternative to things like MS ADCS. To take this furt

[openstack-dev] Error Installing KILO release on powerpc

Hi Team I am trying to run Openstack KILO release on my powerpc platform.I am able to cross compile all the KILO related packages using yocto framework.But while running the following command i am getting below error messages. keystone-manage db_sync Traceback (most recent call last): File "/u

Re: [openstack-dev] Scheduler proposal

Clint Byrum wrote: Excerpts from Joshua Harlow's message of 2015-10-08 08:38:57 -0700: Joshua Harlow wrote: On Thu, 8 Oct 2015 10:43:01 -0400 Monty Taylor wrote: On 10/08/2015 09:01 AM, Thierry Carrez wrote: Maish Saidel-Keesing wrote: Operational overhead has a cost - maintaining 3 diffe

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

I’m in From: Somanchi Trinath [mailto:trinath.soman...@freescale.com] Sent: Thursday, October 08, 2015 4:19 AM To: OpenStack Development Mailing List (not for usage questions); openstack-operat...@lists.openstack.org; openstack-d...@lists.openstack.org Subject: Re: [openstack-dev] [OpenStack-docs

[openstack-dev] [mistral] [heat] Mistral Workflow resource type - resource signal handling

Hi, I would like to propose a change in the behavior of the OS::Mistral::Workflow resource signal. CURRENT: The OS::Mistral::Workflow resource type is expecting the following request body on resource signal request: { "input": { ... }, "params": { ... } } The input section is

Re: [openstack-dev] Fwd: [nova] live migration in Mitaka

Hi Pavel, On 2015-10-08 9:39 AM, Pavel Boldin wrote: > Here you go: https://launchpad.net/~pboldin/+archive/ubuntu/libvirt-python > > Use it, but please keep in mind that this is a draft reupload. > Thank you for your work. I'm sure a lot of people will benefit from it. Live migration is a majo

Re: [openstack-dev] [magnum] Document adding --memory option to create containers

Thanks Hongbin, for raising this for discussion. There is a middle ground that we can reach. We can collect a set of “best practices”, and place them together in a document. Some of them will be operational best practices for cloud operators, and some of them will be for end users. We can make c

[openstack-dev] [Security] Introducing Killick PKI

Hi All, At a previous OpenStack Security Project IRC meeting, we briefly discussed a lightweight traditional PKI using the Anchor validation functionality, for use in internal deployments, as an alternative to things like MS ADCS. To take this further, I have drafted a spec, which is in the sec

[openstack-dev] [Nova][Glance] Liberty RC2 available

Hello everyone, (Note: Those are the last of the release-candidate respins for common bugs and translations updates. In the coming week leading to final release, only major regressions or significant install/upgrade issues will trigger a release candidate respin.) Due to a number of release-criti

Re: [openstack-dev] [devstack] A few questions on configuring DevStack for Neutron

Please see my response here: http://lists.openstack.org/pipermail/openstack-dev/2015-October/076251.html In the future, do not create multiple threads since responses will get lost -- Sean M. Collins __ OpenStack Developmen

Re: [openstack-dev] Scheduler proposal

On Oct 8, 2015, at 8:01 AM, Thierry Carrez wrote: >> Operational overhead has a cost - maintaining 3 different database >> tools, backing them up, providing HA, etc. has operational cost. >> >> This is not to say that this cannot be overseen, but it should be taken >> into consideration. >> >>

Re: [openstack-dev] Scheduler proposal

On Oct 8, 2015, at 10:54 AM, Clint Byrum wrote: > ^^ THIS is the kind of architectural thinking I'd like to see us do more > of. Agreed. If nothing else, I'm glad that I was able to get people thinking about new approaches. > This isn't "hey I have a better database" it is "I have a way to red

Re: [openstack-dev] Scheduler proposal

On Oct 8, 2015, at 11:03 AM, Kevin L. Mitchell wrote: >> Theoretically if the DB knew about what resources were originally available >> and >> what resources have been consumed, then it should be able to allocate >> resources >> race-free (possibly with some retries involved if racing against

Re: [openstack-dev] Scheduler proposal

On Oct 8, 2015, at 10:24 AM, Joshua Harlow wrote: > Now if we imagine each/all schedulers having watches > on /nova/compute_nodes/ ([2] consul and etc.d have equivalent concepts > afaik) then when a compute_node updates that information a push > notification (the watch being triggered) will be

Re: [openstack-dev] Scheduler proposal

On Wed, 2015-10-07 at 23:17 -0600, Chris Friesen wrote: > Why is it inevitable? Well, I would say that this is probably a consequence of the CAP[1] theorem. > Theoretically if the DB knew about what resources were originally available > and > what resources have been consumed, then it should be

[openstack-dev] [magnum] Document adding --memory option to create containers

Hi team, I want to move the discussion in the review below to here, so that we can get more feedback https://review.openstack.org/#/c/232175/ In summary, magnum currently added support for specifying the memory size of containers. The specification of the memory size is optional, and the COE w

Re: [openstack-dev] Scheduler proposal

Excerpts from Joshua Harlow's message of 2015-10-08 08:38:57 -0700: > Joshua Harlow wrote: > > On Thu, 8 Oct 2015 10:43:01 -0400 > > Monty Taylor wrote: > > > >> On 10/08/2015 09:01 AM, Thierry Carrez wrote: > >>> Maish Saidel-Keesing wrote: > Operational overhead has a cost - maintaining 3 d

Re: [openstack-dev] We should move strutils.mask_password back into oslo-incubator

Excerpts from Matt Riedemann's message of 2015-10-07 14:38:07 -0500: > Here's why: > > https://review.openstack.org/#/c/220622/ > > That's marked as fixing an OSSA which means we'll have to backport the > fix in nova but it depends on a change to strutils.mask_password in > oslo.utils, which re

Re: [openstack-dev] Scheduler proposal

Joshua Harlow wrote: On Thu, 8 Oct 2015 10:43:01 -0400 Monty Taylor wrote: On 10/08/2015 09:01 AM, Thierry Carrez wrote: Maish Saidel-Keesing wrote: Operational overhead has a cost - maintaining 3 different database tools, backing them up, providing HA, etc. has operational cost. This is no

Re: [openstack-dev] Scheduler proposal

On Thu, 8 Oct 2015 10:43:01 -0400 Monty Taylor wrote: > On 10/08/2015 09:01 AM, Thierry Carrez wrote: > > Maish Saidel-Keesing wrote: > >> Operational overhead has a cost - maintaining 3 different database > >> tools, backing them up, providing HA, etc. has operational cost. > >> > >> This is not

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

No, I am in Reston, VA. —N. On Oct 8, 2015, at 11:06 AM, Edgar Magana mailto:edgar.mag...@workday.com>> wrote: Awesome Nate! Are you located in Philadelphia? Edgar From: "Johnston, Nate" Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Wednesday, October 7, 2015

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

I could try to allocate some time for this, I think it's deff worth the effort! El 08/10/15 a las 02:11, Edgar Magana escribió: > Hello, > > I would like to invite everybody to become an active contributor for > the OpenStack Networking > Guide: http://docs.openstack.org/networking-guide/ > > Duri

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

Awesome Nate! Are you located in Philadelphia? Edgar From: "Johnston, Nate" Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Wednesday, October 7, 2015 at 8:50 PM To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [OpenSt

[openstack-dev] [swift] Plan to port Swift to Python 3

Hi, Good news, we made good progress last weeks on porting Swift to Python 3, a few changes were merged and all dependencies now work on Python 3. We only need two more simple changes to have a working pyhon34 check job: * "py3: Update pbr and dnspython requirements" https://review.openstac

[openstack-dev] [tripleo] python-tripleoclient has unknown requirement

Current requirements job fails on python-tripleoclient with: 'ipaddress' is not in global-requirements.txt Could you get the requirement in global-requirements or replace it, please? Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX GmbH, Maxfeldstr.

Re: [openstack-dev] We should move strutils.mask_password back into oslo-incubator

> On 08 Oct 2015, at 16:51, Matt Riedemann wrote: > > > > On 10/8/2015 9:25 AM, Jeremy Stanley wrote: >> On 2015-10-08 08:58:06 -0500 (-0500), Matt Riedemann wrote: >> [...] >>> I don't know how many operators are tracking patch releases of >>> dependencies on stable branches unless there is a

Re: [openstack-dev] We should move strutils.mask_password back into oslo-incubator

On 10/8/2015 9:25 AM, Jeremy Stanley wrote: On 2015-10-08 08:58:06 -0500 (-0500), Matt Riedemann wrote: [...] I don't know how many operators are tracking patch releases of dependencies on stable branches unless there is a new minimum requirement on those, especially if they aren't getting the

Re: [openstack-dev] [openstack-ansible] Reviews needed: openstack-ansible-security

for us to try and own everything security-related. However, now you're asking for review I'll make sure this gets discussed at today's weekly Security meeting [r1] and hopefully we'll get some reviews flowing. [r1] https://etherpad.openstack.org/p/security-20151008-irc

Re: [openstack-dev] Scheduler proposal

On 10/08/2015 09:01 AM, Thierry Carrez wrote: Maish Saidel-Keesing wrote: Operational overhead has a cost - maintaining 3 different database tools, backing them up, providing HA, etc. has operational cost. This is not to say that this cannot be overseen, but it should be taken into consideratio

[openstack-dev] [openstack-ansible] Reviews needed: openstack-ansible-security

Hey folks, Now that the openstack-ansible-security role has been added to OpenStack, we're in need of some reviews[1]! Many of these reviews are fairly easy to do as they involve a task or two plus a small amount of documentation. Some reviews involve only documentation. You can refer to eac

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

Lucky me :) > On Oct 8, 2015, at 10:19 AM, Andreas Jaeger wrote: > > On 2015-10-08 16:07, John Belamaric wrote: >> I can write something up on the pluggable IPAM configuration for the >> Advanced Configuration section. How does the docs release schedule move >> in relation to the code release? I

Re: [openstack-dev] We should move strutils.mask_password back into oslo-incubator

On 2015-10-08 08:58:06 -0500 (-0500), Matt Riedemann wrote: [...] > I don't know how many operators are tracking patch releases of > dependencies on stable branches unless there is a new minimum > requirement on those, especially if they aren't getting their > updates from a distro provider. So whi

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

On 2015-10-08 16:07, John Belamaric wrote: I can write something up on the pluggable IPAM configuration for the Advanced Configuration section. How does the docs release schedule move in relation to the code release? I need an idea of when this needs to be done in order to make sure I'll have the

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

I can write something up on the pluggable IPAM configuration for the Advanced Configuration section. How does the docs release schedule move in relation to the code release? I need an idea of when this needs to be done in order to make sure I'll have the time. John On Oct 7, 2015, at 8:11 PM,

Re: [openstack-dev] [tc] naming N and O releases nowish

Monty - Thanks for the background, it brings a viewpoint I hadn't considered. >From a roadmap point of view, as we're working toward communicating the >direction for OpenStack project development across 3 releases (Liberty, >Mitake, N-Release), I think it would better to have a name for N, rathe

Re: [openstack-dev] We should move strutils.mask_password back into oslo-incubator

On 10/8/2015 4:21 AM, Julien Danjou wrote: On Wed, Oct 07 2015, Matt Riedemann wrote: 2. Backport the oslo.utils change to a stable branch, release it as a patch release, bump minimum required version in stable g-r and then backport the nova change and depend on the backported oslo.utils stab

Re: [openstack-dev] Fwd: [nova] live migration in Mitaka

Here you go: https://launchpad.net/~pboldin/+archive/ubuntu/libvirt-python Use it, but please keep in mind that this is a draft reupload. On Fri, Oct 2, 2015 at 11:38 PM, Mathieu Gagné wrote: > On 2015-10-02 4:18 PM, Pavel Boldin wrote: > > > > You have to pass device names from /dev/, e.g.

[openstack-dev] [TripleO] review priorities etherpad

At the TripleO meething this week, we talked about using an etherpad to help get some organization around reviews for the high priority themes in progress. I started on one: https://etherpad.openstack.org/p/tripleo-review-priorities And I subjectively added a few things :). Feel free to add more

[openstack-dev] [cloudkitty] Now that we are in the Big Tent what's the future?

Hi everyone, As you might have guessed based on the title CloudKitty is now part of the Big Tent. It's not new as the decision was taken one week ago, but some people might not be aware of this. Thanks to our Big Tent integration we are lucky enough to get two design summit slots. The first slot

Re: [openstack-dev] Scheduler proposal

Maish Saidel-Keesing wrote: > Operational overhead has a cost - maintaining 3 different database > tools, backing them up, providing HA, etc. has operational cost. > > This is not to say that this cannot be overseen, but it should be taken > into consideration. > > And *if* they can be consolidat

[openstack-dev] [neutron][testing][all] fixtures 1.4.0 breaking py34 jobs

Hi all, just a heads up that today fixtures 1.4.0 broke neutron py34 gate [1] and we needed to patch some logging code to overcome it [2]. The failures were triggered by a patch that started to raise logging exceptions for incorrect format strings (which is fine), but it also started to raise e

Re: [openstack-dev] [Openstack-operators] [cinder] [all] The future of Cinder API v1

Just to follow up, there was a discussion at the TC meeting on this, and given how close we are to summit we're proposing we have a cross project session there about it - http://odsreg.openstack.org/cfp/details/27 We'll try to get that scheduled in a way that it will not conflict with operator ses

Re: [openstack-dev] [Openstack-operators] Scheduler proposal

On 2015-10-08 00:37:31 -0700 (-0700), Clint Byrum wrote: > Excerpts from Maish Saidel-Keesing's message of 2015-10-08 00:14:55 -0700: [...] > > By adding in a new Database solution (Cassandra) we are now up to three > > different database solutions in use in OpenStack > > > > MySQL (practically ev

Re: [openstack-dev] [tc] naming N and O releases nowish

On 10/08/2015 06:59 AM, Daniel P. Berrange wrote: > On Wed, Oct 07, 2015 at 02:57:59PM +0200, Thierry Carrez wrote: >> Sean Dague wrote: >>> We're starting to make plans for the next cycle. Long term plans are >>> getting made for details that would happen in one or two cycles. >>> >>> As we alread

Re: [openstack-dev] [nova][mistral] Automatic evacuation as a long running task

Hi Matthew, Thanks for bringing some light on what problems has nova with evacuation of an instance. It is very important to have those limitations in mind when preparing final solution. Or to fix them, as you proposed. Nevertheless, I would say that evacuationD does more than what calling 'nov

[openstack-dev] [nova-compute][nova][libvirt] Extending Nova-Compute for image prefetching

Hi all, I'm considering to extend the Nova-Compute API in order to provide image-prefetching capabilities to OS. In order to allow image prefetching, I ended up with the need to add three different APIs on the nova-compute nodes: 1. Trigger an image prefetching 2. List prefetched images

[openstack-dev] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling

Hi, folks * Intro Per our discussion at Meeting #54 [0] I would like to propose the uniform approach of exception handling for all puppet-openstack providers accessing any types of OpenStack APIs. * Problem Description While working on Fuel during deployment of multi-node HA-aware environments

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

Hi- Count me too. - Trinath From: Edgar Magana [mailto:edgar.mag...@workday.com] Sent: Thursday, October 08, 2015 5:42 AM To: OpenStack Development Mailing List (not for usage questions) ; openstack-operat...@lists.openstack.org; openstack-d...@lists.openstack.org Subject: [openstack-dev] [Ope

Re: [openstack-dev] [tc] naming N and O releases nowish

On Wed, Oct 07, 2015 at 02:57:59PM +0200, Thierry Carrez wrote: > Sean Dague wrote: > > We're starting to make plans for the next cycle. Long term plans are > > getting made for details that would happen in one or two cycles. > > > > As we already have the locations for the N and O summits I think

Re: [openstack-dev] [openstack-doc-tools] [bashate] liberty rc releases

On 8 October 2015 at 11:51, Andreas Jaeger wrote: > On 2015-10-08 12:32, Dimitri John Ledkov wrote: >> >> Heya, >> >> Looks like openstack-doc-tools have staged updated pbr requirements in >> git tree, but there is no rc libery release for it? > > > Dimitri, > > We released openstack-doc-tools yes

Re: [openstack-dev] [openstack-doc-tools] [bashate] liberty rc releases

On 8 October 2015 at 11:32, Dimitri John Ledkov wrote: > Heya, > > Looks like openstack-doc-tools have staged updated pbr requirements in > git tree, but there is no rc libery release for it? > > Similarly bashate have old pbr global requirements, thus when > liberty's pbr is packaged with opensta

  1   2   >