Re: [openstack-dev] [nova][neutron] New BP for live migration with direct pci passthru

Hi, Fawad, > Can you please share the link? https://blueprints.launchpad.net/nova/+spec/direct-pci-passthrough-live-migration Thanks in advance. Best regards, xiexs From: Fawad Khaliq [mailto:fa...@plumgrid.com] Sent: Tuesday, February 16, 2016 1:19 PM To: OpenStack Development Mailing List

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

Thomas Goirand wrote: > Oh, that, and ... not using CassandraDB. And yes, this thread is a good > place to have this topic. I'm not sure who replied to me this thread > wasn't the place to discuss it: I respectfully disagree, since it's > another major blocker, IMO as important, if not more, as

[openstack-dev] [vitrage] Vitrage meeting tomorrow

Hi, We will have Vitrage weekly meeting tomorrow, Wednesday at 9:00 UTC, on #openstack-meeting-3 channel. Agenda: * Current status and progress * Review action items * Next steps * Open Discussion You are welcome to join. Thanks, Ifat.

Re: [openstack-dev] [Neutron] Integrating physical appliance into virtual infrastructure

On Mon, Feb 1, 2016 at 10:00 PM, Vijay Venkatachalam < vijay.venkatacha...@citrix.com> wrote: > > > L2GW seems like a good option for bridging/linking /integrating physical > appliances which does not support overlay technology (say VXLAN) natively. > > > > In my case the physical appliance

[openstack-dev] [neutron][taas] l2 gateway in OpenStack

Hi TaaS folks, As discussed in the last IRC meeting, here is some information on l2-gateway that might be useful. The project resides here [1]. There was a Neutron lightning talk at Paris summit [2] and another detailed session at Vancouver [3]. I hope this will help understand how l2 gateway

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

On Mon, Feb 15, 2016 at 1:02 PM, Clark Boylan wrote: > On Mon, Feb 15, 2016, at 11:48 AM, Ivan Kolodyazhny wrote: > > Hi all, > > > > I'll talk mostly about python-cinderclient but the same question could be > > related for other clients. > > > > Now, for

Re: [openstack-dev] [Swift] Erasure coding and geo replication

On 16/02/16 17:10, Mark Kirkwood wrote: On 15/02/16 23:29, Kota TSUYUZAKI wrote: Hello Mark, AFAIK, a few reasons for that we still are in working progress for erasure code + geo replication. and expect to survive a region outage... With that I mind I did some experiments (Liberty swift)

Re: [openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

File a bug. https://bugs.launchpad.net/openstack-api-site/+bug/1545922 Anne, Alex, and Ghanshyam Mann, Can this be raised in the API meeting for discussion? I'm very care my patch: https://review.openstack.org/#/c/258771/12/nova/api/openstack/compute/server_migrations.py Should I allow it as

Re: [openstack-dev] [Swift] Erasure coding and geo replication

On 15/02/16 23:29, Kota TSUYUZAKI wrote: Hello Mark, AFAIK, a few reasons for that we still are in working progress for erasure code + geo replication. and expect to survive a region outage... With that I mind I did some experiments (Liberty swift) and it looks to me like if you have: -

[openstack-dev] [Infra] Meeting Tuesday February 16th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday February 16th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting Anyone is welcome to to add

Re: [openstack-dev] [Nova] Should we signal backwards incompatible changes in microversions?

2016-02-16 9:47 GMT+08:00 GHANSHYAM MANN : > Regards > Ghanshyam Mann > > > On Mon, Feb 15, 2016 at 12:07 PM, Alex Xu wrote: > > If we support 2.x.y, when we bump 'x' is a problem. We didn't order the > API > > changes for now, the version of API change

Re: [openstack-dev] [magnum]swarm + compose = k8s?

I think master nodes should be controlled by Magnum, so that we can do the operation work for users. AWS and GCE use the mode. And master nodes are resource-consuming. If master nodes are not controlled by users, we can do some optimization to reduce the cost which is invisible to users. For

Re: [openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

Yes, currently Nova support that for show/update/delete server APIs etc (both v2 and v2.1) and python-novaclient too. But I think that was old behaviour and for ec2 API mainly? I searched on ec2 repo [1] and they get the instance from nova using UUID, i did not find any place they are fetching

Re: [openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

I don't think our API supports get servers by DB index is good idea. So I prefer we remove it in the future with microversions. But for now, yes, it is here. 2016-02-16 8:03 GMT+08:00 少合冯 : > I guess others may ask the same questions. > > I read the nova API doc: > such as

Re: [openstack-dev] [nova][all] Deprecation policy between projects

On 14/02/2016 8:32 AM, Ken'ichi Ohmichi wrote: > Hi, > > Do we have any deprecation policies between projects? > When we can remove old drivers of the other projects after they were > marked as deprecated? > In nova, there are many drivers for the other projects and there are > patches which

Re: [openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

On Mon, Feb 15, 2016 at 6:03 PM, 少合冯 wrote: > I guess others may ask the same questions. > > I read the nova API doc: > such as this API: > http://developer.openstack.org/api-ref-compute-v2.1.html#showServer > > GET /v2.1/​{tenant_id}​/servers/​{server_id}​ > *Show server

[openstack-dev] [release][oslo] tooz 1.31.0 release (mitaka)

We are stoked to announce the release of: tooz 1.31.0: Coordination library for distributed systems. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/tooz With package available at: https://pypi.python.org/pypi/tooz

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

We are pumped to announce the release of: oslo.messaging 4.3.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 With package available at:

[openstack-dev] [release][oslo] taskflow 1.28.0 release (mitaka)

We are pleased to announce the release of: taskflow 1.28.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 With package available at:

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

We are pleased to announce the release of: oslo.versionedobjects 1.6.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 With package available at:

[openstack-dev] [release][oslo] osprofiler 1.1.0 release (mitaka)

We are happy to announce the release of: osprofiler 1.1.0: OpenStack Profiler Library This release is part of the mitaka release series. With package available at: https://pypi.python.org/pypi/osprofiler For more details, please see below. Changes in osprofiler 1.0.1..1.1.0

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

We are stoked to announce the release of: oslo.vmware 2.4.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 With package available at: https://pypi.python.org/pypi/oslo.vmware

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

We are satisfied to announce the release of: oslo.utils 3.6.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 With package available at: https://pypi.python.org/pypi/oslo.utils

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

We are amped to announce the release of: oslo.rootwrap 4.0.0: Oslo Rootwrap This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.rootwrap With package available at: https://pypi.python.org/pypi/oslo.rootwrap Please

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

We are pleased to announce the release of: oslo.service 1.5.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 With package available at: https://pypi.python.org/pypi/oslo.service

[openstack-dev] [release][oslo] oslo.config 3.7.0 release (mitaka)

We are jazzed to announce the release of: oslo.config 3.7.0: Oslo Configuration API This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.config With package available at: https://pypi.python.org/pypi/oslo.config

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

We are jubilant to announce the release of: oslo.reports 1.5.0: oslo.reports library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.reports With package available at: https://pypi.python.org/pypi/oslo.reports

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

We are content to announce the release of: oslo.log 3.0.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 With package available at: https://pypi.python.org/pypi/oslo.log Please report

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

We are thrilled to announce the release of: oslo.privsep 1.1.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:

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

We are glad to announce the release of: oslo.db 4.5.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] futurist 0.12.0 release (mitaka)

We are delighted to announce the release of: futurist 0.12.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 With package available at:

Re: [openstack-dev] [Nova] Should we signal backwards incompatible changes in microversions?

Regards Ghanshyam Mann On Mon, Feb 15, 2016 at 12:07 PM, Alex Xu wrote: > If we support 2.x.y, when we bump 'x' is a problem. We didn't order the API > changes for now, the version of API change is just based on the order of > patch merge. For support 2.x.y, we need bump 'y'

[openstack-dev] [tricircle] weekly meeting of Feb.17th

Hi, After the Chinese new year festival, let's resume the weekly meeting, and agenda as following. Agenda: # Progress of To-do list review: https://etherpad.openstack.org/p/TricircleToDo # SEG # Quota management # exception logging, flavor mapping # Pod scheduling # L2 networking across pods

[openstack-dev] [OpenStack-Ansible] Meetings this week

Hi everyone, Due to being active at the Ops Mid Cycle, the OpenStack-Ansible Mid Cycle and Ansiblefest this week the bug triage and community meetings this week will not be taking place. We'll resume the normal scheduled meetings next week. Thanks, Jesse IRC: odyssey4me

[openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

I guess others may ask the same questions. I read the nova API doc: such as this API: http://developer.openstack.org/api-ref-compute-v2.1.html#showServer GET /v2.1/​{tenant_id}​/servers/​{server_id}​ *Show server details* *Request parameters* ParameterStyleTypeDescription tenant_id URI

Re: [openstack-dev] [TripleO] Stable branch policy for Mitaka

I like any formal documented process. Having only bug fixes for stable releases is a good and consistent stand. But we are bumping into fundamental issue of integrated release. By the time release comes out the new functionality of nova, or neutron or most other components do not triple heat

Re: [openstack-dev] [Nova][Glance]Glance v2 api support in Nova

On 12/02/16 18:24 +0300, Mikhail Fedosin wrote: Hello! In late December I wrote several messages about glance v2 support in Nova and Nova's xen plugin. Many things have been done after that and now I'm happy to announce that there we have a set of commits that makes Nova fully v2 compatible

Re: [openstack-dev] Proposal: Separate design summits from OpenStack conferences

I think this will be very detrimental to development community. The best feedback we get is from user/customer community that are at the summit but most likely will not attend separate design summit. I will ignore financial implication of 2 separate summits. -Original Message- From:

Re: [openstack-dev] [all][requirements] Why do we use pip install -U as our install_command

On 11 February 2016 at 16:09, Clark Boylan wrote: > The reason that I remember off the top of my head is because we spent > far too much time telling people to run `tox -r` when their code failed > during Jenkins testing but ran just fine locally. It removes a > significant

[openstack-dev] Reminder/request for cross-project stable CPLs to be in #openstack-stable IRC

This came up in today's stable team meeting, but cross-project liaisons for stable branches [1] should be available in the #openstack-stable IRC channel. By default if a project doesn't have a stable CPL, then the PTL is the rep. This is more or less just to improve communication between the

Re: [openstack-dev] [TripleO] Thoughts about the relationship between RDO and TripleO

On 02/15/2016 02:50 PM, James Slagle wrote: > On Mon, Feb 15, 2016 at 2:05 PM, John Trowbridge wrote: >> Howdy, >> >> The spec to replace instack-virt-setup[1] got me thinking about the >> relationship between RDO and TripleO. Specifically, when thinking about >> where to

Re: [openstack-dev] [puppet] Push Mitaka beta tag

On 02/15/2016 01:16 PM, David Moreau Simard wrote: > So is it implied that a version "8.0.0b1" of a puppet module works > with the "8.0.0b1" of it's parent project ? No, releases are not synced with OpenStack projects. The only thing we currently guarantee is that 8.0.0b1 will work with what

Re: [openstack-dev] [ironic] Baremetal Deploy Ramdisk functional testing

On Mon, Feb 15, 2016 at 01:48:11PM +0200, Maksym Lobur wrote: > Re-sending with Ironic stamp… Folks, please see below: Hi, I meant to reply to this earlier, but didn't get to it, sorry for that. > > > > > Hi All, > > > > In bareon [1] we have test framework to test deploy ramdsik with bareon

Re: [openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

+1 He is a great addition to the Barbican community. -Nate On Mon, Feb 15, 2016 at 1:34 PM, Dave McCowan (dmccowan) wrote: > +1 > > On 2/15/16, 12:45 PM, "Douglas Mendizábal" > wrote: > >>-BEGIN PGP SIGNED MESSAGE- >>Hash: SHA512

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

Douglas, Which means we should make sure pysaml2 and paramiko do switch to the " pyca/cryptography" ASAP. However, what do we do in the mean time? -- Dims On Mon, Feb 15, 2016 at 1:30 PM, Douglas Mendizábal wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash:

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

On Mon, Feb 15, 2016, at 11:48 AM, Ivan Kolodyazhny wrote: > Hi all, > > I'll talk mostly about python-cinderclient but the same question could be > related for other clients. > > Now, for python-cinderclient we've got to kinds for functional/integrated > jobs: > > 1)

Re: [openstack-dev] Google Sumer of Code 2016 - Call for ideas and mentors (deadline 19/02/2016)

Friendly reminder, we are still looking for mentors and internship ideas. Join us [0] and submit your internship project ideas in [1]. The deadline for our application as mentoring organization is 19/02/2016 [0] https://wiki.openstack.org/wiki/GSoC2016 [1]

Re: [openstack-dev] [TripleO] Thoughts about the relationship between RDO and TripleO

On Mon, Feb 15, 2016 at 2:05 PM, John Trowbridge wrote: > Howdy, > > The spec to replace instack-virt-setup[1] got me thinking about the > relationship between RDO and TripleO. Specifically, when thinking about > where to store/create an undercloud.qcow2 image, and if this

[openstack-dev] [cinder][all] Integration python-*client tests on gates

Hi all, I'll talk mostly about python-cinderclient but the same question could be related for other clients. Now, for python-cinderclient we've got to kinds for functional/integrated jobs: 1) gate-cinderclient-dsvm-functional - a very limited (for now) set of functional tests, most of them were

[openstack-dev] [TripleO] Thoughts about the relationship between RDO and TripleO

Howdy, The spec to replace instack-virt-setup[1] got me thinking about the relationship between RDO and TripleO. Specifically, when thinking about where to store/create an undercloud.qcow2 image, and if this effort is worth duplicating. Originally, I agreed with the comments on the spec wrt the

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

Aleksey, great news! On Mon, Feb 15, 2016 at 7:36 PM, Alexey Shtokolov wrote: > Fuelers, > > Task based deployment engine has been enabled in master (Fuel 9.0) by > default [0] > > [0] - https://review.openstack.org/#/c/273693/ > > WBR, Alexey Shtokolov > > 2016-02-09

Re: [openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

+1 On 2/15/16, 12:45 PM, "Douglas Mendizábal" wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA512 > >Hi All, > >I would like to nominate Fernando Diaz for the Barbican Core team. >Fernando has been an enthusiastic contributor since joining the >Barbican

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 One more thing: I forgot to point out that pyca/cryptography is already part of global-requirements. [1] - - Douglas Mendizábal [1] http://git.openstack.org/cgit/openstack/requirements/tree/global-require ments.txt#n25 On 2/15/16 12:24 PM,

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I had not previously heard of pycryptodome. Is this supposed to be a drop-in replacement for pycrypto? If so then it sounds like they're doing a terrible job of it. The plan for Barbican has been to wait for pyca/cryptography [1] to add support

Re: [openstack-dev] [puppet] Push Mitaka beta tag

So is it implied that a version "8.0.0b1" of a puppet module works with the "8.0.0b1" of it's parent project ? This has some implications, it means there are expectations that puppet-openstack is able to keep up with upstream changes throughout the cycle. We've gotten pretty good at following

Re: [openstack-dev] [puppet] Push Mitaka beta tag

Emilien, More tags like this cannot hurt, it makes it easier to follow things, thanks for doing this. On Mon, Feb 15, 2016 at 9:13 AM, Emilien Macchi wrote: > Hi, > > While Puppet modules releases are independently managed, we have some > requests from both RDO & Debian

Re: [openstack-dev] [magnum]swarm + compose = k8s?

Regarding to the COE mode, it seems there are three options: 1. Place both master nodes and worker nodes to user’s tenant (current implementation). 2. Place only worker nodes to user’s tenant. 3. Hide both master nodes and worker nodes from user’s tenant. Frankly, I don’t

Re: [openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

+1 ! On Mon, Feb 15, 2016 at 7:45 PM, Douglas Mendizábal < douglas.mendiza...@rackspace.com> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi All, > > I would like to nominate Fernando Diaz for the Barbican Core team. > Fernando has been an enthusiastic contributor since joining

[openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi All, I would like to nominate Fernando Diaz for the Barbican Core team. Fernando has been an enthusiastic contributor since joining the Barbican team. He is currently the most active non-core reviewer on Barbican projects for the last 90 days.

Re: [openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

Great article Andreas!   For angular translation to work, you'll need to reference https://github.com/openstack/horizon/blob/master/horizon/utils/babel_extract_angular.py which the guide already covers.   To use it, see https://angular-gettext.rocketeer.be/dev-guide/annotate/ for examples.    

[openstack-dev] [cross-project] Meeting, Tue February 16th, 21:00 UTC

Hi all, We will be having a meeting tomorrow February 16th at 21:00 UTC in the #openstack-meeting-cp channel. * Team announcements (horizontal, vertical, diagonal) * A Common Policy Scenario Across All Projects [1] * Support for 4-byte unicode for naming volume, snapshot, instance etc.(sheel,

Re: [openstack-dev] [neutron] Mitaka Mid-Cycle Coding Sprint Registration

On Mon, Feb 15, 2016 at 10:33 AM, Anita Kuno wrote: > On 02/15/2016 04:06 PM, Kyle Mestery wrote: >> Hi folks! >> >> The mid-cycle is almost upon us. IBM, as the sponsor company, is >> requesting some information from everyone is registered (name, email, >> company, US

[openstack-dev] [mistral] Mistral team meeting minutes

Thank you for attending the meeting today! Next meeting is scheduled on 22 Feb. It is non-working day in Russia so Renat, Anastasia and I very likely won't come to the meeting. Minutes: http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-02-15-16.00.html Log:

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

Fuelers, Task based deployment engine has been enabled in master (Fuel 9.0) by default [0] [0] - https://review.openstack.org/#/c/273693/ WBR, Alexey Shtokolov 2016-02-09 21:57 GMT+03:00 Vladimir Kuklin : > Folks > > It seems that docker removal spoilt our celebration a

Re: [openstack-dev] [neutron] Mitaka Mid-Cycle Coding Sprint Registration

On 02/15/2016 04:06 PM, Kyle Mestery wrote: > Hi folks! > > The mid-cycle is almost upon us. IBM, as the sponsor company, is > requesting some information from everyone is registered (name, email, > company, US citizen or not), so please make sure to register on the > Eventbrite site I've created

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 13.02.2016 02:42, Carl Baldwin wrote: > On Fri, Feb 12, 2016 at 5:01 AM, Ihar Hrachyshka wrote: It is only internal implementation changes. That's not entirely true, is it? There are config variables to change and it opens up the possibility of a

Re: [openstack-dev] [oslo][all] Announcing our new Olso Project

For the #OpenStack Mitaka M3 freeze and final release we have made it even easier to play and win Oslo Bingo. Simply pick the next release word. Free entry at http://j.mp/Oslo-bingo-Mitaka Follow the results on Twitter - https://twitter.com/OsloBingo Ronald Bradford Web Site:

[openstack-dev] [puppet] Push Mitaka beta tag

Hi, While Puppet modules releases are independently managed, we have some requests from both RDO & Debian folks to push a first tag in our Puppet modules, for Mitaka release, so they can start provide Mitaka packaging based on tag, and not on commits. This is something we never did before,

[openstack-dev] [neutron] Mitaka Mid-Cycle Coding Sprint Registration

Hi folks! The mid-cycle is almost upon us. IBM, as the sponsor company, is requesting some information from everyone is registered (name, email, company, US citizen or not), so please make sure to register on the Eventbrite site I've created here [1]. If everyone who's attending could please do

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On Feb 15, 2016, at 7:59 AM, Jeremy Stanley wrote: > >> On 2016-02-15 04:36:25 -0500 (-0500), Eoghan Glynn wrote: >> [...] >> Traditionally all ATCs earn a free pass for summit, whereas the >> other attendees pay $600 or more for entry. I'm wondering if (a) >> there's some

Re: [openstack-dev] [fuel] Fuel plugins: lets have some rules

Dmitry, So this changes the workflow for the devopses, the fuel plugin repo creators under Openstack namespace. As I understand, development of every new fuel plugin must be now started in a private github repo first, and when a developer(s) decide they want to go level higher they request

Re: [openstack-dev] [HA][RabbitMQ][messaging][Pacemaker][operators] Improved OCF resource agent for dynamic active-active mirrored clustering

Hello! A quick status update inline: On 23.10.2015 10:01, Bogdan Dobrelya wrote: > Hello. > I'm glad to announce that the pacemaker OCF resource agent for the > rabbitmq clustering, which was born in the Fuel project initially, now > available and maintained upstream! It will be shipped with the

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On 2016-02-15 04:36:25 -0500 (-0500), Eoghan Glynn wrote: [...] > Traditionally all ATCs earn a free pass for summit, whereas the > other attendees pay $600 or more for entry. I'm wondering if (a) > there's some cross-subsidization going on here and (b) if the > design summit was cleaved off,

[openstack-dev] [puppet] weekly meeting #70

Hello We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting4. https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack As usual, free free to bring topics in this etherpad: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160216 We'll also have open

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On Mon, 2016-02-15 at 04:36 -0500, Eoghan Glynn wrote: > > > > Honestly I don't know of any communication between two cores at a > > > +2 party that couldn't have just as easily happened surrounded by > > > other contributors. Nor, I hope, does anyone put in the > > > substantial reviewing

Re: [openstack-dev] [Horizon] eslint without color?

On 2016-02-15 16:45:09 +1100 (+1100), Richard Jones wrote: > I'm just curious why our eslint configuration (in packages.json) > specifies --no-color. It's much harder to spot the errors without > color, and I always end up running it manually to get the color. > Also, karma output has color, so

Re: [openstack-dev] [all] tenant vs. project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/12/2016 07:40 PM, Adam Young wrote: > Tenant never quite made sense to me. A tenant is the person that > occupies an apartment or building, but not the building itself. For public clouds, where you have customers sharing resources on the

[openstack-dev] [Fuel][QA] New runner for fuel-qa system tests

Hi all! Please be informed that we merged a new runner for fuel-qa system tests [1] : run_system_test.py Features of new runner: - auto discovering all test in both test suites ([2] and [3]) - show the groups from the test suites - explain content of groups - run the several groups at the same

[openstack-dev] [fuel] Move virtualbox scripts to a separate directory

Dear colleagues, I'd like to announce that we are next to moving fuel-main/virtualbox directory to a separate git repository. This directory contains a set of bash scripts that could be used to easily deploy Fuel environment and try to deploy OpenStack cluster using Fuel. Virtualbox is used as a

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/15/2016 03:27 AM, Sylvain Bauza wrote: > - can we have the feature optional for operators One thing that concerns me is the lesson learned from simply having a compute node's instance information sent and persisted in memory. That was

[openstack-dev] [keystone] Testing schema migrations was RE: [grenade][keystone] Keystone multinode grenade

> From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] >> >> Keystone stable working with master db seems like an interesting bit, are >> there already tests for that? > >Not yet. Right now there is only a unit test, checking obvious >incompatibilities. > > As an FYI, this test was reverted

Re: [openstack-dev] [magnum] Re: Assistance with Magnum Setup

Hi Hongbin, There is an online dev-quickstart guide that I have been using to install Magnum. This guide is intended to install magnum with devstack however the guide seems to not include all the information needed to connect magnum, Barbican and keystone which is where my problems are

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Le 15/02/2016 10:48, Cheng, Yingxin a écrit : Thanks Sylvain, 1. The below ideas will be extended to a spec ASAP. Nice, looking forward to it then :-) 2. Thanks for providing concerns I’ve not thought it yet, they will be in the spec soon. 3. Let me copy my thoughts from another

Re: [openstack-dev] [magnum]swarm + compose = k8s?

Hi all, A few thoughts to add: I like the idea of isolating the masters so that they are not tenant-controllable, but I don't think the Magnum control plane is the right place for them. They still need to be running on tenant-owned resources so that they have access to things like isolated

Re: [openstack-dev] [all] Any projects using sqlalchemy-utils?

On Mon, Feb 15, 2016 at 7:57 AM, Julien Danjou wrote: > On Fri, Feb 12 2016, Corey Bryant wrote: > > > taskflow started using it recently, however it's only needed for a single > > type in taskflow (JSONType). I'm wondering if it's worth the effort of > > maintaining it and

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On Fri, 12 Feb 2016, Doug Wiegley wrote: It hurts discoverability, and “expectedness”. If I’m new to openstack, having it default boot unusable just means the first time I use ’nova boot’, I’ll end up with a useless VM. People don’t read docs first, it should “just work” as far as that’s sane.

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

On 14/02/16 17:16 -0500, Davanum Srinivas wrote: Hi, Short Story: pycryptodome if installed inadvertently will break several projects: Example : https://review.openstack.org/#/c/279926/ Long Story: There's a new kid in town pycryptodome: https://github.com/Legrandin/pycryptodome Because

[openstack-dev] [nova] Nova API sub-team meeting

We have weekly Nova API meeting tomorrow. The meeting is being held Tuesday UTC1200. The proposed agenda and meeting details are here: https://wiki.openstack.org/wiki/Meetings/NovaAPI Please feel free to add items to the agenda. Thanks

Re: [openstack-dev] [all] Any projects using sqlalchemy-utils?

On Fri, Feb 12 2016, Corey Bryant wrote: > taskflow started using it recently, however it's only needed for a single > type in taskflow (JSONType). I'm wondering if it's worth the effort of > maintaining it and it's dependencies in Ubuntu main or if perhaps we can > just revert this bit to

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

2016-02-14 23:16 GMT+01:00 Davanum Srinivas : > Hi, > > Short Story: > pycryptodome if installed inadvertently will break several projects: > Example : https://review.openstack.org/#/c/279926/ > > Long Story: > There's a new kid in town pycryptodome: >

[openstack-dev] [Kuryr] IRC Meeting today (2/15) - 1500 UTC

Hello All We will have an IRC meeting today (Monday, 2/15) at 1500 UTC in #openstack-meeting-4 Please review the expected meeting agenda here: https://wiki.openstack.org/wiki/Meetings/Kuryr You can view last meeting action items and logs here:

Re: [openstack-dev] [TripleO] Stable branch policy for Mitaka

On 02/15/2016 03:59 AM, Steven Hardy wrote: > On Wed, Feb 10, 2016 at 07:05:41PM +0100, James Slagle wrote: >>On Wed, Feb 10, 2016 at 4:57 PM, Steven Hardy wrote: >> >> Hi all, >> >> We discussed this in our meeting[1] this week, and agreed a ML >>

[openstack-dev] [ironic] Baremetal Deploy Ramdisk functional testing

Re-sending with Ironic stamp… Folks, please see below: > > Hi All, > > In bareon [1] we have test framework to test deploy ramdsik with bareon > inside (baremetal deployments). This is a functional testing, we do a full > partitioning/image_deployment in a VM, then reboot to see if tenant

Re: [openstack-dev] Octavia (LBaaS) license question

OpenStack is using KVM and Linux as reference implementation, both are GPL. From: Gal Sagie [mailto:gal.sa...@gmail.com] Sent: Sunday, February 14, 2016 8:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] Octavia (LBaaS) license question Hello All,

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

Well done, Fedor! Congrats! -Dmitry. On Mon, Feb 15, 2016 at 1:12 PM, Maksim Malchuk wrote: > Congrats! > > > On Mon, Feb 15, 2016 at 1:08 PM, Fedor Zhadaev > wrote: > >> Thank you! >> -- >> Kind Regards, >> Fedor Zhadaev >> >> skype: zhadaevfm >>

Re: [openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

On 2016-02-15 11:32, Omer (Nokia - IL) Etrog wrote: > Hi, > Is there proper documentation how to add localization for external plugins > that use AngularJS? http://docs.openstack.org/infra/manual/creators.html#enabling-translation-infrastructure Note that the translation team only translates

Re: [openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

Hi, Is there proper documentation how to add localization for external plugins that use AngularJS? Thanks, Omer Etrog Vitrage Team     From: Thai Q Tran [mailto:tqt...@us.ibm.com] Sent: Thursday, December 03, 2015 11:44 PM To: openstack-dev@lists.openstack.org Cc: Vince Brunssen Subject:

Re: [openstack-dev] [Swift] Erasure coding and geo replication

Hello Mark, AFAIK, a few reasons for that we still are in working progress for erasure code + geo replication. >> and expect to survive a region outage... >> >> With that I mind I did some experiments (Liberty swift) and it looks to me >> like if you have: >> >> - num_data_frags < num_nodes in

Re: [openstack-dev] [Nova] Update on live migration priority

On Fri, Feb 12, 2016 at 04:21:27PM +, Murray, Paul (HP Cloud) wrote: > This time with a tag in case anyone is filtering... Yep, I was filtering, and would've missed it without your tag. :-) > From: Murray, Paul (HP Cloud) > Sent: 12 February 2016 16:16 > To: openstack-dev@lists.openstack.org

[openstack-dev] [Bareon] Weekly update

Hi, After the discussion with some folks, we agreed that it might be useful for the community to start sending weekly updates on what Bareon team is working on and what is our progress. So here is a first weekly update from Bareon team. 1. Data pipelines for Nailgun integration (changing

  1   2   >