Re: [openstack-dev] [nova] ram size and huge page number for VM

On 09/02/16 16:25, "Chris Friesen" wrote: >On 02/09/2016 04:20 AM, Daniel P. Berrange wrote: > >> It not actually a huge waste - in fact it is likely to be beneficial to the >> overall performance of your VM. You need to remember that there is no direct >>

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

On 02/09/2016 12:24 PM, McLellan, Steven wrote: From the list of versions that are there (https://pypi.python.org/simple/eventlet/), it appears that for a given major version only the most recent release is kept, so this will likely reoccur when/if 0.18.3 is released. Anybody know anybody in

[openstack-dev] [nova] nova gate blocked on eventlet release

It's eventlet release day! eventlet 0.18.2 has broken the nova unit tests at 'nova.tests.unit.test_wsgi.TestWSGIServerWithSSL' so the gate is blocked. sdague et al are working on it. Please hold off approving patches in nova until they get it resolved. -- Chris Dent

[openstack-dev] [neutron] - please review the neutron security guide

Hello all, This was briefly mentioned in the "What's up doc?" thread[1], but I wanted to highlight it with the neutron tag to get some more eyes on it. The security guide for Neutron has been around for a while and the security team would like to know if everything is still up to date and

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On Fri, 5 Feb 2016, Jim Meyer wrote: On Feb 5, 2016, at 9:54 AM, Tim Bell wrote: The scale could be defined on the basis of the survey data. The reference implementation should be able to address at least X% of deployments. I can think of at least one project which was not

[openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

Hey folks, One of the challenges we have faced with the ability to attach a single volume to multiple instances, is how to correctly detach that volume. The issue is a bit complex, but I'll try and explain the problem, and then describe one approach to solving one part of the detach

Re: [openstack-dev] [nova] nova gate blocked on eventlet release

On 2/9/2016 1:56 PM, Chris Dent wrote: It's eventlet release day! eventlet 0.18.2 has broken the nova unit tests at 'nova.tests.unit.test_wsgi.TestWSGIServerWithSSL' so the gate is blocked. sdague et al are working on it. Please hold off approving patches in nova until they get it resolved.

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

+1 On Tue, Feb 9, 2016 at 11:51 AM, Evgeniy L wrote: > +1 > > On Mon, Feb 8, 2016 at 7:58 PM, Vladimir Kozhukalov < > vkozhuka...@mirantis.com> wrote: > >> +1 to enable it ASAP. >> >> It will also affect our deployment tests (~1 hour vs. ~2.5 hours). >> >> Vladimir Kozhukalov

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

On 08.02.2016 17:05, Igor Kalnitsky wrote: > Hey Fuelers, > > When we are going to enable it? I think since HCF is passed for > stable/8.0, it's time to enable task-based deployment for master > branch. > > Opinion? This must be done for the 9.0, IMHO. > > - Igor > > On Wed, Feb 3, 2016 at

Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

I agree with the mtu setting because there isn't much of a downside to enabling it. However, the others do have reasons to be disabled. csum - requires runtime detection of support for a feature and then auto degradation for systems that don't support it. People were against those so we have the

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

+1 On Mon, Feb 8, 2016 at 7:58 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > +1 to enable it ASAP. > > It will also affect our deployment tests (~1 hour vs. ~2.5 hours). > > Vladimir Kozhukalov > > On Mon, Feb 8, 2016 at 7:35 PM, Bulat Gaifullin > wrote:

Re: [openstack-dev] Proposed Agenda for Kolla Midcycle

On Tue, Feb 9, 2016 at 6:58 AM, Steven Dake (stdake) wrote: > Hey folks, > > The agenda generation happened approximately a month ago over a 3 week > period, and then was voted on. I left the actual creation of the agenda > until today in case any last minute pressing issues

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

+1 On Tue, Feb 9, 2016 at 12:28 PM, Anastasia Urlapova wrote: > +1 > > On Tue, Feb 9, 2016 at 11:51 AM, Evgeniy L wrote: > >> +1 >> >> On Mon, Feb 8, 2016 at 7:58 PM, Vladimir Kozhukalov < >> vkozhuka...@mirantis.com> wrote: >> >>> +1 to enable it

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Well, I'm going to build a new ISO and run BVT. As soon as they are green, I'm going to approve the change. On Tue, Feb 9, 2016 at 12:32 PM, Bogdan Dobrelya wrote: > On 08.02.2016 17:05, Igor Kalnitsky wrote: >> Hey Fuelers, >> >> When we are going to enable it? I think

Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

Hi, > I'm generally sympathetic to what you're saying, and I agree that we > need to do something about disabled-by-default features, at the very > least on the testing front. Comments in-line. > > On Mon, Feb 8, 2016 at 4:47 PM, Sean M. Collins wrote: > > Hi, > > > > With the path_mtu

Re: [openstack-dev] [oslo.messaging] configurable ack-then-process (at least/most once) behavior

On 11.12.2015 12:06, Bogdan Dobrelya wrote: > Hello. > > On 02.12.2015 12:01, Bogdan Dobrelya wrote: >>> Bogdan, >>> >>> Which service would use this flag to start with? and how would the >>> code change to provide "app side is fully responsible for duplicates >>> handling"? >> >> (fixed topic

Re: [openstack-dev] [nova] ram size and huge page number for VM

On Mon, Feb 08, 2016 at 07:47:56PM +, Serguei Bezverkhi (sbezverk) wrote: > Hello, > > I using the latest Liberty and I am trying to bring up a VM with some numa > options configured using flavor. Specifically I need to give this VM 16GB > of RAM and in addition it will need to use 12x1GB

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Igor, We are going to run a swarm test today against the ISO with enabled task-based deployment, than check results and merge changes tomorrow. I've run BVT more than 100 times, it works, but I would like to check more deployment cases. And I guess it should be easy to troubleshoot if

[openstack-dev] [puppet] puppet-mistral backward incompatible change

puppet-mistral has no release and is still considered as experimental. I'm pushed a patch that will make the module consistent with other modules and make it compliant: https://review.openstack.org/#/c/277207/ This patch is everything but backward compatible, so please update your manifests if

Re: [openstack-dev] [nova] ram size and huge page number for VM

On 02/09/2016 04:20 AM, Daniel P. Berrange wrote: It not actually a huge waste - in fact it is likely to be beneficial to the overall performance of your VM. You need to remember that there is no direct relationship between allocation of huge pages to KVM and usage of huge pages inside the

[openstack-dev] [All][Packetary] Release 0.1.0

We are happy to announce that Packetary[0] 0.1.0 has been successfully released. New features: * The structured format of input data (JSON or YAML). * DEB and RPM repositories building. Fixed bugs: * https://bugs.launchpad.net/packetary/+bug/1539703 [0]

[openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Hi, TripleO is currently using puppet-pacemaker [1] which is a module hosted & managed by Github. The module was created and mainly maintained by Redhat. It tends to break TripleO quite often since we don't have any gate. I propose to move the module to OpenStack so we'll use OpenStack Infra

Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard

Cannot we use display the same link we use in the title? > 9 лют. 2016 р. о 14:14 Vitaly Kramskikh написав(ла): > > Hi, Roman, > > I think the only solution here is to underline the title so it would look > like a link. I don't think it's a good idea to show full URL

[openstack-dev] [Nova][Live Migration] Live migration IRC meeting today

Hi All, Forgot to hit "save" on agenda yesterday - the agenda is up. Speak to you later. Paul Paul Murray Technical Lead, HPE Cloud Hewlett Packard Enterprise +44 117 316 2527 __ OpenStack Development Mailing List (not

[openstack-dev] Midcycle today and tomorrow

Reminder, The kolla midcycle begins today at 10:00 AM but breakfast will be available (bagels, coffee) at 9:00 AM. This is an opportunity for folks to visit with other community members and get brain juices flowing :) Tomorrow we are starting pretty early, with breakfast at 9:00 AM and first

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

> I've run BVT more than 100 times, it works, You run it some time ago. There were a lot of opportunities to introduce regression in both Nailgun and tasks of Fuel Library. ;) > We are going to run a swarm test today against the ISO with enabled > task-based deployment So there will be a

[openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard

Hi fuelers! I’m not sure, if it’s my personal problem or the UX can be improved a little, but I’ve literary spend more than 5 minutes trying to figure out how to find a URL of Horizon. I’ve made a screenshot [1] and I suggest to add a full a link with the full URL in its test after "The

[openstack-dev] [release] Mitaka final release process

Hi everyone, We are less than two months away from the final release date for "Mitaka". Most of the release process is now driven by the openstack/releases repository, and we have taken a much less aggressive approach to driving the release cycle. But there are still a number of things the

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 08/02/16 10:52 -0800, Mike Perez wrote: On 13:56 Feb 08, Flavio Percoco wrote: On 08/02/16 09:24 -0500, Sean Dague wrote: >On 02/08/2016 08:54 AM, Flavio Percoco wrote: > >>Would our votes change if Poppy had support for OpenCDN (imagine it's being >>maintained) even if that solution is

[openstack-dev] [neutron][stable] Request to do stable point releases more often if there are going to be a lot of backports

While reviewing the neutron 7.0.2 stable/liberty point release, I noticed there were a lot of changes since 7.0.1. [1] There are 48 non-merge commits by my count. While there is no rule about how many backports should land before we cut a point release, it would be helpful on reviewers for

Re: [openstack-dev] [puppet] weekly meeting #69

penstack.org/p/puppet-openstack-weekly-meeting-20160209 > > We'll also have open discussion for bugs & reviews, so anyone is welcome > to join. > > See you there, We did our meeting and you can read the notes here: http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet

[openstack-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?

Hi all! To run system tests on CI on a daily basis using baremetal servers instead of VMs, Fuel admin node also should be bootstrapped. There is no a simple way to mount an ISO with Fuel as a CDROM or USB device to a baremetal server, so we choose the provisioning with PXE. It could be done in

[openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

For the sake of completeness: The eventlet package version 0.18.1 seems to be disappeared from the PyPi servers, which is a bad thing, as we use that version in the "upper-constraints.txt" of the requirements project. There is patch [1] in the queue which solves that. Until this is merged, there

[openstack-dev] [watcher] weekly meeting agenda

Hi Watcher team, Here is the agenda for our weekly meeting, on Wednesday at 1400 UTC on #openstack-meeting-4 [1] Feel free to add any items you'd like to discuss. Thanks, Antoine [1] https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda#02.2F10.2F2016

Re: [openstack-dev] [lbaas][octavia] Security/networking questions

All, Some more color on (3) our plan was to allow for multiple management nets (and I was advocating strongly for that) but that somehow got lost in the implementation. For (2) we are still working on our operator API which will include that functionality once we get there :-) German On

[openstack-dev] [keystone] Usage of trusts with v2.0 authentication

When trusts were implemented, they were designed to work as an extension under the version 3 API. The implementation didn't prevent the use of a trust to authenticate against version 2.0, which was never officially documented in the v2.0 API docs. The keystone team is curious if there is anyone

Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard

+1 to Vitaly. There can be many links, so just underline those we already have is the best option. On Tue, Feb 9, 2016 at 4:31 PM, Roman Prykhodchenko wrote: > Cannot we use display the same link we use in the title? > > 9 лют. 2016 р. о 14:14 Vitaly Kramskikh

Re: [openstack-dev] [keystone] Usage of trusts with v2.0 authentication

On 02/09/2016 12:06 PM, Lance Bragstad wrote: The keystone team is curious if there is anyone creating trusts using v3 and then using them against version 2.0. If not, we'd like to remove/deprecate support for that case in v2.0. If so, then we'll have to add official documentation for trusts

Re: [openstack-dev] [Openstack-operators] [keystone] Usage of trusts with v2.0 authentication

They were used indirectly I think when you had some services configured for v2 only authentication support because the service didn't work with v2. For example nova->neutron was v2 only for a while. I think all services are supporting v3 these days so that would no longer be necessary? Thanks,

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

On 02/09/2016 02:04 PM, Ildikó Váncsa wrote: Hi Walt, Thanks for starting this thread. It is a good summary of the issue and the proposal also looks feasible to me. I have a quick, hopefully not too wild idea based on the earlier discussions we had. We were considering earlier to store the

[openstack-dev] [app-catalog] IRC Meeting Thursday February 11th at 17:00UTC

Join us Thursday for our weekly meeting, scheduled for February 11th at 17:00UTC in #openstack-meeting-3 The agenda can be found here, and please add to if you want to get something on the agenda: https://wiki.openstack.org/wiki/Meetings/app-catalog Looking forward to seeing all interested

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

On 02/09/2016 08:05 AM, Emilien Macchi wrote: > Hi, > > TripleO is currently using puppet-pacemaker [1] which is a module hosted > & managed by Github. > The module was created and mainly maintained by Redhat. It tends to > break TripleO quite often since we don't have any gate. > > I propose to

Re: [openstack-dev] [release][oslo] oslo.privsep-announce-release 1.0.0 release (mitaka)

I like the idea of this library. It should be very useful but... I think we need to [1] merged soon and get one more release. [1] get https://review.openstack.org/#/c/277957/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Feb 9, 2016 at 8:56 PM, wrote: > We

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Monty, I asked for details and got a response here: https://github.com/eventlet/eventlet/commit/5bf0a6f32b3e4459b38ad1895c9eb4b0b483dae1#commitcomment-15987613 -- Dims On Tue, Feb 9, 2016 at 2:05 PM, Monty Taylor wrote: > On 02/09/2016 12:24 PM, McLellan, Steven wrote: >>

Re: [openstack-dev] [neutron][stable] Request to do stable point releases more often if there are going to be a lot of backports

On Tue, Feb 9, 2016 at 5:10 PM, Matt Riedemann wrote: > While reviewing the neutron 7.0.2 stable/liberty point release, I noticed > there were a lot of changes since 7.0.1. [1] > > There are 48 non-merge commits by my count. > > While there is no rule about how many

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

Hi Walt, > -Original Message- > From: Walter A. Boring IV [mailto:walter.bor...@hpe.com] > Sent: February 09, 2016 23:15 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to > call os-brick's connector.disconnect_volume >

Re: [openstack-dev] [openstack-announce] [release][stable][horizon] horizon release 8.0.1 (liberty)

Excerpts from Alan Pevec's message of 2016-02-08 23:30:53 +0100: > > With package available at: > > > > https://pypi.python.org/pypi/horizon > > AFAICT non-client/non-oslo stable point releases are NOT uploaded to > pypi, are they? > e.g. last horizon on pypi is version 2012.2 > Should we

Re: [openstack-dev] [neutron] - please review the neutron security guide

Kevin Benton wrote: > Hello all, > > This was briefly mentioned in the "What's up doc?" thread[1], but I wanted > to highlight it with the neutron tag to get some more eyes on it. The > security guide for Neutron has been around for a while and the security > team would like to know if everything

Re: [openstack-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?

Unless we hope to gain some insight and specific testing by installing the ISO on a bare-metal node (like UEFI), I'd propose that we stop testing things that are well tested elsewhere (a given ISO produces a working fuel master) and just focus on what we want to test in this environment. Along

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Folks It seems that docker removal spoilt our celebration a bit. Here is a bug link https://bugs.launchpad.net/fuel/+bug/1543720 . Fix is trivial, but will postpone swarm run for another day. Nevertheless, it seems to be the only issue affecting our ability to use TBD. Stay tuned! On Tue, Feb

[openstack-dev] [release][oslo] oslo.privsep-announce-release 1.0.0 release (mitaka)

We are psyched to announce the release of: oslo.privsep-announce-release 1.0.0: OpenStack library for privilege separation This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.privsep With package available at:

Re: [openstack-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?

Hi, Ironic also supports running it as standalone service, w/o Keystone/Glance/Neutron/Nova etc integration, deploying images from HTTP links. Could that be an option too? BTW, there is already an official project under OpenStack Baremetal program called Bifrost [0] that, quoting, "automates the

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

>From the list of versions that are there (https://pypi.python.org/simple/eventlet/), it appears that for a given major version only the most recent release is kept, so this will likely reoccur when/if 0.18.3 is released. Steve On 2/9/16, 10:44 AM, "Markus Zoeller" wrote:

[openstack-dev] Gerrit downtime on Friday 2016-02-12 at 22:00 UTC

Hi everyone, On Friday, February 12th at 22:00 UTC Gerrit will be unavailable for about 60 minutes while we rename some projects. Existing reviews, project watches, etc, should all be carried over. Currently, we plan on renaming the following projects: openstack/ceilometer-specs ->

[openstack-dev] [release][oslo] oslo.policy-announce-release 1.4.0 release (mitaka)

We are thrilled to announce the release of: oslo.policy-announce-release 1.4.0: Oslo Policy library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.policy Please report issues through launchpad:

[openstack-dev] [release][oslo] oslo.middleware-announce-release 3.6.0 release (mitaka)

We are stoked to announce the release of: oslo.middleware-announce-release 3.6.0: Oslo Middleware library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.middleware Please report issues through launchpad:

[openstack-dev] [release][oslo] oslo.i18n-announce-release 3.3.0 release (mitaka)

We are pleased to announce the release of: oslo.i18n-announce-release 3.3.0: Oslo i18n library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.i18n Please report issues through launchpad:

[openstack-dev] [release][oslo] oslo.messaging-announce-release 4.2.0 release (mitaka)

We are excited to announce the release of: oslo.messaging-announce-release 4.2.0: Oslo Messaging API This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.messaging Please report issues through launchpad:

[openstack-dev] [release][oslo] oslo.vmware-announce-release 2.3.0 release (mitaka)

We are stoked to announce the release of: oslo.vmware-announce-release 2.3.0: Oslo VMware library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware Please report issues through launchpad:

[openstack-dev] [qa] Tempest removal of tempest.api.compute.test_authorization

As proposed in this patch - https://review.openstack.org/#/c/271467/ These tests do some manipulation of the request URI to attempt to request Nova resources owned by a different project_id. However they all basically test the same 7 lines of Nova, and now that Nova doesn't require project_id in

[openstack-dev] [release][oslo] oslo.log-announce-release 2.4.0 release (mitaka)

We are jubilant to announce the release of: oslo.log-announce-release 2.4.0: oslo.log library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.log Please report issues through launchpad:

[openstack-dev] [release][oslo] oslo.cache-announce-release 1.3.0 release (mitaka)

We are amped to announce the release of: oslo.cache-announce-release 1.3.0: Cache storage for Openstack projects. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.cache Please report issues through launchpad:

[openstack-dev] [release][oslo] futurist-announce-release 0.11.0 release (mitaka)

We are pleased to announce the release of: futurist-announce-release 0.11.0: Useful additions to futures, from the future. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/futurist Please report issues through launchpad:

[openstack-dev] [release][oslo] mox3-announce-release 0.14.0 release (mitaka)

We are psyched to announce the release of: mox3-announce-release 0.14.0: Mock object framework for Python This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/mox3 Please report issues through launchpad:

[openstack-dev] [release][oslo] oslosphinx-announce-release 4.3.0 release (mitaka)

We are thrilled to announce the release of: oslosphinx-announce-release 4.3.0: OpenStack Sphinx Extensions and Theme This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslosphinx Please report issues through launchpad:

[openstack-dev] [release][oslo] oslotest-announce-release 2.1.0 release (mitaka)

We are overjoyed to announce the release of: oslotest-announce-release 2.1.0: Oslo test framework This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslotest Please report issues through launchpad:

[openstack-dev] [release][oslo] stevedore-announce-release 1.11.0 release (mitaka)

We are gleeful to announce the release of: stevedore-announce-release 1.11.0: Manage dynamic plugins for Python applications This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/stevedore Please report issues through

[openstack-dev] [release][oslo] taskflow-announce-release 1.27.0 release (mitaka)

We are tickled pink to announce the release of: taskflow-announce-release 1.27.0: Taskflow structured state management library. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/taskflow Please report issues through

[openstack-dev] [release][oslo] oslo.rootwrap-announce-release 3.2.0 release (mitaka)

We are tickled pink to announce the release of: oslo.rootwrap-announce-release 3.2.0: Oslo Rootwrap This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.rootwrap Please report issues through launchpad:

[openstack-dev] [release][oslo] oslo.serialization-announce-release 2.3.0 release (mitaka)

We are gleeful to announce the release of: oslo.serialization-announce-release 2.3.0: Oslo Serialization library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.serialization Please report issues through launchpad:

[openstack-dev] [release][oslo] oslo.db 4.4.0 release (mitaka)

We are glad to announce the release of: oslo.db 4.4.0: Oslo Database library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.db With package available at: https://pypi.python.org/pypi/oslo.db Please report

[openstack-dev] [release][oslo] oslo.service-announce-release 1.4.0 release (mitaka)

We are glad to announce the release of: oslo.service-announce-release 1.4.0: oslo.service library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.service Please report issues through launchpad:

Re: [openstack-dev] [OpenStack-Infra] Mitaka Infra Sprint

On Wed, Dec 9, 2015 at 9:17 PM, Joshua Hesketh wrote: > Hi all, > As discussed during the infra-meeting on Tuesday, the infra team will be > holding a mid-cycle sprint to focus on infra-cloud. Some of this was covered at our meeting today[0] but I wanted to repeat and

[openstack-dev] [release][oslo] debtcollector-announce-release 1.3.0 release (mitaka)

We are content to announce the release of: debtcollector-announce-release 1.3.0: A collection of Python deprecation patterns and strategies that help you collect your technical debt in a non-destructive manner. This release is part of the mitaka release series. With source available at:

[openstack-dev] [release][oslo] automaton-announce-release 1.2.0 release (mitaka)

We are glad to announce the release of: automaton-announce-release 1.2.0: Friendly state machines for python. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/automaton Please report issues through launchpad:

[openstack-dev] [release][oslo] oslo.utils-announce-release 3.5.0 release (mitaka)

We are stoked to announce the release of: oslo.utils-announce-release 3.5.0: Oslo Utility library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.utils Please report issues through launchpad:

[openstack-dev] [release][oslo] oslo.versionedobjects-announce-release 1.5.0 release (mitaka)

We are overjoyed to announce the release of: oslo.versionedobjects-announce-release 1.5.0: Oslo Versioned Objects library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.versionedobjects Please report issues through

[openstack-dev] [designate] : Facing issue in automatically creating designate records when Nova instance gets created

Hi All, I am able to create manual designate records by using- designate record-create 3e21787f-8814-4327-9071-0bfdf840be70 --type MX --priority 10 --name rc.edu.au. --data mail.rc.edu.au I am facing issue in automatically creating the records using nova notifications. Kindly provide help

Re: [openstack-dev] [neutron][stable] Request to do stable point releases more often if there are going to be a lot of backports

On Tue, Feb 9, 2016 at 10:10 AM, Matt Riedemann wrote: > While reviewing the neutron 7.0.2 stable/liberty point release, I noticed > there were a lot of changes since 7.0.1. [1] > > There are 48 non-merge commits by my count. > > While there is no rule about how many

Re: [openstack-dev] [keystone] Usage of trusts with v2.0 authentication

On Tue, Feb 09, 2016 at 11:06:10AM -0600, Lance Bragstad wrote: >When trusts were implemented, they were designed to work as an extension >under the version 3 API. The implementation didn't prevent the use of a >trust to authenticate against version 2.0, which was never officially >

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

> On Feb 5, 2016, at 9:54 AM, Tim Bell wrote: > > ... > >> On "production-grade": >> >> I'd be (strongly) in favor of defining a target deployment configuration and >> size which we find representative of the minimum bar for "production-grade." >> Anything less concrete