[openstack-dev] [Tricircle] Original Blueprint

Hi Chaoyi, In blueprint you described for PoC, there are information of tables. [1] They seem to out-to-date. Do you think that those information need to be up-to-date in your blueprint? If it's not necessary, it's better to move those information to different sheet or put some comment like

Re: [openstack-dev] [Openstack-stable-maint] Stable check of openstack/trove failed

On Wed, Apr 06, 2016 at 10:08:44AM +, Amrith Kumar wrote: > Stable team, the reason for this failure of py27 in kilo is > > https://bugs.launchpad.net/trove/+bug/1437179 > > The bug was fixed in liberty in commit > I92eaa1c98f5a58ce124210f2b6a2136dfc573a29 and therefore, at this

[openstack-dev] [QA] Meeting Thursday April 7th at 9:00 UTC

Hello everyone, Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, April 7th at 9:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here:

Re: [openstack-dev] [Tricircle] Asynchronous Job Management Patches

Hi, Zhiyuan, You can also add some reviewers in the patch directly. Best Regards Chaoyi Huang ( Joe Huang ) From: Vega Cai [mailto:luckyveg...@gmail.com] Sent: Thursday, April 07, 2016 9:16 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Tricircle]

Re: [openstack-dev] [Infra] Generic solution for bare metal testing

On 2016-04-06 18:33:06 +0300 (+0300), Igor Belikov wrote: [...] > I suppose there are security issues when we talk about running > custom code on bare metal slaves, but I'm not sure I understand > the difference from running custom code on a virtual machine if > bare metal nodes are isolated,

Re: [openstack-dev] [tricircle] Hello

Hi Lige, You could also check out shipengfei's blog http://shipengfei92.cn/play_tricircle_with_virtualbox on how to play with devstack to setup a Tricircle env on your laptop : ) On Tue, Apr 5, 2016 at 11:54 AM, joehuang wrote: > Hi, Lige, > > > > Welcome to join

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

On 04/06/2016 05:41 PM, Fox, Kevin M wrote: -1 for man in the middle susceptible solutions. This also doesn't solve all the issues listed in the spec, such as suspended nodes, snapshotted nodes, etc. Self signed MITM That is only an issue if you are not trusting the initial setup. I wan a

[openstack-dev] [tacker] Refactoring heat-driver

Now that Mitaka release is out, this is a good time to consider refactoring Tacker's heat-driver. This driver was one of the big module we inherited but it got even bloated with recent enhancements. I've captured some ideas on how to shuffle things out of this component in the etherpad [1].

[openstack-dev] [Tricircle] Asynchronous Job Management Patches

Hi, I have submitted the second patch for asynchronous job management, please help to review. Here is the link: https://review.openstack.org/#/c/302110/ The first patch has been merged. Link for the first patch: https://review.openstack.org/#/c/295729/ BR Zhiyuan

Re: [openstack-dev] [Nova] FPGA as a resource

Hi all, We agree this is an ingesting direction we can do exploration on OpenStack and actually we already have such FPGA/GPU as a resource in our public research cloud called SuperVessel (https://ptopenlab.com). With modification of OpenStack from community, nearly all features mentioned by

[openstack-dev] [Fuel] CI status after Mitaka branching

Hi, everyone, here is the current CI status for Fuel: * there are now regular 10.0 ISO builds which track master branch; 9.0 builds are switched to stable/mitaka https://ci.fuel-infra.org/view/ISO/ * UCA deployment scenario has been added to regular Build Verification Tests for both Mitaka

Re: [openstack-dev] [neutron][api] advanced search criteria

On 2016/04/05 22:23, Ihar Hrachyshka wrote: Hirofumi Ichihara wrote: Hi Ihar, On 2016/04/05 7:57, Ihar Hrachyshka wrote: Hi all, in neutron, we have a bunch of configuration options to control advanced filtering features for API, f.e. allow_sorting,

Re: [openstack-dev] [designate][osc] new sub commands - how should they be named?

Hi Graham, Service is somewhat a pretty common word and would have been used by several components. But the distinguishing point between Keystone, Designate, Nova et.al . would be the component ( in this case , dns) to which the subcommand belongs to. Also, the below commands make more sense. >

Re: [openstack-dev] [Infra] Generic solution for bare metal testing

On Wed, Apr 06, 2016 at 06:33:06PM +0300, Igor Belikov wrote: > Hey Stackers, > > In Fuel we use bare metal testing for deployment tests. This is essentially a > core component of Fuel CI and as much as we like having it around we’d rather > spend time and resources integrating with upstream

Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

On Wed, Apr 6, 2016 at 6:29 PM, David Stanek wrote: > > On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic > wrote: > >> >> 2) This will reduce scope of Keystone, which means 2 things >> 2.1) Smaller code base that has less issues and is simpler for

[openstack-dev] meeting topics for 4/7/2016 networking-sfc project IRC meeting

Hi everyone, Here are some topics I have in mind for tomorrow's meeting discussion. Feel free to add more. 1. Source port specification in the FC 2. Networking-sfc SFC driver for OVN 3. Networking-sfc SFC driver for ODL 4. Networking-sfc integration with ONOS

Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic wrote: > > 2) This will reduce scope of Keystone, which means 2 things > 2.1) Smaller code base that has less issues and is simpler for testing > 2.2) Keystone team would be able to concentrate more on fixing >

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

-1 for man in the middle susceptible solutions. This also doesn't solve all the issues listed in the spec, such as suspended nodes, snapshotted nodes, etc. Nova has several back channel mechanisms at its disposal. We should use one or more of them to solve the problem properly instead of

Re: [openstack-dev] [Security][Barbican] BYOK

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Rob, The Barbican team is dedicating a Fishbowl session to BYOK for the summi t: https://www.openstack.org/summit/austin-2016/summit-schedule/events/9155 - - Doug On 4/6/16 5:12 AM, Clark, Robert Graham wrote: > Hi All, > > We’ve had lots

Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

On 04/06/2016 04:56 PM, Dolph Mathews wrote: For some historical perspective, that's basically how v2 was designed. The "public" service (port 5000) did nothing but the auth flow. The "admin" service (port 35357) was identity management. Unfortunately, there are (perhaps uncommon)

Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

This has been our hidden agenda for many releases (minus the project split). There are other projects that you mention that are much better at handling authentication, many enterprises already have these place as well. We have been trying to get out of the identity management (and consequently,

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

On 04/06/2016 05:42 AM, Daniel P. Berrange wrote: On Tue, Apr 05, 2016 at 06:00:55PM -0400, Adam Young wrote: We have a use case where we want to register a newly spawned Virtual machine with an identity provider. Heat also has a need to provide some form of Identity for a new VM. Looking at

[openstack-dev] [Winstackers][Hyper-V] Newton Design Summit

Hello everyone, We are going to have a session in the upcomming Austin Design Summit about the upcoming features in OpenStack for Hyper-V / Windows / other Microsoft technologies. We have started writing an agenda for the Winstackers work session:

Re: [openstack-dev] [TripleO] FreeIPA integration

On 04/06/2016 10:44 AM, Dan Prince wrote: On Tue, 2016-04-05 at 19:19 -0600, Rich Megginson wrote: On 04/05/2016 07:06 PM, Dan Prince wrote: On Sat, 2016-04-02 at 17:28 -0400, Adam Young wrote: I finally have enough understanding of what is going on with Tripleo to reasonably discuss how to

Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

For some historical perspective, that's basically how v2 was designed. The "public" service (port 5000) did nothing but the auth flow. The "admin" service (port 35357) was identity management. Unfortunately, there are (perhaps uncommon) authentication flows where, for example, you need to 1)

Re: [openstack-dev] [horizon] - oAuth tab proposal

On 04/06/2016 03:20 PM, Brad Pokorny wrote: The last I heard, oauth is likely to be deprecated in Keystone [1]. If you're interested in having it stay around, please let the Keystone team know. It would only make sense to add it to Horizon if it's going to stay. [1]

Re: [openstack-dev] [horizon] - oAuth tab proposal

There was feedback from the murano team asking for it to stick around: http://lists.openstack.org/pipermail/openstack-dev/2016-March/090459.html Thanks, Steve Martinelli OpenStack Keystone Project Team Lead From: Brad Pokorny To: "OpenStack Development

Re: [openstack-dev] [Horizon][Searchlight] Plans for Horizon cross-region view

To add to that - Brad, if you're going to be in Austin I'm planning to bring along a prototype, and I know that this use case is of interest to others. If there is still sufficient interest it's something we have as a priority for Newton, and from the few hours I've spent so far setting it up I

[openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

Hi stackers, I would like to suggest very simple idea of splitting out of Keystone authentication part in the separated project. Such change has 2 positive outcomes: 1) It will be quite simple to create scalable service with high performance for authentication based on very mature projects like:

Re: [openstack-dev] [DIB][Bifrost] Avoid running DIB with simple-init until a new release (1.14.1) is made

On Wed, Apr 6, 2016, at 11:19 AM, Gregory Haynes wrote: > This is a notice for users of diskimage-builder's simple-init element (I > added Bifrost because I believe that is the recommended usage there). > > There is a bug in the latest release (1.14.0) of diskimage-builder which > will delete ssh

Re: [openstack-dev] [horizon] - oAuth tab proposal

The last I heard, oauth is likely to be deprecated in Keystone [1]. If you're interested in having it stay around, please let the Keystone team know. It would only make sense to add it to Horizon if it's going to stay. [1] http://openstack.markmail.org/message/ihqbetack26g5gmg Thanks, Brad

[openstack-dev] [app-catalog] IRC Meeting Thursday April 7th

Join us Thursday for our weekly meeting, scheduled for April 7th 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 We'll include status updates on the Glare PoC

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

On 4/6/16 2:43 PM, Matt Riedemann wrote: > > > On 4/6/2016 1:17 PM, Nikhil Komawar wrote: >> >> >> On 4/6/16 2:09 PM, Clint Byrum wrote: >>> Excerpts from Nikhil Komawar's message of 2016-04-06 10:46:28 -0700: Need a inline clarification. On 4/6/16 10:58 AM, Flavio Percoco wrote:

[openstack-dev] [trove] Trove weekly meeting minutes

Minutes from today's weekly Trove meeting are at http://eavesdrop.openstack.org/meetings/trove/2016/trove.2016-04-06-18.00.html Detailed session schedule for summit is at http://bit.ly/trove-newton-design-summit -amrith __

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

Ive treated m1 flavors as an abstraction layer for flavours. I create other flavors that match various other things, but leave the m1's around as a target for generic, "I need about x size" things. I tweak them slightly to match up with the compute nodes closer but never shrink them past what

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

On 4/6/16 2:09 PM, Clint Byrum wrote: > Excerpts from Nikhil Komawar's message of 2016-04-06 10:46:28 -0700: >> Need a inline clarification. >> >> On 4/6/16 10:58 AM, Flavio Percoco wrote: >>> On 06/04/16 08:26 -0400, Sean Dague wrote: On 04/06/2016 04:13 AM, Markus Zoeller wrote: > +1

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

On Wed, Apr 6, 2016 at 9:29 AM, Fox, Kevin M wrote: > It feels kind of like a defcore issue though. Its harder for app developers > to create stuff like heat templates intended for cross cloud that recommend a > size, m1.small, without a common reference. For most

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

> On Apr 6, 2016, at 11:14 AM, Sean Dague wrote: > > On 04/06/2016 01:28 PM, Dean Troyer wrote: >> On Wed, Apr 6, 2016 at 12:10 PM, Tim Bell > > wrote: >> >>I think Heat needs more of an query engine along the lines of “give me a

[openstack-dev] [DIB][Bifrost] Avoid running DIB with simple-init until a new release (1.14.1) is made

This is a notice for users of diskimage-builder's simple-init element (I added Bifrost because I believe that is the recommended usage there). There is a bug in the latest release (1.14.0) of diskimage-builder which will delete ssh host keys on the image building host when using the simple-init

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

On 04/06/2016 01:28 PM, Dean Troyer wrote: > On Wed, Apr 6, 2016 at 12:10 PM, Tim Bell > wrote: > > I think Heat needs more of an query engine along the lines of “give me a > flavor with at least X cores and Y GB RAM” rather than hard coding >

Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova

On 06/04/16 19:28, "Fox, Kevin M" wrote: >+1 > >From: Neil Jerram [neil.jer...@metaswitch.com] >Sent: Wednesday, April 06, 2016 10:15 AM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev]

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

Excerpts from Nikhil Komawar's message of 2016-04-06 10:46:28 -0700: > Need a inline clarification. > > On 4/6/16 10:58 AM, Flavio Percoco wrote: > > On 06/04/16 08:26 -0400, Sean Dague wrote: > >> On 04/06/2016 04:13 AM, Markus Zoeller wrote: > >>> +1 for deprecation and removal > >>> > >>> To

Re: [openstack-dev] [magnum] Containers lifecycle management

> -Original Message- > From: Flavio Percoco [mailto:fla...@redhat.com] > Sent: April-06-16 12:16 PM > To: Hongbin Lu > Cc: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum] Containers lifecycle management > > On 06/04/16 15:54 +,

[openstack-dev] [Congress] Issues Integrating Policy Panel in Horizon

Hi Congress team, I mentioned before that I was able to get Congress installed using a bash script that puts the service into an LXC container on the OPNFV Controller node (which has all the OpenStack services, some running bare metal and others in LXCs). This is per the JOID installer

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

Need a inline clarification. On 4/6/16 10:58 AM, Flavio Percoco wrote: > On 06/04/16 08:26 -0400, Sean Dague wrote: >> On 04/06/2016 04:13 AM, Markus Zoeller wrote: >>> +1 for deprecation and removal >>> >>> To be honest, when I started with Nova during Kilo, I didn't get >>> why we have those

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

On Tue, Apr 5, 2016 at 11:24 PM, Monty Taylor wrote: > On 04/05/2016 05:07 PM, Michael Still wrote: > >> self.glance = glance_client.Client('2', endpoint, token=token) > > > There are next to zero cases where the thing you want to do is talk to > glance using a token and an

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

> Ops != Cloud App developers. We've really made the latter's job hard, > and are often increasing the difficulty on them. This pushes them > away from OpenStack and eliminates a lot of potential users of > OpenStack, meaning Ops have fewer users then they should. Lets not > continue this trend.

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

Thats an interesting idea. Maybe an extension to the heat param flavour type validator? Thanks, Kevin From: Tim Bell [tim.b...@cern.ch] Sent: Wednesday, April 06, 2016 10:10 AM To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova

+1 From: Neil Jerram [neil.jer...@metaswitch.com] Sent: Wednesday, April 06, 2016 10:15 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova I hesitate to

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

On Wed, Apr 6, 2016 at 12:10 PM, Tim Bell wrote: > I think Heat needs more of an query engine along the lines of “give me a > flavor with at least X cores and Y GB RAM” rather than hard coding > m1.large. > Core performance is another parameter that would be interesting to

Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova

> I haven't researched this particular case in detail, so I could be > misunderstanding its implications. But in general my impression, > from the conversations that occur when these topics are raised, is > that many prominent OpenStack developers do not care enough about > release-to-release

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

Ops != Cloud App developers. We've really made the latter's job hard, and are often increasing the difficulty on them. This pushes them away from OpenStack and eliminates a lot of potential users of OpenStack, meaning Ops have fewer users then they should. Lets not continue this trend. :/

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

On 06/04/16 18:36, "Daniel P. Berrange" wrote: >On Wed, Apr 06, 2016 at 04:29:00PM +, Fox, Kevin M wrote: >> It feels kind of like a defcore issue though. Its harder for app >> developers to create stuff like heat templates intended for cross >> cloud that recommend a

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

On 06/04/2016 17:38, Fox, Kevin M wrote: > A lot of the problems are documented here in the problem description section: > https://review.openstack.org/#/c/93/ > > Thanks, > Kevin I am very much ++ on instance users. > > From: Daniel P. Berrange

Re: [openstack-dev] [OpenStack Foundation] Board of Directors Meeting

Hi, Reading unofficial notes [1], i found one topic very interesting: One Platform – How do we truly support containers and bare metal under a common API with VMs? (Ironic, Nova, adjacent communities e.g. Kubernetes, Apache Mesos etc) Anyone present at the meeting, please expand on those few

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

> It still was more common then not I think? So making it less common > is probably a step on the wrong direction. The responses on the operators mailing list were 100% positive for removal. As Dan said, calling these a standard is really not reasonable. They're just defaults, copied from AWS

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

It still was more common then not I think? So making it less common is probably a step on the wrong direction. Thanks, Kevin From: Daniel P. Berrange [berra...@redhat.com] Sent: Wednesday, April 06, 2016 9:36 AM To: OpenStack Development Mailing List

Re: [openstack-dev] [TripleO] FreeIPA integration

On 04/06/2016 10:38 AM, Hayes, Graham wrote: On 06/04/2016 17:17, Rich Megginson wrote: On 04/06/2016 02:55 AM, Hayes, Graham wrote: On 06/04/16 03:09, Adam Young wrote: On 04/05/2016 08:02 AM, Hayes, Graham wrote: On 02/04/2016 22:33, Adam Young wrote: I finally have enough understanding

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

A lot of the problems are documented here in the problem description section: https://review.openstack.org/#/c/93/ Thanks, Kevin From: Daniel P. Berrange [berra...@redhat.com] Sent: Wednesday, April 06, 2016 9:04 AM To: Hayes, Graham Cc: OpenStack

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

On Wed, Apr 06, 2016 at 04:29:00PM +, Fox, Kevin M wrote: > It feels kind of like a defcore issue though. Its harder for app > developers to create stuff like heat templates intended for cross > cloud that recommend a size, m1.small, without a common reference. Even with Nova defining these

Re: [openstack-dev] [TripleO] FreeIPA integration

On 06/04/2016 17:17, Rich Megginson wrote: > On 04/06/2016 02:55 AM, Hayes, Graham wrote: >> On 06/04/16 03:09, Adam Young wrote: >>> On 04/05/2016 08:02 AM, Hayes, Graham wrote: On 02/04/2016 22:33, Adam Young wrote: > I finally have enough understanding of what is going on with Tripleo

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

It feels kind of like a defcore issue though. Its harder for app developers to create stuff like heat templates intended for cross cloud that recommend a size, m1.small, without a common reference. We keep making it hard for app developers to target openstack, so they don't join, and then

Re: [openstack-dev] [magnum] Containers lifecycle management

On 06/04/16 15:54 +, Hongbin Lu wrote: -Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: April-06-16 9:14 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [magnum] Containers lifecycle management Greetings, I'm fairly new to Magnum and I

Re: [openstack-dev] Floating IPs and Public IPs are not equivalent

Ok. I'll bite. :) Security is like a castle. More walls provide more protection. One outer wall only is something that tends to bite folks because they assume the first wall won't ever be breached. Nat is one type of wall. Not to be used by itself but provides additional protection. For

Re: [openstack-dev] [TripleO] FreeIPA integration

On 04/06/2016 02:55 AM, Hayes, Graham wrote: On 06/04/16 03:09, Adam Young wrote: On 04/05/2016 08:02 AM, Hayes, Graham wrote: On 02/04/2016 22:33, Adam Young wrote: I finally have enough understanding of what is going on with Tripleo to reasonably discuss how to implement solutions for some

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

On 06/04/2016 17:04, Daniel P. Berrange wrote: > On Wed, Apr 06, 2016 at 04:03:18PM +, Hayes, Graham wrote: >> On 06/04/2016 16:54, Gary Kotton wrote: >>> >>> >>> On 4/6/16, 12:42 PM, "Daniel P. Berrange" wrote: >>> On Tue, Apr 05, 2016 at 06:00:55PM -0400, Adam

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

On Wed, Apr 06, 2016 at 04:03:18PM +, Hayes, Graham wrote: > On 06/04/2016 16:54, Gary Kotton wrote: > > > > > > On 4/6/16, 12:42 PM, "Daniel P. Berrange" wrote: > > > >> On Tue, Apr 05, 2016 at 06:00:55PM -0400, Adam Young wrote: > >>> We have a use case where we want to

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

On 06/04/2016 16:54, Gary Kotton wrote: > > > On 4/6/16, 12:42 PM, "Daniel P. Berrange" wrote: > >> On Tue, Apr 05, 2016 at 06:00:55PM -0400, Adam Young wrote: >>> We have a use case where we want to register a newly spawned Virtual >>> machine >>> with an identity provider.

Re: [openstack-dev] [TripleO] FreeIPA integration

Yeah. I'm all for something like that. The solution just needs to meet the requirements listed in https://review.openstack.org/93 That solution could also probably be reused for an ssh key. The security of openssh vms + nova is pretty bad. There should be some kind of way for the vm to

Re: [openstack-dev] [magnum] Containers lifecycle management

> -Original Message- > From: Flavio Percoco [mailto:fla...@redhat.com] > Sent: April-06-16 9:14 AM > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] [magnum] Containers lifecycle management > > > Greetings, > > I'm fairly new to Magnum and I hope my comments below are

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

Nova Instance user spec. https://review.openstack.org/93 We really really need to solve this. it is affecting almost every project in one way or another. Can we please get a summit session dedicated to the topic? Last summit we had only 10 minutes. :/ Thanks, Kevin

Re: [openstack-dev] [nova][neutron] Update on os-vif progress (port binding negotiation)

Hi all. I want to share a status about os-vif’s functional test gate check job. Currently, the all necessary changes are merged and there is a way to run the all tempest tests on devstack in our CI. The name of job is gate-tempest-dsvm-nova-os-vif-nv and it’s a experimental job, that can be

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

On 4/6/16, 12:42 PM, "Daniel P. Berrange" wrote: >On Tue, Apr 05, 2016 at 06:00:55PM -0400, Adam Young wrote: >> We have a use case where we want to register a newly spawned Virtual >>machine >> with an identity provider. >> >> Heat also has a need to provide some form of

[openstack-dev] [Infra] Generic solution for bare metal testing

Hey Stackers, In Fuel we use bare metal testing for deployment tests. This is essentially a core component of Fuel CI and as much as we like having it around we’d rather spend time and resources integrating with upstream instead of growing and polishing third-party testing solutions. On one

[openstack-dev] [kolla] Using reno

Hey folks, Reno is in our master codebase and mitaka. Every new feature should use reno at the conclusion of the patch set. The full documentation is here: http://docs.openstack.org/developer/reno/usage.html#creating-new-release-notes In short, to create a reno note, just run pip install reno

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

On 03/04/16 21:38, Dan Prince wrote: On Mon, 2016-03-21 at 16:14 -0400, Zane Bitter wrote: As of the Liberty release, Magnum now supports provisioning Mesos clusters, so TripleO wouldn't have to maintain the installer for that either. (The choice of Mesos is somewhat unfortunate in our case,

Re: [openstack-dev] [Fuel] Merge Freeze for Mitaka branching

Hi, everyone, we were delayed by npm issue [0] in the gate, but currently we have successfully merged all version bumps [1] and got stable master, thanks to Sergey Kulanov who got it all fully tested in advance. Merge Freeze is lifted. Please note: * To merge change to Mitaka release, you need

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

On 06/04/16 08:26 -0400, Sean Dague wrote: On 04/06/2016 04:13 AM, Markus Zoeller wrote: +1 for deprecation and removal To be honest, when I started with Nova during Kilo, I didn't get why we have those passthrough APIs. They looked like convenience APIs. A short history lesson, why they got

[openstack-dev] [magnum] Containers lifecycle management

Greetings, I'm fairly new to Magnum and I hope my comments below are accurate. After reading some docs, links and other references, I seem to understand the Magnum team has a debate on whether providing abstraction for containers lifecycle is something the project should do or not. There's a

Re: [openstack-dev] [designate][osc] new sub commands - how should they be named?

On Wed, Apr 6, 2016 at 7:44 AM, Sheel Rana Insaan wrote: > Hey Graham, > > I just added service for block storage, we have named these > openstack volume service list/enable/disable. > > Same protocol is used for nova as well previosly. > > Hope this will help. > >

Re: [openstack-dev] [TripleO] FreeIPA integration

On Tue, 2016-04-05 at 19:19 -0600, Rich Megginson wrote: > On 04/05/2016 07:06 PM, Dan Prince wrote: > > > > On Sat, 2016-04-02 at 17:28 -0400, Adam Young wrote: > > > > > > I finally have enough understanding of what is going on with > > > Tripleo > > > to > > > reasonably discuss how to

Re: [openstack-dev] [designate][osc] new sub commands - how should they be named?

Hey Graham, I just added service for block storage, we have named these openstack volume service list/enable/disable. Same protocol is used for nova as well previosly. Hope this will help. Regards, Sheel Rana On Apr 6, 2016 7:54 PM, "Hayes, Graham" wrote: > On

Re: [openstack-dev] [designate][osc] new sub commands - how should they be named?

On 06/04/2016 15:20, Qiming Teng wrote: > On Wed, Apr 06, 2016 at 01:59:29PM +, Hayes, Graham wrote: >> Designate is adding support for viewing the status of the various >> services that are running. >> >> We have added support to our openstack client plugin, but were looking >> for guidance /

Re: [openstack-dev] [designate][osc] new sub commands - how should they be named?

On Wed, Apr 06, 2016 at 01:59:29PM +, Hayes, Graham wrote: > Designate is adding support for viewing the status of the various > services that are running. > > We have added support to our openstack client plugin, but were looking > for guidance / advices on what the actual commands should

Re: [openstack-dev] [Neutron] Newton blueprints call for action

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Armando, On 05/04/16 01:13 AM, Armando M. wrote: > Hi Neutrinos, > > During today's team meeting [0], we went through the current > milestone workload [1]. > > This is mostly made of Mitaka backlog items, amongst which we > discussed two

[openstack-dev] [designate][osc] new sub commands - how should they be named?

Designate is adding support for viewing the status of the various services that are running. We have added support to our openstack client plugin, but were looking for guidance / advices on what the actual commands should be. We have implemented it in [1] as "dns service list" and "dns service

Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova

On 4/6/2016 8:06 AM, Qiming Teng wrote: Thanks for the explanation, Sean. I wasn't subscribing to the operators mailinglist so wasn't aware of the notice. With that, I'm still surprised that there was no response to that email. Anyway, if people believe the benefits overweighs the impacts

Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova

Thanks for the explanation, Sean. I wasn't subscribing to the operators mailinglist so wasn't aware of the notice. With that, I'm still surprised that there was no response to that email. Anyway, if people believe the benefits overweighs the impacts caused, just do it. The only thing I can think

Re: [openstack-dev] [Nova] FPGA as a resource

On Wed, Apr 6, 2016 at 6:37 AM, Daniel P. Berrange wrote: > Most of the > work to support FPGA will be internal to nova, to deal with modelling > of assignable devices and their scheduling / allocation. I think the EPA blueprint already covers some of the FPGA device

Re: [openstack-dev] [nova] New resource tracker

> -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: 04 April 2016 18:47 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova] New resource tracker > > On 04/04/2016 01:21 PM, Rayson Ho wrote: > > I found that even in the latest git tree,

[openstack-dev] [Kuryr] - Austin Design Summit

Hello everyone, We have split our design summit sessions into topics (and sub topics) for each session Please review the topics and agenda here: https://etherpad.openstack.org/p/kuryr-design-summit This is still a tentative schedule/agenda, so if you have any ideas/comments on that agenda or

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

On 04/06/2016 04:13 AM, Markus Zoeller wrote: > +1 for deprecation and removal > > To be honest, when I started with Nova during Kilo, I didn't get > why we have those passthrough APIs. They looked like convenience APIs. > A short history lesson, why they got introduced, would be cool. I only >

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

On 05/04/16 17:49 -0400, Nikhil Komawar wrote: I think in the interest of supporting the OSC effort, I am with deprecating the CLI stuff (possibly glanceclient too -- BUT in a different thread). I believe removing the bindings/modules that support possibly OSC and other libs might be lot

[openstack-dev] [Neutron][Dragonflow] - Austin Design Summit

Hello everyone, We have started writing an agenda for our design summit sessions, please feel free to raise ideas/comments/questions in the following etherpad: https://etherpad.openstack.org/p/dragonflow-design-summit If you are a user/operator and would like to raise questions regarding our

[openstack-dev] [nova][live-migration] Libvirt storage pools and persistent disk metadata specs

I've just submitted a new spec for the imagebackend work was doing in Mitaka, which is a prerequisite for the libvirt storage pools work: https://review.openstack.org/#/c/302117/ I was just about to resubmit libvirt storage pools with my spec as a dependency, but re-reading it perhaps we should

Re: [openstack-dev] [Nova] FPGA as a resource

Yes the project is quite new, we are still developing requirements at the OPNFV side. We will update with full description after the summit when we got all the inputs. Look forward to have a chat with you at the summit :) I think you are right that Nomad does not solve the problem per se in this

Re: [openstack-dev] [Neutron] Newton blueprints call for action

On 04/05/2016 05:43 AM, Armando M. wrote: > > With this email I would like to appeal to the people in CC to report > back their interest in continuing working on these items in their > respective capacities, and/or the wider community, in case new owners > need to be identified. > > I look

Re: [openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

Hello! Thanks for bring this topic up. First of all, as I mentioned before, the great work was done in Mitaka, so Glance v2 adoption in Nova it is not a question of "if", and not even a question of "when" (in Newton), but the question of "how". There is a set of commits that make this trick: 1.

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

On Wed, Apr 6, 2016 at 7:47 PM, Sean Dague wrote: > On 04/06/2016 04:19 AM, Sylvain Bauza wrote: >> >> >> Le 06/04/2016 06:44, Qiming Teng a écrit : >>> Not an expert of Nova but I am really shocked by such a change. Because >>> I'm not a Nova expert, I don't have a say on the

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

On 04/06/2016 04:19 AM, Sylvain Bauza wrote: > > > Le 06/04/2016 06:44, Qiming Teng a écrit : >> Not an expert of Nova but I am really shocked by such a change. Because >> I'm not a Nova expert, I don't have a say on the *huge* efforts in >> maintaining some builtin/default flavors. As a user I

  1   2   >