date:20160728


On 7/28/2016 3:55 PM, Matt Riedemann wrote:

For os-attach-interfaces, we need that to attach/detach interfaces to a
server, so those actions don't go away with 2.36. We can also list and
show interfaces (ports) which is a proxy to neutron, but in this case it
seems a tad bit necessary, else to list ports for a given server you
have to know to list ports via neutron CLI and filter on
device_id=server.uuid.


On second thought, we could drop the proxy APIs to list/show ports for a 
given server. python-openstackclient could have a convenience CLI for 
listing ports for a server. And the show in os-attach-interfaces takes a 
server id but it's not used, so it's basically pointless and should just 
be replaced with neutron.


The question is, as these are proxies and the 2.36 microversion was for 
proxy API deprecation, can we still do those in 2.36 even though it's 
already merged? Or do they need to be 2.37? That seems like the more 
accurate thing to do, but then we really have some weird "which is the 
REAL proxy API microversion?" logic going on.


I think we could move forward with deprecation in novaclient either way.

--

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] [nova] os-virtual-interfaces isn't deprecated in 2.36


On 7/28/2016 3:55 PM, Matt Riedemann wrote:

So I think we're OK with os-attach-interfaces (even though it does some
proxying right now), but I'm thinking we should be deprecating
os-virtual-interfaces.



Or if we don't deprecate os-virtual-interfaces, we should implement it 
for neutron too (since it's really the same as for nova-network, it's 
stuff in the nova db) and return the tag attribute.


--

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

[openstack-dev] [watcher] Mascot final choice

2016-07-28 Thread Antoine Cabot

Hi Watcher team,

Last week during the mid-cycle, we came up with a list of possible mascots
for Watcher. The only one which is in conflict with other projects is the
bee.
So we have this final list :
1. Jellyfish
2. Eagle
3. Hammerhead shark

I'm going to confirm jellyfish as the Watcher mascot by EOW except if any
contributor is against this choice. Please let me know.

Antoine
__
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] [nova] os-virtual-interfaces isn't deprecated in 2.36

I'm not sure if we thought about this before, but the 
os-virtual-interfaces API isn't deprecated with the 2.36 microversion:


https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/virtual_interfaces.py

Neither is os-attach-interfaces:

https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/attach_interfaces.py

Until we had virtual device tagging in 2.32, VirtualInterfaces would 
only be used for nova-network, but with vif tags we store those on VIFs 
in the nova DB, so os-virtual-interfaces could be used to list those. 
However, os-virtual-interfaces doesn't return the VIF tags in the 
responseseems we missed that with the 2.32 microversion. I'm not 
sure how useful that use case is anyway. Plus get_vifs_by_instance isn't 
implemented for neutron, so you'd get a 500 error from this API today 
anyway...


For os-attach-interfaces, we need that to attach/detach interfaces to a 
server, so those actions don't go away with 2.36. We can also list and 
show interfaces (ports) which is a proxy to neutron, but in this case it 
seems a tad bit necessary, else to list ports for a given server you 
have to know to list ports via neutron CLI and filter on 
device_id=server.uuid.


So I think we're OK with os-attach-interfaces (even though it does some 
proxying right now), but I'm thinking we should be deprecating 
os-virtual-interfaces.


--

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] [Congress] Congress horizon plugin - congressclient/congress API auth issue - help

2016-07-28 Thread Aimee Ukasick

I've gotten a little farther, which leads me to my next question -
does the API support v3 token auth?
or am I making mistakes in my manual testing?

using the CLI on local devstack
1) did not modify openrc
2) source openrc
3) openstack token issue
4)  openstack congress datasource list --os-auth-type v3token
--os-token ad74073300e244768e08e0d4cd73fbbd --os-auth-url
http://192.168.56.101:5000/v3
--os-project-id da9a9ba573c34c18a037fd04812d81bc   --debug --verbose

When the python-congressclient calls the API, this is the response:
RESP BODY: Policy doesn't allow get_v1 to be performed.
Request returned failure status: 403

Log:  http://paste.openstack.org/show/543445/

So then I called the API directly:
curl -X POST -H "Content-Type: application/json" -H "Cache-Control: no-cache"
-d '{ "auth": {
"identity": {
  "methods": ["password"],
  "password": {
"user": {
  "name": "demo",
  "domain": { "id": "default" },
  "password": "secret"
}
  }
}
  }
}' "http://192.168.56.101:5000/v3/auth/tokens;

Response:
{
  "token": {
"issued_at": "2016-07-28T20:43:44.258137Z",
"audit_ids": [
  "N6tnfbI5QvyRT4xEB7pGCA"
],
"methods": [
  "password"
],
"expires_at": "2016-07-28T21:43:44.258112Z",
"user": {
  "domain": {
"id": "default",
"name": "Default"
  },
  "id": "f2bf5189bbd7466cbecc1b1315cff3b5",
  "name": "demo"
}
  }
}

Then:
curl -X GET -H "X-Auth-Token: f2bf5189bbd7466cbecc1b1315cff3b5" -H
"Cache-Control: no-cache" "http://192.168.56.101:1789/v1/data-sources;

Response:
{
  "error": {
"message": "The request you have made requires authentication.",
"code": 401,
"title": "Unauthorized"
  }
}

I'm feeling pretty stupid at the moment, like I've missed something obvious.
Any ideas?

Thanks!

aimee

On Fri, Jul 22, 2016 at 9:21 PM, Anusha Ramineni  wrote:
> Hi Aimee,
>
> Thanks for the investigation.
>
> I remember testing congress client with V3 password based authentication ,
> which worked fine .. but never tested with token based .
>
> Please go ahead and fix it , if you think there is any issue .
>
>
> On 22-Jul-2016 9:38 PM, "Aimee Ukasick"  wrote:
>>
>> All - I made the change to the auth_url that  Anusha suggested.
>> Same problem as before " Cannot authorize API client"
>> 2016-07-22 14:13:50.835861 * calling policies_list =
>> client.list_policy()*
>> 2016-07-22 14:13:50.836062 Unable to get policies list: Cannot
>> authorize API client.
>>
>> I used the token from the log output to query the Congress API with
>> the keystone v3 token - no issues.
>> curl -X GET -H "X-Auth-Token: 18ec54ac811b49aa8265c3d535ba0095" -H
>> "Cache-Control: no-cache" "http://192.168.56.103:1789/v1/policies;
>>
>> So I really think the problem is that the python-congressclient
>> doesn't support identity v3.
>> I thought it did, but then I came across this:
>> "support keystone v3 api and session based authentication "
>> https://bugs.launchpad.net/python-congressclient/+bug/1564361
>> This is currently assigned to Anusha.
>> I'd like to start work on it since I am becoming familiar with keystone
>> v3.
>>
>> Thoughts?
>>
>> aimee
>>
>>
>>
>>
>> On Fri, Jul 22, 2016 at 8:07 AM, Aimee Ukasick
>>  wrote:
>> > Thanks Anusha! I will retest this today. I guess I need to learn more
>> > about Horizon as well - thanks for pointing me in the right direction.
>> >
>> > aimee
>> >
>> >
>> >
>> > On Fri, Jul 22, 2016 at 6:30 AM, Anusha Ramineni
>> >  wrote:
>> >> Hi Aimee,
>> >>
>> >> I think devstack by default configured horizon to use v3 .
>> >> For V2 authentication, from the logs , auth_url doesn't seem to be set
>> >> explicitly to v2 auth_url .
>> >>
>> >> I have always set explicit v2 auth which worked fine.
>> >> For eg:- auth_url = 'http://:5000/v2.0' , for V2
>> >> authentication
>> >>
>> >> I have raised a patch, to take the auth_url from horizon settings
>> >> instead of
>> >> from request.
>> >> https://review.openstack.org/#/c/345828/1
>> >>
>> >> Please set explict v2 auth_url as mentioned above in
>> >> OPENSTACK_KESYTONE_URL
>> >> in /openstack_dashboard/local/local_settings.py and restart
>> >> apache2
>> >> server . Then v2 authentication should go through fine.
>> >>
>> >> For v3 , need to add relevant code for v3 authentication in
>> >> contrib/horizon
>> >> as presently it is hardcoded to use only v2. but yes, the code from
>> >> plugin
>> >> model patch is still a WIP , so doesn't work for v3 authentication I
>> >> guess
>> >> I'll have a look at it and let you know .
>> >>
>> >>
>> >> Best Regards,
>> >> Anusha
>> >>
>> >> On 21 July 2016 at 21:56, Tim Hinrichs  wrote:
>> >>>
>> >>> So clearly an authentication problem then.
>> >>>
>> >>> Anusha, do you have any ideas?  (Aimee, I think Anusha has worked with
>> >>> Keystone authentication most

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

2016-07-28 Thread Cathy Zhang

Hi Assaf,

Yes, that makes sense. 

Thanks,
Cathy

-Original Message-
From: Assaf Muller [mailto:as...@redhat.com] 
Sent: Thursday, July 28, 2016 1:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version

On Thu, Jul 28, 2016 at 3:02 PM, Cathy Zhang  wrote:
> Hi Ihar and all,
>
> Yes, we have been preparing for such a release. We will do one more round of 
> testing to make sure everything works fine, and then I will submit the 
> release request.
> There is a new patch on "stadium: adopt openstack/releases in subproject 
> release process" which is not Merged yet.
> Shall I follow this 
> http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
>  to submit the request?
> Do you have a good bug example for Neutron sub-project release request?
>
> BTW, a functional and tempest patch for networking-sfc has been uploaded and 
> it might take some time for the team to complete the review. The test is 
> non-voting. Do you think we should wait until this patch is merged or release 
> can be done without it?

The ideal is that any testing you're doing downstream or manually should be 
happening upstream and via CI. If you feel the need to run things one more time 
then that means that the upstream CI that is running for SFC is insufficient. A 
secondary incentive is to boost adoption - People tend to be attracted to 
stable projects with higher quality testing. I would advise accelerating the 
functional and tempest tests patches and releasing when your CI is in a better 
state.

>
> Thanks,
> Cathy
>
> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Wednesday, July 27, 2016 1:24 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version
>
> Tony Breeds  wrote:
>
>> On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
>>> Hi,
>>> Is anyone looking at creating a stable/mitaka version? What if 
>>> someone want to use this for stable/mitaka?
>>
>> If that's a thing you need it's a matter of Armando asking the 
>> release managers to create it.
>
> I only suggest Armando is not dragged into it, the release liaison (currently 
> me) should be able to handle the request if it comes from the core team for 
> the subproject.
>
> Ihar
>
> __
>  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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Thanks Doug.  I didn't pick up on your choice of Zane's point #1.  If that
is how the rest of the TC feels about it, that wfm.  I will be submitting
a resolution with your wording so clarity is reached and not lost in a
mailing list thread in the future when this issue occurs again.

Regards
-steve


On 7/28/16, 1:13 PM, "Doug Hellmann"  wrote:

>Excerpts from Steven Dake (stdake)'s message of 2016-07-28 19:40:29 +:
>> 
>> On 7/28/16, 12:30 PM, "Davanum Srinivas"  wrote:
>> 
>> >Steven,
>> >
>> >Please see response from Doug:
>> >http://markmail.org/message/yp7fpojnzufb5jki
>> 
>> Dims,
>> 
>> Are you implying Doug's position represents that of the TC?
>> 
>> I have read Doug's position, and it completely ignores Zane's assessment
>> of the problem at hand.
>
>I did not ignore his assessment. If I was not clear, I am saying
>that his interpretation #1 is the correct interpretation, that
>members of official teams can contribute to repositories that are
>not under governance.
>
>If you disagree with my conclusion or think further action is needed,
>then I suggest you formally propose something be added to the TC
>agenda. I consider this resolved, but it is well within your rights
>as a community member to propose topics for discussion yourself and
>I whole-heartedly encourage you to exercise those rights if you
>think you are not being heard and that the full TC needs to be
>involved to take more formal action.
>
>To add an agenda item, all you have to do is edit the wiki page [1]
>but please note there are some stipulations about timing at the
>bottom of the page, so read those first to ensure that your
>expectations are set correctly. If you have any known schedule
>conflicts, include that information so we can be sure to schedule
>the discussion for a week when you can be present to participate.
>
>Doug
>
>[1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
>
>> 
>> Clarity has not been reached.  I could restate the problem for you if
>>you
>> like.
>> 
>> >
>> >If anyone disagrees with that position, please file a resolution.
>> >
>> >Let's stop this thread now please.
>> 
>> 
>> Asking for a thread to be stopped before a resolution is reached is not
>> the right thing.
>> 
>> Regards
>> -steve
>> 
>> >
>> >Thanks,
>> >Dims
>> >
>> >On Thu, Jul 28, 2016 at 3:26 PM, Steven Dake (stdake)
>>
>> >wrote:
>> >> Dims,
>> >>
>> >> I personally think its the responsibility of the TC to resolve this
>> >> problem via a resolution.  That’s why we elected you folks :)
>> >>
>> >> Regards
>> >> -steve
>> >>
>> >>
>> >> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
>> >>
>> >>>Zane, Steve,
>> >>>
>> >>>I'd say go for it! Can you please write up a proposal for the TC to
>> >>>consider? 
>> >>>(https://review.openstack.org/#/q/project:openstack/governance)
>> >>>
>> >>>Thanks,
>> >>>-- Dims
>> >>>
>> >>>On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake)
>>
>> >>>wrote:
>>  Jay,
>> 
>>  I'll be frank.  I have been receiving numerous complaints which
>>mirror
>>  Zane's full second understanding of what it means to be an
>>OpenStack
>> big
>>  tent project.  These are not just Kolla developers.  These are
>>people
>> from
>>  all over the community.  They want something done about it.  I
>>agree
>> with
>>  Zane if clarity is provided by the TC via a resolution, the problem
>> would
>>  disappear.  We are all adults and can live by the rules, even if we
>>  disagree with them.  This contract is the agreement under which
>>  democracies are created, and one of the most appealing properties
>>of
>>  OpenStack.
>> 
>>  In this case there is no policy and one is obviously necessary to
>> avoid
>>  these scenarios in the future.
>> 
>>  The TC has four options as I see it:
>>  1) do nothing
>>  2) write a resolution mirroring Zane's first analysis
>>  3) write a resolution mirroring Zane's second analysis
>>  4) write a different resolution that is a compromise of the first
>> analysis
>>  and second analysis
>> 
>>  I don't wish Mirantis to state anything.  Vladimir did that (thanks
>>  Vladimir!).
>> 
>>  Regards
>>  -steve
>> 
>> 
>>  On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
>> 
>> >I don't see what is unclear about any of it.
>> >
>> >What exactly is it that you wish Mirantis to state?
>> >
>> >Zane says there needs to be some guidance from the TC "about what
>>it
>> >means for a repo to be part of the OpenStack tent".
>> >
>> >But the fuel-ccp repos aren't listed in the governance repo, for
>> >reasons
>> >that were clearly stated by Mirantis engineers. They want to
>>innovate
>> >in
>> >this area without all the politics that this thread exposes.
>> >
>> >Mirantis engineers have

Re: [openstack-dev] [nova][nova-docker] nova-scheduler filters configuration

2016-07-28 Thread yasemin

When ı add the filter about nova-scheduler, the error occur, like the filters 
has no header, but ı don’t  understand which means??  anyone help me ? 


> On Jul 28, 2016, at 3:14 PM, Yasemin DEMİRAL (BİLGEM BTE) 
>  wrote:
> 
> Should I configure nova.conf file for nova-scheduler filter ?  but which 
> step, [docker]  on container node ?  
> Is the same work, Zun project ? what can I do, controller node. it has a 
> error about filters properties.
> 
> Kimden: "Sudipta Biswas" 
> Kime: openstack-dev@lists.openstack.org
> Gönderilenler: 28 Temmuz Perşembe 2016 13:51:39
> Konu: Re: [openstack-dev] [nova][nova-docker] nova-scheduler filters 
> configuration
> 
> 
> 
> 
> On 28/07/16 12:34 PM, Yasemin DEMİRAL (BİLGEM BTE) wrote:
> hi
> I work on installation nova-docker in multi nodes openstack mitaka systems.
> how can I configure nova-scheduler filter to  compute node and controller 
> node ? 
> You should have the nova-scheduler ideally on the controller node (but it can 
> be anywhere other than the compute nodes itself). I am not sure if we 
> recommend excluding any particular scheduler in case of nova-docker that 
> usually
> apply for virtual machines, but you should be able to use the filters you 
> need via the
> nova.conf on your scheduler node.
> Thank you
> Yasemin Demiral
> 
> 
> __
> 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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Excerpts from Steven Dake (stdake)'s message of 2016-07-28 19:40:29 +:
> 
> On 7/28/16, 12:30 PM, "Davanum Srinivas"  wrote:
> 
> >Steven,
> >
> >Please see response from Doug:
> >http://markmail.org/message/yp7fpojnzufb5jki
> 
> Dims,
> 
> Are you implying Doug's position represents that of the TC?
> 
> I have read Doug's position, and it completely ignores Zane's assessment
> of the problem at hand.

I did not ignore his assessment. If I was not clear, I am saying
that his interpretation #1 is the correct interpretation, that
members of official teams can contribute to repositories that are
not under governance.

If you disagree with my conclusion or think further action is needed,
then I suggest you formally propose something be added to the TC
agenda. I consider this resolved, but it is well within your rights
as a community member to propose topics for discussion yourself and
I whole-heartedly encourage you to exercise those rights if you
think you are not being heard and that the full TC needs to be
involved to take more formal action.

To add an agenda item, all you have to do is edit the wiki page [1]
but please note there are some stipulations about timing at the
bottom of the page, so read those first to ensure that your
expectations are set correctly. If you have any known schedule
conflicts, include that information so we can be sure to schedule
the discussion for a week when you can be present to participate.

Doug

[1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

> 
> Clarity has not been reached.  I could restate the problem for you if you
> like.
> 
> >
> >If anyone disagrees with that position, please file a resolution.
> >
> >Let's stop this thread now please.
> 
> 
> Asking for a thread to be stopped before a resolution is reached is not
> the right thing.
> 
> Regards
> -steve
> 
> >
> >Thanks,
> >Dims
> >
> >On Thu, Jul 28, 2016 at 3:26 PM, Steven Dake (stdake) 
> >wrote:
> >> Dims,
> >>
> >> I personally think its the responsibility of the TC to resolve this
> >> problem via a resolution.  That’s why we elected you folks :)
> >>
> >> Regards
> >> -steve
> >>
> >>
> >> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
> >>
> >>>Zane, Steve,
> >>>
> >>>I'd say go for it! Can you please write up a proposal for the TC to
> >>>consider? 
> >>>(https://review.openstack.org/#/q/project:openstack/governance)
> >>>
> >>>Thanks,
> >>>-- Dims
> >>>
> >>>On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
> >>>wrote:
>  Jay,
> 
>  I'll be frank.  I have been receiving numerous complaints which mirror
>  Zane's full second understanding of what it means to be an OpenStack
> big
>  tent project.  These are not just Kolla developers.  These are people
> from
>  all over the community.  They want something done about it.  I agree
> with
>  Zane if clarity is provided by the TC via a resolution, the problem
> would
>  disappear.  We are all adults and can live by the rules, even if we
>  disagree with them.  This contract is the agreement under which
>  democracies are created, and one of the most appealing properties of
>  OpenStack.
> 
>  In this case there is no policy and one is obviously necessary to
> avoid
>  these scenarios in the future.
> 
>  The TC has four options as I see it:
>  1) do nothing
>  2) write a resolution mirroring Zane's first analysis
>  3) write a resolution mirroring Zane's second analysis
>  4) write a different resolution that is a compromise of the first
> analysis
>  and second analysis
> 
>  I don't wish Mirantis to state anything.  Vladimir did that (thanks
>  Vladimir!).
> 
>  Regards
>  -steve
> 
> 
>  On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
> 
> >I don't see what is unclear about any of it.
> >
> >What exactly is it that you wish Mirantis to state?
> >
> >Zane says there needs to be some guidance from the TC "about what it
> >means for a repo to be part of the OpenStack tent".
> >
> >But the fuel-ccp repos aren't listed in the governance repo, for
> >reasons
> >that were clearly stated by Mirantis engineers. They want to innovate
> >in
> >this area without all the politics that this thread exposes.
> >
> >Mirantis engineers have clearly laid out the technical reasons that
> >Kolla doesn't fit the needs that Fuel has of these image definitions
> >and
> >orchestration tooling.
> >
> >The repos *aren't in the OpenStack tent* so how precisely would TC
> >guidance about what it means for a repo to be part of the OpenStack
> >tent
> >be useful here?
> >
> >-jay
> >
> >On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
> >> Jay,
> >>
> >> That resolution doesn't clarify Zane's argument.
>

[openstack-dev] [nova] Reminder: mox conversion and py3 support changes freeze after today


At the end of today we'll be frozen on mox conversion and python 3 support.

These are the outstanding python 3 changes for nova:

https://review.openstack.org/#/q/topic:bp/nova-python3-newton+status:open

And for mox conversion:

https://review.openstack.org/#/q/topic:bp/remove-mox-newton+status:open

There are a ton of the mox conversion changes so I'm not going to be 
-2ing all of those, just be aware we're done reviewing those for newton 
and will open up again in ocata.


--

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] [Neutron] SFC stable/mitaka version

2016-07-28 Thread Assaf Muller

On Thu, Jul 28, 2016 at 3:02 PM, Cathy Zhang  wrote:
> Hi Ihar and all,
>
> Yes, we have been preparing for such a release. We will do one more round of 
> testing to make sure everything works fine, and then I will submit the 
> release request.
> There is a new patch on "stadium: adopt openstack/releases in subproject 
> release process" which is not Merged yet.
> Shall I follow this 
> http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
>  to submit the request?
> Do you have a good bug example for Neutron sub-project release request?
>
> BTW, a functional and tempest patch for networking-sfc has been uploaded and 
> it might take some time for the team to complete the review. The test is 
> non-voting. Do you think we should wait until this patch is merged or release 
> can be done without it?

The ideal is that any testing you're doing downstream or manually
should be happening upstream and via CI. If you feel the need to run
things one more time then that means that the upstream CI that is
running for SFC is insufficient. A secondary incentive is to boost
adoption - People tend to be attracted to stable projects with higher
quality testing. I would advise accelerating the functional and
tempest tests patches and releasing when your CI is in a better state.

>
> Thanks,
> Cathy
>
> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Wednesday, July 27, 2016 1:24 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version
>
> Tony Breeds  wrote:
>
>> On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
>>> Hi,
>>> Is anyone looking at creating a stable/mitaka version? What if
>>> someone want to use this for stable/mitaka?
>>
>> If that's a thing you need it's a matter of Armando asking the release
>> managers to create it.
>
> I only suggest Armando is not dragged into it, the release liaison (currently 
> me) should be able to handle the request if it comes from the core team for 
> the subproject.
>
> Ihar
>
> __
> 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] [octavia]redirection and barbican config

2016-07-28 Thread Akshay Kumar Sanghai

Hi,
I have a couple on questions on octavia. Please answer or redirect me to
relevant documentation:
- Assume listener is listening on 443 and client hits the vip on port 80,
the connection will be refused.  Is it possible to configure http to https
direction?

- For the barbican config, the only config item i can find is
cert_manager_type in neutron_lbaas.conf. How do we configure the barbican
access for lbaas. I assume since we do the access config for nova and
keystone in neutron.conf, there should be some config file where we define
the barbican access(username, password, auth_url).

The community has been very helpful to me. Thanks a lot Guys. Appreciate
your efforts.

Thanks
Akshay Sanghai
__
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

Steve,

This thread has degenerated. So my request is to use Doug's post as
status quo. If there's disagreement then file for a resolution that
suits them

-- Dims

On Thu, Jul 28, 2016 at 3:40 PM, Steven Dake (stdake)  wrote:
>
>
> On 7/28/16, 12:30 PM, "Davanum Srinivas"  wrote:
>
>>Steven,
>>
>>Please see response from Doug:
>>http://markmail.org/message/yp7fpojnzufb5jki
>
> Dims,
>
> Are you implying Doug's position represents that of the TC?
>
> I have read Doug's position, and it completely ignores Zane's assessment
> of the problem at hand.
>
> Clarity has not been reached.  I could restate the problem for you if you
> like.
>
>>
>>If anyone disagrees with that position, please file a resolution.
>>
>>Let's stop this thread now please.
>
>
> Asking for a thread to be stopped before a resolution is reached is not
> the right thing.
>
> Regards
> -steve
>
>>
>>Thanks,
>>Dims
>>
>>On Thu, Jul 28, 2016 at 3:26 PM, Steven Dake (stdake) 
>>wrote:
>>> Dims,
>>>
>>> I personally think its the responsibility of the TC to resolve this
>>> problem via a resolution.  That’s why we elected you folks :)
>>>
>>> Regards
>>> -steve
>>>
>>>
>>> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
>>>
Zane, Steve,

I'd say go for it! Can you please write up a proposal for the TC to
consider?
(https://review.openstack.org/#/q/project:openstack/governance)

Thanks,
-- Dims

On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
wrote:
> Jay,
>
> I'll be frank.  I have been receiving numerous complaints which mirror
> Zane's full second understanding of what it means to be an OpenStack
>big
> tent project.  These are not just Kolla developers.  These are people
>from
> all over the community.  They want something done about it.  I agree
>with
> Zane if clarity is provided by the TC via a resolution, the problem
>would
> disappear.  We are all adults and can live by the rules, even if we
> disagree with them.  This contract is the agreement under which
> democracies are created, and one of the most appealing properties of
> OpenStack.
>
> In this case there is no policy and one is obviously necessary to
>avoid
> these scenarios in the future.
>
> The TC has four options as I see it:
> 1) do nothing
> 2) write a resolution mirroring Zane's first analysis
> 3) write a resolution mirroring Zane's second analysis
> 4) write a different resolution that is a compromise of the first
>analysis
> and second analysis
>
> I don't wish Mirantis to state anything.  Vladimir did that (thanks
> Vladimir!).
>
> Regards
> -steve
>
>
> On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
>
>>I don't see what is unclear about any of it.
>>
>>What exactly is it that you wish Mirantis to state?
>>
>>Zane says there needs to be some guidance from the TC "about what it
>>means for a repo to be part of the OpenStack tent".
>>
>>But the fuel-ccp repos aren't listed in the governance repo, for
>>reasons
>>that were clearly stated by Mirantis engineers. They want to innovate
>>in
>>this area without all the politics that this thread exposes.
>>
>>Mirantis engineers have clearly laid out the technical reasons that
>>Kolla doesn't fit the needs that Fuel has of these image definitions
>>and
>>orchestration tooling.
>>
>>The repos *aren't in the OpenStack tent* so how precisely would TC
>>guidance about what it means for a repo to be part of the OpenStack
>>tent
>>be useful here?
>>
>>-jay
>>
>>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
>>> Jay,
>>>
>>> That resolution doesn't clarify Zane's argument.
>>>
>>> Regards,
>>> -steve
>>>
>>> On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
>>>
 The TC has given guidance on this already:


http://governance.openstack.org/resolutions/20160119-stackforge-reti
re
me
nt
 .html

 "In order to simplify software development lifecycle transitions of
 Unofficial and Official OpenStack projects, all projects developed
 within the OpenStack project infrastructure will be permitted to
use
the
 “openstack/” namespace. The use of the term “Stackforge” to
describe
 unofficial projects should be considered deprecated."

 The Fuel CCP repos are projects that are not official OpenStack
projects.

 They are in the openstack/ git namespace because they use the
common
 infrastructure and there isn't any formal plan to have the repos
join
 the "official OpenStack projects" (i.e.

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

If it ever becomes necessary for us to pass a resolution to deal with
every disagreement, we might as well all go herd goats.

This is a very straightforward situation, which has been blown out of
all reasonable proportion through well-intentioned but misplaced
concerns.

Please, everyone, let's call it resolved.

Doug

Excerpts from Steven Dake (stdake)'s message of 2016-07-28 19:26:37 +:
> Dims,
> 
> I personally think its the responsibility of the TC to resolve this
> problem via a resolution.  That’s why we elected you folks :)
> 
> Regards
> -steve
> 
> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
> 
> >Zane, Steve,
> >
> >I'd say go for it! Can you please write up a proposal for the TC to
> >consider? (https://review.openstack.org/#/q/project:openstack/governance)
> >
> >Thanks,
> >-- Dims
> >
> >On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
> >wrote:
> >> Jay,
> >>
> >> I'll be frank.  I have been receiving numerous complaints which mirror
> >> Zane's full second understanding of what it means to be an OpenStack big
> >> tent project.  These are not just Kolla developers.  These are people
> >>from
> >> all over the community.  They want something done about it.  I agree
> >>with
> >> Zane if clarity is provided by the TC via a resolution, the problem
> >>would
> >> disappear.  We are all adults and can live by the rules, even if we
> >> disagree with them.  This contract is the agreement under which
> >> democracies are created, and one of the most appealing properties of
> >> OpenStack.
> >>
> >> In this case there is no policy and one is obviously necessary to avoid
> >> these scenarios in the future.
> >>
> >> The TC has four options as I see it:
> >> 1) do nothing
> >> 2) write a resolution mirroring Zane's first analysis
> >> 3) write a resolution mirroring Zane's second analysis
> >> 4) write a different resolution that is a compromise of the first
> >>analysis
> >> and second analysis
> >>
> >> I don't wish Mirantis to state anything.  Vladimir did that (thanks
> >> Vladimir!).
> >>
> >> Regards
> >> -steve
> >>
> >>
> >> On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
> >>
> >>>I don't see what is unclear about any of it.
> >>>
> >>>What exactly is it that you wish Mirantis to state?
> >>>
> >>>Zane says there needs to be some guidance from the TC "about what it
> >>>means for a repo to be part of the OpenStack tent".
> >>>
> >>>But the fuel-ccp repos aren't listed in the governance repo, for reasons
> >>>that were clearly stated by Mirantis engineers. They want to innovate in
> >>>this area without all the politics that this thread exposes.
> >>>
> >>>Mirantis engineers have clearly laid out the technical reasons that
> >>>Kolla doesn't fit the needs that Fuel has of these image definitions and
> >>>orchestration tooling.
> >>>
> >>>The repos *aren't in the OpenStack tent* so how precisely would TC
> >>>guidance about what it means for a repo to be part of the OpenStack tent
> >>>be useful here?
> >>>
> >>>-jay
> >>>
> >>>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
>  Jay,
> 
>  That resolution doesn't clarify Zane's argument.
> 
>  Regards,
>  -steve
> 
>  On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
> 
> > The TC has given guidance on this already:
> >
> >
> >http://governance.openstack.org/resolutions/20160119-stackforge-retire
> >me
> >nt
> > .html
> >
> > "In order to simplify software development lifecycle transitions of
> > Unofficial and Official OpenStack projects, all projects developed
> > within the OpenStack project infrastructure will be permitted to use
> >the
> > “openstack/” namespace. The use of the term “Stackforge” to describe
> > unofficial projects should be considered deprecated."
> >
> > The Fuel CCP repos are projects that are not official OpenStack
> >projects.
> >
> > They are in the openstack/ git namespace because they use the common
> > infrastructure and there isn't any formal plan to have the repos join
> > the "official OpenStack projects" (i.e. the ones listed in the
> > projects.yaml file in the openstack/governance repository).
> >
> > Could they be proposed in the future as official OpenStack projects?
> > Maybe. Not sure, and I don't believe it's necessary to decide ahead
> >of
> > time.
> >
> > Please stop using a marketing press release as some indication of
> >what
> > the "intent" is for these repos or even that there *is* any intent at
> > this point. It's really early on and these repos are intended as a
> >place
> > to experiment and innovate. I don't see why there is so much anger
> >about
> > that.
> >
> > Best,
> > -jay
> >
> > On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
> >> Doug,
> >>
> >> Zane's analysis is correct.  I agree with

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



On 7/28/16, 12:30 PM, "Davanum Srinivas"  wrote:

>Steven,
>
>Please see response from Doug:
>http://markmail.org/message/yp7fpojnzufb5jki

Dims,

Are you implying Doug's position represents that of the TC?

I have read Doug's position, and it completely ignores Zane's assessment
of the problem at hand.

Clarity has not been reached.  I could restate the problem for you if you
like.

>
>If anyone disagrees with that position, please file a resolution.
>
>Let's stop this thread now please.


Asking for a thread to be stopped before a resolution is reached is not
the right thing.

Regards
-steve

>
>Thanks,
>Dims
>
>On Thu, Jul 28, 2016 at 3:26 PM, Steven Dake (stdake) 
>wrote:
>> Dims,
>>
>> I personally think its the responsibility of the TC to resolve this
>> problem via a resolution.  That’s why we elected you folks :)
>>
>> Regards
>> -steve
>>
>>
>> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
>>
>>>Zane, Steve,
>>>
>>>I'd say go for it! Can you please write up a proposal for the TC to
>>>consider? 
>>>(https://review.openstack.org/#/q/project:openstack/governance)
>>>
>>>Thanks,
>>>-- Dims
>>>
>>>On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
>>>wrote:
 Jay,

 I'll be frank.  I have been receiving numerous complaints which mirror
 Zane's full second understanding of what it means to be an OpenStack
big
 tent project.  These are not just Kolla developers.  These are people
from
 all over the community.  They want something done about it.  I agree
with
 Zane if clarity is provided by the TC via a resolution, the problem
would
 disappear.  We are all adults and can live by the rules, even if we
 disagree with them.  This contract is the agreement under which
 democracies are created, and one of the most appealing properties of
 OpenStack.

 In this case there is no policy and one is obviously necessary to
avoid
 these scenarios in the future.

 The TC has four options as I see it:
 1) do nothing
 2) write a resolution mirroring Zane's first analysis
 3) write a resolution mirroring Zane's second analysis
 4) write a different resolution that is a compromise of the first
analysis
 and second analysis

 I don't wish Mirantis to state anything.  Vladimir did that (thanks
 Vladimir!).

 Regards
 -steve


 On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:

>I don't see what is unclear about any of it.
>
>What exactly is it that you wish Mirantis to state?
>
>Zane says there needs to be some guidance from the TC "about what it
>means for a repo to be part of the OpenStack tent".
>
>But the fuel-ccp repos aren't listed in the governance repo, for
>reasons
>that were clearly stated by Mirantis engineers. They want to innovate
>in
>this area without all the politics that this thread exposes.
>
>Mirantis engineers have clearly laid out the technical reasons that
>Kolla doesn't fit the needs that Fuel has of these image definitions
>and
>orchestration tooling.
>
>The repos *aren't in the OpenStack tent* so how precisely would TC
>guidance about what it means for a repo to be part of the OpenStack
>tent
>be useful here?
>
>-jay
>
>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
>> Jay,
>>
>> That resolution doesn't clarify Zane's argument.
>>
>> Regards,
>> -steve
>>
>> On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
>>
>>> The TC has given guidance on this already:
>>>
>>>
>>>http://governance.openstack.org/resolutions/20160119-stackforge-reti
>>>re
>>>me
>>>nt
>>> .html
>>>
>>> "In order to simplify software development lifecycle transitions of
>>> Unofficial and Official OpenStack projects, all projects developed
>>> within the OpenStack project infrastructure will be permitted to
>>>use
>>>the
>>> “openstack/” namespace. The use of the term “Stackforge” to
>>>describe
>>> unofficial projects should be considered deprecated."
>>>
>>> The Fuel CCP repos are projects that are not official OpenStack
>>>projects.
>>>
>>> They are in the openstack/ git namespace because they use the
>>>common
>>> infrastructure and there isn't any formal plan to have the repos
>>>join
>>> the "official OpenStack projects" (i.e. the ones listed in the
>>> projects.yaml file in the openstack/governance repository).
>>>
>>> Could they be proposed in the future as official OpenStack
>>>projects?
>>> Maybe. Not sure, and I don't believe it's necessary to decide ahead
>>>of
>>> time.
>>>
>>> Please stop using a marketing press release as some indication of
>>>what
>>> the "intent" is for these

[openstack-dev] [new][openstack] osc-lib 0.4.1 release (newton)

2016-07-28 Thread no-reply

We are joyful to announce the release of:

osc-lib 0.4.1: OpenStackClient Library

This release is part of the newton release series.

With source available at:

https://git.openstack.org/cgit/openstack/osc-lib

With package available at:

https://pypi.python.org/pypi/osc-lib

Please report issues through launchpad:

https://bugs.launchpad.net/python-openstackclient

For more details, please see below.

Changes in osc-lib 0.4.0..0.4.1
---

f535ace Allow shell class to be overridden in test subclass
02a8904 Remove option handling unused code
85c977a Use assertEqual() instead of assertDictEqual()
63b8451 Remove unused releasenotes infrastructure


Diffstat (except docs and test files)
-

osc_lib/clientmanager.py| 53 -
test-requirements.txt   |  1 -
tox.ini |  3 --
5 files changed, 11 insertions(+), 82 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index f9215a2..42bca99 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11 +10,0 @@ oslotest>=1.10.0 # Apache-2.0
-reno>=1.8.0 # Apache2



__
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] [new][keystone] keystoneauth1 2.10.0 release (newton)

2016-07-28 Thread no-reply

We are satisfied to announce the release of:

keystoneauth1 2.10.0: Authentication Library for OpenStack Identity

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/keystoneauth

With package available at:

https://pypi.python.org/pypi/keystoneauth1

Please report issues through launchpad:

http://bugs.launchpad.net/keystoneauth

For more details, please see below.

2.10.0
^^

Add the prompt parameter to loader Opts

Allow specifying additional_headers to the session and the adapter to
add headers to all requests that pass through these objects.


New Features


* Add support for the Client Credentials OpenID Connect grant type.

* Add support for the OpenID Connect Discovery Document
  (https://openid.net/specs/openid-connect-
  discovery-1_0.html#ProviderMetadata) into the OpenID Connect related
  plugins. Now it is possible to only pass the *discovery-url* option
  and the plugins will try to fetch the required metadata from there.

* The prompt parameter was added to the Opts provided by auth
  plugins. The presence of the prompt parameter on an Option will
  indicate to plugin loaders that it is ok to prompt the user for
  input for this parameter if none is provided initially. Actual
  implementation of this prompting mechanism will be handled by the
  individual loaders such as os-client-config.

* Add the ability to provide additional_headers to the session and
  adapter object. This will allow clients particularly to provide
  additional ways to identify their requests. It will also hopefully
  provide an intermediate way to handle setting microversions until we
  support them directly with keystoneauth.


Bug Fixes
*

* [bug 1583682
  (https://bugs.launchpad.net/keystoneauth/+bug/1583682)] OpenID
  Connect plugins should support OpenID Connect Discovery.

Changes in keystoneauth1 2.9.0..2.10.0
--

6306504 Lazy load oauthlib for plugin loading
712ee40 oidc: add missing 'OidcAccessToken' to __all__
e5fd66c oidc: implement client_credentials grant type
67530bd Fix ECP doc link in Saml2 Password class doc
abb63ce Updated from global requirements
53f1e3c Fix link for "extras dependencies" in extras doc
c21ce26 Add pretty serializer for betamax fixture
bc90281 Update hacking to global-requirements value
701b911 Use SAML2 requests plugin
76bd9bb Updated from global requirements
9bf4efd oidc: move the get_unscoped_auth_ref into the base class
885aff0 oidc: deprecate grant_type argument
00746ea oidc: add discovery document support
1045a14 Add additional_headers to session and adapter
88d4fdb Add Python 3.5 classifier and venv
f2cc77c remove unused LOG
391499f Updated from global requirements
eff0936 Updated from global requirements
71d2e1a Add prompt parameter to Opt
e203d61 Auth plugin for X.509 tokenless authentication
68a7962 oidc: fix OpenID scope management
784ac09 Add create_plugin to loader


Diffstat (except docs and test files)
-

keystoneauth1/adapter.py   |  11 +-
keystoneauth1/exceptions/__init__.py   |   1 +
keystoneauth1/exceptions/oidc.py   |  44 ++
keystoneauth1/extras/_saml2/__init__.py|   2 +
keystoneauth1/extras/_saml2/_loading.py|   4 +
keystoneauth1/extras/_saml2/v3/__init__.py |   2 +
keystoneauth1/extras/_saml2/v3/saml2.py| 514 ++---
keystoneauth1/extras/oauth1/_loading.py|   4 +
keystoneauth1/extras/oauth1/v3.py  |   5 +-
keystoneauth1/fixture/keystoneauth_betamax.py  |   8 +-
keystoneauth1/fixture/serializer.py|  92 
keystoneauth1/identity/__init__.py |   9 +-
keystoneauth1/identity/generic/token.py|   3 -
keystoneauth1/identity/v3/__init__.py  |   7 +-
keystoneauth1/identity/v3/oidc.py  | 326 ++---
keystoneauth1/identity/v3/tokenless_auth.py| 115 +
keystoneauth1/loading/_plugins/identity/generic.py |   5 +-
keystoneauth1/loading/_plugins/identity/v2.py  |   5 +-
keystoneauth1/loading/_plugins/identity/v3.py  |  90 +++-
keystoneauth1/loading/base.py  |  22 +-
keystoneauth1/loading/opts.py  |   6 +-
keystoneauth1/session.py   |  10 +-
.../saml2/fixtures/templates/authn_request.xml |  22 +
...d-oidc-client-credentials-2be065926ba4b849.yaml |   4 +
...iscovery-document-support-b07fe54f83286d62.yaml |  12 +
.../notes/add-prompt-to-opt-d083acc357a7f07b.yaml  |  10 +
.../notes/additional-headers-f2d16f85f5abe942.yaml |  10 +
requirements.txt   |   2 +-
setup.cfg  |   4 +
test-requirements.txt  |   7 +-
tox.ini|   2 +-
43 files changed, 1936 insertions(+), 612

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

Steven,

Please see response from Doug:
http://markmail.org/message/yp7fpojnzufb5jki

If anyone disagrees with that position, please file a resolution.

Let's stop this thread now please.

Thanks,
Dims

On Thu, Jul 28, 2016 at 3:26 PM, Steven Dake (stdake)  wrote:
> Dims,
>
> I personally think its the responsibility of the TC to resolve this
> problem via a resolution.  That’s why we elected you folks :)
>
> Regards
> -steve
>
>
> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
>
>>Zane, Steve,
>>
>>I'd say go for it! Can you please write up a proposal for the TC to
>>consider? (https://review.openstack.org/#/q/project:openstack/governance)
>>
>>Thanks,
>>-- Dims
>>
>>On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
>>wrote:
>>> Jay,
>>>
>>> I'll be frank.  I have been receiving numerous complaints which mirror
>>> Zane's full second understanding of what it means to be an OpenStack big
>>> tent project.  These are not just Kolla developers.  These are people
>>>from
>>> all over the community.  They want something done about it.  I agree
>>>with
>>> Zane if clarity is provided by the TC via a resolution, the problem
>>>would
>>> disappear.  We are all adults and can live by the rules, even if we
>>> disagree with them.  This contract is the agreement under which
>>> democracies are created, and one of the most appealing properties of
>>> OpenStack.
>>>
>>> In this case there is no policy and one is obviously necessary to avoid
>>> these scenarios in the future.
>>>
>>> The TC has four options as I see it:
>>> 1) do nothing
>>> 2) write a resolution mirroring Zane's first analysis
>>> 3) write a resolution mirroring Zane's second analysis
>>> 4) write a different resolution that is a compromise of the first
>>>analysis
>>> and second analysis
>>>
>>> I don't wish Mirantis to state anything.  Vladimir did that (thanks
>>> Vladimir!).
>>>
>>> Regards
>>> -steve
>>>
>>>
>>> On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
>>>
I don't see what is unclear about any of it.

What exactly is it that you wish Mirantis to state?

Zane says there needs to be some guidance from the TC "about what it
means for a repo to be part of the OpenStack tent".

But the fuel-ccp repos aren't listed in the governance repo, for reasons
that were clearly stated by Mirantis engineers. They want to innovate in
this area without all the politics that this thread exposes.

Mirantis engineers have clearly laid out the technical reasons that
Kolla doesn't fit the needs that Fuel has of these image definitions and
orchestration tooling.

The repos *aren't in the OpenStack tent* so how precisely would TC
guidance about what it means for a repo to be part of the OpenStack tent
be useful here?

-jay

On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
> Jay,
>
> That resolution doesn't clarify Zane's argument.
>
> Regards,
> -steve
>
> On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
>
>> The TC has given guidance on this already:
>>
>>
>>http://governance.openstack.org/resolutions/20160119-stackforge-retire
>>me
>>nt
>> .html
>>
>> "In order to simplify software development lifecycle transitions of
>> Unofficial and Official OpenStack projects, all projects developed
>> within the OpenStack project infrastructure will be permitted to use
>>the
>> “openstack/” namespace. The use of the term “Stackforge” to describe
>> unofficial projects should be considered deprecated."
>>
>> The Fuel CCP repos are projects that are not official OpenStack
>>projects.
>>
>> They are in the openstack/ git namespace because they use the common
>> infrastructure and there isn't any formal plan to have the repos join
>> the "official OpenStack projects" (i.e. the ones listed in the
>> projects.yaml file in the openstack/governance repository).
>>
>> Could they be proposed in the future as official OpenStack projects?
>> Maybe. Not sure, and I don't believe it's necessary to decide ahead
>>of
>> time.
>>
>> Please stop using a marketing press release as some indication of
>>what
>> the "intent" is for these repos or even that there *is* any intent at
>> this point. It's really early on and these repos are intended as a
>>place
>> to experiment and innovate. I don't see why there is so much anger
>>about
>> that.
>>
>> Best,
>> -jay
>>
>> On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
>>> Doug,
>>>
>>> Zane's analysis is correct.  I agree with Zane's assessment that TC
>>> clarification can solve this situation.
>>>
>>> Regards
>>> -steve
>>>
>>> On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
>>>
 On 28/07/16 08:48, Vladimir

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

Dims,

I personally think its the responsibility of the TC to resolve this
problem via a resolution.  That’s why we elected you folks :)

Regards
-steve


On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:

>Zane, Steve,
>
>I'd say go for it! Can you please write up a proposal for the TC to
>consider? (https://review.openstack.org/#/q/project:openstack/governance)
>
>Thanks,
>-- Dims
>
>On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
>wrote:
>> Jay,
>>
>> I'll be frank.  I have been receiving numerous complaints which mirror
>> Zane's full second understanding of what it means to be an OpenStack big
>> tent project.  These are not just Kolla developers.  These are people
>>from
>> all over the community.  They want something done about it.  I agree
>>with
>> Zane if clarity is provided by the TC via a resolution, the problem
>>would
>> disappear.  We are all adults and can live by the rules, even if we
>> disagree with them.  This contract is the agreement under which
>> democracies are created, and one of the most appealing properties of
>> OpenStack.
>>
>> In this case there is no policy and one is obviously necessary to avoid
>> these scenarios in the future.
>>
>> The TC has four options as I see it:
>> 1) do nothing
>> 2) write a resolution mirroring Zane's first analysis
>> 3) write a resolution mirroring Zane's second analysis
>> 4) write a different resolution that is a compromise of the first
>>analysis
>> and second analysis
>>
>> I don't wish Mirantis to state anything.  Vladimir did that (thanks
>> Vladimir!).
>>
>> Regards
>> -steve
>>
>>
>> On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
>>
>>>I don't see what is unclear about any of it.
>>>
>>>What exactly is it that you wish Mirantis to state?
>>>
>>>Zane says there needs to be some guidance from the TC "about what it
>>>means for a repo to be part of the OpenStack tent".
>>>
>>>But the fuel-ccp repos aren't listed in the governance repo, for reasons
>>>that were clearly stated by Mirantis engineers. They want to innovate in
>>>this area without all the politics that this thread exposes.
>>>
>>>Mirantis engineers have clearly laid out the technical reasons that
>>>Kolla doesn't fit the needs that Fuel has of these image definitions and
>>>orchestration tooling.
>>>
>>>The repos *aren't in the OpenStack tent* so how precisely would TC
>>>guidance about what it means for a repo to be part of the OpenStack tent
>>>be useful here?
>>>
>>>-jay
>>>
>>>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
 Jay,

 That resolution doesn't clarify Zane's argument.

 Regards,
 -steve

 On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:

> The TC has given guidance on this already:
>
>
>http://governance.openstack.org/resolutions/20160119-stackforge-retire
>me
>nt
> .html
>
> "In order to simplify software development lifecycle transitions of
> Unofficial and Official OpenStack projects, all projects developed
> within the OpenStack project infrastructure will be permitted to use
>the
> “openstack/” namespace. The use of the term “Stackforge” to describe
> unofficial projects should be considered deprecated."
>
> The Fuel CCP repos are projects that are not official OpenStack
>projects.
>
> They are in the openstack/ git namespace because they use the common
> infrastructure and there isn't any formal plan to have the repos join
> the "official OpenStack projects" (i.e. the ones listed in the
> projects.yaml file in the openstack/governance repository).
>
> Could they be proposed in the future as official OpenStack projects?
> Maybe. Not sure, and I don't believe it's necessary to decide ahead
>of
> time.
>
> Please stop using a marketing press release as some indication of
>what
> the "intent" is for these repos or even that there *is* any intent at
> this point. It's really early on and these repos are intended as a
>place
> to experiment and innovate. I don't see why there is so much anger
>about
> that.
>
> Best,
> -jay
>
> On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
>> Doug,
>>
>> Zane's analysis is correct.  I agree with Zane's assessment that TC
>> clarification can solve this situation.
>>
>> Regards
>> -steve
>>
>> On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
>>
>>> On 28/07/16 08:48, Vladimir Kozhukalov wrote:
 Fuel-ccp repositories are public, everyone is welcome to
participate.
 I
 don¹t see where we violate ³4 opens². These repos are now
 experimental.
 At the moment the team is working on building CI pipeline and
 developing
 functional tests that are to be run as a part of CI process. These
 repos
 are not to be a part of Fuel

[openstack-dev] [new][keystone] keystonemiddleware 4.7.0 release (newton)

2016-07-28 Thread no-reply

We are excited to announce the release of:

keystonemiddleware 4.7.0: Middleware for OpenStack Identity

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/keystonemiddleware

With package available at:

https://pypi.python.org/pypi/keystonemiddleware

Please report issues through launchpad:

http://bugs.launchpad.net/keystonemiddleware

For more details, please see below.

Changes in keystonemiddleware 4.6.0..4.7.0
--

8873c48 Add Python 3.5 classifier
20547f1 Updated from global requirements
6c0c988 Updated from global requirements
8ef7afa Updated from global requirements
0d1fc6c Use jsonutils instead of ast for loading the service catalog
23711a5 Remove the _is_v2 and _is_v3 helpers


Diffstat (except docs and test files)
-

keystonemiddleware/audit/_api.py |  5 ++---
keystonemiddleware/auth_token/__init__.py|  8 
.../unit/auth_token/test_auth_token_middleware.py| 20 
requirements.txt |  6 +++---
setup.cfg|  1 +
test-requirements.txt|  2 +-
8 files changed, 17 insertions(+), 45 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 9398a42..8d21a86 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6,2 +6,2 @@ keystoneauth1>=2.7.0 # Apache-2.0
-oslo.config>=3.10.0 # Apache-2.0
-oslo.context>=2.4.0 # Apache-2.0
+oslo.config>=3.12.0 # Apache-2.0
+oslo.context!=2.6.0,>=2.4.0 # Apache-2.0
@@ -10 +10 @@ oslo.serialization>=1.10.0 # Apache-2.0
-oslo.utils>=3.14.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 969c9be..526cea2 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -17 +17 @@ sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-stevedore>=1.10.0 # Apache-2.0
+stevedore>=1.16.0 # Apache-2.0



__
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

Excerpts from Zane Bitter's message of 2016-07-28 14:38:12 -0400:
> On 28/07/16 14:20, Jay Pipes wrote:
> > How would guidance from the TC about what it means for a repo to be
> > "part of the OpenStack tent" add clarity for repos that are not trying
> > to be part of the OpenStack tent?
> 
> If it were clear what it means for a repo to be "part of the OpenStack 
> tent" then it would be obvious to *everyone* which ones should be and 
> which ones should not. As it is there are two different interpretations 
> from which follow two different conclusions as to whether the Right 
> Thing(TM) is happening, causing unnecessary wailing and gnashing of 
> teeth. Please re-read my original message on this subject for a full 
> treatment.
> 
> cheers,
> Zane.
> 

There is only one way for a repository's contents to be considered
part of the big tent: It needs to be listed in the projects.yaml
file in the openstack/governance repository, associated with a
deliverable from a team that has been accepted as a big tent member.

The Fuel team has stated that they are not ready to include the
work in these new repositories under governance, and indeed the
repositories are not listed in the set of deliverables for the Fuel
team [1].

Therefore, the situation is clear, to me: They are not part of the
big tent.

Doug

[1] 
http://governance.openstack.org/reference/projects/fuel.html#deliverables-and-tags

__
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] [placement] future topics in resource providers/placement api

2016-07-28 Thread Ed Leafe

On Jul 28, 2016, at 1:19 PM, Chris Dent  wrote:

>> How about we do a query in two steps:
>> 
>> 1) take a list of compute nodes (== resource providers) and apply all
>> the filters which *can not* (or *are not* at some point) be
>> implemented in placement-api
>> 
>> 2) POST a launch request passing the *pre-filtered* list of resource
>> providers.  placement api will pick one of those RP, *claim* its
>> resources and return the claim info
> 
> While I think the ordering you describe might be useful in the use case
> that Ed has described in his message, I think for the general case it is
> backwards. We should use the placement API _first_ to winnow out those
> hosts that physically cannot satisfy the basic requirements for
> inventory of the standard resource classes and then pass that simplified
> list to the filters. That ought to be efficient and also provides a path
> for easy migration of those filters that can be implemented cleanly in
> the placement engine.

I can see several use cases where the different approaches result in different 
efficiencies. Let’s take the Watcher example, as this was the use case that 
started us down this road.

Watcher monitors a data center, and can be configured to migrate VMs to achieve 
different strategies. One such strategy is packing so that hosts that are not 
needed can be turned off, saving energy and cooling costs. In this case, 
Watcher will identify VMs that should be moved, and have a few target hosts 
that would result in better packing. In a large DC with thousands of hosts, 
having the placement API go through all those hosts when Watcher only cares 
about a handful or less is terribly inefficient. In that case, the question 
that Watcher is asking the placement API is “I need instance X migrated to one 
of these N hosts. Which of these hosts (if any) are acceptable?”.

There are many other scenarios where the opposite would be true, so I wouldn’t 
want to have it work only one way. IOW, we could change the ‘get_all_hosts’ to 
‘get_all_hosts_unless_I_already_have_some_hosts”. :)

-- Ed Leafe

__
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] [charms] 16.07 OpenStack charm release

2016-07-28 Thread David Ames

Hi All

We are pleased to announce the 16.07 release of the OpenStack charms.
Highlights include:

* Nova compute apparmor support (Preview)
* openstack-dashboard + Keystone v3 API support
* SR-IOV (Preview)
* External Network Update
* DNS HA (Preview)
* Enhancements to Ceph charms
* New Charm: aodh
* New Charms: designate and designate-bind (Preview)
* All charms are now licensed under the Apache License Version 2.0

For more details please see the release notes here:
https://wiki.ubuntu.com/OpenStack/OpenStackCharms/ReleaseNotes1607

A big thank you to the many people who contributed to the OpenStack
charms over the last cycle and if you'd like to contribute to our next
cycle our charm guide is here:
http://docs.openstack.org/developer/charm-guide/

The OpenStack Charm Team

__
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] Microversioning implementation

2016-07-28 Thread Hongbin Lu

OK. My replies are inline.

> -Original Message-
> From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
> Sent: July-28-16 2:31 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Magnum] Microversioning implementation
> 
> I was completely unaware of any discussion of Semantic Versioning.
> That was brought up by Eli Qiao in the code review, so he might be the
> one to point us in the right direction for that.
> 
> Jaycen
> 
> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> Sent: Thursday, July 28, 2016 11:10 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Magnum] Microversioning implementation
> 
> Added this to the agenda of next team meeting [1].
> 
> I would like to ask clarification for " the community are discussing to
> using Semantic Versioning(X.Y.Z) instead of microversion X.Y ". Could
> anyone provide more information about that?
> 
> Best regards,
> Hongbin
> 
> > -Original Message-
> > From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
> > Sent: July-28-16 10:52 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: [openstack-dev] [Magnum] Microversioning implementation
> >
> >
> > There has been a discussion around micro versioning implementation
> > going on in the following patch:
> > https://review.openstack.org/#/c/343060/8 and I was asked to bring it
> > to the mailing list for further discussion.
> >
> > Magnum added header support for microversioning according to the
> > Openstack spec[1] but since we haven’t had any changes yet it was not
> > being used.  In the patch mentioned above I added code that provides
> > infrastructure for implementing micro versions for our API methods.
> I
> > took the idea from how Nova implemented micro versioning and used
> some
> > of their code modified to work with Pecan.  The basic idea is that
> you
> > version a method using api_version decorator as shown below:
> >
> > @base.Controller.api_version("1.1")
> > @expose.expose(BayCollection, types.uuid)
> > def get_all(self, marker=None):
> > """Retrieve a list of bays.
> > # code for version 1.1
> >
> > @base.Controller.api_version(“1.2”, “1.3")
> > @expose.expose(BayCollection,
> > types.uuid) def get_all(self, marker=None):
> > """Retrieve a list of bays.
> > # code for versions 1.2 through 1.3
> >
> > @base.Controller.api_version("1.4")
> > @expose.expose(BayCollection, types.uuid) def get_all(self,
> > marker=None):
> > """Retrieve a list of bays.
> > # code for version 1.4 to latest version
> >
> >
> > The api_version code takes care of selecting the correct version
> based
> > on version requested in the header. It also checks for version
> > overlaps in the methods and gaps in the method versions.
> >
> >
> > While working on this Vijendar(working on the first api changes that
> > need api versioning) and myself, evaluated several other alternatives:
> >
> > 1) Just have each method check the version object and handle the
> > differences. This was the most basic solution and will work but we
> > were concerned it would add a lot of duplicate code. We were also
> > concerned it would be messy in the future as more and more micro
> > versions were added. Each method would now be responsible for
> > additional checking and more places to change code if there were
> > overall micro version code changes in the future.
> >
> > 2) Separate pecan controllers for each micro version. When a new
> micro
> > version is added a new controller would be created inheriting from
> the
> > previous version controller. The new controller would override the
> > modified methods. Routing changes would be added to make sure that
> the
> > correct controller was used depending on the API header.  We felt
> that
> > the api_version decorator was slightly less complicated and less code
> > overhead on each api version change.
> >
> > I’d appreciate feedback on whether this is the right way to go or if
> > it would be better to go to alternative option 1 or 2. Here were some
> > of the concerns by one of the cores in the code review:
> >
> > I don't accept this patch, mark it as -2:
> > Reason:
> > 1. we have already support microversion in our code base, and
> your
> > propose (copied from nova) make things complicated.
> > 2. I think you want to support "Support for async bay operations"
> > for youadding microversion support, right?
> > I would like suggest you as
> > http://paste.openstack.org/show/543105/ , it should work for you

[Hongbin Lu] It looks the fundamental difference between the proposed patch 
(https://review.openstack.org/#/c/343060/8/magnum/api/controllers/v1/bay.py) 
and the snippet (http://paste.openstack.org/show/543105/) is the usage of a 
decorator "api_version". The proposed patch implemented the decorator and used 
it to

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


On 28/07/16 14:38, Davanum Srinivas wrote:

Zane,


I don't understand why you're directing this reply to me. I *just* made 
clear that I don't have any interest one way or the other.



There's a Spec, Spec was discussed in Weekly Meeting. There's traffic
on the ML. I personally was helpful to some extent with the beginnning
of kolla-kubernetes.

So i don't think it's a lack of communication that's to blame.


AFAICT this has nothing to do with my point that this thread is a *train 
wreck* where everyone is talking past each other.


Also at no time did I ever refer to a "lack of communication".


Also if you see the repos, there's not much there... In effect they
are starting from scratch knowingly.


As I said, I don't have a horse in this race and I don't actually care. 
I'm just trying to explain each side's position to the other in the hope 
that they'll stop arguing.



But if you wish as i said before, please do file a TC resolution and
let's see where it goes.


I wouldn't know which one to file (although Doug's response suggests 
it's interpretation 1). Besides, I already did my good deed for the day 
and got attacked for my trouble.



As Steven said before "We are all adults and can live by the rules,
even if we disagree with them"


I don't even disagree with *either* rule. I'm merely trying to point out 
that different but unexamined opinions on what the rule is leads to bad 
discussions.


cheers,
Zane.


Thanks,
Dims

On Thu, Jul 28, 2016 at 2:29 PM, Zane Bitter  wrote:

On 28/07/16 12:54, Jay Pipes wrote:


The TC has given guidance on this already:


http://governance.openstack.org/resolutions/20160119-stackforge-retirement.html


"In order to simplify software development lifecycle transitions of
Unofficial and Official OpenStack projects, all projects developed
within the OpenStack project infrastructure will be permitted to use the
“openstack/” namespace. The use of the term “Stackforge” to describe
unofficial projects should be considered deprecated."



The word "project" has unfortunately had multiple meanings throughout the
history of OpenStack (I think it's something to do with multitenancy this
week, right?), so to be clear: when I say 'project' here I mean in the sense
of 'team'.

So I believe it's quite clear that there are official projects with official
repos and unofficial projects with unofficial repos, and that all of these
repos are hosted in the openstack/* namespace. (Nobody in the thread has
raised the namespacing as an issue AFAICT.)

What's not clear is whether official projects should have unofficial repos.
I submit that if that _were_ clear then this thread would never have existed
and we would all be happier :)


The Fuel CCP repos are projects that are not official OpenStack projects.



Because of the aforementioned 'project' pun issue there's two ways of
interpreting this. You may be saying that the repos are unofficial repos
within the "Fuel" project (team), in which case the question of whether
official projects should have unofficial repos applies.

Alternatively, you may be saying that the "Fuel CCP" project (team) is an
unofficial project separate from the "Fuel" project (team), with it's own
(naturally unofficial) repos, and that therefore the question of whether
official projects should have unofficial repos is moot. In which case I
think you at least have to forgive people for being confused ;)


They are in the openstack/ git namespace because they use the common
infrastructure and there isn't any formal plan to have the repos join
the "official OpenStack projects" (i.e. the ones listed in the
projects.yaml file in the openstack/governance repository).

Could they be proposed in the future as official OpenStack projects?
Maybe. Not sure, and I don't believe it's necessary to decide ahead of
time.

Please stop using a marketing press release as some indication of what
the "intent" is for these repos or even that there *is* any intent at
this point. It's really early on and these repos are intended as a place
to experiment and innovate. I don't see why there is so much anger about
that.



My only interest here is to try to help two groups that are clearly not
communicating very well to communicate better. TBH I don't think your
response was as helpful to those ends as it could have been. Can we start
again?

cheers,
Zane.



Best,
-jay

On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:


Doug,

Zane's analysis is correct.  I agree with Zane's assessment that TC
clarification can solve this situation.

Regards
-steve

On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:


On 28/07/16 08:48, Vladimir Kozhukalov wrote:


Fuel-ccp repositories are public, everyone is welcome to participate. I
don¹t see where we violate ³4 opens². These repos are now experimental.
At the moment the team is working on building CI pipeline and
developing
functional tests that are to be run as a part of CI process. These
repos
are not to be a

Re: [openstack-dev] [neutron][api] Passing random filters on neutron API calls

2016-07-28 Thread Brandon Logan

On Thu, 2016-07-28 at 19:24 +0200, Ihar Hrachyshka wrote:
> Kevin Benton  wrote:
> 
> > Too late. That's a backwards incompatible change that can mess with  
> > clients putting on cache busting nonce tokens and who knows what else.
> 
> Ideally, API layer would at least avoid passing those unknown filters into  
> plugins; same for plugins returning random fields: API layer should filter  
> unknown data out. We already have attribute maps defined for extensions, so  
> it should be relatively easy to implement that without making plugin layer  
> forgiving to those kinds of requests.
> 
> Ihar

This is possible for most resources, but the resources that use member
actions do not have those attributes mapped out I don't believe so there
won't be a generic way to do this for those.  There aren't many of those
though.  The other one is the extensions that define their own
controllers, like agent reschedulers.  That can be modified in the
controllers themselves though and wouldn't be too big of a deal.

> 
> __
> 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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-28 Thread Jim Rollenhagen

On Thu, Jul 28, 2016 at 02:29:18PM -0400, Zane Bitter wrote:
> On 28/07/16 12:54, Jay Pipes wrote:
> >The TC has given guidance on this already:
> >
> >http://governance.openstack.org/resolutions/20160119-stackforge-retirement.html
> >
> >
> >"In order to simplify software development lifecycle transitions of
> >Unofficial and Official OpenStack projects, all projects developed
> >within the OpenStack project infrastructure will be permitted to use the
> >“openstack/” namespace. The use of the term “Stackforge” to describe
> >unofficial projects should be considered deprecated."
> 
> The word "project" has unfortunately had multiple meanings throughout the
> history of OpenStack (I think it's something to do with multitenancy this
> week, right?), so to be clear: when I say 'project' here I mean in the sense
> of 'team'.
> 
> So I believe it's quite clear that there are official projects with official
> repos and unofficial projects with unofficial repos, and that all of these
> repos are hosted in the openstack/* namespace. (Nobody in the thread has
> raised the namespacing as an issue AFAICT.)
> 
> What's not clear is whether official projects should have unofficial repos.
> I submit that if that _were_ clear then this thread would never have existed
> and we would all be happier :)

Well, that does happen today, just as a note:
https://git.openstack.org/cgit/openstack/ironic-staging-drivers

This is a bunch of out-of-tree drivers that a few Ironic developers
support, because Ironic is beginning to require third-party CI on
in-tree drivers.

As mentioned elsewhere, the Neutron stadium has many repos in and out of
the Neutron governance and the big tent.

So I'm curious, if we say "official projects should never have unofficial
repos", where that bar would be. Is it that the repo is not worked on by
the PTL? Some percent of core reviewers? Some percent of active
developers? Has the name in it?

If we make a rule that doesn't fit some unofficial repo, people will
either 1) work around the rule, or 2) put it on Github. Both of those
are (IMO) not any better for the community than having some unofficial
repo related to an official project.

(Oh, there's another worse outcome: the repo becomes proprietary
instead.)

// jim

> >The Fuel CCP repos are projects that are not official OpenStack projects.
> 
> Because of the aforementioned 'project' pun issue there's two ways of
> interpreting this. You may be saying that the repos are unofficial repos
> within the "Fuel" project (team), in which case the question of whether
> official projects should have unofficial repos applies.
> 
> Alternatively, you may be saying that the "Fuel CCP" project (team) is an
> unofficial project separate from the "Fuel" project (team), with it's own
> (naturally unofficial) repos, and that therefore the question of whether
> official projects should have unofficial repos is moot. In which case I
> think you at least have to forgive people for being confused ;)
> 
> >They are in the openstack/ git namespace because they use the common
> >infrastructure and there isn't any formal plan to have the repos join
> >the "official OpenStack projects" (i.e. the ones listed in the
> >projects.yaml file in the openstack/governance repository).
> >
> >Could they be proposed in the future as official OpenStack projects?
> >Maybe. Not sure, and I don't believe it's necessary to decide ahead of
> >time.
> >
> >Please stop using a marketing press release as some indication of what
> >the "intent" is for these repos or even that there *is* any intent at
> >this point. It's really early on and these repos are intended as a place
> >to experiment and innovate. I don't see why there is so much anger about
> >that.
> 
> My only interest here is to try to help two groups that are clearly not
> communicating very well to communicate better. TBH I don't think your
> response was as helpful to those ends as it could have been. Can we start
> again?
> 
> cheers,
> Zane.
> 
> >Best,
> >-jay
> >
> >On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
> >>Doug,
> >>
> >>Zane's analysis is correct.  I agree with Zane's assessment that TC
> >>clarification can solve this situation.
> >>
> >>Regards
> >>-steve
> >>
> >>On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
> >>
> >>>On 28/07/16 08:48, Vladimir Kozhukalov wrote:
> Fuel-ccp repositories are public, everyone is welcome to participate. I
> don¹t see where we violate ³4 opens². These repos are now experimental.
> At the moment the team is working on building CI pipeline and
> developing
> functional tests that are to be run as a part of CI process. These
> repos
> are not to be a part of Fuel Newton release. From time to time we add
> and retire git repos and it is a part of development process. Not all
> these repos are to become a part of Big tent.
> >>>
> >>>It seems to me that there are two different interpretations of what it
> >>>means for a repo to be

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

2016-07-28 Thread Cathy Zhang

Hi Ihar and all,

Yes, we have been preparing for such a release. We will do one more round of 
testing to make sure everything works fine, and then I will submit the release 
request. 
There is a new patch on "stadium: adopt openstack/releases in subproject 
release process" which is not Merged yet. 
Shall I follow this 
http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
 to submit the request? 
Do you have a good bug example for Neutron sub-project release request?  

BTW, a functional and tempest patch for networking-sfc has been uploaded and it 
might take some time for the team to complete the review. The test is 
non-voting. Do you think we should wait until this patch is merged or release 
can be done without it? 

Thanks,
Cathy

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Wednesday, July 27, 2016 1:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version

Tony Breeds  wrote:

> On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
>> Hi,
>> Is anyone looking at creating a stable/mitaka version? What if 
>> someone want to use this for stable/mitaka?
>
> If that's a thing you need it's a matter of Armando asking the release 
> managers to create it.

I only suggest Armando is not dragged into it, the release liaison (currently 
me) should be able to handle the request if it comes from the core team for the 
subproject.

Ihar

__
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][nova] Globally disabling hw_qemu_guest_agent support

2016-07-28 Thread Tim Bell

Looking at the number of options for image properties, it would seem that a 
blacklist would be in order. I would be in favour for ‘standard’ images which 
support fsfreeze to support guest agent and that some of the NUMA properties 
not be available for end user images, but still for system ones.

How about a list of delegated properties for images which could override the 
default flavor settings ?

Tim

On 20/07/16 00:40, "Daniel Russell"  wrote:

Hi Daniel,

Fair enough.  I don't personally understand your stance against having a 
configuration option to specifically disable guest agent but imagine there 
would be advantages to having a more generic implementation that can handle 
more use-cases (any property instead of just a specific property).  I imagine 
there will need to be a nova scheduler component to it as well (Or we might 
schedule an instance on a hypervisor that is configured not to allow it).

Is there a blueprint or spec for this kind of thing yet?  I can help put one 
together if there is interest but the implementation is probably for more 
seasoned developers.

Regards,
Dan.

-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com] 
Sent: Tuesday, 19 July 2016 6:39 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [glance][nova] Globally disabling 
hw_qemu_guest_agent support

On Tue, Jul 19, 2016 at 12:51:07AM +, Daniel Russell wrote:
> Hi Erno,
> 
> For the size of team I am in I think it would work well but it feels 
> like I am putting the security of Nova in the hands of Glance.

Yep, from an architectural pov it is not very good. Particularly in a 
multi-hypervisor compute deployment you can have the situation where yoyu want 
to allow a property for one type of hypervisor but forbid it for another.

What we really need is the exact same image property security restrictions 
implemented by nova-compute, so we can setup compute nodes to blacklist certain 
properties.

> 
> What I was more after was a setting in Nova that says 'this hypervisor 
> does not allow guest sockets and will ignore any attempt to create 
> them', 'this hypervisor always creates guest sockets regardless of 
> your choice', 'this hypervisor will respect whatever you throw in 
> hw_qemu_guest_agent with a default of no', or 'this hypervisor will 
> respect whatever you throw in hw_qemu_guest_agent with a default of 
> yes'.  It feels like a more appropriate place to control and manage that kind 
> of configuration.

Nope, there's no such facility right now - glance property protection is the 
only real option. I'd be very much against adding a lockdown which was specific 
to the guest agent too - if we did anything it would be to have a generic 
property protection model in nova that mirrors what glance supports.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-28 Thread Andreas Jaeger

On 07/28/2016 07:21 PM, Doug Hellmann wrote:
> [...]
> I think it is a reasonable expectation that teams would want to add
> their new repositories to the governance list to have the rights
> that go along with that, but I'm not aware of any requirement that
> they do so.

Reviewing that change that added the repos, I was struggling with these
interpretations myself.

Here's a team that creates a spec that states they want to develop
certain parts outside of the big tent and seem to work as team on it
(so, much that their marketing believes it;) - a team that is part of
the big tent.

AFAIU, they could have easily opted on adding these repos to their
project and do the same kind of experimentation that they are doing now
as "stackforge" repos.

Most teams are happy to have their new repos as part of the big tent -
let's leave the Neutron stadium out for now which showed some of the
limits for this.

Being part of the Big tent has some advantages - but I did not
understand what kind of advantages it brings the team to have these
repos outside of the big tent.

But it's not my call to make how they do it, and thus I reviewed
positively - I just got the impression that either we have different
understandings on what it means that repos are in the big tent or not -
or I'm missing some information.

If there're any advantages or disadvantages or considerating regarding
the big tent for teams to add repos that I miss, I'd like to be aware of
them so that I can give guidance during project-config review,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

__
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-28 Thread Michał Jastrzębski

Hello,

So as some of you might know, I write from a peculiar position. I'm
both Kolla core and Intel.

I don't like to see where this thread is going to. We are all one
community, we are all OpenStack after all. I think what's hurting us
here is this sense of competition. I would like to share my personal
view on that matter.

Competition is good thing. Let the best one win and therefore make
whole OpenStack namespace a slightly better place overall. However
what I'd hate to see is to silo ourselves and don't talk to each
other. We, Kolla and Fuel, are trying to solve very similar problem
(openstack deployment) in a very similar way (docker containers on top
of kubernetes). This makes us vulnerable to both competing and
knowledge silo, but that also gives us opportunity to cooperate.
Regardless of decision you guys (Mirantis) make, I would like to
encourage you to share your findings and feedback regarding OpenStack
in Docker on top of Kubernetes with Kolla. We will do the same for
you. As I said before, to me it's not us vs you, it's both of us
trying to improve experience of OpenStack.

That being said, I'm glad to hear from you, Sergey, that you're not
ruling out using Kolla as carrier for containers. I know we have few
points we need to discuss, but that's what we should do, discuss. Make
sure that we're splitting community for a reason and there is
something fundamental that would prevent us from closer cooperation.

I understand that Fuel is center of business for Mirantis, and adding
dependency for non-Mirantis driven project is a huge risk and it's not
a decision taken lightly. To that, I'll say that Nova is not a
Mirantis-driven project as well, which means you already do this, this
is just one step further.

Uff..long mail.

TLDR: Even if you want to have completely separate project, that's
cool, just let's make sure to talk so our collective experience will
improve both projects.

I hope this makes sense?

Cheers,
Michal

On 28 July 2016 at 13:29, Zane Bitter  wrote:
> On 28/07/16 12:54, Jay Pipes wrote:
>>
>> The TC has given guidance on this already:
>>
>>
>> http://governance.openstack.org/resolutions/20160119-stackforge-retirement.html
>>
>>
>> "In order to simplify software development lifecycle transitions of
>> Unofficial and Official OpenStack projects, all projects developed
>> within the OpenStack project infrastructure will be permitted to use the
>> “openstack/” namespace. The use of the term “Stackforge” to describe
>> unofficial projects should be considered deprecated."
>
>
> The word "project" has unfortunately had multiple meanings throughout the
> history of OpenStack (I think it's something to do with multitenancy this
> week, right?), so to be clear: when I say 'project' here I mean in the sense
> of 'team'.
>
> So I believe it's quite clear that there are official projects with official
> repos and unofficial projects with unofficial repos, and that all of these
> repos are hosted in the openstack/* namespace. (Nobody in the thread has
> raised the namespacing as an issue AFAICT.)
>
> What's not clear is whether official projects should have unofficial repos.
> I submit that if that _were_ clear then this thread would never have existed
> and we would all be happier :)
>
>> The Fuel CCP repos are projects that are not official OpenStack projects.
>
>
> Because of the aforementioned 'project' pun issue there's two ways of
> interpreting this. You may be saying that the repos are unofficial repos
> within the "Fuel" project (team), in which case the question of whether
> official projects should have unofficial repos applies.
>
> Alternatively, you may be saying that the "Fuel CCP" project (team) is an
> unofficial project separate from the "Fuel" project (team), with it's own
> (naturally unofficial) repos, and that therefore the question of whether
> official projects should have unofficial repos is moot. In which case I
> think you at least have to forgive people for being confused ;)
>
>> They are in the openstack/ git namespace because they use the common
>> infrastructure and there isn't any formal plan to have the repos join
>> the "official OpenStack projects" (i.e. the ones listed in the
>> projects.yaml file in the openstack/governance repository).
>>
>> Could they be proposed in the future as official OpenStack projects?
>> Maybe. Not sure, and I don't believe it's necessary to decide ahead of
>> time.
>>
>> Please stop using a marketing press release as some indication of what
>> the "intent" is for these repos or even that there *is* any intent at
>> this point. It's really early on and these repos are intended as a place
>> to experiment and innovate. I don't see why there is so much anger about
>> that.
>
>
> My only interest here is to try to help two groups that are clearly not
> communicating very well to communicate better. TBH I don't think your
> response was as helpful to those ends as it could have been. Can we start
> again?
>
>

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

Zane,

There's a Spec, Spec was discussed in Weekly Meeting. There's traffic
on the ML. I personally was helpful to some extent with the beginnning
of kolla-kubernetes.

So i don't think it's a lack of communication that's to blame.

Also if you see the repos, there's not much there... In effect they
are starting from scratch knowingly.

But if you wish as i said before, please do file a TC resolution and
let's see where it goes.

As Steven said before "We are all adults and can live by the rules,
even if we disagree with them"

Thanks,
Dims

On Thu, Jul 28, 2016 at 2:29 PM, Zane Bitter  wrote:
> On 28/07/16 12:54, Jay Pipes wrote:
>>
>> The TC has given guidance on this already:
>>
>>
>> http://governance.openstack.org/resolutions/20160119-stackforge-retirement.html
>>
>>
>> "In order to simplify software development lifecycle transitions of
>> Unofficial and Official OpenStack projects, all projects developed
>> within the OpenStack project infrastructure will be permitted to use the
>> “openstack/” namespace. The use of the term “Stackforge” to describe
>> unofficial projects should be considered deprecated."
>
>
> The word "project" has unfortunately had multiple meanings throughout the
> history of OpenStack (I think it's something to do with multitenancy this
> week, right?), so to be clear: when I say 'project' here I mean in the sense
> of 'team'.
>
> So I believe it's quite clear that there are official projects with official
> repos and unofficial projects with unofficial repos, and that all of these
> repos are hosted in the openstack/* namespace. (Nobody in the thread has
> raised the namespacing as an issue AFAICT.)
>
> What's not clear is whether official projects should have unofficial repos.
> I submit that if that _were_ clear then this thread would never have existed
> and we would all be happier :)
>
>> The Fuel CCP repos are projects that are not official OpenStack projects.
>
>
> Because of the aforementioned 'project' pun issue there's two ways of
> interpreting this. You may be saying that the repos are unofficial repos
> within the "Fuel" project (team), in which case the question of whether
> official projects should have unofficial repos applies.
>
> Alternatively, you may be saying that the "Fuel CCP" project (team) is an
> unofficial project separate from the "Fuel" project (team), with it's own
> (naturally unofficial) repos, and that therefore the question of whether
> official projects should have unofficial repos is moot. In which case I
> think you at least have to forgive people for being confused ;)
>
>> They are in the openstack/ git namespace because they use the common
>> infrastructure and there isn't any formal plan to have the repos join
>> the "official OpenStack projects" (i.e. the ones listed in the
>> projects.yaml file in the openstack/governance repository).
>>
>> Could they be proposed in the future as official OpenStack projects?
>> Maybe. Not sure, and I don't believe it's necessary to decide ahead of
>> time.
>>
>> Please stop using a marketing press release as some indication of what
>> the "intent" is for these repos or even that there *is* any intent at
>> this point. It's really early on and these repos are intended as a place
>> to experiment and innovate. I don't see why there is so much anger about
>> that.
>
>
> My only interest here is to try to help two groups that are clearly not
> communicating very well to communicate better. TBH I don't think your
> response was as helpful to those ends as it could have been. Can we start
> again?
>
> cheers,
> Zane.
>
>
>> Best,
>> -jay
>>
>> On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
>>>
>>> Doug,
>>>
>>> Zane's analysis is correct.  I agree with Zane's assessment that TC
>>> clarification can solve this situation.
>>>
>>> Regards
>>> -steve
>>>
>>> On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
>>>
 On 28/07/16 08:48, Vladimir Kozhukalov wrote:
>
> Fuel-ccp repositories are public, everyone is welcome to participate. I
> don¹t see where we violate ³4 opens². These repos are now experimental.
> At the moment the team is working on building CI pipeline and
> developing
> functional tests that are to be run as a part of CI process. These
> repos
> are not to be a part of Fuel Newton release. From time to time we add
> and retire git repos and it is a part of development process. Not all
> these repos are to become a part of Big tent.


 It seems to me that there are two different interpretations of what it
 means for a repo to be part of the OpenStack tent, and that these
 differing interpretations are at the root of the arguments in this
 thread.

 The first interpretation is that repos listed as belonging to a team in
 the governance repo are part of a deliverable that is released each
 development cycle, and that the same team may also control other repos
 that are not

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


On 28/07/16 14:20, Jay Pipes wrote:

How would guidance from the TC about what it means for a repo to be
"part of the OpenStack tent" add clarity for repos that are not trying
to be part of the OpenStack tent?


If it were clear what it means for a repo to be "part of the OpenStack 
tent" then it would be obvious to *everyone* which ones should be and 
which ones should not. As it is there are two different interpretations 
from which follow two different conclusions as to whether the Right 
Thing(TM) is happening, causing unnecessary wailing and gnashing of 
teeth. Please re-read my original message on this subject for a full 
treatment.


cheers,
Zane.

__
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-28 Thread Russell Bryant

On Thu, Jul 28, 2016 at 2:20 PM, Jay Pipes  wrote:

> How would guidance from the TC about what it means for a repo to be "part
> of the OpenStack tent" add clarity for repos that are not trying to be part
> of the OpenStack tent?
>
> Just curious here...

Related, Flavio asked about this earlier, and I don't think it was
answered.

Is the issue with the use of the Fuel name?  Would the concern remain if
the repository was called "pancakes-ccp" instead of "fuel-ccp"?

-- 
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] FPGA as a dynamic nested resources


On 07/20/2016 05:07 AM, Daniel P. Berrange wrote:

For FPGA, I'd like to see an initial proposal that assumed the FPGA
is pre-programmed & pre-divided into a fixed number of slots and simply
deal with this.


For the record, this is precisely what is described in the first version 
of the dynamic-resource-classes use cases section:


https://review.openstack.org/#/c/312696/1/specs/newton/approved/resource-providers-dynamic-resource-classes.rst

See starting at line 193.

This level of details was removed in the second revision of the spec, 
which simply focuses on the CRUD operations to add to the placement REST 
API for these user-defined resource classes.


All the best,
-jay

__
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] Microversioning implementation

2016-07-28 Thread Grant, Jaycen V

I was completely unaware of any discussion of Semantic Versioning.  That was 
brought up by Eli Qiao in the code review, so he might be the one to point us 
in the right direction for that.

Jaycen

-Original Message-
From: Hongbin Lu [mailto:hongbin...@huawei.com] 
Sent: Thursday, July 28, 2016 11:10 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Magnum] Microversioning implementation

Added this to the agenda of next team meeting [1].

I would like to ask clarification for " the community are discussing to using 
Semantic Versioning(X.Y.Z) instead of microversion X.Y ". Could anyone provide 
more information about that?

Best regards,
Hongbin

> -Original Message-
> From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
> Sent: July-28-16 10:52 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Magnum] Microversioning implementation
> 
> 
> There has been a discussion around micro versioning implementation 
> going on in the following patch:
> https://review.openstack.org/#/c/343060/8 and I was asked to bring it 
> to the mailing list for further discussion.
> 
> Magnum added header support for microversioning according to the 
> Openstack spec[1] but since we haven’t had any changes yet it was not 
> being used.  In the patch mentioned above I added code that provides 
> infrastructure for implementing micro versions for our API methods.  I 
> took the idea from how Nova implemented micro versioning and used some 
> of their code modified to work with Pecan.  The basic idea is that you 
> version a method using api_version decorator as shown below:
> 
> @base.Controller.api_version("1.1")
> @expose.expose(BayCollection, types.uuid)
> def get_all(self, marker=None):
> """Retrieve a list of bays.
> # code for version 1.1
> 
> @base.Controller.api_version(“1.2”, “1.3") 
> @expose.expose(BayCollection,
> types.uuid) def get_all(self, marker=None):
> """Retrieve a list of bays.
> # code for versions 1.2 through 1.3
> 
> @base.Controller.api_version("1.4")
> @expose.expose(BayCollection, types.uuid) def get_all(self,
> marker=None):
> """Retrieve a list of bays.
> # code for version 1.4 to latest version
> 
> 
> The api_version code takes care of selecting the correct version based 
> on version requested in the header. It also checks for version 
> overlaps in the methods and gaps in the method versions.
> 
> 
> While working on this Vijendar(working on the first api changes that 
> need api versioning) and myself, evaluated several other alternatives:
> 
> 1) Just have each method check the version object and handle the 
> differences. This was the most basic solution and will work but we 
> were concerned it would add a lot of duplicate code. We were also 
> concerned it would be messy in the future as more and more micro 
> versions were added. Each method would now be responsible for 
> additional checking and more places to change code if there were 
> overall micro version code changes in the future.
> 
> 2) Separate pecan controllers for each micro version. When a new micro 
> version is added a new controller would be created inheriting from the 
> previous version controller. The new controller would override the 
> modified methods. Routing changes would be added to make sure that the 
> correct controller was used depending on the API header.  We felt that 
> the api_version decorator was slightly less complicated and less code 
> overhead on each api version change.
> 
> I’d appreciate feedback on whether this is the right way to go or if 
> it would be better to go to alternative option 1 or 2. Here were some 
> of the concerns by one of the cores in the code review:
> 
> I don't accept this patch, mark it as -2:
> Reason:
> 1. we have already support microversion in our code base, and your 
> propose (copied from nova) make things complicated.
> 2. I think you want to support "Support for async bay operations"
> for youadding microversion support, right?
> I would like suggest you as
> http://paste.openstack.org/show/543105/ , it should work for you
> 3. we don't have too may requirements to bump our microversion (I 
> know you want to use it in bay-creation async), so we don't want bring 
> much code here then we need to maintain it later.
> 4. the community are discussing to using Semantic 
> Versioning(X.Y.Z) [1] instead of microversion X.Y [1]http://semver.org/
>If you have any questions , please discuss it in mailing list or 
> weekly meeting.
>Eli.
> 
> 
> 
> Jaycen Grant
> OSIC
> 
> 
> 
> 
> [1] http://specs.openstack.org/openstack/api-
> wg/guidelines/microversion_specification.html?highlight=microversionin
> g
> 
> >>
> __
> _
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

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


On 28/07/16 12:54, Jay Pipes wrote:

The TC has given guidance on this already:

http://governance.openstack.org/resolutions/20160119-stackforge-retirement.html


"In order to simplify software development lifecycle transitions of
Unofficial and Official OpenStack projects, all projects developed
within the OpenStack project infrastructure will be permitted to use the
“openstack/” namespace. The use of the term “Stackforge” to describe
unofficial projects should be considered deprecated."


The word "project" has unfortunately had multiple meanings throughout 
the history of OpenStack (I think it's something to do with multitenancy 
this week, right?), so to be clear: when I say 'project' here I mean in 
the sense of 'team'.


So I believe it's quite clear that there are official projects with 
official repos and unofficial projects with unofficial repos, and that 
all of these repos are hosted in the openstack/* namespace. (Nobody in 
the thread has raised the namespacing as an issue AFAICT.)


What's not clear is whether official projects should have unofficial 
repos. I submit that if that _were_ clear then this thread would never 
have existed and we would all be happier :)



The Fuel CCP repos are projects that are not official OpenStack projects.


Because of the aforementioned 'project' pun issue there's two ways of 
interpreting this. You may be saying that the repos are unofficial repos 
within the "Fuel" project (team), in which case the question of whether 
official projects should have unofficial repos applies.


Alternatively, you may be saying that the "Fuel CCP" project (team) is 
an unofficial project separate from the "Fuel" project (team), with it's 
own (naturally unofficial) repos, and that therefore the question of 
whether official projects should have unofficial repos is moot. In which 
case I think you at least have to forgive people for being confused ;)



They are in the openstack/ git namespace because they use the common
infrastructure and there isn't any formal plan to have the repos join
the "official OpenStack projects" (i.e. the ones listed in the
projects.yaml file in the openstack/governance repository).

Could they be proposed in the future as official OpenStack projects?
Maybe. Not sure, and I don't believe it's necessary to decide ahead of
time.

Please stop using a marketing press release as some indication of what
the "intent" is for these repos or even that there *is* any intent at
this point. It's really early on and these repos are intended as a place
to experiment and innovate. I don't see why there is so much anger about
that.


My only interest here is to try to help two groups that are clearly not 
communicating very well to communicate better. TBH I don't think your 
response was as helpful to those ends as it could have been. Can we 
start again?


cheers,
Zane.


Best,
-jay

On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:

Doug,

Zane's analysis is correct.  I agree with Zane's assessment that TC
clarification can solve this situation.

Regards
-steve

On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:


On 28/07/16 08:48, Vladimir Kozhukalov wrote:

Fuel-ccp repositories are public, everyone is welcome to participate. I
don¹t see where we violate ³4 opens². These repos are now experimental.
At the moment the team is working on building CI pipeline and
developing
functional tests that are to be run as a part of CI process. These
repos
are not to be a part of Fuel Newton release. From time to time we add
and retire git repos and it is a part of development process. Not all
these repos are to become a part of Big tent.


It seems to me that there are two different interpretations of what it
means for a repo to be part of the OpenStack tent, and that these
differing interpretations are at the root of the arguments in this
thread.

The first interpretation is that repos listed as belonging to a team in
the governance repo are part of a deliverable that is released each
development cycle, and that the same team may also control other repos
that are not deliverables and hence not part of OpenStack. It's easy to
see how people could have developed this interpretation in good faith.

The second interpretation is that the TC blesses a team; that the only
criterion for receiving this blessing is for the project to be "one of
us", which in practice effectively means following the Four Opens; and
that all repos which the team intends to operate in this manner, subject
to TC oversight, should be listed in the governance repo. It's also easy
to see how people could have developed this interpretation in good
faith. (In fact, I was following the big tent discussions very closely
at the time and this was always my understanding of what it meant.)

The only additional thing needed to explain this thread is the
(incorrect) assumption on behalf of all participants that everyone has
the same interpretation :)

Assuming everyone holds the first interpretation,

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

How would guidance from the TC about what it means for a repo to be 
"part of the OpenStack tent" add clarity for repos that are not trying 
to be part of the OpenStack tent?


Just curious here...

-jay

On 07/28/2016 02:01 PM, Steven Dake (stdake) wrote:

Jay,

I'll be frank.  I have been receiving numerous complaints which mirror
Zane's full second understanding of what it means to be an OpenStack big
tent project.  These are not just Kolla developers.  These are people from
all over the community.  They want something done about it.  I agree with
Zane if clarity is provided by the TC via a resolution, the problem would
disappear.  We are all adults and can live by the rules, even if we
disagree with them.  This contract is the agreement under which
democracies are created, and one of the most appealing properties of
OpenStack.

In this case there is no policy and one is obviously necessary to avoid
these scenarios in the future.

The TC has four options as I see it:
1) do nothing
2) write a resolution mirroring Zane's first analysis
3) write a resolution mirroring Zane's second analysis
4) write a different resolution that is a compromise of the first analysis
and second analysis

I don't wish Mirantis to state anything.  Vladimir did that (thanks
Vladimir!).

Regards
-steve


On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:


I don't see what is unclear about any of it.

What exactly is it that you wish Mirantis to state?

Zane says there needs to be some guidance from the TC "about what it
means for a repo to be part of the OpenStack tent".

But the fuel-ccp repos aren't listed in the governance repo, for reasons
that were clearly stated by Mirantis engineers. They want to innovate in
this area without all the politics that this thread exposes.

Mirantis engineers have clearly laid out the technical reasons that
Kolla doesn't fit the needs that Fuel has of these image definitions and
orchestration tooling.

The repos *aren't in the OpenStack tent* so how precisely would TC
guidance about what it means for a repo to be part of the OpenStack tent
be useful here?

-jay

On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:

Jay,

That resolution doesn't clarify Zane's argument.

Regards,
-steve

On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:


The TC has given guidance on this already:


http://governance.openstack.org/resolutions/20160119-stackforge-retireme
nt
.html

"In order to simplify software development lifecycle transitions of
Unofficial and Official OpenStack projects, all projects developed
within the OpenStack project infrastructure will be permitted to use
the
“openstack/” namespace. The use of the term “Stackforge” to describe
unofficial projects should be considered deprecated."

The Fuel CCP repos are projects that are not official OpenStack
projects.

They are in the openstack/ git namespace because they use the common
infrastructure and there isn't any formal plan to have the repos join
the "official OpenStack projects" (i.e. the ones listed in the
projects.yaml file in the openstack/governance repository).

Could they be proposed in the future as official OpenStack projects?
Maybe. Not sure, and I don't believe it's necessary to decide ahead of
time.

Please stop using a marketing press release as some indication of what
the "intent" is for these repos or even that there *is* any intent at
this point. It's really early on and these repos are intended as a
place
to experiment and innovate. I don't see why there is so much anger
about
that.

Best,
-jay

On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:

Doug,

Zane's analysis is correct.  I agree with Zane's assessment that TC
clarification can solve this situation.

Regards
-steve

On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:


On 28/07/16 08:48, Vladimir Kozhukalov wrote:

Fuel-ccp repositories are public, everyone is welcome to
participate.
I
don¹t see where we violate ³4 opens². These repos are now
experimental.
At the moment the team is working on building CI pipeline and
developing
functional tests that are to be run as a part of CI process. These
repos
are not to be a part of Fuel Newton release. From time to time we
add
and retire git repos and it is a part of development process. Not
all
these repos are to become a part of Big tent.


It seems to me that there are two different interpretations of what
it
means for a repo to be part of the OpenStack tent, and that these
differing interpretations are at the root of the arguments in this
thread.

The first interpretation is that repos listed as belonging to a team
in
the governance repo are part of a deliverable that is released each
development cycle, and that the same team may also control other
repos
that are not deliverables and hence not part of OpenStack. It's easy
to
see how people could have developed this interpretation in good
faith.

The second interpretation is that the TC blesses a team; that the
only
criterion for

[openstack-dev] [nova] [placement] future topics in resource providers/placement api

2016-07-28 Thread Chris Dent



Note: I've changed the subject to make it clear that this thread is
about topics related to resource providers and the placement API
that are not relevant to newton. Ideas that we need to be chewing on
but not things that need to solved now.

On Thu, 28 Jul 2016, Roman Podoliaka wrote:

I'd personally prefer the latter. I don't think placement api will be
able to implement all the filters we currently have in
FilterScheduler.

How about we do a query in two steps:

1) take a list of compute nodes (== resource providers) and apply all
the filters which *can not* (or *are not* at some point) be
implemented in placement-api

2) POST a launch request passing the *pre-filtered* list of resource
providers.  placement api will pick one of those RP, *claim* its
resources and return the claim info


While I think the ordering you describe might be useful in the use case
that Ed has described in his message, I think for the general case it is
backwards. We should use the placement API _first_ to winnow out those
hosts that physically cannot satisfy the basic requirements for
inventory of the standard resource classes and then pass that simplified
list to the filters. That ought to be efficient and also provides a path
for easy migration of those filters that can be implemented cleanly in
the placement engine.

--
Chris Dent   ┬─┬ノ( º _ ºノ) http://anticdent.org/
freenode: cdent tw: @anticdent__
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] [placement] unresolved topics in resource providers/placement api


On 07/28/2016 02:10 PM, Chris Dent wrote:

On Thu, 28 Jul 2016, Jay Pipes wrote:


* There was some discussion of adding a configuration setting (e.g.
  'placement_connection') that if not None (the default) would be
  used as the connection for the placement database. If None, the
  API database would be used. I can't recall if we said 'yea' or
  'nay' to this idea. The current code uses the api database and its
  config.


The decision at the mid-cycle was to add a new
placement_sql_connection configuration option to the nova.conf. The
default value would be None which would mean the code in
nova/objects/resource_provider.py would default to using the API
database setting.


Roger that. I was pretty sure that was what we decided but wanted to
confirm as unless I'm mistaken it is a considerable change.

As I understand things it means:

* integrating however much of Roman's WIP at
  https://review.openstack.org/#/c/342384/ is required (we need our
  own copies of the models and migrations and a manage script to do
  a db-sync, yes?)
* adding the config setting
* doing the creation of the correct transaction context dependent on
  that config
* adding the new db into the existing nova.fixtures so the tests can work
* reno note


The above matches my understanding and expectations, yes.


Do we want to test against both configurations?


Not sure. If you're asking whether we should have separate gate jobs 
that pass None and a not-None-not-same-as-API-DB value for 
placement_sql_connection, I don't think that's necessary. A single 
functional test that sets placement_sql_connection to a 
not-None-not-API-DB value and verifies that data is written to a 
database other than the API database would be acceptable to me.



# less straightforward and further out things


[snip]


This will be in Ocata.


Sorry if I wasn't clear about this. By "further out" I meant "not
newton". I'll spin off an adjacent thread to deal with any followups
on these parts. I think it is useful to keep the conversation
flowing on these topics, especially after all the input and
discussion at the mid-cycle.


Ack, and thanks :)

Best,
-jay

__
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] [Openstack] Listing of volume fails while using openstack client

2016-07-28 Thread Turbo Fredriksson

On Jul 28, 2016, at 4:57 PM, varun bhatnagar wrote:

> are you asking me to set the value of max_connections to 5000 in mysql conf?

THere was no suggestion. I just told you that I had a similar/same problem
as you and how I solved it.
--
God gave man both a penis and a brain,
but unfortunately not enough blood supply
to run both at the same time.
- R. Williams


__
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

Zane, Steve,

I'd say go for it! Can you please write up a proposal for the TC to
consider? (https://review.openstack.org/#/q/project:openstack/governance)

Thanks,
-- Dims

On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake)  wrote:
> Jay,
>
> I'll be frank.  I have been receiving numerous complaints which mirror
> Zane's full second understanding of what it means to be an OpenStack big
> tent project.  These are not just Kolla developers.  These are people from
> all over the community.  They want something done about it.  I agree with
> Zane if clarity is provided by the TC via a resolution, the problem would
> disappear.  We are all adults and can live by the rules, even if we
> disagree with them.  This contract is the agreement under which
> democracies are created, and one of the most appealing properties of
> OpenStack.
>
> In this case there is no policy and one is obviously necessary to avoid
> these scenarios in the future.
>
> The TC has four options as I see it:
> 1) do nothing
> 2) write a resolution mirroring Zane's first analysis
> 3) write a resolution mirroring Zane's second analysis
> 4) write a different resolution that is a compromise of the first analysis
> and second analysis
>
> I don't wish Mirantis to state anything.  Vladimir did that (thanks
> Vladimir!).
>
> Regards
> -steve
>
>
> On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
>
>>I don't see what is unclear about any of it.
>>
>>What exactly is it that you wish Mirantis to state?
>>
>>Zane says there needs to be some guidance from the TC "about what it
>>means for a repo to be part of the OpenStack tent".
>>
>>But the fuel-ccp repos aren't listed in the governance repo, for reasons
>>that were clearly stated by Mirantis engineers. They want to innovate in
>>this area without all the politics that this thread exposes.
>>
>>Mirantis engineers have clearly laid out the technical reasons that
>>Kolla doesn't fit the needs that Fuel has of these image definitions and
>>orchestration tooling.
>>
>>The repos *aren't in the OpenStack tent* so how precisely would TC
>>guidance about what it means for a repo to be part of the OpenStack tent
>>be useful here?
>>
>>-jay
>>
>>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
>>> Jay,
>>>
>>> That resolution doesn't clarify Zane's argument.
>>>
>>> Regards,
>>> -steve
>>>
>>> On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
>>>
 The TC has given guidance on this already:


http://governance.openstack.org/resolutions/20160119-stackforge-retireme
nt
 .html

 "In order to simplify software development lifecycle transitions of
 Unofficial and Official OpenStack projects, all projects developed
 within the OpenStack project infrastructure will be permitted to use
the
 “openstack/” namespace. The use of the term “Stackforge” to describe
 unofficial projects should be considered deprecated."

 The Fuel CCP repos are projects that are not official OpenStack
projects.

 They are in the openstack/ git namespace because they use the common
 infrastructure and there isn't any formal plan to have the repos join
 the "official OpenStack projects" (i.e. the ones listed in the
 projects.yaml file in the openstack/governance repository).

 Could they be proposed in the future as official OpenStack projects?
 Maybe. Not sure, and I don't believe it's necessary to decide ahead of
 time.

 Please stop using a marketing press release as some indication of what
 the "intent" is for these repos or even that there *is* any intent at
 this point. It's really early on and these repos are intended as a
place
 to experiment and innovate. I don't see why there is so much anger
about
 that.

 Best,
 -jay

 On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
> Doug,
>
> Zane's analysis is correct.  I agree with Zane's assessment that TC
> clarification can solve this situation.
>
> Regards
> -steve
>
> On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
>
>> On 28/07/16 08:48, Vladimir Kozhukalov wrote:
>>> Fuel-ccp repositories are public, everyone is welcome to
>>>participate.
>>> I
>>> don¹t see where we violate ³4 opens². These repos are now
>>> experimental.
>>> At the moment the team is working on building CI pipeline and
>>> developing
>>> functional tests that are to be run as a part of CI process. These
>>> repos
>>> are not to be a part of Fuel Newton release. From time to time we
>>>add
>>> and retire git repos and it is a part of development process. Not
>>>all
>>> these repos are to become a part of Big tent.
>>
>> It seems to me that there are two different interpretations of what
>>it
>> means for a repo to be part of the OpenStack tent, and that these
>> differing

Re: [openstack-dev] [nova] [placement] unresolved topics in resource providers/placement api

2016-07-28 Thread Chris Dent


On Thu, 28 Jul 2016, Jay Pipes wrote:


* There was some discussion of adding a configuration setting (e.g.
  'placement_connection') that if not None (the default) would be
  used as the connection for the placement database. If None, the
  API database would be used. I can't recall if we said 'yea' or
  'nay' to this idea. The current code uses the api database and its
  config.


The decision at the mid-cycle was to add a new placement_sql_connection 
configuration option to the nova.conf. The default value would be None which 
would mean the code in nova/objects/resource_provider.py would default to 
using the API database setting.


Roger that. I was pretty sure that was what we decided but wanted to
confirm as unless I'm mistaken it is a considerable change.

As I understand things it means:

* integrating however much of Roman's WIP at
  https://review.openstack.org/#/c/342384/ is required (we need our
  own copies of the models and migrations and a manage script to do
  a db-sync, yes?)
* adding the config setting
* doing the creation of the correct transaction context dependent on
  that config
* adding the new db into the existing nova.fixtures so the tests can work
* reno note

Do we want to test against both configurations?


# less straightforward and further out things


[snip]


This will be in Ocata.


Sorry if I wasn't clear about this. By "further out" I meant "not
newton". I'll spin off an adjacent thread to deal with any followups
on these parts. I think it is useful to keep the conversation
flowing on these topics, especially after all the input and
discussion at the mid-cycle.

--
Chris Dent   ┬─┬ノ( º _ ºノ) http://anticdent.org/
freenode: cdent tw: @anticdent__
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][db][models]

2016-07-28 Thread Morales, Victor

Manjeet, 

Tony has some issues moving model classes to other location. Given that some 
class models are used by other neutron services, Ihar suggest to use 
debtcollector to make this transition smoothly.  Can we include that solution 
as part of this movement?

Thanks
Victor Morales



On 7/28/16, 12:19 PM, "Bhatia, Manjeet S"  wrote:

>
>Ihar Hrachyshka  wrote:
>> Manjeet S  wrote:
>> 
>>> Hello Team,
>>>
>>> I have a question regarding centralizing all db models in neutron. As 
>>> you all know Oslo versioned object work is under progress and I also 
>>> had a ticket opened for refactoring Db models. 
>>> (https://bugs.launchpad.net/neutron/+bug/1597913). There are three 
>>> way I can do this, 1, move all models to db/models_v2.py 2, create a 
>>> new dir db/models/ and move whatever models are giving issue Of 
>>> cyclic import to db_models.py under db/models/ tree but all in same 
>>> file, 3rd is move into different files under Same tree db/models. I 
>>> liked second way better, please let me know which one according to 
>>> experienced developers is better, I’ll do that way.
>> 
>> I don’t think 2. is the best way forward because it still keeps all 
>> models in a single file with no classification. I prefer we split 
>> models by topic, so option 3.
>> 
>> I took the approach for security groups here:  
>> https://review.openstack.org/#/c/284738/49/neutron/db/models/securityg
>> roup.py
>
>>I also prefer this organization (option 3).
>
>Ok thanks will follow 3.
>
>
>__
>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] Microversioning implementation

2016-07-28 Thread Hongbin Lu

Added this to the agenda of next team meeting [1].

I would like to ask clarification for " the community are discussing to using 
Semantic Versioning(X.Y.Z) instead of microversion X.Y ". Could anyone provide 
more information about that?

Best regards,
Hongbin

> -Original Message-
> From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
> Sent: July-28-16 10:52 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Magnum] Microversioning implementation
> 
> 
> There has been a discussion around micro versioning implementation
> going on in the following patch:
> https://review.openstack.org/#/c/343060/8 and I was asked to bring it
> to the mailing list for further discussion.
> 
> Magnum added header support for microversioning according to the
> Openstack spec[1] but since we haven’t had any changes yet it was not
> being used.  In the patch mentioned above I added code that provides
> infrastructure for implementing micro versions for our API methods.  I
> took the idea from how Nova implemented micro versioning and used some
> of their code modified to work with Pecan.  The basic idea is that you
> version a method using api_version decorator as shown below:
> 
> @base.Controller.api_version("1.1")
> @expose.expose(BayCollection, types.uuid)
> def get_all(self, marker=None):
> """Retrieve a list of bays.
> # code for version 1.1
> 
> @base.Controller.api_version(“1.2”, “1.3") @expose.expose(BayCollection,
> types.uuid) def get_all(self, marker=None):
> """Retrieve a list of bays.
> # code for versions 1.2 through 1.3
> 
> @base.Controller.api_version("1.4")
> @expose.expose(BayCollection, types.uuid) def get_all(self,
> marker=None):
> """Retrieve a list of bays.
> # code for version 1.4 to latest version
> 
> 
> The api_version code takes care of selecting the correct version based
> on version requested in the header. It also checks for version overlaps
> in the methods and gaps in the method versions.
> 
> 
> While working on this Vijendar(working on the first api changes that
> need api versioning) and myself, evaluated several other alternatives:
> 
> 1) Just have each method check the version object and handle the
> differences. This was the most basic solution and will work but we were
> concerned it would add a lot of duplicate code. We were also concerned
> it would be messy in the future as more and more micro versions were
> added. Each method would now be responsible for additional checking and
> more places to change code if there were overall micro version code
> changes in the future.
> 
> 2) Separate pecan controllers for each micro version. When a new micro
> version is added a new controller would be created inheriting from the
> previous version controller. The new controller would override the
> modified methods. Routing changes would be added to make sure that the
> correct controller was used depending on the API header.  We felt that
> the api_version decorator was slightly less complicated and less code
> overhead on each api version change.
> 
> I’d appreciate feedback on whether this is the right way to go or if it
> would be better to go to alternative option 1 or 2. Here were some of
> the concerns by one of the cores in the code review:
> 
> I don't accept this patch, mark it as -2:
> Reason:
> 1. we have already support microversion in our code base, and your
> propose (copied from nova) make things complicated.
> 2. I think you want to support "Support for async bay operations"
> for youadding microversion support, right?
> I would like suggest you as
> http://paste.openstack.org/show/543105/ , it should work for you
> 3. we don't have too may requirements to bump our microversion (I
> know you want to use it in bay-creation async), so we don't want bring
> much code here then we need to maintain it later.
> 4. the community are discussing to using Semantic Versioning(X.Y.Z)
> [1] instead of microversion X.Y [1]http://semver.org/
>If you have any questions , please discuss it in mailing list or
> weekly meeting.
>Eli.
> 
> 
> 
> Jaycen Grant
> OSIC
> 
> 
> 
> 
> [1] http://specs.openstack.org/openstack/api-
> wg/guidelines/microversion_specification.html?highlight=microversioning
> 
> >>
> ___
> ___
> 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] FPGA as a dynamic nested resources

2016-07-28 Thread Harm Sluiman


> On Jul 28, 2016, at 7:57 AM, Jay Pipes  wrote:
> 
> On 07/19/2016 06:51 PM, Ed Leafe wrote:
>> On Jul 19, 2016, at 2:58 PM, Chris Friesen
>>  wrote:
 Why would a VM program the slot? Wouldn’t it usually be at the
 host level?
>>> 
>>> Are there no cases where a VM might want to download a proprietary
>>> program into an FPGA?
>> 
>> That doesn’t sound right to me, but maybe I’m just not that familiar
>> with FPGA specifics. In general, VMs don’t control their hosts.
> 
> Oh, but in NFV-land they most certainly do. :/
> 
> It's commonplace now to see NFV use cases where VMs are provided passthrough 
> access to an SR-IOV physical function on the host and the VMs application 
> code then controls and allocates at will virtual functions from that physical 
> function. Once that happens, yes, it's true that Nova no longer has any clue 
> about the resource usage of VFs on that host device -- it's essentially at 
> that point totally up to the VNF software to properly manage and maintain 
> access to those VFs and allocate/free resources as needed on the host device.
> 
Agreed as a statement of today. 
Once the “VM” application has what looks like dedicated FPGA resources to it, 
it typically does both management and optionally the actual application 
workload. That typically includes loading the bitstream on the device as well 
and then executing API calls to the service it then provides. This can all be 
done now with PCIe/SR-IOV , which is great….

But the generic boards are getting bigger and we often want greater utilization 
of them and to virtualize and manage them separately from the VM based 
application code that may utilize them. In other words these “funky” devices 
are becoming hosts for dynamically loaded services. While a key first step to 
enable allocating the virtual region of the device to a VM when it is 
provisioned, we may want to enable separating management from data plane (aka 
workload) and support dynamic service consumption through more than network 
connections.

VNFs are a use case for sure and a dominant one, but now that we have NICs on 
these large boards and also want to support service chaining, we have the 
opportunity to do that without consuming many CPU cycles. When I can push 
firewall, or ipsec or compression to the “NIC” and not use CPU cycles, why not 
;-), and why not share it to other nearby VMs.

Then take it past VNFs to other workloads that can exploit FPGA...


> Same goes for FPGAs. VNF vendors want access to the physical host device and 
> want to be able to do with that host device whatever they please.
> 
> As I wrote on Twitter recently, NFV is changing software-defined 
> infrastructure to instead be hardware-defined software.
> 
> It's a funky new* world we live in, Ed :)
> 
> -jay
> 
> * new == old == new again.
> 
> __
> 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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Jay,

I'll be frank.  I have been receiving numerous complaints which mirror
Zane's full second understanding of what it means to be an OpenStack big
tent project.  These are not just Kolla developers.  These are people from
all over the community.  They want something done about it.  I agree with
Zane if clarity is provided by the TC via a resolution, the problem would
disappear.  We are all adults and can live by the rules, even if we
disagree with them.  This contract is the agreement under which
democracies are created, and one of the most appealing properties of
OpenStack.

In this case there is no policy and one is obviously necessary to avoid
these scenarios in the future.

The TC has four options as I see it:
1) do nothing
2) write a resolution mirroring Zane's first analysis
3) write a resolution mirroring Zane's second analysis
4) write a different resolution that is a compromise of the first analysis
and second analysis

I don't wish Mirantis to state anything.  Vladimir did that (thanks
Vladimir!).

Regards
-steve


On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:

>I don't see what is unclear about any of it.
>
>What exactly is it that you wish Mirantis to state?
>
>Zane says there needs to be some guidance from the TC "about what it
>means for a repo to be part of the OpenStack tent".
>
>But the fuel-ccp repos aren't listed in the governance repo, for reasons
>that were clearly stated by Mirantis engineers. They want to innovate in
>this area without all the politics that this thread exposes.
>
>Mirantis engineers have clearly laid out the technical reasons that
>Kolla doesn't fit the needs that Fuel has of these image definitions and
>orchestration tooling.
>
>The repos *aren't in the OpenStack tent* so how precisely would TC
>guidance about what it means for a repo to be part of the OpenStack tent
>be useful here?
>
>-jay
>
>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
>> Jay,
>>
>> That resolution doesn't clarify Zane's argument.
>>
>> Regards,
>> -steve
>>
>> On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
>>
>>> The TC has given guidance on this already:
>>>
>>> 
>>>http://governance.openstack.org/resolutions/20160119-stackforge-retireme
>>>nt
>>> .html
>>>
>>> "In order to simplify software development lifecycle transitions of
>>> Unofficial and Official OpenStack projects, all projects developed
>>> within the OpenStack project infrastructure will be permitted to use
>>>the
>>> “openstack/” namespace. The use of the term “Stackforge” to describe
>>> unofficial projects should be considered deprecated."
>>>
>>> The Fuel CCP repos are projects that are not official OpenStack
>>>projects.
>>>
>>> They are in the openstack/ git namespace because they use the common
>>> infrastructure and there isn't any formal plan to have the repos join
>>> the "official OpenStack projects" (i.e. the ones listed in the
>>> projects.yaml file in the openstack/governance repository).
>>>
>>> Could they be proposed in the future as official OpenStack projects?
>>> Maybe. Not sure, and I don't believe it's necessary to decide ahead of
>>> time.
>>>
>>> Please stop using a marketing press release as some indication of what
>>> the "intent" is for these repos or even that there *is* any intent at
>>> this point. It's really early on and these repos are intended as a
>>>place
>>> to experiment and innovate. I don't see why there is so much anger
>>>about
>>> that.
>>>
>>> Best,
>>> -jay
>>>
>>> On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
 Doug,

 Zane's analysis is correct.  I agree with Zane's assessment that TC
 clarification can solve this situation.

 Regards
 -steve

 On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:

> On 28/07/16 08:48, Vladimir Kozhukalov wrote:
>> Fuel-ccp repositories are public, everyone is welcome to
>>participate.
>> I
>> don¹t see where we violate ³4 opens². These repos are now
>> experimental.
>> At the moment the team is working on building CI pipeline and
>> developing
>> functional tests that are to be run as a part of CI process. These
>> repos
>> are not to be a part of Fuel Newton release. From time to time we
>>add
>> and retire git repos and it is a part of development process. Not
>>all
>> these repos are to become a part of Big tent.
>
> It seems to me that there are two different interpretations of what
>it
> means for a repo to be part of the OpenStack tent, and that these
> differing interpretations are at the root of the arguments in this
> thread.
>
> The first interpretation is that repos listed as belonging to a team
>in
> the governance repo are part of a deliverable that is released each
> development cycle, and that the same team may also control other
>repos
> that are not deliverables and hence not part of OpenStack. It's easy
>to
> see how people

Re: [openstack-dev] [puppet] Propose Sofer Athlan-Guyot (chem) part of Puppet OpenStack core

2016-07-28 Thread Denis Egorenko

big +1 from me, thanks for work Sofer!

2016-07-28 19:42 GMT+03:00 Rich Megginson :

> +1 - good guy
>
>
> On 07/28/2016 09:58 AM, Ivan Berezovskiy wrote:
>
> +1, good job!
>
> 2016-07-28 18:50 GMT+03:00 Matt Fischer :
>
>> +1 from me!
>>
>> On Jul 28, 2016 9:20 AM, "Emilien Macchi"  wrote:
>>
>>> You might not know who Sofer is but he's actually "chem" on IRC.
>>> He's the guy who will find the root cause of insane bugs, in OpenStack
>>> in general but also in Puppet OpenStack modules.
>>> Sofer has been working on Puppet OpenStack modules for a while now,
>>> and is already core in puppet-keystone. Many times he brought his
>>> expertise to make our modules better.
>>> He's always here on IRC to help folks and has excellent understanding
>>> at how our project works.
>>>
>>> If you want stats:
>>> http://stackalytics.com/?user_id=sofer-athlan-guyot=commits
>>> I'm quite sure Sofer will make more reviews over the time but I have
>>> no doubt he fully deserves to be part of core reviewers now, with his
>>> technical experience and involvement.
>>>
>>> As usual, it's an open decision, please vote +1/-1 about this proposal.
>>>
>>> Thanks,
>>> --
>>> 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
>>
>>
>
>
> --
> Thanks, Ivan Berezovskiy
> MOS Puppet Team Lead
> at Mirantis 
>
> slack: iberezovskiy
> skype: bouhforever
> phone: + 7-960-343-42-46
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


-- 
Best Regards,
Egorenko Denis,
Senior Deployment Engineer
Mirantis
__
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-28 Thread Mark Casey




On 7/28/2016 11:29 AM, Clint Byrum wrote:

Excerpts from Fox, Kevin M's message of 2016-07-27 22:56:56 +:

I think that would be true, if the container api was opinionated. for example, 
trying to map only a subset of the openstack config options to docker 
environment variables. This would make the containers specific to what your 
talking about. Which business rules to support, what hardware, etc.

But the api is a fairly small one. Its mostly a standardized way to pass config 
files in through docker volumes and get them to land in the right places in the 
container. You should be able to use any system you want (puppet, chef, jinja, 
shell scripts) to deal with the business logic and such, to generate the config 
files, then use the standard api contract to ensure that whatever way you 
launch the container, (puppet, chef, heat, docker run, kubelet, kubernetes, 
etc) it behaves the same. The way your generated config file specifies.

Kolla has provided many different variants of each of the containers (centos, 
ubuntu, etc), showing that api contract is pretty flexible.

A similar thing is going on with kolla-kubernetes.


I appreciate your optimism, however, Kolla is not "the deployment of
OpenStack". It is a set of tools to deploy OpenStack with a set of options
available. If it were a small thing to do, people would choose it. But
instead, they know, the combinatorial matrix of options is staggering,
and one is much better off specializing if they don't fit into the
somewhat generic model that any tool like Kolla provides.

I'd say focus on _keeping things like Kolla focused_ rather than
worrying about making it interoperable.
The point is well made, but this consideration is there for all kinds of 
decisions and must be evaluated on a case by case basis. "The difficult 
efforts of being interoperable vs. the cost of maintaining more 
non-interoperable things."


In this case, at least from the discussion that made it into the spec, 
the models didn't seem to be so far off.



__
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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off


I don't see what is unclear about any of it.

What exactly is it that you wish Mirantis to state?

Zane says there needs to be some guidance from the TC "about what it 
means for a repo to be part of the OpenStack tent".


But the fuel-ccp repos aren't listed in the governance repo, for reasons 
that were clearly stated by Mirantis engineers. They want to innovate in 
this area without all the politics that this thread exposes.


Mirantis engineers have clearly laid out the technical reasons that 
Kolla doesn't fit the needs that Fuel has of these image definitions and 
orchestration tooling.


The repos *aren't in the OpenStack tent* so how precisely would TC 
guidance about what it means for a repo to be part of the OpenStack tent 
be useful here?


-jay

On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:

Jay,

That resolution doesn't clarify Zane's argument.

Regards,
-steve

On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:


The TC has given guidance on this already:

http://governance.openstack.org/resolutions/20160119-stackforge-retirement
.html

"In order to simplify software development lifecycle transitions of
Unofficial and Official OpenStack projects, all projects developed
within the OpenStack project infrastructure will be permitted to use the
“openstack/” namespace. The use of the term “Stackforge” to describe
unofficial projects should be considered deprecated."

The Fuel CCP repos are projects that are not official OpenStack projects.

They are in the openstack/ git namespace because they use the common
infrastructure and there isn't any formal plan to have the repos join
the "official OpenStack projects" (i.e. the ones listed in the
projects.yaml file in the openstack/governance repository).

Could they be proposed in the future as official OpenStack projects?
Maybe. Not sure, and I don't believe it's necessary to decide ahead of
time.

Please stop using a marketing press release as some indication of what
the "intent" is for these repos or even that there *is* any intent at
this point. It's really early on and these repos are intended as a place
to experiment and innovate. I don't see why there is so much anger about
that.

Best,
-jay

On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:

Doug,

Zane's analysis is correct.  I agree with Zane's assessment that TC
clarification can solve this situation.

Regards
-steve

On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:


On 28/07/16 08:48, Vladimir Kozhukalov wrote:

Fuel-ccp repositories are public, everyone is welcome to participate.
I
don¹t see where we violate ³4 opens². These repos are now
experimental.
At the moment the team is working on building CI pipeline and
developing
functional tests that are to be run as a part of CI process. These
repos
are not to be a part of Fuel Newton release. From time to time we add
and retire git repos and it is a part of development process. Not all
these repos are to become a part of Big tent.


It seems to me that there are two different interpretations of what it
means for a repo to be part of the OpenStack tent, and that these
differing interpretations are at the root of the arguments in this
thread.

The first interpretation is that repos listed as belonging to a team in
the governance repo are part of a deliverable that is released each
development cycle, and that the same team may also control other repos
that are not deliverables and hence not part of OpenStack. It's easy to
see how people could have developed this interpretation in good faith.

The second interpretation is that the TC blesses a team; that the only
criterion for receiving this blessing is for the project to be "one of
us", which in practice effectively means following the Four Opens; and
that all repos which the team intends to operate in this manner,
subject
to TC oversight, should be listed in the governance repo. It's also
easy
to see how people could have developed this interpretation in good
faith. (In fact, I was following the big tent discussions very closely
at the time and this was always my understanding of what it meant.)

The only additional thing needed to explain this thread is the
(incorrect) assumption on behalf of all participants that everyone has
the same interpretation :)

Assuming everyone holds the first interpretation, the current
designation of the fuel-ccp repo looks completely logical and the
complaints about it look like sour grapes.

Assuming everyone holds the second interpretation, the current
designation of the fuel-ccp repo looks like an attempt to avoid TC
oversight in order to violate the Four Opens while using the name of an
official project (and issuing press releases identifying it as part of
said official project), and the complaints look like a logical attempt
to defend OpenStack from at least the appearance of openwashing.

I believe this entire controversy will evaporate if the TC can clarify
what it means for a repository to be listed in the governance repo.

Re: [openstack-dev] [neutron][api] Passing random filters on neutron API calls

2016-07-28 Thread Ihar Hrachyshka


Kevin Benton  wrote:

Too late. That's a backwards incompatible change that can mess with  
clients putting on cache busting nonce tokens and who knows what else.


Ideally, API layer would at least avoid passing those unknown filters into  
plugins; same for plugins returning random fields: API layer should filter  
unknown data out. We already have attribute maps defined for extensions, so  
it should be relatively easy to implement that without making plugin layer  
forgiving to those kinds of requests.


Ihar

__
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][db][models]

2016-07-28 Thread Bhatia, Manjeet S


Ihar Hrachyshka  wrote:
> Manjeet S  wrote:
> 
>> Hello Team,
>>
>> I have a question regarding centralizing all db models in neutron. As 
>> you all know Oslo versioned object work is under progress and I also 
>> had a ticket opened for refactoring Db models. 
>> (https://bugs.launchpad.net/neutron/+bug/1597913). There are three 
>> way I can do this, 1, move all models to db/models_v2.py 2, create a 
>> new dir db/models/ and move whatever models are giving issue Of 
>> cyclic import to db_models.py under db/models/ tree but all in same 
>> file, 3rd is move into different files under Same tree db/models. I 
>> liked second way better, please let me know which one according to 
>> experienced developers is better, I’ll do that way.
> 
> I don’t think 2. is the best way forward because it still keeps all 
> models in a single file with no classification. I prefer we split 
> models by topic, so option 3.
> 
> I took the approach for security groups here:  
> https://review.openstack.org/#/c/284738/49/neutron/db/models/securityg
> roup.py

>I also prefer this organization (option 3).

Ok thanks will follow 3.


__
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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Excerpts from Zane Bitter's message of 2016-07-28 12:15:34 -0400:
> On 28/07/16 08:48, Vladimir Kozhukalov wrote:
> > Fuel-ccp repositories are public, everyone is welcome to participate. I
> > don’t see where we violate “4 opens”. These repos are now experimental.
> > At the moment the team is working on building CI pipeline and developing
> > functional tests that are to be run as a part of CI process. These repos
> > are not to be a part of Fuel Newton release. From time to time we add
> > and retire git repos and it is a part of development process. Not all
> > these repos are to become a part of Big tent.
> 
> It seems to me that there are two different interpretations of what it 
> means for a repo to be part of the OpenStack tent, and that these 
> differing interpretations are at the root of the arguments in this thread.
> 
> The first interpretation is that repos listed as belonging to a team in 
> the governance repo are part of a deliverable that is released each 
> development cycle, and that the same team may also control other repos 
> that are not deliverables and hence not part of OpenStack. It's easy to 
> see how people could have developed this interpretation in good faith.
> 
> The second interpretation is that the TC blesses a team; that the only 
> criterion for receiving this blessing is for the project to be "one of 
> us", which in practice effectively means following the Four Opens; and 
> that all repos which the team intends to operate in this manner, subject 
> to TC oversight, should be listed in the governance repo. It's also easy 
> to see how people could have developed this interpretation in good 
> faith. (In fact, I was following the big tent discussions very closely 
> at the time and this was always my understanding of what it meant.)
> 
> The only additional thing needed to explain this thread is the 
> (incorrect) assumption on behalf of all participants that everyone has 
> the same interpretation :)
> 
> Assuming everyone holds the first interpretation, the current 
> designation of the fuel-ccp repo looks completely logical and the 
> complaints about it look like sour grapes.
> 
> Assuming everyone holds the second interpretation, the current 
> designation of the fuel-ccp repo looks like an attempt to avoid TC 
> oversight in order to violate the Four Opens while using the name of an 
> official project (and issuing press releases identifying it as part of 
> said official project), and the complaints look like a logical attempt 
> to defend OpenStack from at least the appearance of openwashing.
> 
> I believe this entire controversy will evaporate if the TC can clarify 
> what it means for a repository to be listed in the governance repo.
> 
> cheers,
> Zane.
> 

I think it is a reasonable expectation that teams would want to add
their new repositories to the governance list to have the rights
that go along with that, but I'm not aware of any requirement that
they do so.

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] [ptl][requirements] nomination period started

2016-07-28 Thread Tony Breeds

On Thu, Jul 28, 2016 at 12:42:32PM -0400, Doug Hellmann wrote:

> As part of our discussion, we realized that over time we'll be
> automating more and more of the submissions to the requirements
> repo so the core review team (and everyone else) will likely end
> up submitting fewer manual patches. This points out a difference
> in the nature of this team from others that we'll need to address
> to avoid arriving at the unlikely situation where no human is
> actually able to vote for PTL. It's more likely that none of the
> core review team would be on the voter list using our usual "who
> has landed a patch" rule, and that would be bad as well, IMO.
> 
> So, the new team will need to add an item to their bootstrapping
> todo list to specify how their electorate is identified to ensure
> we can continue to have healthy, representative, elections.  Based
> on my interpretation of the TC charter [1], we don't need a rules
> change. Adding some team documentation and (as Jeremy pointed out)
> active maintenance of the "extra-atcs" list for the team in the
> governance repository should be sufficient.
> 
> I propose that we defer any real discussion of what the policy
> should be until after the current election, but try to work it out
> before the team applies for big tent membership.

Sounds like a good plan.

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] [ptl][requirements] nomination period started

2016-07-28 Thread Tony Breeds

On Thu, Jul 28, 2016 at 12:21:26PM -0400, Anita Kuno wrote:

> So Doug and I had a chat and we propose the following workflow for
> deciding the requirements ptl:
> 1) Nominations open, done:
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/100173.html
> 2) Nominations close: August 5th, 11:59 utc
> 3) List of Nominees posted to mailing list, a post appened to the
> parent:
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/100173.html
> 4) Election officials start civs poll after 13:00 utc August 5, 2016
> 5) Election poll closes after 13:00 utc  August 11, 2016
> 6) Winning candidate will be announced to the mailing list
> (openstack-dev@lists.openstack.org)

Perfect!

Thanks Anita and Doug.

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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Jay,

That resolution doesn't clarify Zane's argument.

Regards,
-steve

On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:

>The TC has given guidance on this already:
>
>http://governance.openstack.org/resolutions/20160119-stackforge-retirement
>.html
>
>"In order to simplify software development lifecycle transitions of
>Unofficial and Official OpenStack projects, all projects developed
>within the OpenStack project infrastructure will be permitted to use the
>“openstack/” namespace. The use of the term “Stackforge” to describe
>unofficial projects should be considered deprecated."
>
>The Fuel CCP repos are projects that are not official OpenStack projects.
>
>They are in the openstack/ git namespace because they use the common
>infrastructure and there isn't any formal plan to have the repos join
>the "official OpenStack projects" (i.e. the ones listed in the
>projects.yaml file in the openstack/governance repository).
>
>Could they be proposed in the future as official OpenStack projects?
>Maybe. Not sure, and I don't believe it's necessary to decide ahead of
>time.
>
>Please stop using a marketing press release as some indication of what
>the "intent" is for these repos or even that there *is* any intent at
>this point. It's really early on and these repos are intended as a place
>to experiment and innovate. I don't see why there is so much anger about
>that.
>
>Best,
>-jay
>
>On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
>> Doug,
>>
>> Zane's analysis is correct.  I agree with Zane's assessment that TC
>> clarification can solve this situation.
>>
>> Regards
>> -steve
>>
>> On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
>>
>>> On 28/07/16 08:48, Vladimir Kozhukalov wrote:
 Fuel-ccp repositories are public, everyone is welcome to participate.
I
 don¹t see where we violate ³4 opens². These repos are now
experimental.
 At the moment the team is working on building CI pipeline and
developing
 functional tests that are to be run as a part of CI process. These
repos
 are not to be a part of Fuel Newton release. From time to time we add
 and retire git repos and it is a part of development process. Not all
 these repos are to become a part of Big tent.
>>>
>>> It seems to me that there are two different interpretations of what it
>>> means for a repo to be part of the OpenStack tent, and that these
>>> differing interpretations are at the root of the arguments in this
>>>thread.
>>>
>>> The first interpretation is that repos listed as belonging to a team in
>>> the governance repo are part of a deliverable that is released each
>>> development cycle, and that the same team may also control other repos
>>> that are not deliverables and hence not part of OpenStack. It's easy to
>>> see how people could have developed this interpretation in good faith.
>>>
>>> The second interpretation is that the TC blesses a team; that the only
>>> criterion for receiving this blessing is for the project to be "one of
>>> us", which in practice effectively means following the Four Opens; and
>>> that all repos which the team intends to operate in this manner,
>>>subject
>>> to TC oversight, should be listed in the governance repo. It's also
>>>easy
>>> to see how people could have developed this interpretation in good
>>> faith. (In fact, I was following the big tent discussions very closely
>>> at the time and this was always my understanding of what it meant.)
>>>
>>> The only additional thing needed to explain this thread is the
>>> (incorrect) assumption on behalf of all participants that everyone has
>>> the same interpretation :)
>>>
>>> Assuming everyone holds the first interpretation, the current
>>> designation of the fuel-ccp repo looks completely logical and the
>>> complaints about it look like sour grapes.
>>>
>>> Assuming everyone holds the second interpretation, the current
>>> designation of the fuel-ccp repo looks like an attempt to avoid TC
>>> oversight in order to violate the Four Opens while using the name of an
>>> official project (and issuing press releases identifying it as part of
>>> said official project), and the complaints look like a logical attempt
>>> to defend OpenStack from at least the appearance of openwashing.
>>>
>>> I believe this entire controversy will evaporate if the TC can clarify
>>> what it means for a repository to be listed in the governance repo.
>>>
>>> cheers,
>>> Zane.
>>>
>>> 
>>>
>>>__
>>> 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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off


The TC has given guidance on this already:

http://governance.openstack.org/resolutions/20160119-stackforge-retirement.html

"In order to simplify software development lifecycle transitions of 
Unofficial and Official OpenStack projects, all projects developed 
within the OpenStack project infrastructure will be permitted to use the 
“openstack/” namespace. The use of the term “Stackforge” to describe 
unofficial projects should be considered deprecated."


The Fuel CCP repos are projects that are not official OpenStack projects.

They are in the openstack/ git namespace because they use the common 
infrastructure and there isn't any formal plan to have the repos join 
the "official OpenStack projects" (i.e. the ones listed in the 
projects.yaml file in the openstack/governance repository).


Could they be proposed in the future as official OpenStack projects? 
Maybe. Not sure, and I don't believe it's necessary to decide ahead of time.


Please stop using a marketing press release as some indication of what 
the "intent" is for these repos or even that there *is* any intent at 
this point. It's really early on and these repos are intended as a place 
to experiment and innovate. I don't see why there is so much anger about 
that.


Best,
-jay

On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:

Doug,

Zane's analysis is correct.  I agree with Zane's assessment that TC
clarification can solve this situation.

Regards
-steve

On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:


On 28/07/16 08:48, Vladimir Kozhukalov wrote:

Fuel-ccp repositories are public, everyone is welcome to participate. I
don¹t see where we violate ³4 opens². These repos are now experimental.
At the moment the team is working on building CI pipeline and developing
functional tests that are to be run as a part of CI process. These repos
are not to be a part of Fuel Newton release. From time to time we add
and retire git repos and it is a part of development process. Not all
these repos are to become a part of Big tent.


It seems to me that there are two different interpretations of what it
means for a repo to be part of the OpenStack tent, and that these
differing interpretations are at the root of the arguments in this thread.

The first interpretation is that repos listed as belonging to a team in
the governance repo are part of a deliverable that is released each
development cycle, and that the same team may also control other repos
that are not deliverables and hence not part of OpenStack. It's easy to
see how people could have developed this interpretation in good faith.

The second interpretation is that the TC blesses a team; that the only
criterion for receiving this blessing is for the project to be "one of
us", which in practice effectively means following the Four Opens; and
that all repos which the team intends to operate in this manner, subject
to TC oversight, should be listed in the governance repo. It's also easy
to see how people could have developed this interpretation in good
faith. (In fact, I was following the big tent discussions very closely
at the time and this was always my understanding of what it meant.)

The only additional thing needed to explain this thread is the
(incorrect) assumption on behalf of all participants that everyone has
the same interpretation :)

Assuming everyone holds the first interpretation, the current
designation of the fuel-ccp repo looks completely logical and the
complaints about it look like sour grapes.

Assuming everyone holds the second interpretation, the current
designation of the fuel-ccp repo looks like an attempt to avoid TC
oversight in order to violate the Four Opens while using the name of an
official project (and issuing press releases identifying it as part of
said official project), and the complaints look like a logical attempt
to defend OpenStack from at least the appearance of openwashing.

I believe this entire controversy will evaporate if the TC can clarify
what it means for a repository to be listed in the governance repo.

cheers,
Zane.

__
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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-28 Thread Fox, Kevin M

+1

From: Steven Dake (stdake) [std...@cisco.com]
Sent: Thursday, July 28, 2016 9:33 AM
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

Doug,

Zane's analysis is correct.  I agree with Zane's assessment that TC
clarification can solve this situation.

Regards
-steve

On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:

>On 28/07/16 08:48, Vladimir Kozhukalov wrote:
>> Fuel-ccp repositories are public, everyone is welcome to participate. I
>> don¹t see where we violate ³4 opens². These repos are now experimental.
>> At the moment the team is working on building CI pipeline and developing
>> functional tests that are to be run as a part of CI process. These repos
>> are not to be a part of Fuel Newton release. From time to time we add
>> and retire git repos and it is a part of development process. Not all
>> these repos are to become a part of Big tent.
>
>It seems to me that there are two different interpretations of what it
>means for a repo to be part of the OpenStack tent, and that these
>differing interpretations are at the root of the arguments in this thread.
>
>The first interpretation is that repos listed as belonging to a team in
>the governance repo are part of a deliverable that is released each
>development cycle, and that the same team may also control other repos
>that are not deliverables and hence not part of OpenStack. It's easy to
>see how people could have developed this interpretation in good faith.
>
>The second interpretation is that the TC blesses a team; that the only
>criterion for receiving this blessing is for the project to be "one of
>us", which in practice effectively means following the Four Opens; and
>that all repos which the team intends to operate in this manner, subject
>to TC oversight, should be listed in the governance repo. It's also easy
>to see how people could have developed this interpretation in good
>faith. (In fact, I was following the big tent discussions very closely
>at the time and this was always my understanding of what it meant.)
>
>The only additional thing needed to explain this thread is the
>(incorrect) assumption on behalf of all participants that everyone has
>the same interpretation :)
>
>Assuming everyone holds the first interpretation, the current
>designation of the fuel-ccp repo looks completely logical and the
>complaints about it look like sour grapes.
>
>Assuming everyone holds the second interpretation, the current
>designation of the fuel-ccp repo looks like an attempt to avoid TC
>oversight in order to violate the Four Opens while using the name of an
>official project (and issuing press releases identifying it as part of
>said official project), and the complaints look like a logical attempt
>to defend OpenStack from at least the appearance of openwashing.
>
>I believe this entire controversy will evaporate if the TC can clarify
>what it means for a repository to be listed in the governance repo.
>
>cheers,
>Zane.
>
>__
>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] [ptl][requirements] nomination period started

Excerpts from Anita Kuno's message of 2016-07-28 12:21:26 -0400:
> On 07/27/2016 06:06 PM, Jeremy Stanley wrote:
> > On 2016-07-27 17:56:39 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> >> However, we may have some folks on the core team who have not
> >> contributed a patch, since it is far more common to do reviews than
> >> to submit changes there (more and more of the changes are being
> >> automated). So, we probably need to expand the traditional definition
> >> to also include the existing core review team (members of
> >> requirements-core [1]), just to be safe.
> > [...]
> > 
> > Easy enough to do for a one-off, but might want to consider
> > officially adding them as extra-ATCs in governance down the road to
> > make that more explicit. Our existing tooling is already adapted to
> > that solution as well (for example, the current i18n voters are
> > _all_ recorded as extra-ATCs because we haven't implemented API
> > calls to Zanata for integrating it into the normal roll generation
> > process yet).
> > 
> > However, implicitly adding core reviewers seems a little weird as
> > they're officially appointed by the PTL and so allowing the
> > incumbent PTL to appoint (or remove) specific voters before their
> > pending reelection... well anyway, I guess it's balanced out by
> > there being a lot more committers to that repo than core reviewers
> > on it.
> > 
> 
> So Doug and I had a chat and we propose the following workflow for
> deciding the requirements ptl:
> 1) Nominations open, done:
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/100173.html
> 2) Nominations close: August 5th, 11:59 utc
> 3) List of Nominees posted to mailing list, a post appened to the
> parent:
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/100173.html
> 4) Election officials start civs poll after 13:00 utc August 5, 2016
> 5) Election poll closes after 13:00 utc  August 11, 2016
> 6) Winning candidate will be announced to the mailing list
> (openstack-dev@lists.openstack.org)
> 
> Electorate:
> requirements core reviewers and those who have merged at least one
> patch to the requirements repo between 1 Aug 2015 and July 31 2016

As part of our discussion, we realized that over time we'll be
automating more and more of the submissions to the requirements
repo so the core review team (and everyone else) will likely end
up submitting fewer manual patches. This points out a difference
in the nature of this team from others that we'll need to address
to avoid arriving at the unlikely situation where no human is
actually able to vote for PTL. It's more likely that none of the
core review team would be on the voter list using our usual "who
has landed a patch" rule, and that would be bad as well, IMO.

So, the new team will need to add an item to their bootstrapping
todo list to specify how their electorate is identified to ensure
we can continue to have healthy, representative, elections.  Based
on my interpretation of the TC charter [1], we don't need a rules
change. Adding some team documentation and (as Jeremy pointed out)
active maintenance of the "extra-atcs" list for the team in the
governance repository should be sufficient.

I propose that we defer any real discussion of what the policy
should be until after the current election, but try to work it out
before the team applies for big tent membership.

Doug

[1] 
http://governance.openstack.org/reference/charter.html#voters-for-ptl-seats-apc

> can I vote?
> 
> 
> https://review.openstack.org/#/q/project:openstack/requirements+is:owner+is:merged+after:2015-07-31+before:2016-08-01
> 
> how do I vote?
> 
> eligible voters will receive a ballot sent to their gerrit preferred
> email, if you are an eligible voter and don't receive an email providing
> you a link to the poll by August 6, 2016 please email the election
> officials with a gerrit url for your patch confirming your eligibility
> 
> 
> Please ask any questions you need to ask to clarify this process so you
> understand it.
> 
> If you have a question of a personal nature, please don't hesitate to
> email both election officials: Doug Hellmann  and
> Anita Kuno  as soon as you can so we can
> ensure you have the answers you need.
> 
> Thank you to Jeremy Stanley for his assistance and support as well as
> his offer to help us generate the electoral rolls, which include a wip
> patch to governance to generate an electoral roll separate from the
> Release Management team electorate. After the election, we will abandon
> that patch and let the new team propose its own change, including a
> mission statement and other metadata, when they seek to become a big
> tent project. Gerrit patch: https://review.openstack.org/#/c/348462
> 
> Thanks for your participation in the electoral process,
> 
> Anita and Doug
> 

__
OpenStack Development Mailing List (not

Re: [openstack-dev] [puppet] Propose Sofer Athlan-Guyot (chem) part of Puppet OpenStack core

2016-07-28 Thread Rich Megginson


+1 - good guy

On 07/28/2016 09:58 AM, Ivan Berezovskiy wrote:

+1, good job!

2016-07-28 18:50 GMT+03:00 Matt Fischer >:


+1 from me!


On Jul 28, 2016 9:20 AM, "Emilien Macchi" > wrote:

You might not know who Sofer is but he's actually "chem" on IRC.
He's the guy who will find the root cause of insane bugs, in
OpenStack
in general but also in Puppet OpenStack modules.
Sofer has been working on Puppet OpenStack modules for a while
now,
and is already core in puppet-keystone. Many times he brought his
expertise to make our modules better.
He's always here on IRC to help folks and has excellent
understanding
at how our project works.

If you want stats:
http://stackalytics.com/?user_id=sofer-athlan-guyot=commits
I'm quite sure Sofer will make more reviews over the time but
I have
no doubt he fully deserves to be part of core reviewers now,
with his
technical experience and involvement.

As usual, it's an open decision, please vote +1/-1 about this
proposal.

Thanks,
--
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




--
Thanks, Ivan Berezovskiy
MOS Puppet Team Lead
at Mirantis 

slack: iberezovskiy
skype: bouhforever
phone: + 7-960-343-42-46



__
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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Doug,

Zane's analysis is correct.  I agree with Zane's assessment that TC
clarification can solve this situation.

Regards
-steve

On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:

>On 28/07/16 08:48, Vladimir Kozhukalov wrote:
>> Fuel-ccp repositories are public, everyone is welcome to participate. I
>> don¹t see where we violate ³4 opens². These repos are now experimental.
>> At the moment the team is working on building CI pipeline and developing
>> functional tests that are to be run as a part of CI process. These repos
>> are not to be a part of Fuel Newton release. From time to time we add
>> and retire git repos and it is a part of development process. Not all
>> these repos are to become a part of Big tent.
>
>It seems to me that there are two different interpretations of what it
>means for a repo to be part of the OpenStack tent, and that these
>differing interpretations are at the root of the arguments in this thread.
>
>The first interpretation is that repos listed as belonging to a team in
>the governance repo are part of a deliverable that is released each
>development cycle, and that the same team may also control other repos
>that are not deliverables and hence not part of OpenStack. It's easy to
>see how people could have developed this interpretation in good faith.
>
>The second interpretation is that the TC blesses a team; that the only
>criterion for receiving this blessing is for the project to be "one of
>us", which in practice effectively means following the Four Opens; and
>that all repos which the team intends to operate in this manner, subject
>to TC oversight, should be listed in the governance repo. It's also easy
>to see how people could have developed this interpretation in good
>faith. (In fact, I was following the big tent discussions very closely
>at the time and this was always my understanding of what it meant.)
>
>The only additional thing needed to explain this thread is the
>(incorrect) assumption on behalf of all participants that everyone has
>the same interpretation :)
>
>Assuming everyone holds the first interpretation, the current
>designation of the fuel-ccp repo looks completely logical and the
>complaints about it look like sour grapes.
>
>Assuming everyone holds the second interpretation, the current
>designation of the fuel-ccp repo looks like an attempt to avoid TC
>oversight in order to violate the Four Opens while using the name of an
>official project (and issuing press releases identifying it as part of
>said official project), and the complaints look like a logical attempt
>to defend OpenStack from at least the appearance of openwashing.
>
>I believe this entire controversy will evaporate if the TC can clarify
>what it means for a repository to be listed in the governance repo.
>
>cheers,
>Zane.
>
>__
>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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-28 Thread Clint Byrum

Excerpts from Fox, Kevin M's message of 2016-07-27 22:56:56 +:
> I think that would be true, if the container api was opinionated. for 
> example, trying to map only a subset of the openstack config options to 
> docker environment variables. This would make the containers specific to what 
> your talking about. Which business rules to support, what hardware, etc.
> 
> But the api is a fairly small one. Its mostly a standardized way to pass 
> config files in through docker volumes and get them to land in the right 
> places in the container. You should be able to use any system you want 
> (puppet, chef, jinja, shell scripts) to deal with the business logic and 
> such, to generate the config files, then use the standard api contract to 
> ensure that whatever way you launch the container, (puppet, chef, heat, 
> docker run, kubelet, kubernetes, etc) it behaves the same. The way your 
> generated config file specifies.
> 
> Kolla has provided many different variants of each of the containers (centos, 
> ubuntu, etc), showing that api contract is pretty flexible.
> 
> A similar thing is going on with kolla-kubernetes.
> 

I appreciate your optimism, however, Kolla is not "the deployment of
OpenStack". It is a set of tools to deploy OpenStack with a set of options
available. If it were a small thing to do, people would choose it. But
instead, they know, the combinatorial matrix of options is staggering,
and one is much better off specializing if they don't fit into the
somewhat generic model that any tool like Kolla provides.

I'd say focus on _keeping things like Kolla focused_ rather than
worrying about making it interoperable.

__
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-28 Thread Mark Casey

Sorry for the double post, but the part about people wasting their time 
reads far more inflammatory than I really intended. I merely mean 
community effort is a strong theme.

On 7/28/2016 11:20 AM, Mark Casey wrote:

+1 to one more pass at using the same images. Doing so will become 
practically impossible in a matter of weeks or months, and in the long 
term the additional shared human resources outweigh the interpersonal 
complexities (and for any who don't think so - maybe you're wasting 
your time here?).

Logically, I just view Kolla's existing containers as a thin wrapper 
around OpenStack projects' debs and rpms (though I understand there 
are many differences from a purely technical standpoint, and that the 
containers can be built entirely from source instead). I suppose I 
view them this way because building the existing containers creates 
deployable artifacts (that is, the images) and these images have a lot 
of the same qualities as traditional deb/rpm packages. The resulting 
artifacts in both cases are somewhat immutable, they both put programs 
in certain places, both expect configs in certain places, both 
configure logs to be written in certain places, etc. In fact a lot of 
these locations in the container's case are dictated by where they are 
expected in the packages. Sharing the images could further standardize 
things.

This is different IMHO than deployment tooling in the usual 
configuration management sense, which I presume is one of the reasons 
for this possible Kolla repo-split to begin with. I certainly see the 
upsides to having a diverse set of tooling to deploy project artifacts 
(deb/rpm/container image/git commit [i.e. from source]), but I don't 
get duplicating the artifacts themselves over relatively simple 
technicalities. I highly doubt anyone would create a major packaging 
variation in the deb/rpm packaging (perhaps where all OpenStack 
projects are deployable from a single rpm or deb [wouldn't that be 
fun!], or perhaps a switch to FPM) merely because it made sense for a 
new deployment project. (to be clear though, I am in general happy to 
have more deployment options coming online)

Thank you,
Mark

On 7/28/2016 8:56 AM, Fox, Kevin M wrote:
I really see 3 issues raised in the spec mentioned that have any 
disagreement as far as I can tell.

1. mirantis would like to see kolla-ansible split from the base kolla 
repo. This has a lot of support and is likely to come up for a final 
vote soon. It was postponed due to not wanting to split in the middle 
of a cycle. - This does not seem like a good reason at this point to 
spawn a new project. I support the split.

2. mirantis would like to see repos split for each docker container 
definition to be one per container. This is purely a management style 
difference. Split or combined both has advantages, and at present 
scaling issues have not been hit, so change has a cost that doesn't 
yet have a significant benefit. If it started to be, I'm sure it 
would be re-evaluated. This does not seem like a good reason at this 
point to spawn a new project. I think splitting seems unnecessary at 
this point, but if the whole thing comes down to this one issue, I'd 
support splitting the repos just so we don't duplicate so much work 
over such a minor thing.

3. Some bootstrap logic in some of the containers. mirantis would 
like to see it gone. Its completely optional (just don't set the 
BOOTSTRAP env vars) and needs to stay for api backwards compatibility 
in existing containers. It does not have to be used by deployment 
tools that don't wish to use it. This does not seem like a good 
reason at this point to spawn a new project. I support keeping it to 
not break things as its optional.

Are these really that contentious that we have to split a community 
over? Can we get both sides to give in a little and help each other out?

Maybe something like:
1. kolla commits to split out kolla-ansible as soon as possible 
(right after newton tagged)
2. Some middle ground here. Maybe its keep as is, but come up with a 
formal procedure for re-evaluating when it becomes painful and make a 
change. (Seems similar to the fuel/puppet repo upstreaming thing, in 
a way. Maybe some of the same process could work here? Some time to 
review metrics?)

3. We keep the optional stuff so we don't break existing deployments.

Is this reasonable?

Thanks,
Kevin

*From:* Vladimir Kozhukalov [vkozhuka...@mirantis.com]
*Sent:* Thursday, July 28, 2016 5:48 AM
*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

>1. Alter the mission statement of fuel to match the reality being

>published by the press and Mirantis's executive team

>2. Include these non-experimental repos in the projects.yaml governance

>Repository

Frankly, I don’t

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

2016-07-28 Thread Mark Casey

+1 to one more pass at using the same images. Doing so will become 
practically impossible in a matter of weeks or months, and in the long 
term the additional shared human resources outweigh the interpersonal 
complexities (and for any who don't think so - maybe you're wasting your 
time here?).

Logically, I just view Kolla's existing containers as a thin wrapper 
around OpenStack projects' debs and rpms (though I understand there are 
many differences from a purely technical standpoint, and that the 
containers can be built entirely from source instead). I suppose I view 
them this way because building the existing containers creates 
deployable artifacts (that is, the images) and these images have a lot 
of the same qualities as traditional deb/rpm packages. The resulting 
artifacts in both cases are somewhat immutable, they both put programs 
in certain places, both expect configs in certain places, both configure 
logs to be written in certain places, etc. In fact a lot of these 
locations in the container's case are dictated by where they are 
expected in the packages. Sharing the images could further standardize 
things.

This is different IMHO than deployment tooling in the usual 
configuration management sense, which I presume is one of the reasons 
for this possible Kolla repo-split to begin with. I certainly see the 
upsides to having a diverse set of tooling to deploy project artifacts 
(deb/rpm/container image/git commit [i.e. from source]), but I don't get 
duplicating the artifacts themselves over relatively simple 
technicalities. I highly doubt anyone would create a major packaging 
variation in the deb/rpm packaging (perhaps where all OpenStack projects 
are deployable from a single rpm or deb [wouldn't that be fun!], or 
perhaps a switch to FPM) merely because it made sense for a new 
deployment project. (to be clear though, I am in general happy to have 
more deployment options coming online)

Thank you,
Mark

On 7/28/2016 8:56 AM, Fox, Kevin M wrote:
I really see 3 issues raised in the spec mentioned that have any 
disagreement as far as I can tell.

1. mirantis would like to see kolla-ansible split from the base kolla 
repo. This has a lot of support and is likely to come up for a final 
vote soon. It was postponed due to not wanting to split in the middle 
of a cycle. - This does not seem like a good reason at this point to 
spawn a new project. I support the split.

2. mirantis would like to see repos split for each docker container 
definition to be one per container. This is purely a management style 
difference. Split or combined both has advantages, and at present 
scaling issues have not been hit, so change has a cost that doesn't 
yet have a significant benefit. If it started to be, I'm sure it would 
be re-evaluated. This does not seem like a good reason at this point 
to spawn a new project. I think splitting seems unnecessary at this 
point, but if the whole thing comes down to this one issue, I'd 
support splitting the repos just so we don't duplicate so much work 
over such a minor thing.

3. Some bootstrap logic in some of the containers. mirantis would like 
to see it gone. Its completely optional (just don't set the BOOTSTRAP 
env vars) and needs to stay for api backwards compatibility in 
existing containers. It does not have to be used by deployment tools 
that don't wish to use it. This does not seem like a good reason at 
this point to spawn a new project. I support keeping it to not break 
things as its optional.

Are these really that contentious that we have to split a community 
over? Can we get both sides to give in a little and help each other out?

Maybe something like:
1. kolla commits to split out kolla-ansible as soon as possible (right 
after newton tagged)
2. Some middle ground here. Maybe its keep as is, but come up with a 
formal procedure for re-evaluating when it becomes painful and make a 
change. (Seems similar to the fuel/puppet repo upstreaming thing, in a 
way. Maybe some of the same process could work here? Some time to 
review metrics?)

3. We keep the optional stuff so we don't break existing deployments.

Is this reasonable?

Thanks,
Kevin

*From:* Vladimir Kozhukalov [vkozhuka...@mirantis.com]
*Sent:* Thursday, July 28, 2016 5:48 AM
*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

>1. Alter the mission statement of fuel to match the reality being

>published by the press and Mirantis's executive team

>2. Include these non-experimental repos in the projects.yaml governance

>Repository

Frankly, I don’t understand what part of the press release contradicts 
with Fuel mission.

Current Fuel mission is “To streamline and accelerate the process of 
deploying, testing and maintaining various configurations of OpenStack 
at

Re: [openstack-dev] [ptl][requirements] nomination period started

2016-07-28 Thread Anita Kuno

On 07/27/2016 06:06 PM, Jeremy Stanley wrote:
> On 2016-07-27 17:56:39 -0400 (-0400), Doug Hellmann wrote:
> [...]
>> However, we may have some folks on the core team who have not
>> contributed a patch, since it is far more common to do reviews than
>> to submit changes there (more and more of the changes are being
>> automated). So, we probably need to expand the traditional definition
>> to also include the existing core review team (members of
>> requirements-core [1]), just to be safe.
> [...]
> 
> Easy enough to do for a one-off, but might want to consider
> officially adding them as extra-ATCs in governance down the road to
> make that more explicit. Our existing tooling is already adapted to
> that solution as well (for example, the current i18n voters are
> _all_ recorded as extra-ATCs because we haven't implemented API
> calls to Zanata for integrating it into the normal roll generation
> process yet).
> 
> However, implicitly adding core reviewers seems a little weird as
> they're officially appointed by the PTL and so allowing the
> incumbent PTL to appoint (or remove) specific voters before their
> pending reelection... well anyway, I guess it's balanced out by
> there being a lot more committers to that repo than core reviewers
> on it.
> 

So Doug and I had a chat and we propose the following workflow for
deciding the requirements ptl:
1) Nominations open, done:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/100173.html
2) Nominations close: August 5th, 11:59 utc
3) List of Nominees posted to mailing list, a post appened to the
parent:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/100173.html
4) Election officials start civs poll after 13:00 utc August 5, 2016
5) Election poll closes after 13:00 utc  August 11, 2016
6) Winning candidate will be announced to the mailing list
(openstack-dev@lists.openstack.org)

Electorate:
requirements core reviewers and those who have merged at least one
patch to the requirements repo between 1 Aug 2015 and July 31 2016
can I vote?


https://review.openstack.org/#/q/project:openstack/requirements+is:owner+is:merged+after:2015-07-31+before:2016-08-01

how do I vote?

eligible voters will receive a ballot sent to their gerrit preferred
email, if you are an eligible voter and don't receive an email providing
you a link to the poll by August 6, 2016 please email the election
officials with a gerrit url for your patch confirming your eligibility


Please ask any questions you need to ask to clarify this process so you
understand it.

If you have a question of a personal nature, please don't hesitate to
email both election officials: Doug Hellmann  and
Anita Kuno  as soon as you can so we can
ensure you have the answers you need.

Thank you to Jeremy Stanley for his assistance and support as well as
his offer to help us generate the electoral rolls, which include a wip
patch to governance to generate an electoral roll separate from the
Release Management team electorate. After the election, we will abandon
that patch and let the new team propose its own change, including a
mission statement and other metadata, when they seek to become a big
tent project. Gerrit patch: https://review.openstack.org/#/c/348462

Thanks for your participation in the electoral process,

Anita and 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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off


On 28/07/16 08:48, Vladimir Kozhukalov wrote:

Fuel-ccp repositories are public, everyone is welcome to participate. I
don’t see where we violate “4 opens”. These repos are now experimental.
At the moment the team is working on building CI pipeline and developing
functional tests that are to be run as a part of CI process. These repos
are not to be a part of Fuel Newton release. From time to time we add
and retire git repos and it is a part of development process. Not all
these repos are to become a part of Big tent.


It seems to me that there are two different interpretations of what it 
means for a repo to be part of the OpenStack tent, and that these 
differing interpretations are at the root of the arguments in this thread.


The first interpretation is that repos listed as belonging to a team in 
the governance repo are part of a deliverable that is released each 
development cycle, and that the same team may also control other repos 
that are not deliverables and hence not part of OpenStack. It's easy to 
see how people could have developed this interpretation in good faith.


The second interpretation is that the TC blesses a team; that the only 
criterion for receiving this blessing is for the project to be "one of 
us", which in practice effectively means following the Four Opens; and 
that all repos which the team intends to operate in this manner, subject 
to TC oversight, should be listed in the governance repo. It's also easy 
to see how people could have developed this interpretation in good 
faith. (In fact, I was following the big tent discussions very closely 
at the time and this was always my understanding of what it meant.)


The only additional thing needed to explain this thread is the 
(incorrect) assumption on behalf of all participants that everyone has 
the same interpretation :)


Assuming everyone holds the first interpretation, the current 
designation of the fuel-ccp repo looks completely logical and the 
complaints about it look like sour grapes.


Assuming everyone holds the second interpretation, the current 
designation of the fuel-ccp repo looks like an attempt to avoid TC 
oversight in order to violate the Four Opens while using the name of an 
official project (and issuing press releases identifying it as part of 
said official project), and the complaints look like a logical attempt 
to defend OpenStack from at least the appearance of openwashing.


I believe this entire controversy will evaporate if the TC can clarify 
what it means for a repository to be listed in the governance repo.


cheers,
Zane.

__
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] [placement] unresolved topics in resource providers/placement api

2016-07-28 Thread Sylvain Bauza

Le 28/07/2016 15:57, Chris Dent a écrit :

I've been reviewing my notes from the mid-cycle and discussions
leading up to it and realized I have a few unresolved or open topics
that I hope discussion here can help resolve:

# fairly straightforward things

* At what stage in the game (of the placement api) do we need to
implement oslo_policy handling and enforcement? Right now the auth
model is simply all-admin-role-all-the-time.

LGTM for Newton to keep that simple logic given that only Nova will call
out the placement API for the moment.

Once we begin opening doors, then yes, oslo.policy will become a thing.

* There was some discussion of adding a configuration setting (e.g.
'placement_connection') that if not None (the default) would be
used as the connection for the placement database. If None, the
API database would be used. I can't recall if we said 'yea' or
'nay' to this idea. The current code uses the api database and its
config.

I thought we agreed on that during the midcycle ?

# less straightforward and further out things

There was some discussion that conflicted with reality a bit and I
think we need to resolve before too long, but shouldn't impact the
newton-based changes:

We bounced around two different HTTP resources for returning one or
several resource providers in response to a launch request:

* POST /allocations

returns a representation of the one target for this launch
request, already claimed

Please, why are you opening this thread now given it's ABSOLUTELY not
related to the placement API ?
That confuses a lot of people here, and we basically had a consensus on
the Newton target : allocations are made by the compute nodes, I don't
see things less than straightforward here.

* GET /resource_providers

returns a list of candidate targets for a launch request, similar
to what the existing select_destinations RPC call can do

The immediate problem here is that something else is already using
GET /resource_providers:

http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html#get-resource-providers

Whatever the URI, it's not clear that GET would be correct here:

* We'll probably want to send a body so GET is not ideal.

* We could pass a reference to a persisted "request spec" as a query
string item, thus maintaining a GET, but that seems to go against
the grain of "give a thing the info it needs to get stuff done" that
is elsewhere in the system.

I'd personally be pretty okay with launch-info-by-reference mode as
it allows the placement API to be in charge of request what version
of a launch request it wants rather than its clients needing to know
what version the placement API might accept.

It's pretty clear that were going to need at least an interim and
maybe permanent endpoint that returns a list of candidate target
resource providers. This is because, at least initially, the
placement engine will not be able to resolve all requirements down
to the one single result and additional filtering may be required in
the caller.

So we had a discussion in Hillsboro about that with no consensus yet, if
you remember.
I heard different opinions on how nova-scheduler would integrate with
the placement API in Ocata, and I was concerned by this service doing an
HTTP call to an external API. My idea was rather to integrate the new
placement tables into the existing HostManager, so that instead of
getting a full list of compute nodes, we would provide to the filters a
list of resource providers matching the query.

The question is: Will that need for additional filtering always be
present and if so do we:

* consider that a bad thing that we should strive to fix by
expanding the powers and size of the placement engine
* consider that a good thing that allows the placement engine to be
relatively simple and keeps edge-case behaviors being handled
elsewhere

If the latter, then we'll have to consider how an allocation/claim
in a list of potential allocations can be essentially reserved,
verified, or rejected.

As an example of expanding the powers, there is the
ResourceProviderTags concept, described in:

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

This will expand the data model of resource providers and the surface
area of the HTTP API. This may very well be entirely warranted, but
there might be other options if we assuming that returning a list is
"normal".

Sorry if this is unclear. I'm rather jet-lagged. Ask questions if
you have them. 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 Development Mailing List (not for usage questions)
Unsubscribe:

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

Thanks for the clarity Doug.

Regards
-steve

On 7/28/16, 8:37 AM, "Doug Hellmann"  wrote:

>Excerpts from Flavio Percoco's message of 2016-07-28 16:43:35 +0200:
>> On 28/07/16 04:45 +, Steven Dake (stdake) wrote:
>> >
>> >
>> >On 7/27/16, 2:12 PM, "Jay Pipes"  wrote:
>> >
>> >>On 07/27/2016 04:42 PM, Ed Leafe wrote:
>> >>> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M 
>>wrote:
>> >>>
>>  Its not an "end user" facing thing, but it is an "operator" facing
>> thing.
>> >>>
>> >>> Well, the end user for Kolla is an operator, no?
>> >>>
>>  I deploy kolla containers today on non kolla managed systems in
>> production, and rely on that api being consistent.
>> 
>>  I'm positive I'm not the only operator doing this either. This
>>sounds
>> like a consumable api to me.
>> >>>
>> >>> I don¹t think that an API has to be RESTful to be considered an
>> >>>interface for we should avoid duplication.
>> >>
>> >>Application *Programming* Interface. There's nothing that is being
>> >>*programmed* or *called* in Kolla's image definitions.
>> >>
>> >>What Kolla is/has is not an API. As Stephen said, it's more of an
>> >>Application Binary Interface (ABI). It's not really an ABI, though, in
>> >>the traditional sense of the term that I'm used to.
>> >>
>> >>It's an agreed set of package bases, installation
>>procedures/directories
>> >>and configuration recipes for OpenStack and infrastructure components.
>> >
>> >Jay,
>> >
>> >From my perspective, this isn't about ABI proliferation or competition.
>> >This is about open public discourse.
>> >
>> >It is the responsibility of all community members to protect the four
>> >opens.
>> >
>> >Given the intent of fuel-ccp to fully adopt K8S into Fuel described
>>here:
>> 
>>>https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-
>>>top
>> >-of-kubernetes/
>> >
>> >
>> >It is hard to understand the arguments in the reviews related to "this
>>is
>> >an experimental project, so its not targeted towards big tent" yet
>>Boris
>> >wrote in that press release its Fuel's next big thing.
>> >
>> >I raised the objection early on that a mission statement change was
>>needed
>> >by Fuel if they wanted to proceed down this path, to which I was told
>>K8S
>> >support is not going into big tent.
>> >
>> >As a result of Mirantis's change in mind about fuel-ccp being NOT
>> >experimental and being targeted for big tent, I'd like the record set
>> >straight in the governance repository since the intentions are being
>> >published in the press and the current intentions of this project are
>> >public.
>> 
>> If I can be honest, I think this whole thread is not going anywhere
>>because it
>> just started based on the wrong assumption, the wrong tone and with poor
>> wording. I'd have asked for clarifications before demanding changes
>>from anyone.
>> To me, the way this thread started violates one of principles of our
>>community,
>> which is assuming good faith. I'll assume good faith now and interpret
>>this
>> thread as a hope to clarify the goals and intentions of this projects
>>and not as
>> a way to bluntly point fingers, which is how some people might have
>>perceived
>> it.
>
>+1
>
>I'm not sure how/why this escalated so quickly. It seems there's some
>history between these teams, though. If Kevin's summary of the issues on
>the universal containers spec is correct, it seems like there's room for
>compromise. That said, I agree with Russell and Flavio that there's also
>plenty of room for different implementations in the deployment space,
>whether are part of the big tent or not.
>
>> 
>> >I could see how people could perceive many violations of the four
>>opens in
>> >all of the activities related to the fuel-ccp project.  We as a
>>community
>> >value open discourse because we are all intelligent human beings.  We
>> >value honesty and integrity because trust is the foundation of how our
>> >community operates.  I feel the best way for Fuel to repair the
>>perceived
>> >violations of the four opens going forward is to:
>> 
>> I honestly don't see the violation. The fuel team added these repos and
>> explicitly said they are not planning to join the tent right now.
>>Adding new
>> repos called `fuel-blah` won't make those deliverables official.
>>Whenever the
>> team decides to make these deliverables part of Fuel, they'll have to
>>send a
>> patch to the governance repo.
>> 
>> So, again, where's the lack of openess? Is it just based on the content
>>of the
>> press release? I'm mostly asking because I don't personally read press
>>releases
>> when reviewing patches for the governance repo. I do see the
>>inconsistency
>> between the press release and what's in the repos/reviews but I in
>>those cases,
>> the governance repository is the source of truth not the press release.
>
>Please oh please, let's not start down the path of being driven to
>assert that any contributor is being

Re: [openstack-dev] [puppet] Propose Sofer Athlan-Guyot (chem) part of Puppet OpenStack core

2016-07-28 Thread Ivan Berezovskiy

+1, good job!

2016-07-28 18:50 GMT+03:00 Matt Fischer :

> +1 from me!
>
> On Jul 28, 2016 9:20 AM, "Emilien Macchi"  wrote:
>
>> You might not know who Sofer is but he's actually "chem" on IRC.
>> He's the guy who will find the root cause of insane bugs, in OpenStack
>> in general but also in Puppet OpenStack modules.
>> Sofer has been working on Puppet OpenStack modules for a while now,
>> and is already core in puppet-keystone. Many times he brought his
>> expertise to make our modules better.
>> He's always here on IRC to help folks and has excellent understanding
>> at how our project works.
>>
>> If you want stats:
>> http://stackalytics.com/?user_id=sofer-athlan-guyot=commits
>> I'm quite sure Sofer will make more reviews over the time but I have
>> no doubt he fully deserves to be part of core reviewers now, with his
>> technical experience and involvement.
>>
>> As usual, it's an open decision, please vote +1/-1 about this proposal.
>>
>> Thanks,
>> --
>> 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
>
>


-- 
Thanks, Ivan Berezovskiy
MOS Puppet Team Lead
at Mirantis 

slack: iberezovskiy
skype: bouhforever
phone: + 7-960-343-42-46
__
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] [Openstack] Listing of volume fails while using openstack client

2016-07-28 Thread varun bhatnagar

Hi,

Thanks for the answer.

Just to be clear

are you asking me to set the value of max_connections to 5000 in mysql conf?
If yes then for me it is set to 8192 alreadyor have I misunderstood
your suggestion?

BR,
Varun

On Thu, Jul 28, 2016 at 5:35 PM, Turbo Fredriksson  wrote:

> On Jul 28, 2016, at 1:57 PM, varun bhatnagar wrote:
>
> > I am trying to list volumes using openstack client, the command works
> > sometimes but sometimes it fails:
>
>
> I get that when my MySQL server "max_connections" is reached.
> I've bumped it to 5000 to be absolutly sure!
>
> SET GLOBAL max_connections = 5000;
>
> For some reason, the
>
> max_connections = 5000
>
> in the config file doesn't take between reboots :(. Haven't had
> time or interest to investigate further.
> --
> As soon as you find a product that you really like,
> they will stop making it.
> - Wilson's Law
>
>
> __
> 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] [placement] unresolved topics in resource providers/placement api

2016-07-28 Thread Dan Smith

> No. POST /allocations/{consumer_uuid} is the thing that the resource
> tracker calls for the claim on the compute node.
> 
> The POST /allocations is something we've been throwing around ideas on
> for an eventual call that the placement engine would expose for "claims
> in the scheduler".

Right, okay just wanted to make sure we weren't including /allocations/*
in the statement about Ocata.

So then yeah, I think I agree with all that.

--Dan

__
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] [placement] unresolved topics in resource providers/placement api

2016-07-28 Thread Ed Leafe

On Jul 28, 2016, at 9:47 AM, Roman Podoliaka  wrote:

> How about we do a query in two steps:
> 
> 1) take a list of compute nodes (== resource providers) and apply all
> the filters which *can not* (or *are not* at some point) be
> implemented in placement-api
> 
> 2) POST a launch request passing the *pre-filtered* list of resource
> providers.  placement api will pick one of those RP, *claim* its
> resources and return the claim info
> 
> A similar approach could probably be used for assigning weights to RPs
> when we pass the list of RPs to placement api.

That is very similar to the approach I proposed for the live migration API 
change to accommodate the needs of Watcher: provide a list of potential hosts, 
and have the scheduler select one from that list. Rather than muck with an 
existing API, we decided to postpone supporting that until the placement API 
was available. I think that providing a subset of all resource providers to the 
placement API to limit the potential results is an important addition, 
especially with the eventual thought of having this be a generic placement API 
for all sorts of resources.

-- Ed Leafe

__
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] [puppet] Propose Sofer Athlan-Guyot (chem) part of Puppet OpenStack core

2016-07-28 Thread Matt Fischer

+1 from me!

On Jul 28, 2016 9:20 AM, "Emilien Macchi"  wrote:

> You might not know who Sofer is but he's actually "chem" on IRC.
> He's the guy who will find the root cause of insane bugs, in OpenStack
> in general but also in Puppet OpenStack modules.
> Sofer has been working on Puppet OpenStack modules for a while now,
> and is already core in puppet-keystone. Many times he brought his
> expertise to make our modules better.
> He's always here on IRC to help folks and has excellent understanding
> at how our project works.
>
> If you want stats:
> http://stackalytics.com/?user_id=sofer-athlan-guyot=commits
> I'm quite sure Sofer will make more reviews over the time but I have
> no doubt he fully deserves to be part of core reviewers now, with his
> technical experience and involvement.
>
> As usual, it's an open decision, please vote +1/-1 about this proposal.
>
> Thanks,
> --
> 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

Re: [openstack-dev] [nova] [placement] unresolved topics in resource providers/placement api


On 07/28/2016 11:19 AM, Dan Smith wrote:

There was some discussion that conflicted with reality a bit and I
think we need to resolve before too long, but shouldn't impact the
newton-based changes:

We bounced around two different HTTP resources for returning one or
several resource providers in response to a launch request:

* POST /allocations

  returns a representation of the one target for this launch
  request, already claimed


This will be in Ocata.


We _do_ need the resource tracker to be reporting allocations to the
placement service in Newton in order to allow the following call (GET
/resource_providers) to work. Is this POST that thing or a different thing?


No. POST /allocations/{consumer_uuid} is the thing that the resource 
tracker calls for the claim on the compute node.


The POST /allocations is something we've been throwing around ideas on 
for an eventual call that the placement engine would expose for "claims 
in the scheduler".


Best,
-jay

__
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-28 Thread Emilien Macchi

I hope you liked the presentation, despite of my terrible french accent :-)

The recording is now available on Youtube:
https://www.youtube.com/watch?v=AZO_6UaLLaU
The slides: 
https://docs.google.com/presentation/d/1c3dBboSc8pixAN2yYBnFfoDX8HDab7lxWDd_DMB7-Jc/

Please let me know if you want me to propose another session, on a
specific topic in Puppet, maybe with more details etc.
Also feel free to contact me for any question related to the
presentation, on IRC or by email.

Thanks,

On Tue, Jul 26, 2016 at 8:56 AM, Emilien Macchi  wrote:
> 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



-- 
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

Excerpts from Flavio Percoco's message of 2016-07-28 16:43:35 +0200:
> On 28/07/16 04:45 +, Steven Dake (stdake) wrote:
> >
> >
> >On 7/27/16, 2:12 PM, "Jay Pipes"  wrote:
> >
> >>On 07/27/2016 04:42 PM, Ed Leafe wrote:
> >>> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M  wrote:
> >>>
>  Its not an "end user" facing thing, but it is an "operator" facing
> thing.
> >>>
> >>> Well, the end user for Kolla is an operator, no?
> >>>
>  I deploy kolla containers today on non kolla managed systems in
> production, and rely on that api being consistent.
> 
>  I'm positive I'm not the only operator doing this either. This sounds
> like a consumable api to me.
> >>>
> >>> I don¹t think that an API has to be RESTful to be considered an
> >>>interface for we should avoid duplication.
> >>
> >>Application *Programming* Interface. There's nothing that is being
> >>*programmed* or *called* in Kolla's image definitions.
> >>
> >>What Kolla is/has is not an API. As Stephen said, it's more of an
> >>Application Binary Interface (ABI). It's not really an ABI, though, in
> >>the traditional sense of the term that I'm used to.
> >>
> >>It's an agreed set of package bases, installation procedures/directories
> >>and configuration recipes for OpenStack and infrastructure components.
> >
> >Jay,
> >
> >From my perspective, this isn't about ABI proliferation or competition.
> >This is about open public discourse.
> >
> >It is the responsibility of all community members to protect the four
> >opens.
> >
> >Given the intent of fuel-ccp to fully adopt K8S into Fuel described here:
> >https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top
> >-of-kubernetes/
> >
> >
> >It is hard to understand the arguments in the reviews related to "this is
> >an experimental project, so its not targeted towards big tent" yet Boris
> >wrote in that press release its Fuel's next big thing.
> >
> >I raised the objection early on that a mission statement change was needed
> >by Fuel if they wanted to proceed down this path, to which I was told K8S
> >support is not going into big tent.
> >
> >As a result of Mirantis's change in mind about fuel-ccp being NOT
> >experimental and being targeted for big tent, I'd like the record set
> >straight in the governance repository since the intentions are being
> >published in the press and the current intentions of this project are
> >public.
> 
> If I can be honest, I think this whole thread is not going anywhere because it
> just started based on the wrong assumption, the wrong tone and with poor
> wording. I'd have asked for clarifications before demanding changes from 
> anyone.
> To me, the way this thread started violates one of principles of our 
> community,
> which is assuming good faith. I'll assume good faith now and interpret this
> thread as a hope to clarify the goals and intentions of this projects and not 
> as
> a way to bluntly point fingers, which is how some people might have perceived
> it.

+1

I'm not sure how/why this escalated so quickly. It seems there's some
history between these teams, though. If Kevin's summary of the issues on
the universal containers spec is correct, it seems like there's room for
compromise. That said, I agree with Russell and Flavio that there's also
plenty of room for different implementations in the deployment space,
whether are part of the big tent or not.

> 
> >I could see how people could perceive many violations of the four opens in
> >all of the activities related to the fuel-ccp project.  We as a community
> >value open discourse because we are all intelligent human beings.  We
> >value honesty and integrity because trust is the foundation of how our
> >community operates.  I feel the best way for Fuel to repair the perceived
> >violations of the four opens going forward is to:
> 
> I honestly don't see the violation. The fuel team added these repos and
> explicitly said they are not planning to join the tent right now. Adding new
> repos called `fuel-blah` won't make those deliverables official. Whenever the
> team decides to make these deliverables part of Fuel, they'll have to send a
> patch to the governance repo.
> 
> So, again, where's the lack of openess? Is it just based on the content of the
> press release? I'm mostly asking because I don't personally read press 
> releases
> when reviewing patches for the governance repo. I do see the inconsistency
> between the press release and what's in the repos/reviews but I in those 
> cases,
> the governance repository is the source of truth not the press release.

Please oh please, let's not start down the path of being driven to
assert that any contributor is being dishonest or lacks integrity
because of the content of press releases.

> 
> >1. Alter the mission statement of fuel to match the reality being
> >published by the press and Mirantis's executive team

I don't think the mission statement needs to change to

Re: [openstack-dev] [Cinder] Pending removal of X-IO volume driver

2016-07-28 Thread Hedlind, Richard

Hi Sean,
Thanks for the heads up. I have been busy on other projects and not been 
involved in maintaining the CI. I will look into it and get it back up and 
running.
I will keep you posted on the progress.

Thanks,
Richard

-Original Message-
From: Sean McGinnis [mailto:sean.mcgin...@gmx.com] 
Sent: Wednesday, July 27, 2016 2:26 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Cinder] Pending removal of X-IO volume driver

The Cinder policy for driver CI requires that all volume drivers have a CI 
reporting on any new patchset. CI's may have some down time, but if they do not 
report within a two week period they are considered out of compliance with our 
policy.

This is a notification that the X-IO OpenStack CI is out of compliance.
It has not reported since March 18th, 2016.

The patch for driver removal has been posted here:

https://review.openstack.org/348022

If this CI is not brought into compliance, the patch to remove the driver will 
be approved one week from now.

Thanks,
Sean McGinnis (smcginnis)


__
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] [Openstack] Listing of volume fails while using openstack client

2016-07-28 Thread Turbo Fredriksson

On Jul 28, 2016, at 1:57 PM, varun bhatnagar wrote:

> I am trying to list volumes using openstack client, the command works
> sometimes but sometimes it fails:


I get that when my MySQL server "max_connections" is reached.
I've bumped it to 5000 to be absolutly sure!

SET GLOBAL max_connections = 5000;

For some reason, the

max_connections = 5000

in the config file doesn't take between reboots :(. Haven't had
time or interest to investigate further.
--
As soon as you find a product that you really like,
they will stop making it.
- Wilson's Law


__
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] [puppet] Propose Sofer Athlan-Guyot (chem) part of Puppet OpenStack core

2016-07-28 Thread Iury Gregory

I'm not a core, but +1 to chem, awesome work!

2016-07-28 12:18 GMT-03:00 Alex Schultz :

> +1
>
> On Thu, Jul 28, 2016 at 9:16 AM, Emilien Macchi 
> wrote:
> > You might not know who Sofer is but he's actually "chem" on IRC.
> > He's the guy who will find the root cause of insane bugs, in OpenStack
> > in general but also in Puppet OpenStack modules.
> > Sofer has been working on Puppet OpenStack modules for a while now,
> > and is already core in puppet-keystone. Many times he brought his
> > expertise to make our modules better.
> > He's always here on IRC to help folks and has excellent understanding
> > at how our project works.
> >
> > If you want stats:
> > http://stackalytics.com/?user_id=sofer-athlan-guyot=commits
> > I'm quite sure Sofer will make more reviews over the time but I have
> > no doubt he fully deserves to be part of core reviewers now, with his
> > technical experience and involvement.
> >
> > As usual, it's an open decision, please vote +1/-1 about this proposal.
> >
> > Thanks,
> > --
> > 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
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@gmail.com *
~
__
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] [fuel] Meeting for today 7/28 is caneled

2016-07-28 Thread Andrew Woodward

The meeting agenda is empty for this week's meeting is empty so I'm calling
it on the meeting.

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
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-28 Thread Sergey Lukjanov

Hi folks,

First of all, let me say that it’s a marketing announcement and as all of
you know such announcements aren’t precise from a technical side.
Personally I’ve seen this paper first time on TechCrunch.

First of all, fuel-ccp-* are a set of OpenStack projects and everyone is
welcome to participate. All the regular community process(es) for other
openstack projects apply to fuel-ccp-*. At the moment, in spite of what the
marketing announcements say, it’s a bunch of people from Mirantis working
on the repositories. Please think of this as an incubation process to try
and see what the next incarnation of Fuel would look like in the future.

Regardless of what was written, we aren’t applying to the Big Tent right
now (as it was initially said explicitly when we were creating repos and
it’s still valid). The state of the repos is still experimental, but I’d
like to make things clear and confirm that Mirantis has chosen to use
containers for infrastructure and OpenStack components and to use
Kubernetes as the orchestrator of those containers. In the future, the Fuel
OpenStack installer will use these containerized OpenStack/infrastructure
component images. There are many questions to be solved and things to be
done first in Fuel CCP, such as:

* Freeze technologies and approaches, such as repos structure, image
layers, etc.
* Cleanup deprecated PoC stuff from the code
* Implement basic test coverage for all parts of the project
* Create Release Management approach
* Consume OpenStack CI to run tests
* Fully implement 3rd party CI (with end-to-end integration tests only)
* Make at least initial documentation and ensure that it’s deployable using
this doc

and etc. In general, I would not expect us to seriously consider applying
to the Big Tent for another 5-6 months at the earliest.

Regarding the Fuel mission, that is:

To streamline and accelerate the process of deploying, testing and
maintaining various configurations of OpenStack at scale.

I think that it’s 100% aligned with that we’re doing in Fuel CCP.

About the Kolla usage in Fuel CCP, I agree with Kevin and we can see in
future that Fuel CCP will be potentially using Kolla containers, it’ll
require some time anyway, but it doesn’t mean that we stop considering it.
And as Kevin correctly noticed, we did it already one time with Fuel
adopting upstream Puppet modules and contributing actively to them.

Thanks.

On Thu, Jul 28, 2016 at 7:43 AM, Flavio Percoco  wrote:

> On 28/07/16 04:45 +, Steven Dake (stdake) wrote:
>
>>
>>
>> On 7/27/16, 2:12 PM, "Jay Pipes"  wrote:
>>
>> On 07/27/2016 04:42 PM, Ed Leafe wrote:
>>>
 On Jul 27, 2016, at 2:42 PM, Fox, Kevin M  wrote:

 Its not an "end user" facing thing, but it is an "operator" facing
> thing.
>

 Well, the end user for Kolla is an operator, no?

 I deploy kolla containers today on non kolla managed systems in
> production, and rely on that api being consistent.
>
> I'm positive I'm not the only operator doing this either. This sounds
> like a consumable api to me.
>

 I don¹t think that an API has to be RESTful to be considered an
 interface for we should avoid duplication.

>>>
>>> Application *Programming* Interface. There's nothing that is being
>>> *programmed* or *called* in Kolla's image definitions.
>>>
>>> What Kolla is/has is not an API. As Stephen said, it's more of an
>>> Application Binary Interface (ABI). It's not really an ABI, though, in
>>> the traditional sense of the term that I'm used to.
>>>
>>> It's an agreed set of package bases, installation procedures/directories
>>> and configuration recipes for OpenStack and infrastructure components.
>>>
>>
>> Jay,
>>
>> From my perspective, this isn't about ABI proliferation or competition.
>> This is about open public discourse.
>>
>> It is the responsibility of all community members to protect the four
>> opens.
>>
>> Given the intent of fuel-ccp to fully adopt K8S into Fuel described here:
>>
>> https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top
>> -of-kubernetes/
>>
>>
>> It is hard to understand the arguments in the reviews related to "this is
>> an experimental project, so its not targeted towards big tent" yet Boris
>> wrote in that press release its Fuel's next big thing.
>>
>> I raised the objection early on that a mission statement change was needed
>> by Fuel if they wanted to proceed down this path, to which I was told K8S
>> support is not going into big tent.
>>
>> As a result of Mirantis's change in mind about fuel-ccp being NOT
>> experimental and being targeted for big tent, I'd like the record set
>> straight in the governance repository since the intentions are being
>> published in the press and the current intentions of this project are
>> public.
>>
>
> If I can be honest, I think this whole thread is not going anywhere
> because it
> just started based

Re: [openstack-dev] [nova] [placement] unresolved topics in resource providers/placement api

2016-07-28 Thread Dan Smith

>> There was some discussion that conflicted with reality a bit and I
>> think we need to resolve before too long, but shouldn't impact the
>> newton-based changes:
>>
>> We bounced around two different HTTP resources for returning one or
>> several resource providers in response to a launch request:
>>
>> * POST /allocations
>>
>>   returns a representation of the one target for this launch
>>   request, already claimed
> 
> This will be in Ocata.

We _do_ need the resource tracker to be reporting allocations to the
placement service in Newton in order to allow the following call (GET
/resource_providers) to work. Is this POST that thing or a different thing?

--Dan

__
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] [puppet] Propose Sofer Athlan-Guyot (chem) part of Puppet OpenStack core

2016-07-28 Thread Emilien Macchi

You might not know who Sofer is but he's actually "chem" on IRC.
He's the guy who will find the root cause of insane bugs, in OpenStack
in general but also in Puppet OpenStack modules.
Sofer has been working on Puppet OpenStack modules for a while now,
and is already core in puppet-keystone. Many times he brought his
expertise to make our modules better.
He's always here on IRC to help folks and has excellent understanding
at how our project works.

If you want stats:
http://stackalytics.com/?user_id=sofer-athlan-guyot=commits
I'm quite sure Sofer will make more reviews over the time but I have
no doubt he fully deserves to be part of core reviewers now, with his
technical experience and involvement.

As usual, it's an open decision, please vote +1/-1 about this proposal.

Thanks,
-- 
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] [puppet] Propose Sofer Athlan-Guyot (chem) part of Puppet OpenStack core

2016-07-28 Thread Alex Schultz

+1

On Thu, Jul 28, 2016 at 9:16 AM, Emilien Macchi  wrote:
> You might not know who Sofer is but he's actually "chem" on IRC.
> He's the guy who will find the root cause of insane bugs, in OpenStack
> in general but also in Puppet OpenStack modules.
> Sofer has been working on Puppet OpenStack modules for a while now,
> and is already core in puppet-keystone. Many times he brought his
> expertise to make our modules better.
> He's always here on IRC to help folks and has excellent understanding
> at how our project works.
>
> If you want stats:
> http://stackalytics.com/?user_id=sofer-athlan-guyot=commits
> I'm quite sure Sofer will make more reviews over the time but I have
> no doubt he fully deserves to be part of core reviewers now, with his
> technical experience and involvement.
>
> As usual, it's an open decision, please vote +1/-1 about this proposal.
>
> Thanks,
> --
> 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

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

2016-07-28 Thread Flavio Percoco


On 28/07/16 13:56 +, Fox, Kevin M wrote:

I really see 3 issues raised in the spec mentioned that have any disagreement 
as far as I can tell.

1. mirantis would like to see kolla-ansible split from the base kolla repo. 
This has a lot of support and is likely to come up for a final vote soon. It 
was postponed due to not wanting to split in the middle of a cycle. - This does 
not seem like a good reason at this point to spawn a new project. I support the 
split.


Not just mirantis. *I* would love to see kolla-ansible split (and I'd also love
to be able to do `pip install kolla-build, but I digress).


2. mirantis would like to see repos split for each docker container definition 
to be one per container. This is purely a management style difference. Split or 
combined both has advantages, and at present scaling issues have not been hit, 
so change has a cost that doesn't yet have a significant benefit. If it started 
to be, I'm sure it would be re-evaluated. This does not seem like a good reason 
at this point to spawn a new project. I think splitting seems unnecessary at 
this point, but if the whole thing comes down to this one issue, I'd support 
splitting the repos just so we don't duplicate so much work over such a minor 
thing.

3. Some bootstrap logic in some of the containers. mirantis would like to see 
it gone. Its completely optional (just don't set the BOOTSTRAP env vars) and 
needs to stay for api backwards compatibility in existing containers. It does 
not have to be used by deployment tools that don't wish to use it. This does 
not seem like a good reason at this point to spawn a new project. I support 
keeping it to not break things as its optional.

Are these really that contentious that we have to split a community over? Can 
we get both sides to give in a little and help each other out?

Maybe something like:
1. kolla commits to split out kolla-ansible as soon as possible (right after 
newton tagged)
2. Some middle ground here. Maybe its keep as is, but come up with a formal 
procedure for re-evaluating when it becomes painful and make a change. (Seems 
similar to the fuel/puppet repo upstreaming thing, in a way. Maybe some of the 
same process could work here? Some time to review metrics?)
3. We keep the optional stuff so we don't break existing deployments.

Is this reasonable?


This is definitely a better way to encourage collaboration on this topic, which
I happen to be interested into as well. :D

Flavio



Thanks,
Kevin

From: Vladimir Kozhukalov [vkozhuka...@mirantis.com]
Sent: Thursday, July 28, 2016 5:48 AM
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



1. Alter the mission statement of fuel to match the reality being



published by the press and Mirantis's executive team



2. Include these non-experimental repos in the projects.yaml governance



Repository



Frankly, I don’t understand what part of the press release contradicts with 
Fuel mission.

Current Fuel mission is “To streamline and accelerate the process of deploying, 
testing and maintaining various configurations of OpenStack at scale.” which 
means we are not bound to any specific technology when deploying OpenStack.


At the moment Fuel deploys RPM/DEB packages using Puppet and Fuel specific 
orchestration mechanism. We are not going to drop this approach immediately, it 
works quite well and we are working hard to make things better (including 
ability to upgrade). But we also keep in mind that technologies are constantly 
changing and we’d like to benefit of this progress. That is why we are now 
looking at Docker containers and Kubernetes. Our users know that it is not our 
first experience of trying to use containers. Fuel releases prior to 9.0 used 
to deploy Fuel services in containers on the Fuel admin node.


Many of you know how difficult it is to upgrade OpenStack clusters. We hope 
that containers could help us to solve not all but some of problems that we 
encounter when upgrading cluster. Maintaining and hence upgrade of OpenStack 
clusters is a part of Fuel mission and we are just trying to find a way how to 
do things.


Why not Kolla but Fuel-ccp? It is not a secret that Fuel is driven by Mirantis. 
At Mirantis we deploy and maintain OpenStack. In attempts to find a way how to 
make OpenStack easily maintainable, some of Mirantis folks spent some time to 
contribute to Kolla and Mesos. But there were some concerns that were discussed 
several times (including this Kolla spec 
https://review.openstack.org/#/c/330575) that would make it not so easy to use 
Kolla containers for our use cases. Fuel-ccp is just an attempt to address 
these concerns. Frankly, I don’t see anything bad in having more than one set 
of container images (like we have more than one set of RPM/DEB distributions).


Those concerns are, for example,

Re: [openstack-dev] [nova] [infra] Intel NFV CI voting permission

On 7/21/2016 5:38 AM, Znoinski, Waldemar wrote:

Hi Nova cores et al,

I would like to acquire voting (+/-1 Verified) permission for our Intel
NFV CI.

1. It’s running since Q1’2015.

2. Wiki [1].

3. It’s using openstack-infra/puppet-openstackci
with Zuul 2.1.1
for last 4 months: zuul, gearman, Jenkins, nodepool, local Openstack cloud.

4. We have a team of 2 people + me + Nagios looking after it. Its
problems are fixed promptly and rechecks triggered after non-code
related issues. It’s being reconciled against ci-watch [2].

5. Reviews [3].

Let me know if further questions.

1. https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI

2. http://ci-watch.tintri.com/project?project=nova

3.
https://review.openstack.org/#/q/reviewer:%22Intel+NFV-CI+%253Copenstack-nfv-ci%2540intel.com%253E%22

*Waldek*

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution by
others is strictly prohibited. If you are not the intended recipient,
please contact the sender and delete all copies.

We talked about this in the nova meeting today. I don't have a great
grasp on how the Intel NFV CI has been performing, but making it voting
will help with that. Looking at the 7 day results:

http://ci-watch.tintri.com/project?project=nova=7+days

Everything looks pretty good except for
tempest-dsvm-ovsdpdk-nfv-networking but Waldemar pointed out there was a
change in devstack that broke the CI for a day or so:

https://github.com/openstack-dev/devstack/commit/130a11f8aaf08ea529b6ce60dd9052451cb7bb5c

I would like to know a little more about why we don't run the Intel NFV
CI on devstack changes to catch stuff like this before it becomes a
breaking problem? The team worked around it for now, but it is a concern
of mine. I think at least the Xen and PowerKVM CIs also run on devstack
changes to avoid problems like this.

So please give me some details on running against devstack changes and
then I'll ack or nack the request.

Thanks,

Matt Riedemann

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

2016-07-28 Thread Russell Bryant

On Thu, Jul 28, 2016 at 10:52 AM, Flavio Percoco  wrote:

> On 28/07/16 15:48 +0300, Vladimir Kozhukalov wrote:
>
>> 1. Alter the mission statement of fuel to match the reality being
>>>
>>
>> published by the press and Mirantis's executive team
>>>
>>
>> 2. Include these non-experimental repos in the projects.yaml governance
>>>
>>
>> Repository
>>>
>>
>> Frankly, I don’t understand what part of the press release contradicts
>> with
>> Fuel mission.
>>
>> Current Fuel mission is “To streamline and accelerate the process of
>> deploying, testing and maintaining various configurations of OpenStack at
>> scale.” which means we are not bound to any specific technology when
>> deploying OpenStack.
>>
>
> TBH, I also think this statement is broad enough to cover containers.
> Unless the
> request is to explicitly mention "containers" in the mission statement, I
> think
> there's no need to change it. I'd also be against having "containers" being
> explicitly mentioned in Fuel's statement, FWIW. I don't think it'd be of
> any
> benefit/use. Unless I'm missing something fundamental here, of course.


I agree that the current mission statement seems fine.


>
> At the moment Fuel deploys RPM/DEB packages using Puppet and Fuel specific
>> orchestration mechanism. We are not going to drop this approach
>> immediately, it works quite well and we are working hard to make things
>> better (including ability to upgrade). But we also keep in mind that
>> technologies are constantly changing and we’d like to benefit of this
>> progress. That is why we are now looking at Docker containers and
>> Kubernetes. Our users know that it is not our first experience of trying
>> to
>> use containers. Fuel releases prior to 9.0 used to deploy Fuel services in
>> containers on the Fuel admin node.
>>
>> Many of you know how difficult it is to upgrade OpenStack clusters. We
>> hope
>> that containers could help us to solve not all but some of problems that
>> we
>> encounter when upgrading cluster. Maintaining and hence upgrade of
>> OpenStack clusters is a part of Fuel mission and we are just trying to
>> find
>> a way how to do things.
>>
>> Why not Kolla but Fuel-ccp? It is not a secret that Fuel is driven by
>> Mirantis. At Mirantis we deploy and maintain OpenStack. In attempts to
>> find
>> a way how to make OpenStack easily maintainable, some of Mirantis folks
>> spent some time to contribute to Kolla and Mesos. But there were some
>> concerns that were discussed several times (including this Kolla spec
>> https://review.openstack.org/#/c/330575) that would make it not so easy
>> to
>> use Kolla containers for our use cases. Fuel-ccp is just an attempt to
>> address these concerns. Frankly, I don’t see anything bad in having more
>> than one set of container images (like we have more than one set of
>> RPM/DEB
>> distributions).
>>
>
> ++
>

I think the project seems fine.  They are clearly aware of Kolla.  If they
don't want to use it (for whatever the reason), I don't think it matters.
OpenStack deployment is far from a well solved problem.  We have plenty of
overlapping deployment related projects and I'm happy to see that
continue.  Ongoing experimentation with different approaches is a good
thing here.

To summarize, I see all actions taken so far by the Fuel team as fine.  I
see no need to change anything in governance.  They are free to add it as
an official deliverable if and when they choose to do so.  Even if they
have a vision of these things becoming official and supported in the
future, that does not mean they must mark them that way today.

-- 
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][db][models]

2016-07-28 Thread Henry Gessau

Ihar Hrachyshka  wrote:
> Manjeet S  wrote:
> 
>> Hello Team,
>>
>> I have a question regarding centralizing all db models in neutron. As you  
>> all know
>> Oslo versioned object work is under progress and I also had a ticket  
>> opened for refactoring
>> Db models. (https://bugs.launchpad.net/neutron/+bug/1597913). There are  
>> three way I can do this,
>> 1, move all models to db/models_v2.py 2, create a new dir db/models/ and  
>> move whatever models are giving issue
>> Of cyclic import to db_models.py under db/models/ tree but all in same  
>> file, 3rd is move into different files under
>> Same tree db/models. I liked second way better, please let me know which  
>> one according to experienced developers
>> is better, I’ll do that way.
> 
> I don’t think 2. is the best way forward because it still keeps all models  
> in a single file with no classification. I prefer we split models by topic,  
> so option 3.
> 
> I took the approach for security groups here:  
> https://review.openstack.org/#/c/284738/49/neutron/db/models/securitygroup.py

I also prefer this organization (option 3).


__
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] FPGA as a dynamic nested resources