date:20160726

Jim,

Thinking like Kevin's below are the reason I asked for the two requested
changes.  He isn't the only person to think along these lines.  His
argument is coherent and logical and if you analyze his response he
indicates his perception is the four opens are not being followed by Fuel.

It is the responsibility of every OpenStack community member to protect
the four opens.  The four opens are the founding of OpenStack's
fundamental tenants.  Even if the reality is Fuel is participating in the
OpenStack community using the four opens, people may not perceive it as
such based upon the many reviews linked in this thread.

As can be seen by Kevin's email, perception matters.

Clearly Mirantis is committed to this effort with two pages of Mirantis
reviews outstanding.

What precisely is the harm in acknowledging the _truth_ directly in the
governance repo?

Regards
-steve

On 7/26/16, 4:44 PM, "Fox, Kevin M"  wrote:

>Hi Jim,
>
>The issue is, as I see it, a parallel activity to one of the that is
>currently accepted into the Big Tent, aka Containerized Deployment:
>Kolla's mission:
>To provide production-ready containers and deployment tools for operating
>OpenStack clouds.
>
>Fuel's mission:
>To streamline and accelerate the process of deploying, testing and
>maintaining various configurations of OpenStack at scale.
>
>To me, this totally lets both projects work together, fuel providing the
>bare metal provisioning/kubernetes provisioning, the k8s orchestration to
>manage pods/deployments/etc, its awesome ui, etc, and using
>kolla-kubernetes/kolla for the container bits/k8s templates. Otherwise
>there's a quite a bit duplication of work. This feels in line with fuel
>trying to reimplement another core openstack project (say, nova)
>
>When fuel-ccp was proposed, it was proposed as more of a proof of concept
>and not a big tent thing: https://review.openstack.org/#/c/331139/
>
>If you look at contributions to each of kolla-kubernetes its a fairly
>diverse set of contributors:
>http://stackalytics.com/?module=kolla-kubernetes
>fuel-ccp doesn't show up in stackalytics but if you check the commit log
>its very heavily dominated by one company. That's not really open
>development.
>
>The kolla-kubernetes project was having discussions about how to work
>with the Fuel team to ensure that their needs were met, when they
>suddenly stopped talking and spawned a new project. This doesn't feel
>like working with the community. Our differences didn't feel unsolvable
>to the point of spawning a new, competing project.
>
>Now its being advertised very openly. This feels like it was snuck in the
>back door, behind the communities back then pushed hard.
>
>OpenStack is already distressingly fractured already. Can we try and work
>together rather then keep making an already pretty bad situation worse?
>Are the technical differences really that far apart to prevent it?
>
>Does that help to clarify the concern?
>
>Thanks,
>Kevin
>
>
>
>
>
>
>From: Jim Rollenhagen [j...@jimrollenhagen.com]
>Sent: Tuesday, July 26, 2016 3:28 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is
>getting Fuel CCP (docker/k8s) kicked off
>
>On Tue, Jul 26, 2016 at 09:42:10PM +, Steven Dake (stdake) wrote:
>>
>>
>> On 7/26/16, 2:13 PM, "Jim Rollenhagen"  wrote:
>>
>> >On Tue, Jul 26, 2016 at 08:36:01PM +, Steven Dake (stdake) wrote:
>> >> Dims,
>> >>
>> >> The project-config addition was debated by Andreas before this
>> >>partnership
>> >> in this press release was announced and the full intent of the
>>project
>> >>was
>> >> understood.  The argument I see used in the review  is that since
>> >>fuel-ccp
>> >> not part of Newton, it doesn't need to be in the projects.yaml file.
>> >> Given the intent of the project is obvious (to me) from the press
>> >>release
>> >> to join the big tent, my two requests still apply.  At present this
>> >> project may be perceived as "flying under the radar" and further not
>> >> following the four opens as I already stated.
>> >
>> >I'm confused, what specifically is happening that is against the four
>> >opens? What part of the press release implies big tent in the future?
>>
>> My exact words were proceeded by "may be perceived"
>
>Okay, I'm still confused what part of it may be perceived as not
>following the four opens.
>
>>
>> The press release itself implies a big effort with big contributors
>>hence
>> big tent.
>
>I guess the big tent means something different to me - that a project is
>"one of us" in that they work the same way we do, etc. I don't think
>large efforts or large contributor base matter.
>
>>
>> >
>> >>
>> >> The two requests were:
>> >>
>> >> 1. Please submit the repositories for projects.yaml TC oversight
>> >> 2. Please change Fuel's mission statement to match reality of this
>> >> announcement
>> >
>> >Why?

[openstack-dev] Reply: [Magnum] Select our project mascot/logo

2016-07-26 Thread xiangxinyong

Hi hongbin,


* Shark is very cool :)


Best Regards,
xiangxinyong
  
> Hi all,

> 
 
> Thanks for providing mascot ideas. As discussed at the team meeting, below is 
> the short list of popular mascots. I believe you will receive a link to vote 
> among them later.
 
> * Waves -  http://www.123rf.com/photo_11649085_set-of-waves.html
 
> * Kangaroo -  http://www.supercoloring.com/pages/red-kangaroo
 
> * Shark -  http://www.logoground.com/logo.php?id=10554
 
> * Majestic moose -  
> https://images.indiegogo.com/file_attachments/1328366/files/20150326083908-Mooselaughing.jpg?1427384348
 
>  
 
> Best regards,
 
> Hongbin 

From: Watson, Stephen [mailto:stephen.wat...@intel.com] 
 Sent: July-26-16 12:09 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Magnum] Select our project mascot/logo
 
 
 
 
 
+1 for kangaroo and stallion
 
 
 
And my own suggestion even though it doesn??t fit the container or name themes 
directly would be a St. Bernard because dogs and myths are cool:  
http://mentalfloss.com/article/20908/why-are-st-bernards-always-depicted-barrels-around-their-necks
 
 
 
-Stephen
 
 
  
From: Hongbin Lu 
 Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

 Date: Monday, July 25, 2016 at 5:54 PM
 To: "OpenStack Development Mailing List (not for usage questions)" 

 Subject: [openstack-dev] [Magnum] Select our project mascot/logo
 
  
 
 
   
Hi team,
 
 
 
OpenStack want to promote individual projects by choosing a mascot to represent 
the project. The idea is to create a family of logos for OpenStack projects 
that are unique, yet immediately identifiable as part  of OpenStack. OpenStack 
will be using these logos to promote each project on the OpenStack website, at 
the Summit and in marketing materials. 
 
 
 
We can select our own mascot, and then OpenStack will have an illustrator 
create the logo for us. The mascot can be anything from the natural world??an 
animal, fish, plant, or natural feature such as a mountain  or waterfall. We 
need to select our top mascot candidates by the first deadline (July 27, this 
Wednesday). There??s more info on the website: 
http://www.openstack.org/project-mascots
 
 
 
Action Item: Everyone please let me know what is your favorite mascot. You can 
either reply to this ML or discuss it in the next team meeting.
 
 
 
Best regards,
 
Hongbin__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] ?????? [Sahara] Error launching a defined domain withXML

2016-07-26 Thread ????????

3ks for your reply. But where to add [sahara]?
is nova.conf?
Can you detail it?  thanks.




--  --
??: "Qiming Teng";;
: 2016??7??27??(??) 9:34
??: "OpenStack Development Mailing List (not for usage 
questions)"; 

: Re: [openstack-dev] [Sahara] Error launching a defined domain withXML



This should add a [sahara] tag at subject line.

- Qiming

On Tue, Jul 26, 2016 at 05:46:25PM +0800,  wrote:
> hi ,
> 
> when create cluster with sahara 4.0.0 in M version ,using command line:
> 
> 
> $  time openstack dataprocessing cluster create --json 
> my_cluster_create_default.json
> ++--+
> | Field  | Value|
> ++--+
> | Anti affinity  |  |
> | Cluster template id| b7e8f1b5-1aff-4baf-977b-3ef74d4326cf |
> | Description| None |
> | Id | 47ac6404-8fc0-4d3c-b8eb-0f3a2b9e1b2c |
> | Image  | b3e899c4-a282-4337-a084-50ca0454535e |
> | Is protected   | False|
> | Is public  | False|
> | Is transient   | False|
> | Name   | my-cluster-default-1 |
> | Neutron management network | 3aaa392b-af4d-4f70-9e2e-1b71a965ff7d |
> | Node groups| master:1, worker:1   |
> | Plugin name| vanilla  |
> | Status | Validating   |
> | Use autoconfig | True |
> | User keypair id| my_stack |
> | Version| 2.7.1|
> ++--+
> $  nova list
> +--+---+++-+--+
> | ID   | Name  | 
> Status | Task State | Power State | Networks |
> +--+---+++-+--+
> | 4e3fdb6c-6805-447c-b01d-c4cb0fc1ca87 | my-cluster-default-1-master-0 | 
> BUILD  | scheduling | NOSTATE |  |
> | 95dd207b-6047-416c-a95f-6d08aa0c6409 | my-cluster-default-1-worker-0 | 
> BUILD  | scheduling | NOSTATE |  |
> +--+---+++-+--+
> 
> 
> 
> 
> an error occur :
> 
> 
> log in nova-compute.log
> 2016-07-25 18:09:47.440 37208 INFO nova.compute.resource_tracker 
> [req-8ce86863-8324-4dc3-93bf-a997d3512ab1 - - - - -] Auditing locally 
> available compute resources for node localhost.localdomain
> 2016-07-25 18:09:47.767 37208 WARNING nova.virt.libvirt.driver 
> [req-8ce86863-8324-4dc3-93bf-a997d3512ab1 - - - - -] couldn't obtain the vcpu 
> count from domain id: af17e813-fe6d-4769-b7d3-17369afd7313, exception: 
> Requested operation is not valid: cpu affinity is not supported
> 2016-07-25 18:09:47.768 37208 WARNING nova.virt.libvirt.driver 
> [req-8ce86863-8324-4dc3-93bf-a997d3512ab1 - - - - -] couldn't obtain the vcpu 
> count from domain id: eaa076c0-2930-4257-8fd7-e36033c4e86c, exception: 
> Requested operation is not valid: cpu affinity is not supported
> 2016-07-25 18:10:41.136 37208 ERROR nova.virt.libvirt.guest 
> [req-14a51b87-4b95-4b80-a042-193df77278bb 7fff70fbbf83441a9b3c4d91a5613825 
> 6cb156a82d0f486a9f50132be9438eb6 - - -] Error launching a defined domain with 
> XML: 
>   instance-00e3
> 
> 
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager 
> [req-14a51b87-4b95-4b80-a042-193df77278bb 7fff70fbbf83441a9b3c4d91a5613825 
> 6cb156a82d0f486a9f50132be9438eb6 - - -] [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313] Instance failed to spawn
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313] Traceback (most recent call last):
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313]   File 
> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2218, in 
> _build_resources
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313] yield resources
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313]   File 
> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2064, in 
> _build_and_run_instance
>

Re: [openstack-dev] [Magnum] Select our project mascot/logo

2016-07-26 Thread Hongbin Lu

Dims,

You are fast :). I believe OpenStack Foundation will coordinate in this case.

Best regards,
Hongbin

> -Original Message-
> From: Davanum Srinivas [mailto:dava...@gmail.com]
> Sent: July-26-16 9:56 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Magnum] Select our project mascot/logo
> 
> Hongbin,
> 
> Moose is already taken by Oslo team (2 summits ago :)
> 
> -- Dims
> 
> On Tue, Jul 26, 2016 at 9:48 PM, Hongbin Lu 
> wrote:
> > Hi all,
> >
> >
> >
> > Thanks for providing mascot ideas. As discussed at the team meeting,
> > below is the short list of popular mascots. I believe you will
> receive
> > a link to vote among them later.
> >
> > * Waves - http://www.123rf.com/photo_11649085_set-of-waves.html
> >
> > * Kangaroo - http://www.supercoloring.com/pages/red-kangaroo
> >
> > * Shark - http://www.logoground.com/logo.php?id=10554
> >
> > * Majestic moose -
> >
> https://images.indiegogo.com/file_attachments/1328366/files/2015032608
> > 3908-Mooselaughing.jpg?1427384348
> >
> >
> >
> > Best regards,
> >
> > Hongbin
> >
> >
> >
> > From: Watson, Stephen [mailto:stephen.wat...@intel.com]
> > Sent: July-26-16 12:09 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Magnum] Select our project mascot/logo
> >
> >
> >
> > +1 for kangaroo and stallion
> >
> >
> >
> > And my own suggestion even though it doesn’t fit the container or
> name
> > themes directly would be a St. Bernard because dogs and myths are
> cool:
> > http://mentalfloss.com/article/20908/why-are-st-bernards-always-
> depict
> > ed-barrels-around-their-necks
> >
> >
> >
> > -Stephen
> >
> >
> >
> > From: Hongbin Lu 
> > Reply-To: "OpenStack Development Mailing List (not for usage
> questions)"
> > 
> > Date: Monday, July 25, 2016 at 5:54 PM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Subject: [openstack-dev] [Magnum] Select our project mascot/logo
> >
> >
> >
> > Hi team,
> >
> >
> >
> > OpenStack want to promote individual projects by choosing a mascot to
> > represent the project. The idea is to create a family of logos for
> > OpenStack projects that are unique, yet immediately identifiable as
> part of OpenStack.
> > OpenStack will be using these logos to promote each project on the
> > OpenStack website, at the Summit and in marketing materials.
> >
> >
> >
> > We can select our own mascot, and then OpenStack will have an
> > illustrator create the logo for us. The mascot can be anything from
> > the natural world—an animal, fish, plant, or natural feature such as
> a
> > mountain or waterfall. We need to select our top mascot candidates by
> > the first deadline (July 27, this Wednesday). There’s more info on
> the website:
> > http://www.openstack.org/project-mascots
> >
> >
> >
> > Action Item: Everyone please let me know what is your favorite mascot.
> > You can either reply to this ML or discuss it in the next team
> meeting.
> >
> >
> >
> > Best regards,
> >
> > Hongbin
> >
> >
> >
> __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 
> 
> --
> Davanum Srinivas :: https://twitter.com/dims
> 
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Magnum] Select our project mascot/logo

2016-07-26 Thread Davanum Srinivas

Hongbin,

Moose is already taken by Oslo team (2 summits ago :)

-- Dims

On Tue, Jul 26, 2016 at 9:48 PM, Hongbin Lu  wrote:
> Hi all,
>
>
>
> Thanks for providing mascot ideas. As discussed at the team meeting, below
> is the short list of popular mascots. I believe you will receive a link to
> vote among them later.
>
> * Waves - http://www.123rf.com/photo_11649085_set-of-waves.html
>
> * Kangaroo - http://www.supercoloring.com/pages/red-kangaroo
>
> * Shark - http://www.logoground.com/logo.php?id=10554
>
> * Majestic moose -
> https://images.indiegogo.com/file_attachments/1328366/files/20150326083908-Mooselaughing.jpg?1427384348
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> From: Watson, Stephen [mailto:stephen.wat...@intel.com]
> Sent: July-26-16 12:09 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Magnum] Select our project mascot/logo
>
>
>
> +1 for kangaroo and stallion
>
>
>
> And my own suggestion even though it doesn’t fit the container or name
> themes directly would be a St. Bernard because dogs and myths are cool:
> http://mentalfloss.com/article/20908/why-are-st-bernards-always-depicted-barrels-around-their-necks
>
>
>
> -Stephen
>
>
>
> From: Hongbin Lu 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Monday, July 25, 2016 at 5:54 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [Magnum] Select our project mascot/logo
>
>
>
> Hi team,
>
>
>
> OpenStack want to promote individual projects by choosing a mascot to
> represent the project. The idea is to create a family of logos for OpenStack
> projects that are unique, yet immediately identifiable as part of OpenStack.
> OpenStack will be using these logos to promote each project on the OpenStack
> website, at the Summit and in marketing materials.
>
>
>
> We can select our own mascot, and then OpenStack will have an illustrator
> create the logo for us. The mascot can be anything from the natural world—an
> animal, fish, plant, or natural feature such as a mountain or waterfall. We
> need to select our top mascot candidates by the first deadline (July 27,
> this Wednesday). There’s more info on the website:
> http://www.openstack.org/project-mascots
>
>
>
> Action Item: Everyone please let me know what is your favorite mascot. You
> can either reply to this ML or discuss it in the next team meeting.
>
>
>
> Best regards,
>
> Hongbin
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Magnum] Select our project mascot/logo

2016-07-26 Thread Hongbin Lu

Hi all,

Thanks for providing mascot ideas. As discussed at the team meeting, below is 
the short list of popular mascots. I believe you will receive a link to vote 
among them later.
* Waves - http://www.123rf.com/photo_11649085_set-of-waves.html
* Kangaroo - http://www.supercoloring.com/pages/red-kangaroo
* Shark - http://www.logoground.com/logo.php?id=10554
* Majestic moose - 
https://images.indiegogo.com/file_attachments/1328366/files/20150326083908-Mooselaughing.jpg?1427384348

Best regards,
Hongbin

From: Watson, Stephen [mailto:stephen.wat...@intel.com]
Sent: July-26-16 12:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Select our project mascot/logo

+1 for kangaroo and stallion

And my own suggestion even though it doesn’t fit the container or name themes 
directly would be a St. Bernard because dogs and myths are cool: 
http://mentalfloss.com/article/20908/why-are-st-bernards-always-depicted-barrels-around-their-necks

-Stephen

From: Hongbin Lu >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, July 25, 2016 at 5:54 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [Magnum] Select our project mascot/logo

Hi team,

OpenStack want to promote individual projects by choosing a mascot to represent 
the project. The idea is to create a family of logos for OpenStack projects 
that are unique, yet immediately identifiable as part of OpenStack. OpenStack 
will be using these logos to promote each project on the OpenStack website, at 
the Summit and in marketing materials.

We can select our own mascot, and then OpenStack will have an illustrator 
create the logo for us. The mascot can be anything from the natural world—an 
animal, fish, plant, or natural feature such as a mountain or waterfall. We 
need to select our top mascot candidates by the first deadline (July 27, this 
Wednesday). There’s more info on the website: 
http://www.openstack.org/project-mascots

Action Item: Everyone please let me know what is your favorite mascot. You can 
either reply to this ML or discuss it in the next team meeting.

Best regards,
Hongbin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Sahara] Error launching a defined domain with XML

2016-07-26 Thread Qiming Teng

This should add a [sahara] tag at subject line.

- Qiming

On Tue, Jul 26, 2016 at 05:46:25PM +0800, 云淡风轻 wrote:
> hi ,
> 
> when create cluster with sahara 4.0.0 in M version ,using command line:
> 
> 
> $  time openstack dataprocessing cluster create --json 
> my_cluster_create_default.json
> ++--+
> | Field  | Value|
> ++--+
> | Anti affinity  |  |
> | Cluster template id| b7e8f1b5-1aff-4baf-977b-3ef74d4326cf |
> | Description| None |
> | Id | 47ac6404-8fc0-4d3c-b8eb-0f3a2b9e1b2c |
> | Image  | b3e899c4-a282-4337-a084-50ca0454535e |
> | Is protected   | False|
> | Is public  | False|
> | Is transient   | False|
> | Name   | my-cluster-default-1 |
> | Neutron management network | 3aaa392b-af4d-4f70-9e2e-1b71a965ff7d |
> | Node groups| master:1, worker:1   |
> | Plugin name| vanilla  |
> | Status | Validating   |
> | Use autoconfig | True |
> | User keypair id| my_stack |
> | Version| 2.7.1|
> ++--+
> $  nova list
> +--+---+++-+--+
> | ID   | Name  | 
> Status | Task State | Power State | Networks |
> +--+---+++-+--+
> | 4e3fdb6c-6805-447c-b01d-c4cb0fc1ca87 | my-cluster-default-1-master-0 | 
> BUILD  | scheduling | NOSTATE |  |
> | 95dd207b-6047-416c-a95f-6d08aa0c6409 | my-cluster-default-1-worker-0 | 
> BUILD  | scheduling | NOSTATE |  |
> +--+---+++-+--+
> 
> 
> 
> 
> an error occur :
> 
> 
> log in nova-compute.log
> 2016-07-25 18:09:47.440 37208 INFO nova.compute.resource_tracker 
> [req-8ce86863-8324-4dc3-93bf-a997d3512ab1 - - - - -] Auditing locally 
> available compute resources for node localhost.localdomain
> 2016-07-25 18:09:47.767 37208 WARNING nova.virt.libvirt.driver 
> [req-8ce86863-8324-4dc3-93bf-a997d3512ab1 - - - - -] couldn't obtain the vcpu 
> count from domain id: af17e813-fe6d-4769-b7d3-17369afd7313, exception: 
> Requested operation is not valid: cpu affinity is not supported
> 2016-07-25 18:09:47.768 37208 WARNING nova.virt.libvirt.driver 
> [req-8ce86863-8324-4dc3-93bf-a997d3512ab1 - - - - -] couldn't obtain the vcpu 
> count from domain id: eaa076c0-2930-4257-8fd7-e36033c4e86c, exception: 
> Requested operation is not valid: cpu affinity is not supported
> 2016-07-25 18:10:41.136 37208 ERROR nova.virt.libvirt.guest 
> [req-14a51b87-4b95-4b80-a042-193df77278bb 7fff70fbbf83441a9b3c4d91a5613825 
> 6cb156a82d0f486a9f50132be9438eb6 - - -] Error launching a defined domain with 
> XML: 
>   instance-00e3
> 
> 
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager 
> [req-14a51b87-4b95-4b80-a042-193df77278bb 7fff70fbbf83441a9b3c4d91a5613825 
> 6cb156a82d0f486a9f50132be9438eb6 - - -] [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313] Instance failed to spawn
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313] Traceback (most recent call last):
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313]   File 
> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2218, in 
> _build_resources
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313] yield resources
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313]   File 
> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2064, in 
> _build_and_run_instance
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313] block_device_info=block_device_info)
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313]   File 
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2768, in 
> spawn
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
>

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

2016-07-26 Thread Alex Xu

Hi,

We have weekly Nova API meeting today. The meeting is being held Wednesday
UTC1300 and irc channel is #openstack-meeting-4.

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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-07-26 Thread Tony Breeds

On Tue, Jul 26, 2016 at 05:44:06AM +, A mailing list for the OpenStack 
Stable Branch test reports. wrote:
> Build failed.
> 
> - periodic-heat-docs-liberty 
> http://logs.openstack.org/periodic-stable/periodic-heat-docs-liberty/6835807/ 
> : SUCCESS in 10m 19s
> - periodic-heat-python27-db-liberty 
> http://logs.openstack.org/periodic-stable/periodic-heat-python27-db-liberty/0dd2d48/
>  : FAILURE in 8m 19s

This job started failing recently [1] with the following error[2]:
 novaclient.exceptions.Forbidden: 'novaclient.v2.client.Client' is not designed 
to be initialized directly. It is inner class of novaclient. You should use 
'novaclient.client.Client' instead. Related lp bug-report: 1493576 (HTTP 403)

This is because the heat tests on the liberty branch are using the novaclient 
from master.

As I see it there are 2 options
1. Add upper-constraints support to heat, this will ensure that all client
   libraries are used appropriately per release.
2. Backport variations of:
I8f42e4ab446b0369d4c53fa4d3a734689ab541e3
I428abb4ca05847da8ffc2da7157aa5c34263a205
  To mitaka and liberty
3. Something else I haven't thought of

From a stable-maint point of view option 1 is preferred.  Is there anything
specific to heat that would prevent it from working with upper-constraints
enabled?

Yours Tony.

[1] 
http://status.openstack.org//openstack-health/#/job/periodic-heat-python27-db-liberty
[2] 
http://logs.openstack.org/periodic-stable/periodic-heat-python27-db-liberty/0dd2d48/console.html#_2016-07-26_05_35_18_970003

signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Hi Jim,

The issue is, as I see it, a parallel activity to one of the that is currently 
accepted into the Big Tent, aka Containerized Deployment:
Kolla's mission:
To provide production-ready containers and deployment tools for operating 
OpenStack clouds.

Fuel's mission:
To streamline and accelerate the process of deploying, testing and maintaining 
various configurations of OpenStack at scale.

To me, this totally lets both projects work together, fuel providing the bare 
metal provisioning/kubernetes provisioning, the k8s orchestration to manage 
pods/deployments/etc, its awesome ui, etc, and using kolla-kubernetes/kolla for 
the container bits/k8s templates. Otherwise there's a quite a bit duplication 
of work. This feels in line with fuel trying to reimplement another core 
openstack project (say, nova)

When fuel-ccp was proposed, it was proposed as more of a proof of concept and 
not a big tent thing: https://review.openstack.org/#/c/331139/

If you look at contributions to each of kolla-kubernetes its a fairly diverse 
set of contributors:
http://stackalytics.com/?module=kolla-kubernetes
fuel-ccp doesn't show up in stackalytics but if you check the commit log its 
very heavily dominated by one company. That's not really open development.

The kolla-kubernetes project was having discussions about how to work with the 
Fuel team to ensure that their needs were met, when they suddenly stopped 
talking and spawned a new project. This doesn't feel like working with the 
community. Our differences didn't feel unsolvable to the point of spawning a 
new, competing project.

Now its being advertised very openly. This feels like it was snuck in the back 
door, behind the communities back then pushed hard.

OpenStack is already distressingly fractured already. Can we try and work 
together rather then keep making an already pretty bad situation worse? Are the 
technical differences really that far apart to prevent it?

Does that help to clarify the concern?

Thanks,
Kevin

From: Jim Rollenhagen [j...@jimrollenhagen.com]
Sent: Tuesday, July 26, 2016 3:28 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

On Tue, Jul 26, 2016 at 09:42:10PM +, Steven Dake (stdake) wrote:
>
>
> On 7/26/16, 2:13 PM, "Jim Rollenhagen"  wrote:
>
> >On Tue, Jul 26, 2016 at 08:36:01PM +, Steven Dake (stdake) wrote:
> >> Dims,
> >>
> >> The project-config addition was debated by Andreas before this
> >>partnership
> >> in this press release was announced and the full intent of the project
> >>was
> >> understood.  The argument I see used in the review  is that since
> >>fuel-ccp
> >> not part of Newton, it doesn't need to be in the projects.yaml file.
> >> Given the intent of the project is obvious (to me) from the press
> >>release
> >> to join the big tent, my two requests still apply.  At present this
> >> project may be perceived as "flying under the radar" and further not
> >> following the four opens as I already stated.
> >
> >I'm confused, what specifically is happening that is against the four
> >opens? What part of the press release implies big tent in the future?
>
> My exact words were proceeded by "may be perceived"

Okay, I'm still confused what part of it may be perceived as not
following the four opens.

>
> The press release itself implies a big effort with big contributors hence
> big tent.

I guess the big tent means something different to me - that a project is
"one of us" in that they work the same way we do, etc. I don't think
large efforts or large contributor base matter.

>
> >
> >>
> >> The two requests were:
> >>
> >> 1. Please submit the repositories for projects.yaml TC oversight
> >> 2. Please change Fuel's mission statement to match reality of this
> >> announcement
> >
> >Why? The current mission statement is "To streamline and accelerate the
> >process of deploying, testing and maintaining various configurations of
> >OpenStack at scale." I don't see why anything about this announcement
> >doesn't fit into that mission statement.
>
> That mission statement doesn't match intent, which is to produce a
> kubernetes deployment of openstack.  I don't feel "various configurations"
> cuts it.

Well, it's unclear to me if Fuel is pivoting completely to Kubernetes or
adding it as an option. That said, I suspect that many configurations
will still be a thing, just that everything runs on Kubernetes.

>
> But its really up to the Fuel team, not you or I.

Indeed, mostly just curious as your email was pretty strongly worded and
I didn't really understand it.

// jim

>
> Regards
> -steve
>
> >
> >// jim
> >
> >>
> >> Regards
> >> -steve
> >>
> >> On 7/26/16, 1:18 PM, "Davanum Srinivas"  wrote:
> >>
> >> >Steven,
> >> >
> >> >fyi, This was debated in the project-config review:
> >>

Re: [openstack-dev] [neutron][networking-l2gw] Python 3 support

2016-07-26 Thread Armando M.

On 25 July 2016 at 04:13, Gary Kotton  wrote:

> Hi,
>
> This morning I discovered that the project does not have python 3 support.
> This was due to the fact that it broke the vmware-nsx unit tests.
>
> I have started to kick the wheels with the python 3 support:
>
> 1.   Project infra - https://review.openstack.org/346701 (currently
> non-voting)
>
> 2.   L2 gw:
>
> a.   https://review.openstack.org/#/c/346638/ - this is currently
> blocking all decomposed plugins invoking l2-gw unit tests
>
> b.   https://review.openstack.org/#/c/346658/
>
> c.   https://review.openstack.org/#/c/346697/
>
> If anyone else would like to jump in and help then please let me know.
> Hopefully we can get this done in a couple of days.
>

Thanks for doing this. Another parallel effort Henry et al. are
spearheading is elevating the bar as far as DB migrations and functional
testing go, in preparation of effort [1] and consolidation effort [2].

[1] https://etherpad.openstack.org/p/neutron-stadium-tenant2project
[2] https://review.openstack.org/#/c/335739/

A luta continua
>
> Thanks
>
> Gary
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Announcing Gertty 1.4.0

2016-07-26 Thread James E. Blair

Announcing Gertty 1.4.0
===

Gertty is a console-based interface to the Gerrit Code Review system.

Gertty is designed to support a workflow similar to reading network
news or mail.  It syncs information from Gerrit to local storage to
support disconnected operation and easy manipulation of local git
repos.  It is fast and efficient at dealing with large numbers of
changes and projects.

The full README may be found here:

  https://git.openstack.org/cgit/openstack/gertty/tree/README.rst

Changes since 1.3.0:


* Gertty is now available in Gentoo.

* Large changes with many patchsets load faster.

* The change screen now displays changes which may conflict with the
  current change.

* Added support for a command socket so that external applications may
  request Gertty to open a change.  An example of how to configure
  Gerrit URLs to automatically open in Gertty when clicked in the
  unicode-rxvt terminal emulater is provided in the documentation.

* Added an optional vi-style keymap and navigation commands.

* Added "project topics" -- the ability to group projects in the
  project list.

* Added support for the process mark on the project list.

* Email addresses are displayed in the change screen.

* Added support for the "projects:" search term.

* Added support for searching by last-seen.  This can be used to
  create a dashboard of changes that have been recently viewed in
  Gertty.  See the example config files for how to set this up.

* The project and change lists are now searchable with the interactive
  search command.

* The change list now displays more columns if there is room.

* Added a navigation breadcrumb footer.

* Added a "Reply" button to the change screen to facilitate quoted
  replies to messages.

* When re-reviewing a change, the review dialog defaults to previous
  values.

* Added support for batch abandon and restore.

* Unified diff display now groups changed lines better.

* Added lockfile support to prevent multiple copies of Gertty from
  accessing the same database.

* Added support for form-based authentication.

* Added an option to specify the URL for cloning git repos.

* In the default keymap, the sorting commands now take two keystrokes
  (e.g., "Sn" for sort by number) to facilitate more sorting options.

* Multi-keystroke commands now display suggestion completions.

* Dashboards may now specify their default sorting option.

* Sphinx-based documentation now availablet at
  http://gertty.readthedocs.io/

* Added an option to disable mouse support.

* Several bug fixes related to:
  * Improved handling of abandoned related changes.
  * Fixed "too many SQL variables" error which occurred in large
projects.
  * Corrected ordering of test results.
  * Treat HTTP 503 responses as server-offline so that the action will
be retried later.
  * Handle additional python-requests SSL errors.
  * Better handle missing git commits.
  * Several Unicode fixes.
  * Support more recent versions of GitPython.
  * Better handle more than one change result when searching.
  * Fix a crash on permissions-only changes.
  * Fixes to support some changes in Gerrit 2.8 and 2.9.
  * Python 3 improvements.
  * Correct the display of comments at the start of a file.

Thanks to the following people whose changes are included in this
release:

  Christoph Gysin
  Cody A.W. Somerville
  Craige McWhirter
  David Shrewsbury
  Doug Hellmann
  Doug Wiegley
  Jan Kundrát
  Jay Pipes
  Jim Rollenhagen
  K Jonathan Harker
  Martin André
  Matthew Oliver
  Matthew Thode
  Matthew Treinish
  Matthias Runge

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-26 Thread Jim Rollenhagen

On Tue, Jul 26, 2016 at 09:42:10PM +, Steven Dake (stdake) wrote:
> 
> 
> On 7/26/16, 2:13 PM, "Jim Rollenhagen"  wrote:
> 
> >On Tue, Jul 26, 2016 at 08:36:01PM +, Steven Dake (stdake) wrote:
> >> Dims,
> >> 
> >> The project-config addition was debated by Andreas before this
> >>partnership
> >> in this press release was announced and the full intent of the project
> >>was
> >> understood.  The argument I see used in the review  is that since
> >>fuel-ccp
> >> not part of Newton, it doesn't need to be in the projects.yaml file.
> >> Given the intent of the project is obvious (to me) from the press
> >>release
> >> to join the big tent, my two requests still apply.  At present this
> >> project may be perceived as "flying under the radar" and further not
> >> following the four opens as I already stated.
> >
> >I'm confused, what specifically is happening that is against the four
> >opens? What part of the press release implies big tent in the future?
> 
> My exact words were proceeded by "may be perceived"

Okay, I'm still confused what part of it may be perceived as not
following the four opens.

> 
> The press release itself implies a big effort with big contributors hence
> big tent.

I guess the big tent means something different to me - that a project is
"one of us" in that they work the same way we do, etc. I don't think
large efforts or large contributor base matter.

> 
> >
> >> 
> >> The two requests were:
> >> 
> >> 1. Please submit the repositories for projects.yaml TC oversight
> >> 2. Please change Fuel's mission statement to match reality of this
> >> announcement 
> >
> >Why? The current mission statement is "To streamline and accelerate the
> >process of deploying, testing and maintaining various configurations of
> >OpenStack at scale." I don't see why anything about this announcement
> >doesn't fit into that mission statement.
> 
> That mission statement doesn't match intent, which is to produce a
> kubernetes deployment of openstack.  I don't feel "various configurations"
> cuts it.

Well, it's unclear to me if Fuel is pivoting completely to Kubernetes or
adding it as an option. That said, I suspect that many configurations
will still be a thing, just that everything runs on Kubernetes.

> 
> But its really up to the Fuel team, not you or I.

Indeed, mostly just curious as your email was pretty strongly worded and
I didn't really understand it.

// jim

> 
> Regards
> -steve
> 
> >
> >// jim
> >
> >> 
> >> Regards
> >> -steve
> >> 
> >> On 7/26/16, 1:18 PM, "Davanum Srinivas"  wrote:
> >> 
> >> >Steven,
> >> >
> >> >fyi, This was debated in the project-config review:
> >> >https://review.openstack.org/#/c/335584/
> >> >
> >> >
> >> >Thanks,
> >> >Dims
> >> >
> >> >On Tue, Jul 26, 2016 at 3:47 PM, Steven Dake (stdake)
> >>
> >> >wrote:
> >> >> Dims,
> >> >>
> >> >> Given the strong language around partnership between Intel, Mirantis,
> >> >>and
> >> >> Google in that press release, and the activity in the review queue (2
> >> >> pages of outstanding reviews) it seems clear to me that the intent is
> >> >>for
> >> >> this part of Fuel to participate in the big tent.  The right thing
> >>to do
> >> >> here is for fuel-ccp to submit their repos to TC oversight by adding
> >> >>them
> >> >> to the official project list.
> >> >>
> >> >> Fuel requires a mission change, or it may be perceived that Fuel
> >>itself
> >> >> does not adhere to the Four Opens [1] specifically Open Development
> >>and
> >> >> Open Community.
> >> >>
> >> >> Regards
> >> >> -steve
> >> >>
> >> >> [1] 
> >> 
> https://github.com/openstack/governance/blob/master/reference/opens.rst
> >> >>
> >> >> On 7/26/16, 11:15 AM, "Davanum Srinivas"  wrote:
> >> >>
> >> >>>And. it's here in OpenStack:
> >> >>>
> >> >>>Look for fuel-ccp-* in http://git.openstack.org/cgit/ or the gerrit
> >> >>>search
> >> 
> >https://review.openstack.org/#/q/status:open+branch:master+project:^op
> >en
> >> >>>st
> >> >>>ack/fuel-ccp.*
> >> >>>
> >> >>>-- Dims
> >> >>>
> >> >>>On Tue, Jul 26, 2016 at 1:53 PM, Fox, Kevin M 
> >> >>>wrote:
> >>  They are starting their own project.
> >>  
> >>  From: Stephen Hindle [shin...@llnw.com]
> >>  Sent: Tuesday, July 26, 2016 10:35 AM
> >>  To: OpenStack Development Mailing List (not for usage questions)
> >>  Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is
> >>getting
> >> Fuel CCP (docker/k8s) kicked off
> >> 
> >>  So just saw this:
> >> 
> >> 
> >>http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-K
> >>ub
> >> er
> >> netes-Mirantis-fuels-Fuel-with-Google-Intel-heat
> >> 
> >>  Wonder if that means we'll get more devs or maybe some prebuilt
> >>  containers for Kolla?
> >> 
> >> 
> >>  --
> >>  Stephen Hindle - Senior Systems

[openstack-dev] [RefStack] - No RefStack IRC Meeting on August 2, 2016

2016-07-26 Thread Catherine Cuong Diep



Hi everyone,

We will not have IRC meeting on August 2, 2016 since many of the RefStack
team members will be attending the DefCore mid-cycle. We will resume our
weekly IRC meeting on August 9, 2016.

- Catherine
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off



On 7/26/16, 2:13 PM, "Jim Rollenhagen"  wrote:

>On Tue, Jul 26, 2016 at 08:36:01PM +, Steven Dake (stdake) wrote:
>> Dims,
>> 
>> The project-config addition was debated by Andreas before this
>>partnership
>> in this press release was announced and the full intent of the project
>>was
>> understood.  The argument I see used in the review  is that since
>>fuel-ccp
>> not part of Newton, it doesn't need to be in the projects.yaml file.
>> Given the intent of the project is obvious (to me) from the press
>>release
>> to join the big tent, my two requests still apply.  At present this
>> project may be perceived as "flying under the radar" and further not
>> following the four opens as I already stated.
>
>I'm confused, what specifically is happening that is against the four
>opens? What part of the press release implies big tent in the future?

My exact words were proceeded by "may be perceived"

The press release itself implies a big effort with big contributors hence
big tent.

>
>> 
>> The two requests were:
>> 
>> 1. Please submit the repositories for projects.yaml TC oversight
>> 2. Please change Fuel's mission statement to match reality of this
>> announcement 
>
>Why? The current mission statement is "To streamline and accelerate the
>process of deploying, testing and maintaining various configurations of
>OpenStack at scale." I don't see why anything about this announcement
>doesn't fit into that mission statement.

That mission statement doesn't match intent, which is to produce a
kubernetes deployment of openstack.  I don't feel "various configurations"
cuts it.

But its really up to the Fuel team, not you or I.

Regards
-steve

>
>// jim
>
>> 
>> Regards
>> -steve
>> 
>> On 7/26/16, 1:18 PM, "Davanum Srinivas"  wrote:
>> 
>> >Steven,
>> >
>> >fyi, This was debated in the project-config review:
>> >https://review.openstack.org/#/c/335584/
>> >
>> >
>> >Thanks,
>> >Dims
>> >
>> >On Tue, Jul 26, 2016 at 3:47 PM, Steven Dake (stdake)
>>
>> >wrote:
>> >> Dims,
>> >>
>> >> Given the strong language around partnership between Intel, Mirantis,
>> >>and
>> >> Google in that press release, and the activity in the review queue (2
>> >> pages of outstanding reviews) it seems clear to me that the intent is
>> >>for
>> >> this part of Fuel to participate in the big tent.  The right thing
>>to do
>> >> here is for fuel-ccp to submit their repos to TC oversight by adding
>> >>them
>> >> to the official project list.
>> >>
>> >> Fuel requires a mission change, or it may be perceived that Fuel
>>itself
>> >> does not adhere to the Four Opens [1] specifically Open Development
>>and
>> >> Open Community.
>> >>
>> >> Regards
>> >> -steve
>> >>
>> >> [1] 
>> 
https://github.com/openstack/governance/blob/master/reference/opens.rst
>> >>
>> >> On 7/26/16, 11:15 AM, "Davanum Srinivas"  wrote:
>> >>
>> >>>And. it's here in OpenStack:
>> >>>
>> >>>Look for fuel-ccp-* in http://git.openstack.org/cgit/ or the gerrit
>> >>>search
>> 
>https://review.openstack.org/#/q/status:open+branch:master+project:^op
>en
>> >>>st
>> >>>ack/fuel-ccp.*
>> >>>
>> >>>-- Dims
>> >>>
>> >>>On Tue, Jul 26, 2016 at 1:53 PM, Fox, Kevin M 
>> >>>wrote:
>>  They are starting their own project.
>>  
>>  From: Stephen Hindle [shin...@llnw.com]
>>  Sent: Tuesday, July 26, 2016 10:35 AM
>>  To: OpenStack Development Mailing List (not for usage questions)
>>  Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is
>>getting
>> Fuel CCP (docker/k8s) kicked off
>> 
>>  So just saw this:
>> 
>> 
>>http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-K
>>ub
>> er
>> netes-Mirantis-fuels-Fuel-with-Google-Intel-heat
>> 
>>  Wonder if that means we'll get more devs or maybe some prebuilt
>>  containers for Kolla?
>> 
>> 
>>  --
>>  Stephen Hindle - Senior Systems Engineer
>>  480.807.8189 480.807.8189
>>  www.limelight.com Delivering Faster Better
>> 
>>  Join the conversation
>> 
>>  at Limelight Connect
>> 
>>  --
>>  The information in this message may be confidential.  It is
>>intended
>> solely
>>  for
>>  the addressee(s).  If you are not the intended recipient, any
>> disclosure,
>>  copying or distribution of the message, or any action or omission
>> taken
>> by
>>  you
>>  in reliance on it, is prohibited and may be unlawful.  Please
>> immediately
>>  contact the sender if you have received this message in error.
>> 
>> 
>> 
>> 
>>_
>>__
>> __
>> _
>>  OpenStack Development Mailing List (not for usage questions)
>>  Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

+1

From: Steven Dake (stdake) [std...@cisco.com]
Sent: Tuesday, July 26, 2016 12:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

Dims,

Given the strong language around partnership between Intel, Mirantis, and
Google in that press release, and the activity in the review queue (2
pages of outstanding reviews) it seems clear to me that the intent is for
this part of Fuel to participate in the big tent.  The right thing to do
here is for fuel-ccp to submit their repos to TC oversight by adding them
to the official project list.

Fuel requires a mission change, or it may be perceived that Fuel itself
does not adhere to the Four Opens [1] specifically Open Development and
Open Community.

Regards
-steve

[1] https://github.com/openstack/governance/blob/master/reference/opens.rst

On 7/26/16, 11:15 AM, "Davanum Srinivas"  wrote:

>And. it's here in OpenStack:
>
>Look for fuel-ccp-* in http://git.openstack.org/cgit/ or the gerrit search
>https://review.openstack.org/#/q/status:open+branch:master+project:^openst
>ack/fuel-ccp.*
>
>-- Dims
>
>On Tue, Jul 26, 2016 at 1:53 PM, Fox, Kevin M  wrote:
>> They are starting their own project.
>> 
>> From: Stephen Hindle [shin...@llnw.com]
>> Sent: Tuesday, July 26, 2016 10:35 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting
>>Fuel CCP (docker/k8s) kicked off
>>
>> So just saw this:
>>
>>http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-Kuber
>>netes-Mirantis-fuels-Fuel-with-Google-Intel-heat
>>
>> Wonder if that means we'll get more devs or maybe some prebuilt
>> containers for Kolla?
>>
>>
>> --
>> Stephen Hindle - Senior Systems Engineer
>> 480.807.8189 480.807.8189
>> www.limelight.com Delivering Faster Better
>>
>> Join the conversation
>>
>> at Limelight Connect
>>
>> --
>> The information in this message may be confidential.  It is intended
>>solely
>> for
>> the addressee(s).  If you are not the intended recipient, any
>>disclosure,
>> copying or distribution of the message, or any action or omission taken
>>by
>> you
>> in reliance on it, is prohibited and may be unlawful.  Please
>>immediately
>> contact the sender if you have received this message in error.
>>
>>
>>
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>--
>Davanum Srinivas :: https://twitter.com/dims
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Modifying just a few values on overcloud redeploy

2016-07-26 Thread Adam Young

I worked through how to do a complete clone of the templates to do a 
deploy and change a couple values here:


http://adam.younglogic.com/2016/06/custom-overcloud-deploys/

However, all I want to do is to set two config options in Keystone.  Is 
there a simple way to just modify the two values below?  Ideally, just 
making a single env file and passing it via openstack overcloud deploy 
-e somehow.



|'identity/domain_specific_drivers_enabled'||: value => ||'True'||;
|

|'identity/||domain_configurations_from_database||'||: value => ||'True'||;
|

|
|

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-26 Thread Jim Rollenhagen

On Tue, Jul 26, 2016 at 08:36:01PM +, Steven Dake (stdake) wrote:
> Dims,
> 
> The project-config addition was debated by Andreas before this partnership
> in this press release was announced and the full intent of the project was
> understood.  The argument I see used in the review  is that since fuel-ccp
> not part of Newton, it doesn't need to be in the projects.yaml file.
> Given the intent of the project is obvious (to me) from the press release
> to join the big tent, my two requests still apply.  At present this
> project may be perceived as "flying under the radar" and further not
> following the four opens as I already stated.

I'm confused, what specifically is happening that is against the four
opens? What part of the press release implies big tent in the future?

> 
> The two requests were:
> 
> 1. Please submit the repositories for projects.yaml TC oversight
> 2. Please change Fuel's mission statement to match reality of this
> announcement 

Why? The current mission statement is "To streamline and accelerate the
process of deploying, testing and maintaining various configurations of
OpenStack at scale." I don't see why anything about this announcement
doesn't fit into that mission statement.

// jim

> 
> Regards
> -steve
> 
> On 7/26/16, 1:18 PM, "Davanum Srinivas"  wrote:
> 
> >Steven,
> >
> >fyi, This was debated in the project-config review:
> >https://review.openstack.org/#/c/335584/
> >
> >
> >Thanks,
> >Dims
> >
> >On Tue, Jul 26, 2016 at 3:47 PM, Steven Dake (stdake) 
> >wrote:
> >> Dims,
> >>
> >> Given the strong language around partnership between Intel, Mirantis,
> >>and
> >> Google in that press release, and the activity in the review queue (2
> >> pages of outstanding reviews) it seems clear to me that the intent is
> >>for
> >> this part of Fuel to participate in the big tent.  The right thing to do
> >> here is for fuel-ccp to submit their repos to TC oversight by adding
> >>them
> >> to the official project list.
> >>
> >> Fuel requires a mission change, or it may be perceived that Fuel itself
> >> does not adhere to the Four Opens [1] specifically Open Development and
> >> Open Community.
> >>
> >> Regards
> >> -steve
> >>
> >> [1] 
> >>https://github.com/openstack/governance/blob/master/reference/opens.rst
> >>
> >> On 7/26/16, 11:15 AM, "Davanum Srinivas"  wrote:
> >>
> >>>And. it's here in OpenStack:
> >>>
> >>>Look for fuel-ccp-* in http://git.openstack.org/cgit/ or the gerrit
> >>>search
> >>>https://review.openstack.org/#/q/status:open+branch:master+project:^open
> >>>st
> >>>ack/fuel-ccp.*
> >>>
> >>>-- Dims
> >>>
> >>>On Tue, Jul 26, 2016 at 1:53 PM, Fox, Kevin M 
> >>>wrote:
>  They are starting their own project.
>  
>  From: Stephen Hindle [shin...@llnw.com]
>  Sent: Tuesday, July 26, 2016 10:35 AM
>  To: OpenStack Development Mailing List (not for usage questions)
>  Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting
> Fuel CCP (docker/k8s) kicked off
> 
>  So just saw this:
> 
> http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-Kub
> er
> netes-Mirantis-fuels-Fuel-with-Google-Intel-heat
> 
>  Wonder if that means we'll get more devs or maybe some prebuilt
>  containers for Kolla?
> 
> 
>  --
>  Stephen Hindle - Senior Systems Engineer
>  480.807.8189 480.807.8189
>  www.limelight.com Delivering Faster Better
> 
>  Join the conversation
> 
>  at Limelight Connect
> 
>  --
>  The information in this message may be confidential.  It is intended
> solely
>  for
>  the addressee(s).  If you are not the intended recipient, any
> disclosure,
>  copying or distribution of the message, or any action or omission
> taken
> by
>  you
>  in reliance on it, is prohibited and may be unlawful.  Please
> immediately
>  contact the sender if you have received this message in error.
> 
> 
> 
> ___
> __
> _
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> __
> _
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>>
> >>>--
> >>>Davanum Srinivas :: https://twitter.com/dims
> >>>
> >>>
> >>>__
> >>>OpenStack Development Mailing List (not for

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Dims,

The project-config addition was debated by Andreas before this partnership
in this press release was announced and the full intent of the project was
understood.  The argument I see used in the review  is that since fuel-ccp
not part of Newton, it doesn't need to be in the projects.yaml file.
Given the intent of the project is obvious (to me) from the press release
to join the big tent, my two requests still apply.  At present this
project may be perceived as "flying under the radar" and further not
following the four opens as I already stated.

The two requests were:

1. Please submit the repositories for projects.yaml TC oversight
2. Please change Fuel's mission statement to match reality of this
announcement 

Regards
-steve

On 7/26/16, 1:18 PM, "Davanum Srinivas"  wrote:

>Steven,
>
>fyi, This was debated in the project-config review:
>https://review.openstack.org/#/c/335584/
>
>
>Thanks,
>Dims
>
>On Tue, Jul 26, 2016 at 3:47 PM, Steven Dake (stdake) 
>wrote:
>> Dims,
>>
>> Given the strong language around partnership between Intel, Mirantis,
>>and
>> Google in that press release, and the activity in the review queue (2
>> pages of outstanding reviews) it seems clear to me that the intent is
>>for
>> this part of Fuel to participate in the big tent.  The right thing to do
>> here is for fuel-ccp to submit their repos to TC oversight by adding
>>them
>> to the official project list.
>>
>> Fuel requires a mission change, or it may be perceived that Fuel itself
>> does not adhere to the Four Opens [1] specifically Open Development and
>> Open Community.
>>
>> Regards
>> -steve
>>
>> [1] 
>>https://github.com/openstack/governance/blob/master/reference/opens.rst
>>
>> On 7/26/16, 11:15 AM, "Davanum Srinivas"  wrote:
>>
>>>And. it's here in OpenStack:
>>>
>>>Look for fuel-ccp-* in http://git.openstack.org/cgit/ or the gerrit
>>>search
>>>https://review.openstack.org/#/q/status:open+branch:master+project:^open
>>>st
>>>ack/fuel-ccp.*
>>>
>>>-- Dims
>>>
>>>On Tue, Jul 26, 2016 at 1:53 PM, Fox, Kevin M 
>>>wrote:
 They are starting their own project.
 
 From: Stephen Hindle [shin...@llnw.com]
 Sent: Tuesday, July 26, 2016 10:35 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting
Fuel CCP (docker/k8s) kicked off

 So just saw this:

http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-Kub
er
netes-Mirantis-fuels-Fuel-with-Google-Intel-heat

 Wonder if that means we'll get more devs or maybe some prebuilt
 containers for Kolla?


 --
 Stephen Hindle - Senior Systems Engineer
 480.807.8189 480.807.8189
 www.limelight.com Delivering Faster Better

 Join the conversation

 at Limelight Connect

 --
 The information in this message may be confidential.  It is intended
solely
 for
 the addressee(s).  If you are not the intended recipient, any
disclosure,
 copying or distribution of the message, or any action or omission
taken
by
 you
 in reliance on it, is prohibited and may be unlawful.  Please
immediately
 contact the sender if you have received this message in error.



___
__
_
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
__
_
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>--
>>>Davanum Srinivas :: https://twitter.com/dims
>>>
>>>
>>>__
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: 
>>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>-- 
>Davanum Srinivas :: https://twitter.com/dims
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [puppet] mascot/logo ideas

2016-07-26 Thread Emilien Macchi

We have 6 votes in total, results are:

2 votes for wolf.
2 votes for  tardigrade - https://en.wikipedia.org/wiki/Tardigrade
1 vote for axolotl - https://en.wikipedia.org/wiki/Axolotl
1 vote for dog puppet:
https://img1.etsystatic.com/000/0/5613081/il_fullxfull.241000707.jpg

Sounds like we haven't reached a consensus and failed to get more
votes... I would propose to either report our vote or cancel and
choose no mascot.
Thoughts?

On Mon, Jul 25, 2016 at 10:27 PM, Emilien Macchi  wrote:
> Hi,
>
> So we have until July 27th to take the decision about our mascot.
> If you are interested to vote, please add +1 on the proposals on the
> etherpad [1].
>
> By Wednesday, we'll take the one with the most of +1
>
> Thanks,
>
> [1] https://etherpad.openstack.org/p/puppet-openstack-mascot-logo
>
> On Tue, Jul 12, 2016 at 11:23 AM, Emilien Macchi  wrote:
>> Hey,
>>
>> During the meeting we decided to use etherpad to submit new ideas for
>> our mascot / logo [1]:
>> https://etherpad.openstack.org/p/puppet-openstack-mascot-logo
>>
>> Feel free to use your imagination as long you stay SFW :-)
>>
>> Thanks,
>>
>> [1] http://osdir.com/ml/openstack-dev/2016-07/msg00456.html
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [E] [TripleO] scripts to do post deployment analysis of an overcloud

2016-07-26 Thread Gonéri Le Bouder

"Gordon, Kent"  writes:

Oops: https://github.com/goneri/tripleo-stack-dump

-- 
Gonéri Le Bouder


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-26 Thread Davanum Srinivas

Steven,

fyi, This was debated in the project-config review:
https://review.openstack.org/#/c/335584/


Thanks,
Dims

On Tue, Jul 26, 2016 at 3:47 PM, Steven Dake (stdake)  wrote:
> Dims,
>
> Given the strong language around partnership between Intel, Mirantis, and
> Google in that press release, and the activity in the review queue (2
> pages of outstanding reviews) it seems clear to me that the intent is for
> this part of Fuel to participate in the big tent.  The right thing to do
> here is for fuel-ccp to submit their repos to TC oversight by adding them
> to the official project list.
>
> Fuel requires a mission change, or it may be perceived that Fuel itself
> does not adhere to the Four Opens [1] specifically Open Development and
> Open Community.
>
> Regards
> -steve
>
> [1] https://github.com/openstack/governance/blob/master/reference/opens.rst
>
> On 7/26/16, 11:15 AM, "Davanum Srinivas"  wrote:
>
>>And. it's here in OpenStack:
>>
>>Look for fuel-ccp-* in http://git.openstack.org/cgit/ or the gerrit search
>>https://review.openstack.org/#/q/status:open+branch:master+project:^openst
>>ack/fuel-ccp.*
>>
>>-- Dims
>>
>>On Tue, Jul 26, 2016 at 1:53 PM, Fox, Kevin M  wrote:
>>> They are starting their own project.
>>> 
>>> From: Stephen Hindle [shin...@llnw.com]
>>> Sent: Tuesday, July 26, 2016 10:35 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting
>>>Fuel CCP (docker/k8s) kicked off
>>>
>>> So just saw this:
>>>
>>>http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-Kuber
>>>netes-Mirantis-fuels-Fuel-with-Google-Intel-heat
>>>
>>> Wonder if that means we'll get more devs or maybe some prebuilt
>>> containers for Kolla?
>>>
>>>
>>> --
>>> Stephen Hindle - Senior Systems Engineer
>>> 480.807.8189 480.807.8189
>>> www.limelight.com Delivering Faster Better
>>>
>>> Join the conversation
>>>
>>> at Limelight Connect
>>>
>>> --
>>> The information in this message may be confidential.  It is intended
>>>solely
>>> for
>>> the addressee(s).  If you are not the intended recipient, any
>>>disclosure,
>>> copying or distribution of the message, or any action or omission taken
>>>by
>>> you
>>> in reliance on it, is prohibited and may be unlawful.  Please
>>>immediately
>>> contact the sender if you have received this message in error.
>>>
>>>
>>>
>>>_
>>>_
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>_
>>>_
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>--
>>Davanum Srinivas :: https://twitter.com/dims
>>
>>__
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [meghdwar] Base code to use and irc call agenda

2016-07-26 Thread prakash RAMCHANDRAN

Hi all,
Please join the meeting  for API and codes decision 
Meeting Wednesday 27th (14 Hr-15 Hr UTC )   [7AM-8AM PDT]

irc #openstck-megdwar
Follow up 1 The last meeting  agenda and actions taken or pending 
2 Megdwar Gateway API discussions 
3. What other modules are needed in OpenStack 'meghdwar'   a. Cloudlet 
(existing)
   b  Cloudlet Clinet (existing)
   c. Cloudlet Gateway Management  (Cluster Management)
   d. python  Cloudlet  Cluster Management 
   e. Cloudlet Agent 
   f. Cloudlet horizon plug-in for supporting d & e as GUI instead as CLI
4. How do we go about priority 
5. Any other missing items. 

thankspramchan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] service validation during deployment steps

2016-07-26 Thread Emilien Macchi

I would love to hear some feedback about $topic, thanks.

On Fri, Jul 15, 2016 at 11:31 AM, Emilien Macchi  wrote:
> Hi,
>
> Some people on the field brought interesting feedback:
>
> "As a TripleO User, I would like the deployment to stop immediately
> after an resource creation failure during a step of the deployment and
> be able to easily understand what service or resource failed to be
> installed".
>
> Example:
> If during step4 Puppet tries to deploy Neutron and OVS, but OVS fails
> to start for some reasons, deployment should stop at the end of the
> step.
>
> So there are 2 things in this user story:
>
> 1) Be able to run some service validation within a step deployment.
> Note about the implementation: make the validation composable per
> service (OVS, nova, etc) and not per role (compute, controller, etc).
>
> 2) Make this information readable and easy to access and understand
> for our users.
>
> I have a proof-of-concept for 1) and partially 2), with the example of
> OVS: https://review.openstack.org/#/c/342202/
> This patch will make sure OVS is actually usable at step 4 by running
> 'ovs-vsctl show' during the Puppet catalog and if it's working, it
> will create a Puppet anchor. This anchor is currently not useful but
> could be in future if we want to rely on it for orchestration.
> I wrote the service validation in Puppet 2 years ago when doing Spinal
> Stack with eNovance:
> https://github.com/openstack/puppet-openstacklib/blob/master/manifests/service_validation.pp
> I think we could re-use it very easily, it has been proven to work.
> Also, the code is within our Puppet profiles, so it's by design
> composable and we don't need to make any connection with our current
> services with some magic. Validation will reside within Puppet
> manifests.
> If you look my PoC, this code could even live in puppet-vswitch itself
> (we already have this code for puppet-nova, and some others).
>
> Ok now, what if validation fails?
> I'm testing it here: https://review.openstack.org/#/c/342205/
> If you look at /var/log/messages, you'll see:
>
> Error: 
> /Stage[main]/Tripleo::Profile::Base::Neutron::Ovs/Openstacklib::Service_validation[openvswitch]/Exec[execute
> openvswitch validation]/returns: change from notrun to 0 failed
>
> So it's pretty clear by looking at logs that openvswitch service
> validation failed and something is wrong. You'll also notice in the
> logs that deployed stopped at step 4 since OVS is not considered to
> run.
> It's partially addressing 2) because we need to make it more explicit
> and readable. Dan Prince had the idea to use
> https://github.com/ripienaar/puppet-reportprint to print a nice report
> of Puppet catalog result (we haven't tried it yet). We could also use
> Operational Tools later to monitor Puppet logs and find Service
> validation failures.
>
>
> So this email is a bootstrap of discussion, it's open for feedback.
> Don't take my PoC as something we'll implement. It's an idea and I
> think it's worth to look at it.
> I like it for 2 reasons:
> - the validation code reside within our profiles, so it's composable by 
> design.
> - it's flexible and allow us to test everything. It can be a bash
> script, a shell command, a Puppet resource (provider, service, etc).
>
> Thanks for reading so far,
> --
> Emilien Macchi



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Dims,

Given the strong language around partnership between Intel, Mirantis, and
Google in that press release, and the activity in the review queue (2
pages of outstanding reviews) it seems clear to me that the intent is for
this part of Fuel to participate in the big tent.  The right thing to do
here is for fuel-ccp to submit their repos to TC oversight by adding them
to the official project list.

Fuel requires a mission change, or it may be perceived that Fuel itself
does not adhere to the Four Opens [1] specifically Open Development and
Open Community.

Regards
-steve

[1] https://github.com/openstack/governance/blob/master/reference/opens.rst

On 7/26/16, 11:15 AM, "Davanum Srinivas"  wrote:

>And. it's here in OpenStack:
>
>Look for fuel-ccp-* in http://git.openstack.org/cgit/ or the gerrit search
>https://review.openstack.org/#/q/status:open+branch:master+project:^openst
>ack/fuel-ccp.*
>
>-- Dims
>
>On Tue, Jul 26, 2016 at 1:53 PM, Fox, Kevin M  wrote:
>> They are starting their own project.
>> 
>> From: Stephen Hindle [shin...@llnw.com]
>> Sent: Tuesday, July 26, 2016 10:35 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting
>>Fuel CCP (docker/k8s) kicked off
>>
>> So just saw this:
>>   
>>http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-Kuber
>>netes-Mirantis-fuels-Fuel-with-Google-Intel-heat
>>
>> Wonder if that means we'll get more devs or maybe some prebuilt
>> containers for Kolla?
>>
>>
>> --
>> Stephen Hindle - Senior Systems Engineer
>> 480.807.8189 480.807.8189
>> www.limelight.com Delivering Faster Better
>>
>> Join the conversation
>>
>> at Limelight Connect
>>
>> --
>> The information in this message may be confidential.  It is intended
>>solely
>> for
>> the addressee(s).  If you are not the intended recipient, any
>>disclosure,
>> copying or distribution of the message, or any action or omission taken
>>by
>> you
>> in reliance on it, is prohibited and may be unlawful.  Please
>>immediately
>> contact the sender if you have received this message in error.
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>-- 
>Davanum Srinivas :: https://twitter.com/dims
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ovs-dev] [networking-ovn] Re: Issue when using ovn with Openstack

2016-07-26 Thread Richard Theis

"dev"  wrote on 07/20/2016 12:42:20 AM:

> From: Chen Li 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: d...@openvswitch.org, "OpenStack Development Mailing List \(not 
> for usage questions\)" 
> Date: 07/20/2016 12:42 AM
> Subject: Re: [ovs-dev] [networking-ovn] Re: Issue when using ovn 
> with Openstack
> Sent by: "dev" 
> 
> Just Tested with another multi-node setup with older code (code download 
in
> last week), and everything works.
> 
> Here are the last changes for workable ovs/neutron/networking-ovn:
> 
> ovs:
> 
> commit 3041e1fc963886c3e19f1b848df20c6f9d96b289
> Author: William Tu 
> Date:   Fri Jul 1 09:45:52 2016 -0700
> 
> system-traffic: Remove datapath specific tests and macro.
> 
> We generally try to keep the testsuite independent of the underlying
> datapath. This patch removes the datapath-specific tests and macros.
> 
> Tested-at: 
https://travis-ci.org/williamtu/ovs-travis/builds/141642065
> Signed-off-by: William Tu 
> Signed-off-by: Joe Stringer 
> 
> 
> neutron:
> 
> commit 2f29a5db3ca0a5a26571be07109bf49e57c0fc2d
> Merge: 86c02d8 09a6a46
> Author: Jenkins 
> Date:   Thu Jul 14 23:24:58 2016 +
> 
> Merge "Pecan: Implement pagination"
> 
> 
> networking-ovn:
> 
> commit 12919d0d48c63d252be4a42f3f20a2176b53f7d9
> Merge: 381b57f 28b2c55
> Author: Jenkins 
> Date:   Thu Jul 14 23:36:10 2016 +
> 
> Merge "Grenade plugin for testing OVN migration from ML2/OVS"
> 
> 

If this problem is still occurring on master, please file a bug at [1] 
with
your recreate scenario in detail.  If you can pinpoint the commit that 
broke
things that would be even better.

[1] https://bugs.launchpad.net/networking-ovn/+filebug

Thanks,
Richard

> On Wed, Jul 20, 2016 at 1:17 PM, Chen Li  
wrote:
> 
> > Thanks for adding the openstack-dev.
> >
> > Yes, I'm running with devstack, and using the master branch of 
everything.
> > I just updated every thing several hours ago to make sure this is not 
an
> > issue already been fixed.
> >
> > The last change in neutron:
> >
> > commit 122a971656671f92927d44ddd3725cca74b4e0bb
> > Merge: 827bb07 01a6c9c
> > Author: Jenkins 
> > Date:   Tue Jul 19 17:14:33 2016 +
> >
> > Merge "Generalize agent extension mechanism"
> >
> > The last change in networking-ovn:
> >
> > commit a8abf7517f86df6e0ff532cd49550b4dc3c0a9ed
> > Author: Ryan Moats 
> > Date:   Fri Jul 15 11:32:33 2016 -0500
> >
> > [doc] Prettify logical flow examples
> >
> > Rather than showing database objects, use the output of ovn-sbctl
> > lflow-list, because it is prettier.
> >
> > Change-Id: I243b7316731c6c723bf6e64c9326800272643578
> >
> >
> >
> > I do not know where to find : neutron.ini and networking-ovn.ini, are 
you
> > mean neutron.conf & networking-ovn.conf ? Could you point to me where 
I can
> > find them ?
> > I did no change to these configuration files after stack.sh finished.
> >
> > On Wed, Jul 20, 2016 at 12:42 PM, Ryan Moats  
wrote:
> >
> >> "dev"  wrote on 07/19/2016 10:44:27 PM:
> >>
> >> > From: Chen Li 
> >> > To: d...@openvswitch.org
> >> > Date: 07/19/2016 10:44 PM
> >> > Subject: [ovs-dev] Issue when using ovn with Openstack
> >> > Sent by: "dev" 
> >> >
> >> > Hi list,
> >> >
> >> > I have an all-in-one devstack environment with ovn enabled.
> >> > I create a neutron network.
> >> > Create a port A from the network with secgroup A
> >> > Create a vm from the network with secgroup B.
> >> > Secgroup B has both ICMP  and tcp 22 enabled.
> >> >
> >> > Then I try to ping the VM from the dhcp namespace, since the 
Secgroup B
> >> has
> >> > enabled ICMP,  I suppose this should work. But, unfortunately, this 
do
> >> not
> >> > work. And,  the ssh failed too.
> >> >
> >> > Anyone can help me to solve this issue ?
> >> >
> >> > I did some basic checks and looks like flows are missing in table 
52.
> >> >
> >> > Here are flows in table 52:
> >> >
> >> > sudo ovs-ofctl dump-flows br-int |grep table=52
> >> >
> >> >  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> >> > idle_age=7766,
> >> priority=65535,icmp6,metadata=0x4,icmp_type=135,icmp_code=0
> >> > actions=resubmit(,53)
> >> >  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> >> > idle_age=7766,
> >> priority=65535,icmp6,metadata=0x4,icmp_type=136,icmp_code=0
> >> > actions=resubmit(,53)
> >> >  cookie=0x0, duration=7766.195s, table=52, n_packets=4, 
n_bytes=1474,
> >> > idle_age=7744, priority=2002,udp,reg15=0x2,metadata=0x4,nw_src=
> >> > 192.168.0.0/24,tp_src=67,tp_dst=68
> >> > actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
> >>

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

Excerpts from Hayes, Graham's message of 2016-07-26 18:16:16 +:
> On 26/07/2016 18:47, Doug Hellmann wrote:
> > Excerpts from Hayes, Graham's message of 2016-07-26 13:48:35 +:
> >> On 26/07/2016 14:15, Sean Dague wrote:
> >>> On 07/26/2016 08:51 AM, Doug Hellmann wrote:
> >>> 
> 
>  Given the amount of in-progress work to address the issue you've
>  raised, I'm not convinced we need a global rule or policy. All of
>  the teams mentioned are working toward the goal of providing stable
>  APIs already, and no one seems to be arguing against that goal. The
>  teams doing the work are not dragging their feet, and a rule or
>  policy wouldn't make the work go any faster.
> 
>  The directions for cross-project teams were given when the bit tent
>  change went into effect were to "support all official teams" and
>  definitely not "do the work for all official teams." There was also
>  no requirement that the support be exactly equal, and it would be
>  a mistake to try to require that because the issue is almost always
>  lack of resources and not lack of desire.  Volunteers to contribute
>  to the work that's needed will do more to help than a one-size-fits-all
>  policy.
> >>>
> >>> Yes, exactly.
> >>>
> >>> Like Ihar said earlier, we get all kinds of breaks across out system all
> >>> the time. It's a complex system. If you look hard what you'll notice is
> >>> that project interactions where there are team members in common break a
> >>> bit less. For instance Grenade breaks Nova less than other projects.
> >>> oslo.versionedobjects breaks Nova less than oslo.messaging does. Why?
> >>> Because even with stable interfaces and tests, a lot of behavior remains
> >>> in flux given the patch rate on all projects. And when people understand
> >>> both sides of a problem, they are more likely to anticipate a problem
> >>> during review that no tests caught and didn't seem to change an interface.
> >>>
> >>> This isn't a thing that gets fixed with policy. It gets fixed with people.
> >>>
> >>> -Sean
> >>>
> >>
> >> If this is where all these projects are going, is a policy not a good
> >> way to indicate that this is how we want to work in the future?
> >>
> >> So when the next project starts, or a team wants to move in a different
> >> direction we have a piece of policy that shows we feel that this is the
> >> way we work as a community?
> >>
> >> I don't understand the objection to stating "this is how we should work"
> >> when teams are moving that way anyway.
> >>
> >> If to do that we need to dilute the policy, so be it.
> >>
> >
> > I do agree that writing down our expectations is a good thing.  In
> > this case, I think the policy that the TC has agreed to is accurately
> > and sufficiently documented in the existing resolution under the
> > "Impact for horizontal teams" section [1].  The stewardship working
> > group is actively working on a set of general principles for the
> > TC to consider, and it may make sense to incorporate the existing
> > policy into that list of principles to make it easier to find.
> 
> Sure, I know the work they are doing - this has been bouncing around
> my PC for a bit before I had any knowledge of what the plans were there.
> 
> > I personally don't agree with changing the policy, or making it
> > "stronger" in some way, right now because I'm not convinced that
> > we need to treat all projects exactly the same in all cases.  It
> 
> This is the crux of the debate.
> 
> Are all projects equal?

According to our current policy, all projects are equal in the sense
that cross-project teams must support them. They are not equal in
that the level of support given, and criteria for choosing that
level of support, is left up to the cross-project teams.

> 
> If they are not, I will be disappointed, but we should then move to
> define this in-equality, and state who is in, and who is out.

This is not an in-or-out distinction. It's a matter of resources
available to support teams directly, or not. A few examples:

* The documentation team has drawn a line for which projects
  are included in the tutorial-driven installation guide they are
  writing.  Other teams are able to write their own installation
  guides, or even collaborate to create joint guides.

* The release team formerly had a special tag that we used to
  indicate which project teams we were managing. With the increasing
  automation, we have expanded that list of projects significantly.

* The TC has directed the QA team to take tests into the Tempest
  tree when those tests are needed for DefCore. Any other decisions
  about what tests live in-tree or out is up to the QA team.

> In some ways we are back to the stackforge vs integrated situation,
> but unlike then we have no frame of reference for how a project would
> become more equal.
> 
> If projects have difficulty getting into top level docs (for example)
> it is more difficult to grow

Re: [openstack-dev] Running CI jobs on Ubuntu Xenial by default

2016-07-26 Thread Clark Boylan

On Thu, Jul 21, 2016, at 06:07 PM, Clark Boylan wrote:
> Hello,
> 
> Recently we added python3.5 jobs that run on Ubuntu Xenial and switched
> the PyPy jobs to run on Ubuntu Xenial. The next step in this process is
> to switch the "python-jobs" and their database siblings to run on Ubuntu
> Xenial by default as well. We will be doing this Monday July 25, 2016.
> This should get the ball rolling on our switch for the remaining jobs as
> well. Expect devstack/tempest jobs to also get this treatment next week.
> This switch will only be for >= Newton (master today), Liberty and
> Mitaka will continue to run on Ubuntu Trusty by default.
> 
> In preparation for this switch I have personally run the pep8, docs,
> python27, and releasenotes tox envs for all projects that use the Zuul
> python-jobs and python-db-jobs templates. This shook out a couple issues
> that I have corrected and others I filed bugs for. While this isn't a
> complete test for all projects using one of these jobs it does give a
> good cross section so I am pretty confident that any issues will be
> minor.
> 
> Known Issues:
> * Mysql is updated to 5.7 and there are some user management and client
> changes. SQLAlchemy/oslodb seem to handle this just fine though so most
> projects likely won't notice.
> * SSLv3 is gone gone gone. Python does not include SSLv3 on Xenial
> because it is removed from the underlying SSL lib(s). If your project
> has explicit support for SSLv3 you will need to address this. Keep in
> mind that SSLv3 is not considered secure any more.
> 
> Why you should be excited for this:
> * New versions of all the things means new features (but also likely new
> bugs
> * "Secure" version of python2.7. Those annoying warnings from requests
> are gone.
> * Modern(ish) 4.4 Linux Kernel
> * Libvirt 1.3.1
> * OVS 2.5
> * Regardless of your opinion on Systemd this means all testing against
> master will be on distros that use Systemd greatly simplifying process
> management

As a heads up this work has begun. python-jobs were switched over late
yesterday and we will continue to move other sets of jobs through the
week and beyond.

Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][networking-ovn][networking-odl] Syncing neutron DB and OVN DB

2016-07-26 Thread Russell Bryant

On Fri, Jul 22, 2016 at 9:37 PM, Zhou, Han  wrote:

> However, I didn't figure out how errors are handled with this approach.
> For example, a port is created in Neutron but ODL controller failed to
> create it although the journal thread successfully sent the request to ODL.
> And I didn't see how the port states (UP & DOWN) are handled (I didn’t see
> any call to ProvisioningBlock, so does it mean it will just be UP from the
> beginning?) It would be great if anyone can help answer this question.
>

Port state is up from the beginning in ODL.

-- 
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][networking-ovn][networking-odl] Syncing neutron DB and OVN DB

2016-07-26 Thread Russell Bryant

On Fri, Jul 22, 2016 at 7:51 AM, Numan Siddique  wrote:

> Thanks for the comments Amitabha.
> Please see comments inline
>
> On Fri, Jul 22, 2016 at 5:50 AM, Amitabha Biswas 
> wrote:
>
>> Hi Numan,
>>
>> Thanks for the proposal. We have also been thinking about this use-case.
>>
>> If I’m reading this accurately (and I may not be), it seems that the
>> proposal is to not have any OVN NB (CUD) operations (R operations outside
>> the scope) done by the api_worker threads but rather by a new journal
>> thread.
>>
>>
> Correct.
> 
>
>
>> If this is indeed the case, I’d like to consider the scenario when there
>> any N neutron nodes, each node with M worker threads. The journal thread at
>> the each node contain list of pending operations. Could there be (sequence)
>> dependency in the pending operations amongst each the journal threads in
>> the nodes that prevents them from getting applied (for e.g.
>> Logical_Router_Port and Logical_Switch_Port inter-dependency), because we
>> are returning success on neutron operations that have still not been
>> committed to the NB DB.
>>
>>
> I
> ts a valid scenario and should be designed properly to handle such
> scenarios in case we take this approach.
>

I believe a new table in the Neutron DB is used to synchronize all of the
journal threads.

Also note that OVN currently has no custom tables in the Neutron database
and it would be *very* good to keep it that way if we can.


>
> 
>
>> Couple of clarifications and thoughts below.
>>
>> Thanks
>> Amitabha 
>>
>> On Jul 13, 2016, at 1:20 AM, Numan Siddique  wrote:
>>
>> Adding the proper tags in subject
>>
>> On Wed, Jul 13, 2016 at 1:22 PM, Numan Siddique 
>> wrote:
>>
>>> Hi Neutrinos,
>>>
>>> Presently, In the OVN ML2 driver we have 2 ways to sync neutron DB and
>>> OVN DB
>>>  - At neutron-server startup, OVN ML2 driver syncs the neutron DB and
>>> OVN DB if sync mode is set to repair.
>>>  - Admin can run the "neutron-ovn-db-sync-util" to sync the DBs.
>>>
>>> Recently, in the v2 of networking-odl ML2 driver (Please see (1) below
>>> which has more details). (ODL folks please correct me if I am wrong here)
>>>
>>>   - a journal thread is created which does the CRUD operations of
>>> neutron resources asynchronously (i.e it sends the REST APIs to the ODL
>>> controller).
>>>
>>
>> Would this be the equivalent of making OVSDB transactions to the OVN NB
>> DB?
>>
>
> Correct.
> 
>
>
>>
>>   - a maintenance thread is created which does some cleanup periodically
>>> and at startup does full sync if it detects ODL controller cold reboot.
>>>
>>>
>>> Few question I have
>>>  - can OVN ML2 driver take same or similar approach. Are there any
>>> advantages in taking this approach ? One advantage is neutron resources can
>>> be created/updated/deleted even if the OVN ML2 driver has lost connection
>>> to the ovsdb-server. The journal thread would eventually sync these
>>> resources in the OVN DB. I would like to know the communities thoughts on
>>> this.
>>>
>>
>>
I question whether making operations appear to be successful even when
ovsdb-server is unreachable is a useful thing.  API calls fail today if the
Neutron db is unreachable.  Why would we bend over backwards for the OVN
database?

If this was easy to do, sure, but this solution seems *incredibly* complex
to me, so I see it as an absolute last resort.



> If we can make it work, it would indeed be a huge plus for system wide
>> upgrades and some corner cases in the code (ACL specifically), where the
>> post_commit relies on all transactions to be successful and doesn’t revert
>> the neutron db if something fails.
>>
>
>
Can we just improve the ML2 framework to make this problem easier to deal
with?  This problem would affect several drivers.  Driver specific partial
solutions just keep getting replicated.  I'd like to see if we can solve
the problems more generally.



>
>
>
>>
>>
>>>  - Are there are other ML2 drivers which might have to handle the DB
>>> sync's (cases where the other controllers also maintain their own DBs) and
>>> how they are handling it ?
>>>
>>>  - Can a common approach be taken to sync the neutron DB and controller
>>> DBs ?
>>>
>>>
>>>
>>> ---
>>>
>>> (1)
>>> Sync threads created by networking-odl ML2 driver
>>> --
>>> ODL ML2 driver creates 2 threads (threading.Thread module) at init
>>>  - Journal thread
>>>  - Maintenance thread
>>>
>>> Journal thread
>>> 
>>> The journal module creates a new journal table by name
>>> “opendaylightjournal”  -
>>> https://github.com/openstack/networking-odl/blob/master/networking_odl/db/models.py#L23
>>>
>>> Journal thread will be in loop waiting for the sync event from the ODL
>>> ML2 driver.
>>>
>>>  - ODL ML2 driver

Re: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-26 Thread Davanum Srinivas

And. it's here in OpenStack:

Look for fuel-ccp-* in http://git.openstack.org/cgit/ or the gerrit search
https://review.openstack.org/#/q/status:open+branch:master+project:^openstack/fuel-ccp.*

-- Dims

On Tue, Jul 26, 2016 at 1:53 PM, Fox, Kevin M  wrote:
> They are starting their own project.
> 
> From: Stephen Hindle [shin...@llnw.com]
> Sent: Tuesday, July 26, 2016 10:35 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting Fuel 
> CCP (docker/k8s) kicked off
>
> So just saw this:
>   
> http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-Kubernetes-Mirantis-fuels-Fuel-with-Google-Intel-heat
>
> Wonder if that means we'll get more devs or maybe some prebuilt
> containers for Kolla?
>
>
> --
> Stephen Hindle - Senior Systems Engineer
> 480.807.8189 480.807.8189
> www.limelight.com Delivering Faster Better
>
> Join the conversation
>
> at Limelight Connect
>
> --
> The information in this message may be confidential.  It is intended solely
> for
> the addressee(s).  If you are not the intended recipient, any disclosure,
> copying or distribution of the message, or any action or omission taken by
> you
> in reliance on it, is prohibited and may be unlawful.  Please immediately
> contact the sender if you have received this message in error.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

2016-07-26 Thread Hayes, Graham

On 26/07/2016 18:47, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-07-26 13:48:35 +:
>> On 26/07/2016 14:15, Sean Dague wrote:
>>> On 07/26/2016 08:51 AM, Doug Hellmann wrote:
>>> 

 Given the amount of in-progress work to address the issue you've
 raised, I'm not convinced we need a global rule or policy. All of
 the teams mentioned are working toward the goal of providing stable
 APIs already, and no one seems to be arguing against that goal. The
 teams doing the work are not dragging their feet, and a rule or
 policy wouldn't make the work go any faster.

 The directions for cross-project teams were given when the bit tent
 change went into effect were to "support all official teams" and
 definitely not "do the work for all official teams." There was also
 no requirement that the support be exactly equal, and it would be
 a mistake to try to require that because the issue is almost always
 lack of resources and not lack of desire.  Volunteers to contribute
 to the work that's needed will do more to help than a one-size-fits-all
 policy.
>>>
>>> Yes, exactly.
>>>
>>> Like Ihar said earlier, we get all kinds of breaks across out system all
>>> the time. It's a complex system. If you look hard what you'll notice is
>>> that project interactions where there are team members in common break a
>>> bit less. For instance Grenade breaks Nova less than other projects.
>>> oslo.versionedobjects breaks Nova less than oslo.messaging does. Why?
>>> Because even with stable interfaces and tests, a lot of behavior remains
>>> in flux given the patch rate on all projects. And when people understand
>>> both sides of a problem, they are more likely to anticipate a problem
>>> during review that no tests caught and didn't seem to change an interface.
>>>
>>> This isn't a thing that gets fixed with policy. It gets fixed with people.
>>>
>>> -Sean
>>>
>>
>> If this is where all these projects are going, is a policy not a good
>> way to indicate that this is how we want to work in the future?
>>
>> So when the next project starts, or a team wants to move in a different
>> direction we have a piece of policy that shows we feel that this is the
>> way we work as a community?
>>
>> I don't understand the objection to stating "this is how we should work"
>> when teams are moving that way anyway.
>>
>> If to do that we need to dilute the policy, so be it.
>>
>
> I do agree that writing down our expectations is a good thing.  In
> this case, I think the policy that the TC has agreed to is accurately
> and sufficiently documented in the existing resolution under the
> "Impact for horizontal teams" section [1].  The stewardship working
> group is actively working on a set of general principles for the
> TC to consider, and it may make sense to incorporate the existing
> policy into that list of principles to make it easier to find.

Sure, I know the work they are doing - this has been bouncing around
my PC for a bit before I had any knowledge of what the plans were there.

> I personally don't agree with changing the policy, or making it
> "stronger" in some way, right now because I'm not convinced that
> we need to treat all projects exactly the same in all cases.  It

This is the crux of the debate.

Are all projects equal?

If they are not, I will be disappointed, but we should then move to
define this in-equality, and state who is in, and who is out.

In some ways we are back to the stackforge vs integrated situation,
but unlike then we have no frame of reference for how a project would
become more equal.

If projects have difficulty getting into top level docs (for example)
it is more difficult to grow adoption, which would let them into
top level docs, which would help adoption ...

> seems like a relatively benign assumption to make, but until we
> actually have an issue that would be solved by formalizing it in

I think that we have one. I could be wrong (it happens), but I think
this is a problem, and waiting for something bigger to happen, then
having the existential debate about what OpenStack is (again) causes
issues that could be dealt with to grow. (See Golang discussion).

> policy I would prefer to avoid introducing unintended consequences
> in implementations of projects brought on by layers of rules.  We
> don't want any projects discriminated against, but I don't think
> that's what is happening in these cases, and I think the existing
> policy addresses that case.

And I disagree - I think we need it to be more explicit.

> Doug
>
> [1] 
> http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html#impact-for-horizontal-teams
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>

Re: [openstack-dev] [E] [TripleO] scripts to do post deployment analysis of an overcloud

2016-07-26 Thread Gordon, Kent






> -Original Message-
> From: Gonéri Le Bouder [mailto:gon...@lebouder.net]
> Sent: Tuesday, July 26, 2016 12:24 PM
> To: openstack-dev@lists.openstack.org
> Subject: [E] [openstack-dev] [TripleO] scripts to do post deployment analysis
> of an overcloud
> 
> Hi all,
> 
> For the Distributed-CI[0] project, we did two scripts[1] that we use to 
> extract

Links not included in message

> information from an overcloud.
> We use this information to improve the readability of the deployment logs.
> I attached an example to show how we use the extracted stack information.
> 
> Now my question, do you know some other tools that we can use to do this
> kind of anaylsis?
> --
> Gonéri Le Bouder

Kent S. Gordon

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] Independent tag and stable branches

2016-07-26 Thread Jeremy Stanley

On 2016-07-26 15:51:19 +0200 (+0200), Julien Danjou wrote:
> So I'm about to release Gnocchi 2.2.0. I'd expect to have a stable/2.2
> branch. Is this going to happen? Based on the format of the YAML file,
> I'm not sure this scenario is handled.

Just to be clear, this assumes that Gnocchi's stable branches aren't
subject to any integration testing. Our CI framework's integration
testing branch selection is based on matching up consistent branch
names across projects, with a fallback to "master" if a suitable
match is not found. That means that any integration test jobs using
zuul-cloner (including devstack-gate based jobs) will only ever test
Gnocchi stable/2.2 changes against stable/2.2 branches in other
projects or, lacking that, their master branch.

Right now it looks like you have at least a few integration tests
run against changes to the openstack/gnocchi repo
(gate-gnocchi-dsvm-functional-swift-postgresql,
gate-telemetry-dsvm-integration-gnocchi, et cetera) which would need
to be either kept working against master of all other projects being
tested (including keeping their respective requirements
coinstallable) or else you'll probably want to exclude these jobs
from running against the stable/2.2 branch.

You already have a number of existing stable/x.y branches so I'm
curious how this has worked for you in practice up to this point.
Skimming those branches I think you've simply gotten lucky and
haven't run into the issue yet because most have received no
backports at all and the handful of changes that have been
backported are usually within the first few days to a month after
branching while still fairly close to the master branch state (after
which point those branches have gone stagnant).
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

They are starting their own project.

From: Stephen Hindle [shin...@llnw.com]
Sent: Tuesday, July 26, 2016 10:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting Fuel CCP 
(docker/k8s) kicked off

So just saw this:
  
http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-Kubernetes-Mirantis-fuels-Fuel-with-Google-Intel-heat

Wonder if that means we'll get more devs or maybe some prebuilt
containers for Kolla?


--
Stephen Hindle - Senior Systems Engineer
480.807.8189 480.807.8189
www.limelight.com Delivering Faster Better

Join the conversation

at Limelight Connect

--
The information in this message may be confidential.  It is intended solely
for
the addressee(s).  If you are not the intended recipient, any disclosure,
copying or distribution of the message, or any action or omission taken by
you
in reliance on it, is prohibited and may be unlawful.  Please immediately
contact the sender if you have received this message in error.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] Independent tag and stable branches

Excerpts from Tony Breeds's message of 2016-07-26 10:19:22 -0500:
> On Tue, Jul 26, 2016 at 03:51:19PM +0200, Julien Danjou wrote:
> > Hi release team,
> > 
> > So I'm about to release Gnocchi 2.2.0. I'd expect to have a stable/2.2
> > branch. Is this going to happen? Based on the format of the YAML file,
> > I'm not sure this scenario is handled.
> 
> Note, I'm clearly note a release manager and I'm not signing anyone up for
> work, I was curious so I had a look for how this would be handled.
> 
> I think you're right the code/data in openstack/releases wouldn't handle your
> request.
> 
> Which is probably something that needs to change however it'd be bad to hold 
> up
> your release while that integration code is being written.  In the near term I
> think it'll boil down to:
> - A release manager to run make_stable_branch.sh (from
>   openstack-infra/release-tools) to create your stable/2.2 branch
> - Using the std. release tools to tag the release.  Worst case it'd be running
>   release.sh by hand.

The tag should be done first, but otherwise this is right.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] Independent tag and stable branches

Excerpts from Julien Danjou's message of 2016-07-26 15:51:19 +0200:
> Hi release team,
> 
> So I'm about to release Gnocchi 2.2.0. I'd expect to have a stable/2.2
> branch. Is this going to happen? Based on the format of the YAML file,
> I'm not sure this scenario is handled.
> 

We have not yet automated the process of creating stable branches. When
we do, it's likely to first apply to the cycle-based release models,
since handling those branches is clearer.

If you don't have permission to create the branch yourself, drop by
#openstack-release and I'll help you with it.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][kolla] Error in tagging process by release liason



On 7/26/16, 5:55 AM, "Doug Hellmann"  wrote:

>Excerpts from Steven Dake (stdake)'s message of 2016-07-23 18:27:00 +:
>> Doug and friends,
>> 
>> I made a pretty serious error when tagging kolla-kubernetes originally.
>> Kolla-kubernetes is in development and not in a production ready state.
>> We also don't intend to apply for many if any tags for this repository
>>until it becomes more mature.  We do not intend to do backports to this
>>repository once Newton is released.
>> 
>> The original tag should have been 0.1.0.0b1.  The second milestone tag
>>was 0.1.1 (which should have been 0.1.0.0b2).  I caught this during
>>Doug's review but it was merged before I had a chance to talk to the
>>release team about solutions to this problem.
>> 
>> I don't expect to rewrite the tags or any of that.  I'd like guidance
>>on what to do for milestone 3 and Ocatta as well (where I guess we can
>>just reset on 0.2.0.0b1).
>> 
>> Regards
>> -steve
>
>kolla-kubernetes uses the release:independent model, for which we don't
>really intend to support beta-style milestone tags. The version number
>is already a pre-1.0 version, which should clearly indicate instability
>and immaturity to anyone consuming it.
>
>Milestone 3 should continue to use semantic versioning and either
>use 0.1.2 or 0.2.0 depending on the content. If you want to change
>the release model to cycle-with-milestones for Ocata, we can do
>that between the end of Newton and the first Ocata milestone.
>
>Doug

Doug,

Great news thanks.  I think maybe we had this conversation once over IRC
in various contexts, and I struggled to put them all together.

I've got it now.  I don't think we will be changing release cycles until
we have a proper 1.0.0 release of kolla-kubernetes.

Regards
-steve

>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Next steps for proxy API deprecation

Excerpts from Matt Riedemann's message of 2016-07-26 12:14:03 -0500:
> On 7/26/2016 11:59 AM, Matt Riedemann wrote:
> > Now that the 2.36 microversion change has merged [1], we can work on the
> > python-novaclient changes for this microversion.
> >
> > At the midcycle we agreed [2] to also return a 404 for network APIs,
> > including nova-network (which isn't a proxy), for consistency and
> > further signaling that nova-network is going away.
> >
> > In the client, we agreed to soften the impact for network CLIs by
> > determining if the latest microversion supported will fail (so will we
> > send >=2.36) and rather than fail, send 2.35 instead (if the user didn't
> > specifically specify a different version). However, we'd emit a warning
> > saying this is deprecated and will go away in the first major client
> > release (in Ocata? after nova-network is removed? after Ocata is
> > released?).
> >
> > We should probably just deprecate any CLIs/APIs in python-novaclient
> > today that are part of this server side API change, including network
> > CLIs/APIs in novaclient. The baremetal and image proxies in the client
> > are already deprecated, and the volume proxies were already removed.
> > That leaves the network proxies in the client.
> >
> > From my notes, Dan Smith was going to work on the novaclient changes for
> > 2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to
> > do that work (please speak up).
> >
> > We can probably do the network CLI/API deprecations in the client in
> > parallel to the 2.36 support, but need someone to step up for that. I'll
> > try to get it started this week if no one else does.
> >
> > [1] https://review.openstack.org/#/c/337005/
> > [2] https://etherpad.openstack.org/p/nova-newton-midcycle
> >
> 
> I forgot to mention Tempest. We're going to have to probably put a 
> max_microversion cap in several tests in Tempest to cap at 2.35 (or 
> change those to use Neutron?). There are also going to be some response 
> schema changes like for quota usage/limits, I'm not sure if anyone is 
> looking at this yet. We could also get it done after feature freeze on 
> 9/2, but I still need to land the get-me-a-network API change which is 
> microversion 2.37 and has it's own Tempest test, although that test 
> relies on Neutron so I might be OK for the most part.
> 

If these tests are being used by DefCore, it would be better to cap
the existing behavior and add new tests to use neutron instead of
changing the existing tests. That will make it easier for DefCore
to handle the transition from the old to new behavior by replacing
the old tests in their list with the new ones.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

Excerpts from Hayes, Graham's message of 2016-07-26 13:48:35 +:
> On 26/07/2016 14:15, Sean Dague wrote:
> > On 07/26/2016 08:51 AM, Doug Hellmann wrote:
> > 
> >>
> >> Given the amount of in-progress work to address the issue you've
> >> raised, I'm not convinced we need a global rule or policy. All of
> >> the teams mentioned are working toward the goal of providing stable
> >> APIs already, and no one seems to be arguing against that goal. The
> >> teams doing the work are not dragging their feet, and a rule or
> >> policy wouldn't make the work go any faster.
> >>
> >> The directions for cross-project teams were given when the bit tent
> >> change went into effect were to "support all official teams" and
> >> definitely not "do the work for all official teams." There was also
> >> no requirement that the support be exactly equal, and it would be
> >> a mistake to try to require that because the issue is almost always
> >> lack of resources and not lack of desire.  Volunteers to contribute
> >> to the work that's needed will do more to help than a one-size-fits-all
> >> policy.
> >
> > Yes, exactly.
> >
> > Like Ihar said earlier, we get all kinds of breaks across out system all
> > the time. It's a complex system. If you look hard what you'll notice is
> > that project interactions where there are team members in common break a
> > bit less. For instance Grenade breaks Nova less than other projects.
> > oslo.versionedobjects breaks Nova less than oslo.messaging does. Why?
> > Because even with stable interfaces and tests, a lot of behavior remains
> > in flux given the patch rate on all projects. And when people understand
> > both sides of a problem, they are more likely to anticipate a problem
> > during review that no tests caught and didn't seem to change an interface.
> >
> > This isn't a thing that gets fixed with policy. It gets fixed with people.
> >
> > -Sean
> >
> 
> If this is where all these projects are going, is a policy not a good
> way to indicate that this is how we want to work in the future?
> 
> So when the next project starts, or a team wants to move in a different
> direction we have a piece of policy that shows we feel that this is the
> way we work as a community?
> 
> I don't understand the objection to stating "this is how we should work"
> when teams are moving that way anyway.
> 
> If to do that we need to dilute the policy, so be it.
> 

I do agree that writing down our expectations is a good thing.  In
this case, I think the policy that the TC has agreed to is accurately
and sufficiently documented in the existing resolution under the
"Impact for horizontal teams" section [1].  The stewardship working
group is actively working on a set of general principles for the
TC to consider, and it may make sense to incorporate the existing
policy into that list of principles to make it easier to find.

I personally don't agree with changing the policy, or making it
"stronger" in some way, right now because I'm not convinced that
we need to treat all projects exactly the same in all cases.  It
seems like a relatively benign assumption to make, but until we
actually have an issue that would be solved by formalizing it in
policy I would prefer to avoid introducing unintended consequences
in implementations of projects brought on by layers of rules.  We
don't want any projects discriminated against, but I don't think
that's what is happening in these cases, and I think the existing
policy addresses that case.

Doug

[1] 
http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html#impact-for-horizontal-teams

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Next steps for proxy API deprecation

2016-07-26 Thread Matthew Treinish

On Tue, Jul 26, 2016 at 01:21:53PM -0400, Sean Dague wrote:
> On 07/26/2016 01:14 PM, Matt Riedemann wrote:
> > On 7/26/2016 11:59 AM, Matt Riedemann wrote:
> >> Now that the 2.36 microversion change has merged [1], we can work on the
> >> python-novaclient changes for this microversion.
> >>
> >> At the midcycle we agreed [2] to also return a 404 for network APIs,
> >> including nova-network (which isn't a proxy), for consistency and
> >> further signaling that nova-network is going away.
> >>
> >> In the client, we agreed to soften the impact for network CLIs by
> >> determining if the latest microversion supported will fail (so will we
> >> send >=2.36) and rather than fail, send 2.35 instead (if the user didn't
> >> specifically specify a different version). However, we'd emit a warning
> >> saying this is deprecated and will go away in the first major client
> >> release (in Ocata? after nova-network is removed? after Ocata is
> >> released?).
> >>
> >> We should probably just deprecate any CLIs/APIs in python-novaclient
> >> today that are part of this server side API change, including network
> >> CLIs/APIs in novaclient. The baremetal and image proxies in the client
> >> are already deprecated, and the volume proxies were already removed.
> >> That leaves the network proxies in the client.
> >>
> >> From my notes, Dan Smith was going to work on the novaclient changes for
> >> 2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to
> >> do that work (please speak up).
> >>
> >> We can probably do the network CLI/API deprecations in the client in
> >> parallel to the 2.36 support, but need someone to step up for that. I'll
> >> try to get it started this week if no one else does.
> >>
> >> [1] https://review.openstack.org/#/c/337005/
> >> [2] https://etherpad.openstack.org/p/nova-newton-midcycle
> >>
> > 
> > I forgot to mention Tempest. We're going to have to probably put a
> > max_microversion cap in several tests in Tempest to cap at 2.35 (or
> > change those to use Neutron?). There are also going to be some response
> > schema changes like for quota usage/limits, I'm not sure if anyone is
> > looking at this yet. We could also get it done after feature freeze on
> > 9/2, but I still need to land the get-me-a-network API change which is
> > microversion 2.37 and has it's own Tempest test, although that test
> > relies on Neutron so I might be OK for the most part.
> 
> Is that strictly true? We could also just configure all the jobs for
> Nova network to set max microversion at 2.35. That would probably be
> more straight forward way of approaching this, and make it a bit more
> clear how serious we are here.
> 

Yeah, for the gate that should work. By default tempest sends the minimum
microversion based on the config and the test requirements. So we should
never send 2.36 unless the test says it's minimum required microversion
is >=2.36. Setting the max at 2.35 would mean we skip those tests. My bigger
concern is for people using tempest outside of the gate. I still think we
should set a max microversion on any test classes that call nova's network
apis to make sure they're properly skipped just in case someone sets the
min microversion in the tempest config at 2.36. (assuming such a test class
exists at all, I don't actually know) Unless you thinking failing there is the
correct way to do it?

-Matt Treinish



signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-26 Thread Stephen Hindle

So just saw this:
  
http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-Kubernetes-Mirantis-fuels-Fuel-with-Google-Intel-heat

Wonder if that means we'll get more devs or maybe some prebuilt
containers for Kolla?


-- 
Stephen Hindle - Senior Systems Engineer
480.807.8189 480.807.8189
www.limelight.com Delivering Faster Better

Join the conversation

at Limelight Connect

-- 
The information in this message may be confidential.  It is intended solely 
for
the addressee(s).  If you are not the intended recipient, any disclosure,
copying or distribution of the message, or any action or omission taken by 
you
in reliance on it, is prohibited and may be unlawful.  Please immediately
contact the sender if you have received this message in error.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Next steps for proxy API deprecation

2016-07-26 Thread Matthew Treinish

On Tue, Jul 26, 2016 at 12:14:03PM -0500, Matt Riedemann wrote:
> On 7/26/2016 11:59 AM, Matt Riedemann wrote:
> > Now that the 2.36 microversion change has merged [1], we can work on the
> > python-novaclient changes for this microversion.
> > 
> > At the midcycle we agreed [2] to also return a 404 for network APIs,
> > including nova-network (which isn't a proxy), for consistency and
> > further signaling that nova-network is going away.
> > 
> > In the client, we agreed to soften the impact for network CLIs by
> > determining if the latest microversion supported will fail (so will we
> > send >=2.36) and rather than fail, send 2.35 instead (if the user didn't
> > specifically specify a different version). However, we'd emit a warning
> > saying this is deprecated and will go away in the first major client
> > release (in Ocata? after nova-network is removed? after Ocata is
> > released?).
> > 
> > We should probably just deprecate any CLIs/APIs in python-novaclient
> > today that are part of this server side API change, including network
> > CLIs/APIs in novaclient. The baremetal and image proxies in the client
> > are already deprecated, and the volume proxies were already removed.
> > That leaves the network proxies in the client.
> > 
> > From my notes, Dan Smith was going to work on the novaclient changes for
> > 2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to
> > do that work (please speak up).
> > 
> > We can probably do the network CLI/API deprecations in the client in
> > parallel to the 2.36 support, but need someone to step up for that. I'll
> > try to get it started this week if no one else does.
> > 
> > [1] https://review.openstack.org/#/c/337005/
> > [2] https://etherpad.openstack.org/p/nova-newton-midcycle
> > 
> 
> I forgot to mention Tempest. We're going to have to probably put a
> max_microversion cap in several tests in Tempest to cap at 2.35 (or change
> those to use Neutron?). There are also going to be some response schema
> changes like for quota usage/limits, I'm not sure if anyone is looking at
> this yet. We could also get it done after feature freeze on 9/2, but I still
> need to land the get-me-a-network API change which is microversion 2.37 and
> has it's own Tempest test, although that test relies on Neutron so I might
> be OK for the most part.

The only case where this will matter is for test classes that have an unbound
max microversion, which should be very few. It's only classes that specify a
higher minimum. The simple way around that is just change the max microversion
for those classes to 2.35 and it won't ever send a 2.36 request. For example:

http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/compute/volumes/test_attach_volume.py#n187

change 'latest' to 2.35 if it calls nova-network anywhere in that call path.
(as an aside to people unfamiliar with microversions in tempest that doesn't
mean send 'latest' on the wire but that all microversions are valid for this
test, ie it won't skip based on the min microversion in config)

However, this does raise a bigger issue about removing nova-network next cycle.
It's still the default a lot of places. We can't remove the tempest support
until newton eol (assuming an ocata removal) So we'll likely have to add a flag
or 2 to make sure we never use it on master, there will also be devstack,
devstack-gate, etc changes that will have to happen first too. But this is all
probably a topic better suited for another thread or even a summit discussion.

-Matt Treinish


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Next steps for proxy API deprecation

2016-07-26 Thread Sean Dague

On 07/26/2016 01:14 PM, Matt Riedemann wrote:
> On 7/26/2016 11:59 AM, Matt Riedemann wrote:
>> Now that the 2.36 microversion change has merged [1], we can work on the
>> python-novaclient changes for this microversion.
>>
>> At the midcycle we agreed [2] to also return a 404 for network APIs,
>> including nova-network (which isn't a proxy), for consistency and
>> further signaling that nova-network is going away.
>>
>> In the client, we agreed to soften the impact for network CLIs by
>> determining if the latest microversion supported will fail (so will we
>> send >=2.36) and rather than fail, send 2.35 instead (if the user didn't
>> specifically specify a different version). However, we'd emit a warning
>> saying this is deprecated and will go away in the first major client
>> release (in Ocata? after nova-network is removed? after Ocata is
>> released?).
>>
>> We should probably just deprecate any CLIs/APIs in python-novaclient
>> today that are part of this server side API change, including network
>> CLIs/APIs in novaclient. The baremetal and image proxies in the client
>> are already deprecated, and the volume proxies were already removed.
>> That leaves the network proxies in the client.
>>
>> From my notes, Dan Smith was going to work on the novaclient changes for
>> 2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to
>> do that work (please speak up).
>>
>> We can probably do the network CLI/API deprecations in the client in
>> parallel to the 2.36 support, but need someone to step up for that. I'll
>> try to get it started this week if no one else does.
>>
>> [1] https://review.openstack.org/#/c/337005/
>> [2] https://etherpad.openstack.org/p/nova-newton-midcycle
>>
> 
> I forgot to mention Tempest. We're going to have to probably put a
> max_microversion cap in several tests in Tempest to cap at 2.35 (or
> change those to use Neutron?). There are also going to be some response
> schema changes like for quota usage/limits, I'm not sure if anyone is
> looking at this yet. We could also get it done after feature freeze on
> 9/2, but I still need to land the get-me-a-network API change which is
> microversion 2.37 and has it's own Tempest test, although that test
> relies on Neutron so I might be OK for the most part.

Is that strictly true? We could also just configure all the jobs for
Nova network to set max microversion at 2.35. That would probably be
more straight forward way of approaching this, and make it a bit more
clear how serious we are here.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Next steps for proxy API deprecation

2016-07-26 Thread Matt Riedemann


On 7/26/2016 11:59 AM, Matt Riedemann wrote:

Now that the 2.36 microversion change has merged [1], we can work on the
python-novaclient changes for this microversion.

At the midcycle we agreed [2] to also return a 404 for network APIs,
including nova-network (which isn't a proxy), for consistency and
further signaling that nova-network is going away.

In the client, we agreed to soften the impact for network CLIs by
determining if the latest microversion supported will fail (so will we
send >=2.36) and rather than fail, send 2.35 instead (if the user didn't
specifically specify a different version). However, we'd emit a warning
saying this is deprecated and will go away in the first major client
release (in Ocata? after nova-network is removed? after Ocata is
released?).

We should probably just deprecate any CLIs/APIs in python-novaclient
today that are part of this server side API change, including network
CLIs/APIs in novaclient. The baremetal and image proxies in the client
are already deprecated, and the volume proxies were already removed.
That leaves the network proxies in the client.

From my notes, Dan Smith was going to work on the novaclient changes for
2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to
do that work (please speak up).

We can probably do the network CLI/API deprecations in the client in
parallel to the 2.36 support, but need someone to step up for that. I'll
try to get it started this week if no one else does.

[1] https://review.openstack.org/#/c/337005/
[2] https://etherpad.openstack.org/p/nova-newton-midcycle



I forgot to mention Tempest. We're going to have to probably put a 
max_microversion cap in several tests in Tempest to cap at 2.35 (or 
change those to use Neutron?). There are also going to be some response 
schema changes like for quota usage/limits, I'm not sure if anyone is 
looking at this yet. We could also get it done after feature freeze on 
9/2, but I still need to land the get-me-a-network API change which is 
microversion 2.37 and has it's own Tempest test, although that test 
relies on Neutron so I might be OK for the most part.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [heat] [murano] [app-catalog] OpenStack Apps Community, several suggestions how to improve collaboration

2016-07-26 Thread Igor Marnat

Colleagues,
let me share an update with our progress with initiative I sent across in
late May about improving our collaboration around development of OpenStack
applications and Community App Catalog. Several teams have been busily
working on it, including App Catalog team, Glare/Glance, Murano and Murano
Apps.

You can also find suggested plan and status update quoted below in the
second part of this etherpad
https://etherpad.openstack.org/p/OpenStackAppsCommunity.

*Suggested plan and progress with it*

*1. Introduce label openstack-apps, put repositories with source code of
OpenStack Apps under it, i.e.:*
  * http://git.openstack.org/cgit/openstack-apps/murano-apps
  * http://git.openstack.org/cgit/openstack-apps/heat-templates
  * http://git.openstack.org/cgit/openstack-apps/tosca-workflows
* Status: *
  OpenStack Infra team suggested not to introduce yet another label. Thus
we just changed ownership of
http://git.openstack.org/cgit/openstack/murano-apps repository to
murano-apps-core team. Didn't make progress with other projects (Heat,
Tosca), TBD if they need/want it.

Besides we agreed with OpenStack Infra that for complicated Murano
Applications we'll be creating and maintaining separated repositories,
specific for application (
http://lists.openstack.org/pipermail/openstack-dev/2016-June/096471.html).
I.e. we use http://git.openstack.org/cgit/openstack/murano-apps for simple
applications and dedicated repositories for mostly complex apps (i.e.
http://git.openstack.org/cgit/openstack/ci-cd-pipeline-app-murano).

*2. Agree with OpenStack Community App Catalog team on how content of App
Catalog is managed and by whom*
*Status:*
To change an approach to managing content in Community App Catalog we need
first to switch its backend to Glare. Current implementation of backend
doesn't allow to make changes in apps management workflow, it's mostly
manual and has to be done by App Catalog Core team. ETA for switching -
mid/end Aug, 2016 (work in progress).

There is a test instance of App Catalog based on Glare V 1.0,
http://r-ci.tk:8100. It is a very early version under development, can be
updated/turned off w/o prior notification. App Catalog team works on
implementation of existing App Catalog functionality based on this backend.

App Catalog team is about to start discussions on what new upload workflows
look like. Please follow [app-catalog] mailing list on openstack-dev or
come to #openstack-app-catalog in IRC for more information.

*3. Describe workflow of how to add source code of new application to
repositories, who approves its addition*
*Status: *
App Catalog team is about to start discussing this/working on it once
switched to new backend. Please follow [app-catalog] mailing list on
openstack-dev or come to openstack-app-catalog in IRC for updates.

*4. Introduce simplified workflow of publishing new Application to the
catalog:*
  * register/login
  * push/update
  * done
*Status:*
See #2, #3

*5. Introduce teams (core reviewers) contributing to/maintaining Murano
apps, Heat templates, ...*
*Status:*
Done for Murano (introduced murano-apps-core team):
http://lists.openstack.org/pipermail/openstack-dev/2016-May/096268.html

*6. Establish channels of communications with potential contributors
(mailing list, meetings, IRC/slack channel, ... ?)*
*Status:*
Introduced murano-apps IRC channel, rest will be added working on #3.

*7. Agree with contributors on QA process for applications and how we track
it in Community App Catalog:*
7.1 Get from Heat, Murano and TOSCA team list of documentation resources,
tools and best practices on QA of templates, apps and workflows
7.2 Make this list structured and visible for apps developers and apps
users in app-catalog documentation
7.3 Implement automated checks of apps integrity using tests/checks already
available in Heat, Glance, Murano, TOSCA
7.4 Discuss with Heat, Murano and TOSCA teams additions to their roadmaps
for verification tools for their assets

*Status:*
Good progress with 7.3. Most of the results described below are work in
progress, still needs to be polished and documented. However, they allow to
understand progress and approach
- implemented yaml + bash syntax check for Murano Apps (
https://review.openstack.org/#/c/344922/ )
- implemented third-party CI for Murano Apps for
http://git.openstack.org/cgit/openstack/ci-cd-pipeline-app-murano (see for
example feedback from murano-ci-cd-bot in
https://review.openstack.org/#/c/316209/).
- validation of TOSCA blueprints on upload to Glare v 1.0 using
tosca-parser (https://review.openstack.org/#/c/337633/). If template
doesn't pass validation it can't be uploaded to the catalog. To be
elaborated in the future based on new upload workflows we agree with
community.
- validation of Heat templates and Glance images is being discussed
with Heat and Glance teams correspondingly

Next steps - improve 7.3, work on 7.1, 7.2, 7.4, and to discuss with
OpenStack Infra an approach to

[openstack-dev] [nova] Next steps for proxy API deprecation

2016-07-26 Thread Matt Riedemann

Now that the 2.36 microversion change has merged [1], we can work on the 
python-novaclient changes for this microversion.


At the midcycle we agreed [2] to also return a 404 for network APIs, 
including nova-network (which isn't a proxy), for consistency and 
further signaling that nova-network is going away.


In the client, we agreed to soften the impact for network CLIs by 
determining if the latest microversion supported will fail (so will we 
send >=2.36) and rather than fail, send 2.35 instead (if the user didn't 
specifically specify a different version). However, we'd emit a warning 
saying this is deprecated and will go away in the first major client 
release (in Ocata? after nova-network is removed? after Ocata is released?).


We should probably just deprecate any CLIs/APIs in python-novaclient 
today that are part of this server side API change, including network 
CLIs/APIs in novaclient. The baremetal and image proxies in the client 
are already deprecated, and the volume proxies were already removed. 
That leaves the network proxies in the client.


From my notes, Dan Smith was going to work on the novaclient changes 
for 2.36 to not fail and use 2.35 - unless anyone else wants to 
volunteer to do that work (please speak up).


We can probably do the network CLI/API deprecations in the client in 
parallel to the 2.36 support, but need someone to step up for that. I'll 
try to get it started this week if no one else does.


[1] https://review.openstack.org/#/c/337005/
[2] https://etherpad.openstack.org/p/nova-newton-midcycle

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [searchlight] Rick Aulino core nomination

2016-07-26 Thread David Lyle

+1

On Tue, Jul 26, 2016 at 9:27 AM, McLellan, Steven
 wrote:
> +1 - Rick's done a lot of good reviews over various parts of the codebase.
>
> On 7/25/16, 4:01 PM, "Tripp, Travis S"  wrote:
>
>>Hello!
>>
>>I am nominating Rick Aulino for Searchlight core. Rick has been working
>>on the core indexing engine throughout Mitaka and Newton. He has
>>developed a Neutron plug-in and has reviewed most of the other plugins in
>>Searchlight.  Since the beginning of Mitaka [0] and for the first two
>>Newton milestones [1], Rick is consistently in the top 5 for reviews and
>>commits. He has provided thoughtful feedback and valuable insights
>>throughout his time on Searchlight.
>>
>>[0] http://stackalytics.com/report/contribution/searchlight-group/242
>>[1] http://stackalytics.com/report/contribution/searchlight-group/100
>>
>>Thanks,
>>Travis
>>__
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Magnum] Select our project mascot/logo

2016-07-26 Thread Watson, Stephen

+1 for kangaroo and stallion

And my own suggestion even though it doesn’t fit the container or name themes 
directly would be a St. Bernard because dogs and myths are cool: 
http://mentalfloss.com/article/20908/why-are-st-bernards-always-depicted-barrels-around-their-necks

-Stephen

From: Hongbin Lu 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, July 25, 2016 at 5:54 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [Magnum] Select our project mascot/logo

Hi team,

OpenStack want to promote individual projects by choosing a mascot to represent 
the project. The idea is to create a family of logos for OpenStack projects 
that are unique, yet immediately identifiable as part of OpenStack. OpenStack 
will be using these logos to promote each project on the OpenStack website, at 
the Summit and in marketing materials.

We can select our own mascot, and then OpenStack will have an illustrator 
create the logo for us. The mascot can be anything from the natural world—an 
animal, fish, plant, or natural feature such as a mountain or waterfall. We 
need to select our top mascot candidates by the first deadline (July 27, this 
Wednesday). There’s more info on the website: 
http://www.openstack.org/project-mascots

Action Item: Everyone please let me know what is your favorite mascot. You can 
either reply to this ML or discuss it in the next team meeting.

Best regards,
Hongbin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance][Heat][Horizon] Glance v2 and custom locations

The app catalog has suffered this change too. We had to force v1 in our 
suggested download cli lines to make it work when newer clients defaulted to v2 
and the previously working command line switches suddenly vanished.

As I understand, v2 had a solution to it, but that solution too was deprecated. 
I've heard rumor of a new suggested way of doing it, but I haven't been able to 
find it, so I guess its still cooking.

I'd ask the Glance team to not deprecate v1 until this issue is resolved, as it 
is a very common use case for Glance. I understand the desire to sluff off the 
old and only support a single, new api. But the new api has a big gap in it 
that needs to be fixed first.

Thanks,
Kevin

From: Mikhail Fedosin [mfedo...@mirantis.com]
Sent: Tuesday, July 26, 2016 4:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Glance][Heat][Horizon] Glance v2 and custom locations

Hello!

As you may know glance v1 is going to be deprecated in Newton cycle. Almost all 
projects support glance v2 at this moment, Nova uses it by default. Only one 
thing that blocks us from complete adoption is a possibility to set custom 
locations to images. In v1 any user can set a location to his image, but in v2 
this functionality is not allowed by default, which prevents v2 adoption in 
services like Horizon or Heat.

It all happens because of differences between v1 and v2 locations. In v1 it is 
pretty easy - user specifies an url and send a request, glance adds this url to 
the image and activates it.
In v2 things are more complicated: v2 supports multiple locations per image, 
which means that when user wants to download image file glance will choose the 
best one from the list of locations. It leads to some inconsistencies: user can 
add or delete locations from his image even if it is active.

To enable adding custom locations operator has to set True to config option 
'show_multiple_locations'. After that any user will be able to add or remove 
his image locations, update locations metadata, and finally see locations of 
all images even if they were uploaded to local storage. All this things are not 
desired if glance v2 has public interface, because it exposes inner cloud 
architecture. It leads to the fact that Heat and Horizon and Nova in some cases 
and other services that used to set custom locations in glance v1 won't be able 
to adopt glance v2. Unfortunately, removing this behavior in v2 isn't easy, 
because it requires serious architecture changes and breaks API. Moreover, many 
vendors use these features in their clouds for private glance deployments and 
they really won't like if we break anything.

So, I want to hear opinions from Glance community and other involved people.

Best regards,
Mikhail Fedosin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] libvirt/qemu source install plugin.

2016-07-26 Thread Michele Paolino

I see. In any case, I am open to discuss further contributions and 
improvement to the plugin. Let me know!


In case this can be useful for you, in the early implementations of the 
current devstack plugin (i.e., Patch set 1)[1], it was able to download 
and install libvirt and qemu from git repositories. The community then 
suggested to go for the tar releases, and that's where the current 
implementation comes from.


[1]https://review.openstack.org/#/c/108714/1

Regards,

On 07/26/2016 05:23 PM, Mooney, Sean K wrote:

Hi I was not aware of the
Plugin tar installer but it would not have been usefully in my case as
I needed to build from specific git commit id not release tars.

For my use case I also need the ability to apply patches automatically to 
evaluate change
To qemu and Libvirt before they are merged upstream.

It would be good to see if we could combine the two though to duplicate
Code to build and install Libvirt and qemu.

If there is no object I think it still makes sense to create a
openstack/devstack-plugin-libvirt-qemu repo then as the 
devstack-plugin-tar-installer
expcitly will be using tar files not git repos.



-Original Message-
From: Michele Paolino [mailto:m.paol...@virtualopensystems.com]
Sent: Tuesday, July 26, 2016 1:40 PM
To: OpenStack Development Mailing List (not for usage questions)

Cc: Kashyap Chamarthy ;
mzoel...@linux.vnet.ibm.com; Mooney, Sean K 
Subject: Re: [openstack-dev] [devstack] libvirt/qemu source install
plugin.

All,

the purpose of the devstack-plugin-tar-installer[1] is exactly what you
mentioned: a tool needed to test experimental features in libvirt and
qemu. I am planning to release a new version next week, addressing some
of the comments received, however new testers/developers are more than
welcome! Sean, maybe you can have a look at the code and, if you are
interested, we can discuss how to proceed further.

I also think it would be nice if we can join all together the efforts
on this project[2], as I believe this is an interesting feature for
devstack. Maybe there is also a way to integrate this work with the
gate Markus was mentioning.

Thank you Kashyap for pointing this out!

Regards,

[1]https://review.openstack.org/#/c/313568/
[2]https://review.openstack.org/#/q/project:openstack/devstack-plugin-
tar-installer

On 07/26/2016 01:13 PM, Kashyap Chamarthy wrote:

On Thu, Jul 21, 2016 at 02:25:46PM +0200, Markus Zoeller wrote:

On 20.07.2016 22:38, Mooney, Sean K wrote:

Hi
I recently had the need to test a feature (vhost-user reconnect)
that was commit to the qemu source tree a few weeks ago. As there
has been no release since then I needed to build from source so to
that end I wrote a small devstack plugin to do just that.

I was thinking of opening a review to create a new repo to host the
plugin under The openstack namespace
(openstack/devstack-plugin-libvirt-qemu) but before I do I wanted

to

ask if others are interested In a devstack plugin that just

compiles

and installs qemu and Libvirt?

Regards Sean.


tonby and I try to make the devstack plugin "additional package

repos"

(apr) work [1]. What you did is within the scope of that project. We
also have an experimental job
"gate-tempest-dsvm-nova-libvirt-kvm-apr"[2].  The last time I worked
on this I wasn't able to create installable *.deb packages from
libvirt + qemu source code. Other work items did then get more
important and I had to pause the work on that.  I think we can work
together to combine our efforts there.

NB: There's also in-progress work to allow configuring libvirt / QEMU
from source tar balls, as an external DevStack plugin:

  https://review.openstack.org/#/c/313568/ -- Plugin to setup
  libvirt/QEMU from tar releases

It was originally proposed (now abandoned, in favour of the above) as
a patch to DevStack proper, but was abandoned, as it was suggested to
make it as external plugin:

  https://review.openstack.org/#/c/108714/


References:
[1]
https://github.com/openstack/devstack-plugin-additional-pkg-repos/
[2]
https://github.com/openstack-infra/project-

config/blob/master/jenkins

/jobs/devstack-gate.yaml#L565-L595


--
Michele Paolino


--
Michele Paolino


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [freezer] PTL on vacation

2016-07-26 Thread Mathieu, Pierre-Arthur

Hello, 

I will be on holidays and hard to reach until August 18th.
My deputies will be Fausto Marzi and Saad Zaher.

I’ll be obviously less active, but I should have some internet access and wil 
still check emails from time to time.
 
Regards,
- Pierre 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Binary containers with pip install?

+1.

Its relatively easy to write some cron jobs that look at your images and tell 
you want containers have out of date rpms and need upgrading. its much harder 
when there are pip packages/virtualenvs involved. Having a nice way to let ops 
know (or automation know) that there are potential non system packages involved 
brings needed attention to them.

Thanks,
Kevin

From: Jeffrey Zhang [zhang.lei@gmail.com]
Sent: Tuesday, July 26, 2016 5:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Binary containers with pip install?

On Tue, Jul 26, 2016 at 5:00 PM, Dave Walker  wrote:
>  - Add support to have per project build type, but this is likely a testing
> scenario that cannot be reasonably assured.

I think  this is another feature we can overwrite some variables in
certain image.

>  - Allow source installs in binary containers, but track it as a TODO bug
> "Please package foo" (Launchpad has great support for linking to other bug
> trackers).  Then once this bug is closed, proper binary support can be
> resolved.  This has the benefit of 'best-effort' towards binary, with a
> clear intent to move across.  It also allows more testing of the binary
> parts that are present, with just the source parts as required. (this is my
> favourite)

Love this too.
Maybe we need a WARNING to the stdout to tell the operators.

--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [freezer] Freezer midcycle minutes

2016-07-26 Thread Mathieu, Pierre-Arthur

Hello everyone,

The freezer team recently had his mid-cycle meeting hosted in Galway.

Please head over to this etherpad ([1]) know everything about it.

Here is a short recap of the topics that we discussed:
- Update on documentation [2]
Guillermo already did a great job. The new documentation needs to be
released and we discussed how and where this will be done.
We also discussed the developper documentation
- Update on python-freezerclient [3]
We are ready. The only thing missing is to release python-freezer-client.
- Falcon and Paste and PasteDeploy
We need to figure out how to build middlewares that are compatible with
falcon and paste. If this will not work in the long run, maybe we will have
to move to a different api framework.
- Update on freezer-agent refactoring [4]
- Backup as a Service [5]
Required:
  - freezer-web-ui fixes / tests
  - Retention for openstack based backup (nova, cinder, cindernative)
  - oslo.policy
  - freezer-scheduler running multiple jobs in parallel
- Nova / Cinder backups [6]
We need to update/merge a few bugfixes
- Core team review
- On-duty reviewers [7]
We are going to have two on-duty reviewers per week. They will try to focus
a bit more on doing reviews in order to speed up the process. This is not a
replacement for reviews asked to a specific developer (because of his
knowledge around a specific topic) or urgent reviews asked in the IRC
channel.
- Engines and tar [8]
Conclusions to be presented soon on the openstack-dev mailing list about
what we should do regarding tar and its broken incremental.
- Integration testing [9]
This is going the right way. We need to keep focussing on adding more tests.
We have a list of features and scenarios that needs to be added.


A big thanks to everyone that participated in this midcycle meetup!


Regards
- Pierre, for the Freezer Team

[1]: https://etherpad.openstack.org/p/freezer_midcycle_meetup_newton
[2]: https://etherpad.openstack.org/p/documentation
[3]: https://etherpad.openstack.org/p/python-freezerclient
[4]: https://etherpad.openstack.org/p/freezer_new_archi
[5]: https://etherpad.openstack.org/p/freezer_austin_session_baas
[6]: https://etherpad.openstack.org/p/freezer_nova_cinder
[7]: https://etherpad.openstack.org/p/freezer_review_enhancements
[8]: https://etherpad.openstack.org/p/freezer_engine
[9]: https://etherpad.openstack.org/p/integration_test_newton

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] libvirt/qemu source install plugin.

2016-07-26 Thread Mooney, Sean K

Hi I was not aware of the 
Plugin tar installer but it would not have been usefully in my case as 
I needed to build from specific git commit id not release tars.

For my use case I also need the ability to apply patches automatically to 
evaluate change
To qemu and Libvirt before they are merged upstream.

It would be good to see if we could combine the two though to duplicate
Code to build and install Libvirt and qemu.

If there is no object I think it still makes sense to create a 
openstack/devstack-plugin-libvirt-qemu repo then as the 
devstack-plugin-tar-installer
expcitly will be using tar files not git repos.


> -Original Message-
> From: Michele Paolino [mailto:m.paol...@virtualopensystems.com]
> Sent: Tuesday, July 26, 2016 1:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Cc: Kashyap Chamarthy ;
> mzoel...@linux.vnet.ibm.com; Mooney, Sean K 
> Subject: Re: [openstack-dev] [devstack] libvirt/qemu source install
> plugin.
> 
> All,
> 
> the purpose of the devstack-plugin-tar-installer[1] is exactly what you
> mentioned: a tool needed to test experimental features in libvirt and
> qemu. I am planning to release a new version next week, addressing some
> of the comments received, however new testers/developers are more than
> welcome! Sean, maybe you can have a look at the code and, if you are
> interested, we can discuss how to proceed further.
> 
> I also think it would be nice if we can join all together the efforts
> on this project[2], as I believe this is an interesting feature for
> devstack. Maybe there is also a way to integrate this work with the
> gate Markus was mentioning.
> 
> Thank you Kashyap for pointing this out!
> 
> Regards,
> 
> [1]https://review.openstack.org/#/c/313568/
> [2]https://review.openstack.org/#/q/project:openstack/devstack-plugin-
> tar-installer
> 
> On 07/26/2016 01:13 PM, Kashyap Chamarthy wrote:
> > On Thu, Jul 21, 2016 at 02:25:46PM +0200, Markus Zoeller wrote:
> >> On 20.07.2016 22:38, Mooney, Sean K wrote:
> >>> Hi
> >>> I recently had the need to test a feature (vhost-user reconnect)
> >>> that was commit to the qemu source tree a few weeks ago. As there
> >>> has been no release since then I needed to build from source so to
> >>> that end I wrote a small devstack plugin to do just that.
> >>>
> >>> I was thinking of opening a review to create a new repo to host the
> >>> plugin under The openstack namespace
> >>> (openstack/devstack-plugin-libvirt-qemu) but before I do I wanted
> to
> >>> ask if others are interested In a devstack plugin that just
> compiles
> >>> and installs qemu and Libvirt?
> >>>
> >>> Regards Sean.
> >>>
> >> tonby and I try to make the devstack plugin "additional package
> repos"
> >> (apr) work [1]. What you did is within the scope of that project. We
> >> also have an experimental job
> >> "gate-tempest-dsvm-nova-libvirt-kvm-apr"[2].  The last time I worked
> >> on this I wasn't able to create installable *.deb packages from
> >> libvirt + qemu source code. Other work items did then get more
> >> important and I had to pause the work on that.  I think we can work
> >> together to combine our efforts there.
> > NB: There's also in-progress work to allow configuring libvirt / QEMU
> > from source tar balls, as an external DevStack plugin:
> >
> >  https://review.openstack.org/#/c/313568/ -- Plugin to setup
> >  libvirt/QEMU from tar releases
> >
> > It was originally proposed (now abandoned, in favour of the above) as
> > a patch to DevStack proper, but was abandoned, as it was suggested to
> > make it as external plugin:
> >
> >  https://review.openstack.org/#/c/108714/
> >
> >> References:
> >> [1]
> >> https://github.com/openstack/devstack-plugin-additional-pkg-repos/
> >> [2]
> >> https://github.com/openstack-infra/project-
> config/blob/master/jenkins
> >> /jobs/devstack-gate.yaml#L565-L595
> >>
> 
> --
> Michele Paolino


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] Independent tag and stable branches

2016-07-26 Thread Tony Breeds

On Tue, Jul 26, 2016 at 03:51:19PM +0200, Julien Danjou wrote:
> Hi release team,
> 
> So I'm about to release Gnocchi 2.2.0. I'd expect to have a stable/2.2
> branch. Is this going to happen? Based on the format of the YAML file,
> I'm not sure this scenario is handled.

Note, I'm clearly note a release manager and I'm not signing anyone up for
work, I was curious so I had a look for how this would be handled.

I think you're right the code/data in openstack/releases wouldn't handle your
request.

Which is probably something that needs to change however it'd be bad to hold up
your release while that integration code is being written.  In the near term I
think it'll boil down to:
- A release manager to run make_stable_branch.sh (from
  openstack-infra/release-tools) to create your stable/2.2 branch
- Using the std. release tools to tag the release.  Worst case it'd be running
  release.sh by hand.

Yours Tony.


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testing core

2016-07-26 Thread Miguel Angel Ajo Pelayo

Ohhh, yikes, even though I'm late my vote would have been super +1!!


On Tue, Jul 26, 2016 at 5:04 PM, Jakub Libosvar  wrote:
> On 26/07/16 16:56, Assaf Muller wrote:
>>
>> We've hit critical mass from cores interesting in the testing area.
>>
>> Welcome Jakub to the core reviewer team. May you enjoy staring at the
>> Gerrit interface and getting yelled at by people... It's a glamorous
>> life.
>
>
> Thanks everyone for support! I'll try to do my best :)
>
>
>>
>>
>>
>> On Mon, Jul 25, 2016 at 10:49 PM, Brian Haley  wrote:
>>>
>>> +1
>>>
>>> On 07/22/2016 04:12 AM, Oleg Bondarev wrote:


 +1

 On Fri, Jul 22, 2016 at 2:36 AM, Doug Wiegley
 > wrote:

 +1

> On Jul 21, 2016, at 5:13 PM, Kevin Benton  > wrote:
>
> +1
>
> On Thu, Jul 21, 2016 at 2:41 PM, Carl Baldwin  > wrote:
>
> +1 from me
>
> On Thu, Jul 21, 2016 at 1:35 PM, Assaf Muller  > wrote:
>
> As Neutron's so called testing lieutenant I would like to
> propose
> Jakub Libosvar to be a core in the testing area.
>
> Jakub has demonstrated his inherent interest in the testing
> area over
> the last few years, his reviews are consistently insightful
> and his
> numbers [1] are in line with others and I know will improve
> if given
> the responsibilities of a core reviewer. Jakub is deeply
> involved with
> the project's testing infrastructures and CI systems.
>
> As a reminder the expectation from cores is found here [2],
> and
> specifically for cores interesting in helping out shaping
> Neutron's
> testing story:
>
> * Guide community members to craft a testing strategy for
> features [3]
> * Ensure Neutron's testing infrastructures are sufficiently
> sophisticated to achieve the above.
> * Provide leadership when determining testing Do's & Don'ts
> [4]. What
> makes for an effective test?
> * Ensure the gate stays consistently green
>
> And more tactically we're looking at finishing the
> Tempest/Neutron
> tests dedup [5] and to provide visual graphing for
> historical
> control
> and data plane performance results similar to [6].
>
> [1] http://stackalytics.com/report/contribution/neutron/90
> [2]
>
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html
> [3]
>
>
> http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
> [4]
> https://assafmuller.com/2015/05/17/testing-lightning-talk/
> [5] https://etherpad.openstack.org/p/neutron-tempest-defork
> [6]
>
> https://www.youtube.com/watch?v=a0qlsH1hoKs=youtu.be=24m22s
>
>
>
> __
> OpenStack Development Mailing List (not for usage
> questions)
> Unsubscribe:
>
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> 
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> 
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testing core

2016-07-26 Thread Jakub Libosvar


On 26/07/16 16:56, Assaf Muller wrote:

We've hit critical mass from cores interesting in the testing area.

Welcome Jakub to the core reviewer team. May you enjoy staring at the
Gerrit interface and getting yelled at by people... It's a glamorous
life.


Thanks everyone for support! I'll try to do my best :)





On Mon, Jul 25, 2016 at 10:49 PM, Brian Haley  wrote:

+1

On 07/22/2016 04:12 AM, Oleg Bondarev wrote:


+1

On Fri, Jul 22, 2016 at 2:36 AM, Doug Wiegley
> wrote:

+1


On Jul 21, 2016, at 5:13 PM, Kevin Benton > wrote:

+1

On Thu, Jul 21, 2016 at 2:41 PM, Carl Baldwin > wrote:

+1 from me

On Thu, Jul 21, 2016 at 1:35 PM, Assaf Muller > wrote:

As Neutron's so called testing lieutenant I would like to
propose
Jakub Libosvar to be a core in the testing area.

Jakub has demonstrated his inherent interest in the testing
area over
the last few years, his reviews are consistently insightful
and his
numbers [1] are in line with others and I know will improve
if given
the responsibilities of a core reviewer. Jakub is deeply
involved with
the project's testing infrastructures and CI systems.

As a reminder the expectation from cores is found here [2],
and
specifically for cores interesting in helping out shaping
Neutron's
testing story:

* Guide community members to craft a testing strategy for
features [3]
* Ensure Neutron's testing infrastructures are sufficiently
sophisticated to achieve the above.
* Provide leadership when determining testing Do's & Don'ts
[4]. What
makes for an effective test?
* Ensure the gate stays consistently green

And more tactically we're looking at finishing the
Tempest/Neutron
tests dedup [5] and to provide visual graphing for historical
control
and data plane performance results similar to [6].

[1] http://stackalytics.com/report/contribution/neutron/90
[2]

http://docs.openstack.org/developer/neutron/policies/neutron-teams.html
[3]

http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
[4]
https://assafmuller.com/2015/05/17/testing-lightning-talk/
[5] https://etherpad.openstack.org/p/neutron-tempest-defork
[6]

https://www.youtube.com/watch?v=a0qlsH1hoKs=youtu.be=24m22s


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe



http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe


http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org

?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testing core

2016-07-26 Thread Assaf Muller

We've hit critical mass from cores interesting in the testing area.

Welcome Jakub to the core reviewer team. May you enjoy staring at the
Gerrit interface and getting yelled at by people... It's a glamorous
life.



On Mon, Jul 25, 2016 at 10:49 PM, Brian Haley  wrote:
> +1
>
> On 07/22/2016 04:12 AM, Oleg Bondarev wrote:
>>
>> +1
>>
>> On Fri, Jul 22, 2016 at 2:36 AM, Doug Wiegley
>> > > wrote:
>>
>> +1
>>
>>> On Jul 21, 2016, at 5:13 PM, Kevin Benton >> > wrote:
>>>
>>> +1
>>>
>>> On Thu, Jul 21, 2016 at 2:41 PM, Carl Baldwin >> > wrote:
>>>
>>> +1 from me
>>>
>>> On Thu, Jul 21, 2016 at 1:35 PM, Assaf Muller >> > wrote:
>>>
>>> As Neutron's so called testing lieutenant I would like to
>>> propose
>>> Jakub Libosvar to be a core in the testing area.
>>>
>>> Jakub has demonstrated his inherent interest in the testing
>>> area over
>>> the last few years, his reviews are consistently insightful
>>> and his
>>> numbers [1] are in line with others and I know will improve
>>> if given
>>> the responsibilities of a core reviewer. Jakub is deeply
>>> involved with
>>> the project's testing infrastructures and CI systems.
>>>
>>> As a reminder the expectation from cores is found here [2],
>>> and
>>> specifically for cores interesting in helping out shaping
>>> Neutron's
>>> testing story:
>>>
>>> * Guide community members to craft a testing strategy for
>>> features [3]
>>> * Ensure Neutron's testing infrastructures are sufficiently
>>> sophisticated to achieve the above.
>>> * Provide leadership when determining testing Do's & Don'ts
>>> [4]. What
>>> makes for an effective test?
>>> * Ensure the gate stays consistently green
>>>
>>> And more tactically we're looking at finishing the
>>> Tempest/Neutron
>>> tests dedup [5] and to provide visual graphing for historical
>>> control
>>> and data plane performance results similar to [6].
>>>
>>> [1] http://stackalytics.com/report/contribution/neutron/90
>>> [2]
>>>
>>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html
>>> [3]
>>>
>>> http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
>>> [4]
>>> https://assafmuller.com/2015/05/17/testing-lightning-talk/
>>> [5] https://etherpad.openstack.org/p/neutron-tempest-defork
>>> [6]
>>>
>>> https://www.youtube.com/watch?v=a0qlsH1hoKs=youtu.be=24m22s
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> 
>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>>>
>>> ?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

Re: [openstack-dev] [Glance][Heat][Horizon] Glance v2 and custom locations

2016-07-26 Thread Timur Sufiev

Can we have a special way (i.e. restricted) of setting Image locations, to
be used by clients like Horizon (where an end-users create images)? It
would be hard to explain different set of Image Sources depending on their
adminness.

Anoher question that I'm asking myself about Horizon is how affordable
would be the loss of 'URL Image Source', since 'copy-from' is missing for
sure already. Are there many valuable use cases for URL source in absence
of 'copy-from' feature?

On Tue, Jul 26, 2016 at 5:33 PM <stuart.mcla...@hp.com> wrote:

> Hi Mike,
>
> Here's my $0.02 on setting locations directly:
>
> I think there will always be some (probably public cloud) operators who
> are wary of allowing regular users to do this. For this reason,
> and also because the API calls are backend specific (setting location
> isn't supported for a filesystem backend [1]), my guess is it's unlikely
> that
> API calls for setting locations directly will become part of DefCore.
>
> In general I'm not a huge fan of setting the image locations directly
> because:
>
> * Any time you allow setting the location directly you're risking the
> database and the image data getting out of sync. Eg an 'active' image's
> data can be deleted from under it.
> * Some ways of setting the locations directly give you images without
> a known checksum.
>
> In my mind, the feature is probably best restricted (by default at least)
> to power users (admins) and other services -- eg Cinder can do this
> to reduce copying data around in some cases. Existing policies can be
> used to restrict to admin; something like service tokens [1] could be
> used to allow other services (eg Cinder) to do this on behalf of users,
> while preventing users from doing it directly themselves.
>
> To keep things as inter-operable as possible it might be good to ensure
> that services are able to use Glance even if setting locations directly
> is completely disabled.
>
> -Stuart
>
> [1] https://review.openstack.org/#/c/141706
> [2]
> https://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddleware/implemented/service-tokens.html
>
> > Hello!
> >
> > As you may know glance v1 is going to be deprecated in Newton cycle.
> Almost
> > all projects support glance v2 at this moment, Nova uses it by default.
> > Only one thing that blocks us from complete adoption is a possibility to
> > set custom locations to images. In v1 any user can set a location to his
> > image, but in v2 this functionality is not allowed by default, which
> > prevents v2 adoption in services like Horizon or Heat.
> >
> > It all happens because of differences between v1 and v2 locations. In v1
> it
> > is pretty easy - user specifies an url and send a request, glance adds
> this
> > url to the image and activates it.
> > In v2 things are more complicated: v2 supports multiple locations per
> > image, which means that when user wants to download image file glance
> will
> > choose the best one from the list of locations. It leads to some
> > inconsistencies: user can add or delete locations from his image even if
> it
> > is active.
> >
> > To enable adding custom locations operator has to set True to config
> option
> > 'show_multiple_locations'. After that any user will be able to add or
> > remove his image locations, update locations metadata, and finally see
> > locations of all images even if they were uploaded to local storage. All
> > this things are not desired if glance v2 has public interface, because it
> > exposes inner cloud architecture. It leads to the fact that Heat and
> > Horizon and Nova in some cases and other services that used to set custom
> > locations in glance v1 won't be able to adopt glance v2. Unfortunately,
> > removing this behavior in v2 isn't easy, because it requires serious
> > architecture changes and breaks API. Moreover, many vendors use these
> > features in their clouds for private glance deployments and they really
> > won't like if we break anything.
> >
> > So, I want to hear opinions from Glance community and other involved
> > people.
> >
> > Best regards,
> > Mikhail Fedosin
> > -- next part --
> > An HTML attachment was scrubbed...
> > URL:
> > <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160726/b97af3b0/attachment-0001.html
> >
> >
> > --
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] Capacity table

2016-07-26 Thread Vitaly Kramskikh

Hi, Dmitry,

Your design seems to be similar to one of our attempts to fix this bug:
https://review.openstack.org/#/c/280737/. Though this fix was reverted,
because it led to the bug with a higher priority:
https://bugs.launchpad.net/fuel/+bug/1556909. So your proposed design would
lead to reopening of this bug.

2016-07-19 11:06 GMT+03:00 Dmitry Dmitriev :

> Hello All!
>
> We have a very old bug about the Capacity table on the Dashboard tab of
> environment in Fuel:
>
> https://bugs.launchpad.net/fuel/+bug/1375750
>
> Current design:
>
> https://drive.google.com/open?id=0Bxi_JFs365mBNy1WT0xQT253SWc
>
> It shows the full capacity (CPU/Memory/HDD) of all discovered by Fuel
> nodes.
>
> New design:
>
> https://drive.google.com/open?id=0Bxi_JFs365mBaWZ0cUtla3N6aEU
>
> It contains compute node CPU/Memory capacity and Ceph disk capacity only.
>
> New design pros:
> - cloud administrator can easily estimate all available resources for
> cloud instances
>
> New design cons:
> - if cloud doesn’t use Ceph then HDD value is zero
>
> What do you think about the new design?
>
> With best regards, Dmitry
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Magnum] Select our project mascot/logo

2016-07-26 Thread Ton Ngo

For "container", I am thinking of an animal with a pouch, the marsupial:
a kangaroo with a joey in its pouch:
http://www.supercoloring.com/pages/red-kangaroo
a koala bear with a joey in its pouch:
http://web.stanford.edu/~jay/koalas/koala%20mums.jpg

For "infrastructure management", how about a beaver, known for building
dams:
https://commons.wikimedia.org/wiki/File:Beaver_%28PSF%29.jpg

Ton Ngo,



From:   Hongbin Lu 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   07/25/2016 03:56 PM
Subject:[openstack-dev] [Magnum] Select our project mascot/logo



Hi team,

OpenStack want to promote individual projects by choosing a mascot to
represent the project. The idea is to create a family of logos for
OpenStack projects that are unique, yet immediately identifiable as part of
OpenStack. OpenStack will be using these logos to promote each project on
the OpenStack website, at the Summit and in marketing materials.

We can select our own mascot, and then OpenStack will have an illustrator
create the logo for us. The mascot can be anything from the natural
world—an animal, fish, plant, or natural feature such as a mountain or
waterfall. We need to select our top mascot candidates by the first
deadline (July 27, this Wednesday). There’s more info on the website:
http://www.openstack.org/project-mascots

Action Item: Everyone please let me know what is your favorite mascot. You
can either reply to this ML or discuss it in the next team meeting.

Best regards,
Hongbin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Proposing Attila Darazs for tripleo-quickstart core

2016-07-26 Thread Wesley Hayutin

On Tue, Jul 26, 2016 at 10:32 AM, John Trowbridge  wrote:

> I would like to add Attila to the tripleo-quickstart core reviewers
> group. Much of his work has been on some of the auxillary roles that
> quickstart makes use of in RDO CI, however his numbers on quickstart
> itself[1] are in line with the other core reviewers.
>
> I will be out for paternity leave the next 4 weeks, so it will also be
> nice to have 3 core reviewers during that time in case I dont end up
> doing too many reviews.
>
> If there are no objections I will make the change at the end of the week.
>
> - trown
>
> [1] http://stackalytics.com/report/contribution/tripleo-quickstart/90


+1 very nice


>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Proposing Attila Darazs for tripleo-quickstart core

2016-07-26 Thread John Trowbridge

I would like to add Attila to the tripleo-quickstart core reviewers
group. Much of his work has been on some of the auxillary roles that
quickstart makes use of in RDO CI, however his numbers on quickstart
itself[1] are in line with the other core reviewers.

I will be out for paternity leave the next 4 weeks, so it will also be
nice to have 3 core reviewers during that time in case I dont end up
doing too many reviews.

If there are no objections I will make the change at the end of the week.

- trown

[1] http://stackalytics.com/report/contribution/tripleo-quickstart/90

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance][Heat][Horizon] Glance v2 and custom locations

2016-07-26 Thread stuart . mclaren

Hi Mike,

Here's my $0.02 on setting locations directly:

I think there will always be some (probably public cloud) operators who
are wary of allowing regular users to do this. For this reason,
and also because the API calls are backend specific (setting location
isn't supported for a filesystem backend [1]), my guess is it's unlikely that
API calls for setting locations directly will become part of DefCore.

In general I'm not a huge fan of setting the image locations directly
because:

* Any time you allow setting the location directly you're risking the
database and the image data getting out of sync. Eg an 'active' image's
data can be deleted from under it.
* Some ways of setting the locations directly give you images without
a known checksum.

In my mind, the feature is probably best restricted (by default at least)
to power users (admins) and other services -- eg Cinder can do this
to reduce copying data around in some cases. Existing policies can be
used to restrict to admin; something like service tokens [1] could be
used to allow other services (eg Cinder) to do this on behalf of users,
while preventing users from doing it directly themselves.

To keep things as inter-operable as possible it might be good to ensure
that services are able to use Glance even if setting locations directly
is completely disabled.

-Stuart

[1] https://review.openstack.org/#/c/141706
[2]
https://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddleware/implemented/service-tokens.html

Hello!

As you may know glance v1 is going to be deprecated in Newton cycle. Almost
all projects support glance v2 at this moment, Nova uses it by default.
Only one thing that blocks us from complete adoption is a possibility to
set custom locations to images. In v1 any user can set a location to his
image, but in v2 this functionality is not allowed by default, which
prevents v2 adoption in services like Horizon or Heat.

It all happens because of differences between v1 and v2 locations. In v1 it
is pretty easy - user specifies an url and send a request, glance adds this
url to the image and activates it.
In v2 things are more complicated: v2 supports multiple locations per
image, which means that when user wants to download image file glance will
choose the best one from the list of locations. It leads to some
inconsistencies: user can add or delete locations from his image even if it
is active.

To enable adding custom locations operator has to set True to config option
'show_multiple_locations'. After that any user will be able to add or
remove his image locations, update locations metadata, and finally see
locations of all images even if they were uploaded to local storage. All
this things are not desired if glance v2 has public interface, because it
exposes inner cloud architecture. It leads to the fact that Heat and
Horizon and Nova in some cases and other services that used to set custom
locations in glance v1 won't be able to adopt glance v2. Unfortunately,
removing this behavior in v2 isn't easy, because it requires serious
architecture changes and breaks API. Moreover, many vendors use these
features in their clouds for private glance deployments and they really
won't like if we break anything.

So, I want to hear opinions from Glance community and other involved
people.

Best regards,
Mikhail Fedosin
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20160726/b97af3b0/attachment-0001.html>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [searchlight] Rick Aulino core nomination

2016-07-26 Thread McLellan, Steven

+1 - Rick's done a lot of good reviews over various parts of the codebase.

On 7/25/16, 4:01 PM, "Tripp, Travis S"  wrote:

>Hello!
>
>I am nominating Rick Aulino for Searchlight core. Rick has been working
>on the core indexing engine throughout Mitaka and Newton. He has
>developed a Neutron plug-in and has reviewed most of the other plugins in
>Searchlight.  Since the beginning of Mitaka [0] and for the first two
>Newton milestones [1], Rick is consistently in the top 5 for reviews and
>commits. He has provided thoughtful feedback and valuable insights
>throughout his time on Searchlight.
>
>[0] http://stackalytics.com/report/contribution/searchlight-group/242
>[1] http://stackalytics.com/report/contribution/searchlight-group/100
>
>Thanks,
>Travis
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [searchlight] Rick Aulino core nomination

2016-07-26 Thread Brian Rosmaita

+1 from me, Rick has been doing great work and will be a good addition to
the Searchlight core team.

On 7/25/16, 5:01 PM, "Tripp, Travis S"  wrote:

>Hello!
>
>I am nominating Rick Aulino for Searchlight core. Rick has been working
>on the core indexing engine throughout Mitaka and Newton. He has
>developed a Neutron plug-in and has reviewed most of the other plugins in
>Searchlight.  Since the beginning of Mitaka [0] and for the first two
>Newton milestones [1], Rick is consistently in the top 5 for reviews and
>commits. He has provided thoughtful feedback and valuable insights
>throughout his time on Searchlight.
>
>[0] http://stackalytics.com/report/contribution/searchlight-group/242
>[1] http://stackalytics.com/report/contribution/searchlight-group/100
>
>Thanks,
>Travis
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][vitrage] Midcycle Summary

2016-07-26 Thread gordon chung

this is probably a continuation from the design summit back in Japan[1]. 
basically, it's a very common use case that people want to visualise 
ceilometer(system) data. the issue is that the existing dashboard in horizon  
(Resource Usage tab) is unusable both because it is just a data dump of 
ceilometer data and because it's not possible to data dump effectively using 
ceilometer's legacy storage.

iirc, we wanted something that was more responsive and dynamic (see: 
sparklines). in Gnocchi, we have support for graphana which can satisfy these 
requirements. the CloudKitty team also showed a great demo of visualising 
ceilometer data (in Gnocchi)[2] which is probably more inline with what users 
would want.

[1] https://etherpad.openstack.org/p/mitaka-telemetry-ui

[2] https://youtu.be/-K8NI38LPtU?t=2049

On 26/07/16 03:13 AM, Afek, Ifat (Nokia - IL) wrote:

-Original Message-
From: Matthias Runge [mailto:mru...@redhat.com]
Sent: Friday, July 22, 2016 9:53 AM

Did you also talk about deprecating of ceilometer based metering
dashboard?

IIRC, we all agreed at the last summit, this doesn't really work for
large deployments and should be removed or replaced?

Or does anyone still use it?

Matthias




Hi,

Can you please explain what ceilometer dashboard you want to deprecate?

Thanks,
Ifat.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
--
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release] Independent tag and stable branches

2016-07-26 Thread Julien Danjou

Hi release team,

So I'm about to release Gnocchi 2.2.0. I'd expect to have a stable/2.2
branch. Is this going to happen? Based on the format of the YAML file,
I'm not sure this scenario is handled.

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

2016-07-26 Thread Hayes, Graham

On 26/07/2016 14:15, Sean Dague wrote:
> On 07/26/2016 08:51 AM, Doug Hellmann wrote:
> 
>>
>> Given the amount of in-progress work to address the issue you've
>> raised, I'm not convinced we need a global rule or policy. All of
>> the teams mentioned are working toward the goal of providing stable
>> APIs already, and no one seems to be arguing against that goal. The
>> teams doing the work are not dragging their feet, and a rule or
>> policy wouldn't make the work go any faster.
>>
>> The directions for cross-project teams were given when the bit tent
>> change went into effect were to "support all official teams" and
>> definitely not "do the work for all official teams." There was also
>> no requirement that the support be exactly equal, and it would be
>> a mistake to try to require that because the issue is almost always
>> lack of resources and not lack of desire.  Volunteers to contribute
>> to the work that's needed will do more to help than a one-size-fits-all
>> policy.
>
> Yes, exactly.
>
> Like Ihar said earlier, we get all kinds of breaks across out system all
> the time. It's a complex system. If you look hard what you'll notice is
> that project interactions where there are team members in common break a
> bit less. For instance Grenade breaks Nova less than other projects.
> oslo.versionedobjects breaks Nova less than oslo.messaging does. Why?
> Because even with stable interfaces and tests, a lot of behavior remains
> in flux given the patch rate on all projects. And when people understand
> both sides of a problem, they are more likely to anticipate a problem
> during review that no tests caught and didn't seem to change an interface.
>
> This isn't a thing that gets fixed with policy. It gets fixed with people.
>
>   -Sean
>

If this is where all these projects are going, is a policy not a good
way to indicate that this is how we want to work in the future?

So when the next project starts, or a team wants to move in a different
direction we have a piece of policy that shows we feel that this is the
way we work as a community?

I don't understand the objection to stating "this is how we should work"
when teams are moving that way anyway.

If to do that we need to dilute the policy, so be it.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

2016-07-26 Thread Luigi Toscano

On Tuesday, 26 July 2016 13:23:05 CEST Hayes, Graham wrote:
> On 26/07/2016 14:18, Doug Hellmann wrote:

> >>> And just to satisfy my own curiosity, how does someone looking at the
> >>> internals of tempest know what's on the stable API and what's not
> >>> considered stable? Are the parts of the API documented separately
> >>> somehow or is there a different part of the code tree to look at?
> >> 
> >> tempest.lib is the stable part (previously split in a separate
> >> tempest-lib
> >> repository, which is now deprecated as the code was put back into the
> >> main
> >> tempest repository):
> >> http://docs.openstack.org/developer/tempest/overview.html#library
> > 
> > That seems quite clear, thanks.
> 
> it is actually a bit more -
> 
> http://docs.openstack.org/developer/tempest/plugin.html

This is the documentation on how plugins should be implemented, i.e. how the 
plugin code can consume the stable API described above. It's really a bit of 
boilerplate about the custom configuration options and the registration of the 
classes.

-- 
Luigi


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][neutron][nova] Sync port state changes.

2016-07-26 Thread John Garbutt

On 26 July 2016 at 10:52, Sam Betts (sambetts)  wrote:
> On 26/07/2016 09:32, "John Garbutt"  wrote:
>
>>On 22 July 2016 at 11:51, Vasyl Saienko  wrote:
>>> Kevin, thanks for reply,
>>>
>>> On Fri, Jul 22, 2016 at 11:50 AM, Kevin Benton  wrote:

 Hi,

 Once you solve the issue of getting the baremetal ports to transition
to
 the ACTIVE state, a notification will automatically be emitted to Nova
of
 'network-vif-plugged' with the port ID. Will ironic not have access to
that
 event via Nova?

>>> To solve issues of getting the baremetal ports to transition to the
>>>ACTIVE
>>> state we should do the following:
>>>
>>> Use FLAT network instead of VXLAN for Ironic gate jobs [3].
>>> On Nova side set vnic_type to baremetal for Ironic hypervisor [0].
>>> On Neutron side, perform fake 'baremetal' port binding [2] in case of
>>>FLAT
>>> network.
>>>
>>> We need to receive direct notifications from Neutron to Ironic, because
>>> Ironic creates ports in provisioning network by his own.
>>> Nova doesn't know anything about provisioning ports.
>>>
 If not, Ironic could develop a service plugin that just listens for
port
 update events and relays them to Ironic.

>>>
>>> I already prepared PoC [4] to Neutron that allows to send notifications
>>>to
>>> Ironic on port_update event.
>>>
>>> Reference:
>>> [0] https://review.openstack.org/339143
>>> [1] https://review.openstack.org/339129
>>> [3] https://review.openstack.org/340695
>>> [4] https://review.openstack.org/345211
>>
>>I prefer Kevin's idea of Nova always getting the vif events.
>>
>>Can't the ironic virt driver can pass on the event to ironic, if required?
>>
>>In the libvirt case, for example, the virt driver waits to start the
>>instance until the networking has been setup. It feels like we might
>>need that in the Ironic case as well?
>>
>>Or is that likely to all end up too messy?
>>
>>Thanks,
>>John
>
> This is potentially possible for the nova user's network ports, but Ironic
> creates its own neutron ports in the Ironic provisioning and cleaning
> networks to perform provisioning and cleaning for a node. Nova is never
> aware of these ports as they have nothing to do with the tenant¹s
> requested connectivity.

Ah, OK. I see why you want those to go to ironic.

I clearly need to go a re-read the plan we have for all that.

Thanks,
johnthetubaguy

>>

 On Tue, Jul 12, 2016 at 4:07 AM, Vasyl Saienko 
 wrote:
>
> Hello Community,
>
> I'm working to make Ironic be aware about  Neutron port state changes
> [0].
> The issue consists of two parts:
>
> Neutron ports for baremetal instances remain in DOWN state [1]. The
>issue
> occurs because there is no mechanism driver that binds ports. To
>solve it we
> need to create port with  vnic_type='baremetal' in Nova [2], and bind
>in
> Neutron. New mechanism driver that supports baremetal vnic_type is
>needed
> [3].
>
> Sync Neutron events with Ironic. According to Neutron architecture [4]
> mechanism drivers work synchronously. When the port is bound by ml2
> mechanism driver it becomes ACTIVE. While updating dhcp information
>Neutron
> uses dhcp agent, which is asynchronous call. I'm confused here, since
>ACTIVE
> port status doesn't mean that it operates (dhcp agent may fail to
>setup
> port). The issue was solved by [5]. So starting from [5] when ML2
>uses new
> port status update flow, port update is always asynchronous
>operation. And
> the most efficient way is to implement callback mechanism between
>Neutron
> and Ironic is like it's done for Neutron/Nova.
>
> Neutron/Nova/Ironic teams let me know your thoughts on this.
>
>
> Reference:
> [0] https://bugs.launchpad.net/ironic/+bug/1304673
> [1] https://bugs.launchpad.net/neutron/+bug/1599836
> [2] https://review.openstack.org/339143
> [3] https://review.openstack.org/#/c/339129/
> [4]
>
>https://www.packtpub.com/sites/default/files/Article-Images/B04751_01.p
>ng
> [5]
>
>https://github.com/openstack/neutron/commit/b672c26cb42ad3d9a17ed049b50
>6b5622601e891
>
>
>
>___
>___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

2016-07-26 Thread Hayes, Graham

On 26/07/2016 14:18, Doug Hellmann wrote:
> Excerpts from Luigi Toscano's message of 2016-07-26 15:02:28 +0200:
>> On Tuesday, 26 July 2016 08:34:27 CEST Doug Hellmann wrote:
>>> Excerpts from Andrea Frittoli's message of 2016-07-26 10:24:07 +:

 What still requires work in Tempest is the stable interface. Because
 plugins are not in the Tempest tree, the QA team recommend that they use
 only tempest stable interfaces. Increasing the surface of stable
 interfaces
 is what keeps a lot of the QA folks busy.

 There's a lot of code in tempest that was written under the assumption
 that
 all tests would always live in the tempest tree; evolving that code into a
 stable publicly consumable interface is simply a lot of work, which the QA
 team is prioritising based on the input from plugins.

 Tempest plugins are for all right now. Keystone, Cinder and Neutron
 already
 have a plugin today. We don't want tests which are not relevant for
 integration or defcore to be added to Tempest, and that is true for *all*
 services.
>>>
>>> Thank you for those details, and for confirming that the situation
>>> is more or less what I expected (it's in progress, creating a stable
>>> API takes work, etc.). Where would someone who wanted to contribute
>>> look for details? Are there specs or an etherpad with a task list
>>> or something like that?
>> Andrea can share more details as he is driving the Client Manager refactors,
>> but for example:
>>
>> http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager-refactor.html
>> https://etherpad.openstack.org/p/newton-tempest-service-clients
>
> Good.
>
>>
>>>
>>> And just to satisfy my own curiosity, how does someone looking at the
>>> internals of tempest know what's on the stable API and what's not
>>> considered stable? Are the parts of the API documented separately
>>> somehow or is there a different part of the code tree to look at?
>>
>> tempest.lib is the stable part (previously split in a separate tempest-lib
>> repository, which is now deprecated as the code was put back into the main
>> tempest repository):
>> http://docs.openstack.org/developer/tempest/overview.html#library
>
> That seems quite clear, thanks.

it is actually a bit more -

http://docs.openstack.org/developer/tempest/plugin.html

>>
>> Ciao
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

Excerpts from Luigi Toscano's message of 2016-07-26 15:02:28 +0200:
> On Tuesday, 26 July 2016 08:34:27 CEST Doug Hellmann wrote:
> > Excerpts from Andrea Frittoli's message of 2016-07-26 10:24:07 +:
> > > 
> > > What still requires work in Tempest is the stable interface. Because
> > > plugins are not in the Tempest tree, the QA team recommend that they use
> > > only tempest stable interfaces. Increasing the surface of stable
> > > interfaces
> > > is what keeps a lot of the QA folks busy.
> > > 
> > > There's a lot of code in tempest that was written under the assumption
> > > that
> > > all tests would always live in the tempest tree; evolving that code into a
> > > stable publicly consumable interface is simply a lot of work, which the QA
> > > team is prioritising based on the input from plugins.
> > > 
> > > Tempest plugins are for all right now. Keystone, Cinder and Neutron
> > > already
> > > have a plugin today. We don't want tests which are not relevant for
> > > integration or defcore to be added to Tempest, and that is true for *all*
> > > services.
> > 
> > Thank you for those details, and for confirming that the situation
> > is more or less what I expected (it's in progress, creating a stable
> > API takes work, etc.). Where would someone who wanted to contribute
> > look for details? Are there specs or an etherpad with a task list
> > or something like that?
> Andrea can share more details as he is driving the Client Manager refactors, 
> but for example:
> 
> http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager-refactor.html
> https://etherpad.openstack.org/p/newton-tempest-service-clients

Good.

> 
> > 
> > And just to satisfy my own curiosity, how does someone looking at the
> > internals of tempest know what's on the stable API and what's not
> > considered stable? Are the parts of the API documented separately
> > somehow or is there a different part of the code tree to look at?
> 
> tempest.lib is the stable part (previously split in a separate tempest-lib 
> repository, which is now deprecated as the code was put back into the main 
> tempest repository):
> http://docs.openstack.org/developer/tempest/overview.html#library

That seems quite clear, thanks.

> 
> Ciao

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

2016-07-26 Thread Sean Dague

On 07/26/2016 08:51 AM, Doug Hellmann wrote:

> 
> Given the amount of in-progress work to address the issue you've
> raised, I'm not convinced we need a global rule or policy. All of
> the teams mentioned are working toward the goal of providing stable
> APIs already, and no one seems to be arguing against that goal. The
> teams doing the work are not dragging their feet, and a rule or
> policy wouldn't make the work go any faster.
> 
> The directions for cross-project teams were given when the bit tent
> change went into effect were to "support all official teams" and
> definitely not "do the work for all official teams." There was also
> no requirement that the support be exactly equal, and it would be
> a mistake to try to require that because the issue is almost always
> lack of resources and not lack of desire.  Volunteers to contribute
> to the work that's needed will do more to help than a one-size-fits-all
> policy.

Yes, exactly.

Like Ihar said earlier, we get all kinds of breaks across out system all
the time. It's a complex system. If you look hard what you'll notice is
that project interactions where there are team members in common break a
bit less. For instance Grenade breaks Nova less than other projects.
oslo.versionedobjects breaks Nova less than oslo.messaging does. Why?
Because even with stable interfaces and tests, a lot of behavior remains
in flux given the patch rate on all projects. And when people understand
both sides of a problem, they are more likely to anticipate a problem
during review that no tests caught and didn't seem to change an interface.

This isn't a thing that gets fixed with policy. It gets fixed with people.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

2016-07-26 Thread Luigi Toscano

On Tuesday, 26 July 2016 08:34:27 CEST Doug Hellmann wrote:
> Excerpts from Andrea Frittoli's message of 2016-07-26 10:24:07 +:
> > 
> > What still requires work in Tempest is the stable interface. Because
> > plugins are not in the Tempest tree, the QA team recommend that they use
> > only tempest stable interfaces. Increasing the surface of stable
> > interfaces
> > is what keeps a lot of the QA folks busy.
> > 
> > There's a lot of code in tempest that was written under the assumption
> > that
> > all tests would always live in the tempest tree; evolving that code into a
> > stable publicly consumable interface is simply a lot of work, which the QA
> > team is prioritising based on the input from plugins.
> > 
> > Tempest plugins are for all right now. Keystone, Cinder and Neutron
> > already
> > have a plugin today. We don't want tests which are not relevant for
> > integration or defcore to be added to Tempest, and that is true for *all*
> > services.
> 
> Thank you for those details, and for confirming that the situation
> is more or less what I expected (it's in progress, creating a stable
> API takes work, etc.). Where would someone who wanted to contribute
> look for details? Are there specs or an etherpad with a task list
> or something like that?
Andrea can share more details as he is driving the Client Manager refactors, 
but for example:

http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager-refactor.html
https://etherpad.openstack.org/p/newton-tempest-service-clients

> 
> And just to satisfy my own curiosity, how does someone looking at the
> internals of tempest know what's on the stable API and what's not
> considered stable? Are the parts of the API documented separately
> somehow or is there a different part of the code tree to look at?

tempest.lib is the stable part (previously split in a separate tempest-lib 
repository, which is now deprecated as the code was put back into the main 
tempest repository):
http://docs.openstack.org/developer/tempest/overview.html#library

Ciao
-- 
Luigi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] TripleO Deep Dive session - July 28th

2016-07-26 Thread Emilien Macchi

On Tue, Jul 26, 2016 at 8:32 AM, Udi Kalifon  wrote:
> I think the agenda is great. At what time will the session be? Can you send
> an invite?

https://etherpad.openstack.org/p/tripleo-deep-dive-topics

Keep the link in your bookmarks, it's always the same.

>
> Regards,
> Udi Kalifon; QE Automation; RHOS-UI
>
>
> On Mon, Jul 25, 2016 at 7:25 PM, Emilien Macchi  wrote:
>>
>> Hi,
>>
>> I propose to lead the next TripleO Deep Dive session and it will be
>> about Puppet (go figure).
>>
>> Here's an agenda draft:
>> 1) Introduction about Puppet OpenStack modules.
>> 2) TripleO profiles under the hood
>> 3) Managing data using Hiera and composable services
>> 4) Write your own service step by step.
>>
>> To join the Meeting:
>> https://bluejeans.com/275264340
>>
>> To join via Browser:
>> https://bluejeans.com/275264340/browser
>>
>> To join with Lync:
>> https://bluejeans.com/275264340/lync
>>
>> To join via Room System:
>> Video Conferencing System: bjn.vc -or-199.48.152.152
>> Meeting ID : 275264340
>>
>> To join via phone :
>> 1)  Dial:
>> +44 203 574 6870
>> (see all numbers -
>>
>> https://www.intercallonline.com/listNumbersByCode.action?confCode=3422501687)
>> 2)  Enter Conference ID : 3422501687
>>
>> The session will be recorded and I'll present some slides using my
>> tablet; but I won't share my screen and do terminal things (not needed
>> in this session), since I'm experiencing CPU consumption issues with
>> bluejeans on my laptop.
>>
>> Any feedback is welcome,
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][kolla] Error in tagging process by release liason

Excerpts from Steven Dake (stdake)'s message of 2016-07-23 18:27:00 +:
> Doug and friends,
> 
> I made a pretty serious error when tagging kolla-kubernetes originally.  
> Kolla-kubernetes is in development and not in a production ready state.  We 
> also don't intend to apply for many if any tags for this repository until it 
> becomes more mature.  We do not intend to do backports to this repository 
> once Newton is released.
> 
> The original tag should have been 0.1.0.0b1.  The second milestone tag was 
> 0.1.1 (which should have been 0.1.0.0b2).  I caught this during Doug's review 
> but it was merged before I had a chance to talk to the release team about 
> solutions to this problem.
> 
> I don't expect to rewrite the tags or any of that.  I'd like guidance on what 
> to do for milestone 3 and Ocatta as well (where I guess we can just reset on 
> 0.2.0.0b1).
> 
> Regards
> -steve

kolla-kubernetes uses the release:independent model, for which we don't
really intend to support beta-style milestone tags. The version number
is already a pre-1.0 version, which should clearly indicate instability
and immaturity to anyone consuming it.

Milestone 3 should continue to use semantic versioning and either
use 0.1.2 or 0.2.0 depending on the content. If you want to change
the release model to cycle-with-milestones for Ocata, we can do
that between the end of Newton and the first Ocata milestone.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] How to enable SSL in devStack?

2016-07-26 Thread Rob Crittenden


Clark Boylan wrote:



On Wed, Jul 20, 2016, at 07:01 AM, Rob Crittenden wrote:

Andrey Pavlov wrote:

Hi,

When I ran devstack with SSL I found a bug and tried to fix it -
https://review.openstack.org/#/c/242812/
But no one agree with me.
Try to apply this patch - it may help.
Also there is a chance that new bugs present in devstack that
prevented to install it with SSL.


Seeing how some other things in your local.conf might help but when I
tried to reproduce it I got the same error and it failed because Apache
didn't have an SSL listener on 443.

I'm not sure I'd recommend direct SSL in any case. I'd recommend the
tls-proxy service instead. Note that I'm pretty sure it has the same
problem: it hasn't been updated to handle port 443 for Keystone.


I pushed a change up (https://review.openstack.org/#/c/296771/) to
enable tls-proxy in devstack-gate to see how it does and it wasn't too
happy. Is it worth trying to make a push on this and just enabling it by
default in devstack?


The failure is due to the Keystone switch to using URLs in favor of 
ports to distinguish user and admin operations. The fix is fairly 
straightforward and I have it fixed in a related change, switching from 
stud to mod_proxy https://review.openstack.org/#/c/301172


I'd be fine making the tls-proxy gate job voting once we get things 
working again.


rob


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

Excerpts from Hayes, Graham's message of 2016-07-25 21:36:29 +:
> Top posting - this is a recap of what has been said, and some
> clarifications
> 
> I realise that I was not very clear at the beginning of this process, so
> here is my effort to clarify things, from the ML thread, and the review.
> 
>  >   ... does this also include plugins within projects, like storage
>  >   backends in cinder and hypervisor drivers in nova?
> 
> No - this was not clear enough. This change is aimed at projects that are
> points of significant cross project interaction. While, in the future 
> there may
> come a point where Nova Compute Drivers are developed out of tree (though
> I doubt it), that is not happening today. As a result, there is no 
> projects in
> the list of projects that would need to integrate with Nova.
> 
>  >   Could you please clarify: do you advocate for a generic plugin 
> interface for
>  >   every project, or that each project should expose a plugin 
> interface that
>  >   allows plugin to behave as in-tree components? Because the latter 
> is what
>  >   happens with Tempest, and I see the former a bit complicated.
> 
> For every project that has cross project interaction - tempest is a good
> example.
> 
> For these projects, they should allow all projects in tree (like Nova,
> Neutron, Cinder etc are today), or they should have a plugin interface
> (like they currently do), but all projects *must* use it, and not use
> parts of tempest that are not exposed in that interface.
> 
> This would mean that tempest would move the nova, neutron, etc tests to
> use the plugin interface.
> 
> Now, that plugin could be kept in the tempest repo, and still maintained
> by the QA team, but should use the same interface as the other plugins
> that are not in that repository.
> 
> Of course, it is not just tempest - an incomplete list looks like:
> 
> * Tempest
> * Devstack
> * Grende
> * Horizon
> * OpenStack Client
> * OpenStack SDK
> * Searchlight
> * Heat
> * Mistral
> * Celiometer
> * Rally
> * Documentation
> 
> And I am sure I have missed some obvious ones. (if you see a project missing
> let me know on the review)
> 
>  >   I think I disagree here. The root cause is being addressed: 
> external tests can
>  >   use the Tempest plugin interface, and use the API, which is being 
> stabilized.
>  >   The fact that the Tempest API is partially unstable is a temporary 
> things, due
>  >   to the origin of the project and the way the scope was redefined, 
> but again
>  >   it's temporary.
> 
> This seems to be the core of a lot of the disagreement - this is only 
> temporary,
> it will all be fixed in the future, and it should stay this way.
> 
> Unfortunately the discrepancy between projects is not temporary. The 
> specific
> problems I have highlighted in the thread for one of the projects is 
> temporary,
> but I beleive the only long-term solution is to remove the difference 
> between
> projects.
> 
>  >   Before we start making lots of specific rules about how teams
>  >   coordinate, I would like to understand the problem those rules are 
> meant
>  >   to solve, so thank you for providing that example.
>  >   ...
>  >   It's not clear yet whether there needs to be a new policy to change the
>  >   existing intent, or if a discussion just hasn't happened, or if someone
>  >   simply needs to edit some code.
> 
> Unfortunately there is a big push back on editing code to help plugins from
> some of the projects. Again, having the differing access between 
> projects will
> continue to exacerbate the problem.
> 
>  >   "Change the name of the resolution"
> 
> That was done in the last patchset. I think the Level Playing Field title
> bounced around my head from the other resolution that was titled Level 
> Playing
> Field. It may have been confusing alright.
> 
> I feel like I have been using tempest as an example a little too much, 
> as it captures
> the current issues perfectly, and a large number of the community have some
> knowledge of it, and how it works.
> 
> There is other areas across OpenStack where plugins need attention as well:
> 
> Horizon
> ---
> 
> Horizon privileged projects have access to much more panels than
> plugins (service status, quotas, overviews etc).

Is this by intent, lack of foresight, or changing requirements?

> Plugins have to rely on tarballs of horizon

It sounds like we need to figure out how to tag intermediate releases of
horizon and publish them to PyPI so projects can use them in tests. I'd
be happy to work with the Horizon team on that.

> 
> OpenStack Client
> 
> 
> OpenStack CLI privileged projects have access to more commands, as
> plugins cannot hook in to them (e.g. quotas)

I think Steve addressed this point elsewhere on the thread (it's not by
design, but due to lack of contributor resources).

> 
> Grenade
> ---
> 
> Plugins may or may not have tempest tests ran (I think that patch
> merged), they have to use parts of

Re: [openstack-dev] [devstack] libvirt/qemu source install plugin.

2016-07-26 Thread Michele Paolino


All,

the purpose of the devstack-plugin-tar-installer[1] is exactly what you 
mentioned: a tool needed to test experimental features in libvirt and 
qemu. I am planning to release a new version next week, addressing some 
of the comments received, however new testers/developers are more than 
welcome! Sean, maybe you can have a look at the code and, if you are 
interested, we can discuss how to proceed further.


I also think it would be nice if we can join all together the efforts on 
this project[2], as I believe this is an interesting feature for 
devstack. Maybe there is also a way to integrate this work with the gate 
Markus was mentioning.


Thank you Kashyap for pointing this out!

Regards,

[1]https://review.openstack.org/#/c/313568/
[2]https://review.openstack.org/#/q/project:openstack/devstack-plugin-tar-installer

On 07/26/2016 01:13 PM, Kashyap Chamarthy wrote:

On Thu, Jul 21, 2016 at 02:25:46PM +0200, Markus Zoeller wrote:

On 20.07.2016 22:38, Mooney, Sean K wrote:

Hi
I recently had the need to test a feature (vhost-user reconnect)
that was commit to the qemu source tree a few weeks ago. As there
has been no release since then I needed to build from source so to
that end I wrote a small devstack plugin to do just that.

I was thinking of opening a review to create a new repo to host the
plugin under The openstack namespace
(openstack/devstack-plugin-libvirt-qemu) but before I do I wanted to
ask if others are interested In a devstack plugin that just compiles
and installs qemu and Libvirt?

Regards Sean.


tonby and I try to make the devstack plugin "additional package repos"
(apr) work [1]. What you did is within the scope of that project. We
also have an experimental job
"gate-tempest-dsvm-nova-libvirt-kvm-apr"[2].  The last time I worked
on this I wasn't able to create installable *.deb packages from
libvirt + qemu source code. Other work items did then get more
important and I had to pause the work on that.  I think we can work
together to combine our efforts there.

NB: There's also in-progress work to allow configuring libvirt / QEMU
from source tar balls, as an external DevStack plugin:

 https://review.openstack.org/#/c/313568/ -- Plugin to setup
 libvirt/QEMU from tar releases

It was originally proposed (now abandoned, in favour of the above) as a
patch to DevStack proper, but was abandoned, as it was suggested to make
it as external plugin:

 https://review.openstack.org/#/c/108714/


References:
[1] https://github.com/openstack/devstack-plugin-additional-pkg-repos/
[2]
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/devstack-gate.yaml#L565-L595



--
Michele Paolino


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Binary containers with pip install?

2016-07-26 Thread Jeffrey Zhang

On Tue, Jul 26, 2016 at 5:00 PM, Dave Walker  wrote:
>  - Add support to have per project build type, but this is likely a testing
> scenario that cannot be reasonably assured.

I think  this is another feature we can overwrite some variables in
certain image.

>  - Allow source installs in binary containers, but track it as a TODO bug
> "Please package foo" (Launchpad has great support for linking to other bug
> trackers).  Then once this bug is closed, proper binary support can be
> resolved.  This has the benefit of 'best-effort' towards binary, with a
> clear intent to move across.  It also allows more testing of the binary
> parts that are present, with just the source parts as required. (this is my
> favourite)

Love this too.
Maybe we need a WARNING to the stdout to tell the operators.




-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kuryr] Kuryr IRC Meeting time

2016-07-26 Thread Vikas Choudhary

On Tue, Jul 26, 2016 at 5:36 PM, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:

>
>
> On Tue, Jul 26, 2016 at 12:53 PM, Vikas Choudhary <
> choudharyvika...@gmail.com> wrote:
>
>> +1
>> On 26 Jul 2016 15:45, "Liping Mao (limao)"  wrote:
>>
>>> Hi Team,
>>>
>>> Currently, kuryr team meeting time is as following:
>>>
>>> Every two weeks (on even weeks) on Tuesday at 0300 UTC in
>>> #openstack-meeting-4
>>>
>>>
>>> Every two weeks (on odd weeks) on Monday at 1400 UTC in
>>> #openstack-meeting-4
>>>
>>>
>>>
>>> But seems like there are less people join the meeting on Tuesday at 0300
>>> UTC.
>>> You can see[1], we did not start the meeting at 0300 UTC for two times
>>> recently.
>>> IMO, If the time is not suitable for attendee, what about change the
>>> meeting time(0300 UTC)?
>>>
>>
> Sounds good to me. Could the people that used to attend it (and those who
> would like to)
> propose times that suit them?
>
>
Its not happening because of 'Chair' unavailability. So I think, we should
first discuss who can be alternate chair in case Taku is not there. We
chose this time slot so that team members from almost all time zones would
be able to attend atleast bi-weekly.


>
>>> Thanks.
>>> [1]http://eavesdrop.openstack.org/meetings/kuryr/2016/
>>>
>>> Regards,
>>> Liping Mao
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)