Re: [openstack-dev] [mistral] Promoting Dawid Deja to core reviewers

[Renat Akhmerov]

Team, thank you for your support!

Dawid, welcome to the Mistral core team :)

You now can vote +2 and approve patches. Use them wisely!

Renat Akhmerov
@Nokia

> On 01 Aug 2016, at 10:59, Hardik  wrote:
> 
> +1 , Nice work Dawid !
> 
> Thanks and Regards,
> Hardik Parekh
> 
> On Sunday 31 July 2016 06:56 AM, Lingxian Kong wrote:
>> +1, good job, Dawid!
>> 
>> Regards!
>> ---
>> Lingxian Kong
>> 
>> 
>> On Sat, Jul 30, 2016 at 10:59 PM, Elisha, Moshe (Nokia - IL)
>>  wrote:
>>> Hi,
>>> 
>>> I am not a core reviewer but having met Dawid in person and working closely
>>> with him on some important bug fixes – I fully support the idea.
>>> 
>>> From: Anastasia Kuznetsova 
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Date: Friday, 29 July 2016 at 15:53
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Subject: Re: [openstack-dev] [mistral] Promoting Dawid Deja to core
>>> reviewers
>>> 
>>> Renat,
>>> 
>>> I fully support Dawid's promotion! Here is my +1 for Dawid.
>>> 
>>> Dawid,
>>> 
>>> I will be glad to see you in the Mistral core team.
>>> 
>>> On Fri, Jul 29, 2016 at 2:39 PM, Renat Akhmerov 
>>> wrote:
 Hi,
 
 I’d like to promote Dawid Deja working at Intel (ddeja in IRC) to Mistral
 core reviewers.
 
 The reasons why I want to see Dawid in the core team is that he provides
 amazing, very thorough reviews.
 Just by looking at a few of them I was able to make a conclusion that he
 knows the system architecture very well
 although he started contributing actively not so long ago. He always sees
 things deeply, can examine a problem
 from different angles, demonstrates solid technical background in general.
 He is in top 5 reviewers now by a number
 of reviews and the only one who still doesn’t have core status. He also
 implemented several very important changes
 during Newton cycle. Some of them were in progress for more than a year
 (flexible RPC) but Dawid helped to knock
 them down elegantly.
 
 Besides purely professional skills that I just mentioned I also want to
 say that it’s a great pleasure to work with
 Dawid. He’s a bright cheerful guy and a good team player.
 
 Dawid’s statistics is here:
 http://stackalytics.com/?module=mistral-group=commits_id=dawid-deja-0
 
 
 I’m hoping for your support in making this promotion.
 
 Thanks
 
 Renat Akhmerov
 @Nokia
 
 
 __
 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,
>>> Anastasia Kuznetsova
>>> 
>>> __
>>> 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] [mistral] Promoting Dawid Deja to core reviewers

[Hardik]

+1 , Nice work Dawid !

Thanks and Regards,
Hardik Parekh

On Sunday 31 July 2016 06:56 AM, Lingxian Kong wrote:

+1, good job, Dawid!

Regards!
---
Lingxian Kong


On Sat, Jul 30, 2016 at 10:59 PM, Elisha, Moshe (Nokia - IL)
 wrote:

Hi,

I am not a core reviewer but having met Dawid in person and working closely
with him on some important bug fixes – I fully support the idea.

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

Date: Friday, 29 July 2016 at 15:53
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] [mistral] Promoting Dawid Deja to core
reviewers

Renat,

I fully support Dawid's promotion! Here is my +1 for Dawid.

Dawid,

I will be glad to see you in the Mistral core team.

On Fri, Jul 29, 2016 at 2:39 PM, Renat Akhmerov 
wrote:

Hi,

I’d like to promote Dawid Deja working at Intel (ddeja in IRC) to Mistral
core reviewers.

The reasons why I want to see Dawid in the core team is that he provides
amazing, very thorough reviews.
Just by looking at a few of them I was able to make a conclusion that he
knows the system architecture very well
although he started contributing actively not so long ago. He always sees
things deeply, can examine a problem
from different angles, demonstrates solid technical background in general.
He is in top 5 reviewers now by a number
of reviews and the only one who still doesn’t have core status. He also
implemented several very important changes
during Newton cycle. Some of them were in progress for more than a year
(flexible RPC) but Dawid helped to knock
them down elegantly.

Besides purely professional skills that I just mentioned I also want to
say that it’s a great pleasure to work with
Dawid. He’s a bright cheerful guy and a good team player.

Dawid’s statistics is here:
http://stackalytics.com/?module=mistral-group=commits_id=dawid-deja-0


I’m hoping for your support in making this promotion.

Thanks

Renat Akhmerov
@Nokia


__
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,
Anastasia Kuznetsova

__
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] [tripleo] [ironic] Exception registering nodes when Ironic API with apache

[Ryan Brady]

On Sun, Jul 31, 2016 at 7:01 PM, Emilien Macchi  wrote:

> Hi,
>
> On Friday we landed a patch in TripleO to deploy Ironic API in WSGI with
> Apache.
> Since then, our baremetal CI jobs were failing randomly, and a lot of
> time, with an exception.
> I decided to revert the patch to bring our CI back:
> https://review.openstack.org/#/c/349281/ (+2 from slagle).
>
> Ironic experts, please have a look at the bug report:
> https://bugs.launchpad.net/tripleo/+bug/1608252


I hit a similar issue earlier this year when we tried deploying mistral
with apache.  https://bugs.launchpad.net/mistral/+bug/1581649


>
>
> I'll propose to re-activate it so we can debug more of what it fails.
>
> 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
>



-- 
Ryan Brady
Cloud Engineering
rbr...@redhat.com
919.890.8925
__
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] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

[Alex Xu]

2016-07-28 22:31 GMT+08:00 Jay Pipes :

> On 07/20/2016 11:25 PM, Alex Xu wrote:
>
>> One more for end users: Capabilities Discovery API, it should be 'GET
>> /resource_providers/tags'. Or a proxy API from nova to the placement
>> API?
>>
>
> I would imagine that it should be a `GET
> /resource-providers/{uuid}/capabilities` call on the placement API, only
> visible to cloud administrators.
>
>
When the end-user request a capability which doesn't support by the cloud,
the end-user needs to wait for a moment after sent boot request due to we
use async call in nova, then he get an instance with error status. The
error info is no valid host. If this is the only way for user to discover
the capabilities in the cloud, that sounds bad. So we need an API for the
end-user to discover the Capabilities which are supported in the cloud, the
end-user can query this API before send boot request.


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

[Xingchao Yu]

+1 to chem, nice work !

2016-07-31 21:40 GMT+08:00 Sebastien Badia :

> On Thu, Jul 28, 2016 at 11:16:17AM (-0400), 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.
>
> Hi!
>
> I'm not puppet-openstack core anymore, but I already worked with Sofer, and
> I think it's very valuable for the team to have him as core!
>
> Thanks Sofer for all your work and engagement since the beginning!
>
> A big +1 for me!
>
> Seb
>
> --
> Sebastien Badia
>
> __
> 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
>
>


-- 

  Email:   yux...@gmail.com
GitHub:   https://github.com/NewpTone
Blog:http://cnblogs.com/yuxc
 Weibo:   http://www.weibo.com/nupta

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

[openstack-dev] [tripleo] [ironic] Exception registering nodes when Ironic API with apache

[Emilien Macchi]

Hi,

On Friday we landed a patch in TripleO to deploy Ironic API in WSGI with Apache.
Since then, our baremetal CI jobs were failing randomly, and a lot of
time, with an exception.
I decided to revert the patch to bring our CI back:
https://review.openstack.org/#/c/349281/ (+2 from slagle).

Ironic experts, please have a look at the bug report:
https://bugs.launchpad.net/tripleo/+bug/1608252

I'll propose to re-activate it so we can debug more of what it fails.

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-dev] [nova][scheduler] Scheduler subteam meeting Monday at 1400 UTC

[Edward Leafe]

Sorry for the late email, but I was swamped last week after getting back from 
the mid-cycle. The next meeting of the Nova Scheduler subteam will be Monday, 
August 1, at 1400 UTC [0], in #openstack-meeting-alt

I've updated the agenda [1] with the main items; if you have other issues to 
discuss, please add them.

[0] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160801T14
[1] https://wiki.openstack.org/wiki/Meetings/NovaScheduler


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [zaqar] Mascot for Zaqar

[Fei Long Wang]

Hi Team,

Based on the initial proposals on etherpad, we have decided to go for
*Nightingale *or***Carrier Pigeon*, and we can use either of them which
is confirmed by Foundation. So let's do a final vote on
https://etherpad.openstack.org/p/zaqar-project-mascot Thanks for all
your support.

On 15/07/16 11:30, Fei Long Wang wrote:
> Not sure why the URL is wrong. Please use this
> https://etherpad.openstack.org/p/zaqar-project-mascot  Thanks.
>
> On 15/07/16 11:25, Fei Long Wang wrote:
>> Hi team,
>>
>> I've created an etherpad [1] to discuss mascots for Zaqar project.
>> Please input and vote. Thanks.
>>
>> [1] https://etherpad.openstack.org/p/zaqar-project-mascot
>> -- 
>> Cheers & Best regards,
>> Fei Long Wang (王飞龙)
>> --
>> Senior Cloud Software Engineer
>> Tel: +64-48032246
>> Email: flw...@catalyst.net.nz
>> Catalyst IT Limited
>> Level 6, Catalyst House, 150 Willis Street, Wellington
>> -- 
>>
>>
>> __
>> 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
>
> -- 
> Cheers & Best regards,
> Fei Long Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> -- 
>
>
> __
> 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

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

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

Re: [openstack-dev] [tc] persistently single-vendor projects

[Steven Dake (stdake)]

On 7/31/16, 11:29 AM, "Doug Hellmann"  wrote:

>Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28 +:
>> Kevin,
>> 
>> Just assessing your numbers, the team:diverse-affiliation tag covers
>>what
>> is required to maintain that tag.  It covers more then core reviewers -
>> also covers commits and reviews.
>> 
>> See:
>> 
>>https://github.com/openstack/governance/blob/master/reference/tags/team_d
>>iv
>> erse-affiliation.rst
>> 
>> 
>> I can tell you from founding 3 projects with the
>>team:diverse-affiliation
>> tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to
>> meet.  I don't think its wise to have such strict requirements on single
>> vendor projects as those objectively defined in
>>team:diverse-affiliation.
>> 
>> But Doug's suggestion of timelines could make sense if the timelines
>>gave
>> plenty of time to meet whatever requirements make sense and the
>> requirements led to some increase in diverse affiliation.
>
>To be clear, I'm suggesting that projects with team:single-vendor be
>given enough time to lose that tag. That does not require them to grow
>diverse enough to get team:diverse-affiliation.
>
>Doug
Doug,

That makes sense and doesn't send the wrong message.  I wasn't trying to
suggest that either; was just pointing out Kevin's numbers are more in
line with diverse-affiliation than single vendor.  My personal thoughts
are single vendor projects are ok in OpenStack if they are undertaking
community-building activities to increase their diversity of contributors.

Regards
-steve

>
>> 
>> The 45% core requirement sort of goes against the tag name
>> "single-vendor".
>> 
>> I know of many single vendor projects that would like to have a diverse
>> affiliation, strive for it, and actively promote the integration of new
>> community members into their respective sub-communities.  We don't want
>>to
>> send these folks the wrong message they aren't welcome.
>> 
>> Regards
>> -steve
>> 
>> On 7/31/16, 8:59 AM, "Fox, Kevin M"  wrote:
>> 
>> >This sounds good to me.
>> >
>> >What about making it iterative but with a delayed start. Something
>>like:
>> >
>> >There is a grace period of 1 year for projects that newly join the big
>> >tent. After which, the following criteria will be evaluated to keep a
>> >project in the big tent, evaluated at the end of each OpenStack release
>> >cycle to keep the project for the next cycle. The project should not
>>have
>> >active cores from one company in the amount greater then 45% of the
>> >active core membership. If that number is higher, the project is given
>> >notice they are under diverse and have 6 months of remaining in the big
>> >tent to show they are attempting to increase diversity by shifting the
>> >ratio to a more diverse active core membership. The active core
>> >membership percentage by the over represented company, called X%, will
>>be
>> >shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%).
>>If
>> >the criteria is met, the project can remain in the big tent and a new
>> >cycle will begin. (another notification and 6 months if still out of
>> >compliance)
>> >
>> >This should allow projects that are, or become under diverse a path
>> >towards working on project membership diversity. It gives projects that
>> >are very far out of wack a while to fix it. It basically gives projects
>> >over represented:
>> > * (80%, 100%] -  gets 18 months to fix it
>> > * (60%, 80%] - gets 12 months
>> > * (45%, 60%] - gets 6 months
>> >
>> >Thoughts? The numbers should be fairly easy to change to make for
>> >different amounts of grace period.
>> >
>> >Thanks,
>> >Kevin
>> >
>> >From: Doug Hellmann [d...@doughellmann.com]
>> >Sent: Sunday, July 31, 2016 7:16 AM
>> >To: openstack-dev
>> >Subject: [openstack-dev] [tc] persistently single-vendor projects
>> >
>> >Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
>> >Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"
>> >
>> >Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
>> >> Doug Hellmann wrote:
>> >> > 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.
>> >>
>> >> Reading this thread after a week off, I'd like to +1 Doug's
>> >> interpretation since it was referenced to describe the status quo.
>> >>
>> >> As others have said, we 

Re: [openstack-dev] [tc] persistently single-vendor projects

[Doug Hellmann]

Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28 +:
> Kevin,
> 
> Just assessing your numbers, the team:diverse-affiliation tag covers what
> is required to maintain that tag.  It covers more then core reviewers -
> also covers commits and reviews.
> 
> See:
> https://github.com/openstack/governance/blob/master/reference/tags/team_div
> erse-affiliation.rst
> 
> 
> I can tell you from founding 3 projects with the team:diverse-affiliation
> tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to
> meet.  I don't think its wise to have such strict requirements on single
> vendor projects as those objectively defined in team:diverse-affiliation.
> 
> But Doug's suggestion of timelines could make sense if the timelines gave
> plenty of time to meet whatever requirements make sense and the
> requirements led to some increase in diverse affiliation.

To be clear, I'm suggesting that projects with team:single-vendor be
given enough time to lose that tag. That does not require them to grow
diverse enough to get team:diverse-affiliation.

Doug

> 
> The 45% core requirement sort of goes against the tag name
> "single-vendor". 
> 
> I know of many single vendor projects that would like to have a diverse
> affiliation, strive for it, and actively promote the integration of new
> community members into their respective sub-communities.  We don't want to
> send these folks the wrong message they aren't welcome.
> 
> Regards
> -steve
> 
> On 7/31/16, 8:59 AM, "Fox, Kevin M"  wrote:
> 
> >This sounds good to me.
> >
> >What about making it iterative but with a delayed start. Something like:
> >
> >There is a grace period of 1 year for projects that newly join the big
> >tent. After which, the following criteria will be evaluated to keep a
> >project in the big tent, evaluated at the end of each OpenStack release
> >cycle to keep the project for the next cycle. The project should not have
> >active cores from one company in the amount greater then 45% of the
> >active core membership. If that number is higher, the project is given
> >notice they are under diverse and have 6 months of remaining in the big
> >tent to show they are attempting to increase diversity by shifting the
> >ratio to a more diverse active core membership. The active core
> >membership percentage by the over represented company, called X%, will be
> >shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%). If
> >the criteria is met, the project can remain in the big tent and a new
> >cycle will begin. (another notification and 6 months if still out of
> >compliance)
> >
> >This should allow projects that are, or become under diverse a path
> >towards working on project membership diversity. It gives projects that
> >are very far out of wack a while to fix it. It basically gives projects
> >over represented:
> > * (80%, 100%] -  gets 18 months to fix it
> > * (60%, 80%] - gets 12 months
> > * (45%, 60%] - gets 6 months
> >
> >Thoughts? The numbers should be fairly easy to change to make for
> >different amounts of grace period.
> >
> >Thanks,
> >Kevin
> >
> >From: Doug Hellmann [d...@doughellmann.com]
> >Sent: Sunday, July 31, 2016 7:16 AM
> >To: openstack-dev
> >Subject: [openstack-dev] [tc] persistently single-vendor projects
> >
> >Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
> >Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"
> >
> >Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
> >> Doug Hellmann wrote:
> >> > 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.
> >>
> >> Reading this thread after a week off, I'd like to +1 Doug's
> >> interpretation since it was referenced to describe the status quo.
> >>
> >> As others have said, we wouldn't even have that discussion if the new
> >> repositories didn't use "fuel" as part of the naming. We probably
> >> wouldn't have that discussion either if the Fuel team affiliation was
> >> more diverse and the new repositories were an experiment of a specific
> >> subgroup of that team.
> >>
> >> NB: I *do* have some concerns about single-vendor OpenStack projects
> >> that don't grow more diverse affiliations over time, but that's a
> >> completely separate topic.
> >
> >I'm starting to think that perhaps we should add some sort of
> >expectation of a time-frame for projects 

Re: [openstack-dev] [tc] persistently single-vendor projects

[Steven Dake (stdake)]

Kevin,

Just assessing your numbers, the team:diverse-affiliation tag covers what
is required to maintain that tag.  It covers more then core reviewers -
also covers commits and reviews.

See:
https://github.com/openstack/governance/blob/master/reference/tags/team_div
erse-affiliation.rst


I can tell you from founding 3 projects with the team:diverse-affiliation
tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to
meet.  I don't think its wise to have such strict requirements on single
vendor projects as those objectively defined in team:diverse-affiliation.

But Doug's suggestion of timelines could make sense if the timelines gave
plenty of time to meet whatever requirements make sense and the
requirements led to some increase in diverse affiliation.

The 45% core requirement sort of goes against the tag name
"single-vendor". 

I know of many single vendor projects that would like to have a diverse
affiliation, strive for it, and actively promote the integration of new
community members into their respective sub-communities.  We don't want to
send these folks the wrong message they aren't welcome.

Regards
-steve

On 7/31/16, 8:59 AM, "Fox, Kevin M"  wrote:

>This sounds good to me.
>
>What about making it iterative but with a delayed start. Something like:
>
>There is a grace period of 1 year for projects that newly join the big
>tent. After which, the following criteria will be evaluated to keep a
>project in the big tent, evaluated at the end of each OpenStack release
>cycle to keep the project for the next cycle. The project should not have
>active cores from one company in the amount greater then 45% of the
>active core membership. If that number is higher, the project is given
>notice they are under diverse and have 6 months of remaining in the big
>tent to show they are attempting to increase diversity by shifting the
>ratio to a more diverse active core membership. The active core
>membership percentage by the over represented company, called X%, will be
>shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%). If
>the criteria is met, the project can remain in the big tent and a new
>cycle will begin. (another notification and 6 months if still out of
>compliance)
>
>This should allow projects that are, or become under diverse a path
>towards working on project membership diversity. It gives projects that
>are very far out of wack a while to fix it. It basically gives projects
>over represented:
> * (80%, 100%] -  gets 18 months to fix it
> * (60%, 80%] - gets 12 months
> * (45%, 60%] - gets 6 months
>
>Thoughts? The numbers should be fairly easy to change to make for
>different amounts of grace period.
>
>Thanks,
>Kevin
>
>From: Doug Hellmann [d...@doughellmann.com]
>Sent: Sunday, July 31, 2016 7:16 AM
>To: openstack-dev
>Subject: [openstack-dev] [tc] persistently single-vendor projects
>
>Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
>Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"
>
>Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
>> Doug Hellmann wrote:
>> > 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.
>>
>> Reading this thread after a week off, I'd like to +1 Doug's
>> interpretation since it was referenced to describe the status quo.
>>
>> As others have said, we wouldn't even have that discussion if the new
>> repositories didn't use "fuel" as part of the naming. We probably
>> wouldn't have that discussion either if the Fuel team affiliation was
>> more diverse and the new repositories were an experiment of a specific
>> subgroup of that team.
>>
>> NB: I *do* have some concerns about single-vendor OpenStack projects
>> that don't grow more diverse affiliations over time, but that's a
>> completely separate topic.
>
>I'm starting to think that perhaps we should add some sort of
>expectation of a time-frame for projects that join the big tent as
>single-vendor to attract other contributors.
>
>We removed the requirement that new projects need to have some
>minimal level of diversity when they join because projects asserted
>that they would have a better chance of attracting other contributors
>after becoming official. It might focus the team's efforts on that
>priority if we said that after a year or 18 months without any
>increased diversity, the project would be removed from the big tent.

Re: [openstack-dev] [nova] [container] [docker] [magnum] [zun] nova-docker alternatives ?

[yasemin]

that is docker swarm bay ?? 
> On Jul 31, 2016, at 8:40 AM, Ton Ngo  wrote:
> 
> for a second I thought that would be a great life cycle operation for bays .. 
> :)
> Ton,
> 
> Adrian Otto ---07/29/2016 11:31:53 AM---s/mentally/centrally/ 
> Autocorrect is not my friend.
> 
> From: Adrian Otto 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 07/29/2016 11:31 AM
> Subject: Re: [openstack-dev] [nova] [container] [docker] [magnum] [zun] 
> nova-docker alternatives ?
> 
> 
> 
> 
> s/mentally/centrally/ 
> 
> Autocorrect is not my friend.
> On Jul 29, 2016, at 11:26 AM, Adrian Otto  > wrote:
> 
> Yasmin, 
> 
> One option you have is to use the libvirt-lxc nova virt driver, and use an 
> image that has a docker daemon installed on it. That would give you a way to 
> place docker containers on a data plane the uses no virtualization, but you 
> need to individually manage each instance. Another option is to add Magnum to 
> your cloud (with or without a libvirt-lxc nova virt driver) and use Magnum to 
> mentally manage each container cluster. We refer to such clusters as bays. 
> 
> Adrian
> On Jul 29, 2016, at 11:01 AM, Yasemin DEMİRAL (BİLGEM BTE) 
> > 
> wrote:
> 
> 
> nova-docker is a dead project, i learned irc channel. 
> I need the hypervisor for nova, and I cant installation nova-docker in 
> physical openstack systems. In devstack, I could deploy nova-docker.
> What can I do ? openstack-magnum or openstack-zun project is useful for me ?? 
> I dont know.
> Do you have any ideas ?
> 
> 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

[openstack-dev] The a o and: [mhmm zlkkko I you'llopenstack-dev] [puppet] Propose Sofer At yourhlan-Guyot (che il jm) p req levelaojrmore a bit late Puppet OpenStack core

[Jon Schlueter]

Ihzkoookk OTO Ou GM is a kks

On Jul 28, 2016 11:19 AM, "Alex Schultz"  wrote:

> +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
>
__
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] [infra] [TripleO] ntp-wait issue breaks TripleO jobs

[Paul Belanger]

On Sun, Jul 31, 2016 at 04:12:32PM +0300, Sagi Shnaidman wrote:
> Hi infra and TripleO cores,
> 
> I'd like to ask you for review+merge of bugfix which limits ntp-wait tries
> to 100 instead of current 1000. These long tries cause timeout of 100
> minutes and breaks TripleO jobs.
> 
> More details are in the bug: https://bugs.launchpad.net/tripleo/+bug/1608226
> The patch: https://review.openstack.org/#/c/349261
> 
I spent 30mins or so debugging this with help from fungi. While the patch is
reasonable, it has actually exposed a ntpd problem limited to 
tripleo-test-cloud-rh2.

I've added comment into the bug, but it looks like there is some upstream
firewall / packet filtering that is stopping ntpd from working correctly.

Since we don't have access to the network control plane, we need somebody at Red
Hat to look into the problem.

> __
> 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] [tc] persistently single-vendor projects

[Fox, Kevin M]

This sounds good to me.

What about making it iterative but with a delayed start. Something like:

There is a grace period of 1 year for projects that newly join the big tent. 
After which, the following criteria will be evaluated to keep a project in the 
big tent, evaluated at the end of each OpenStack release cycle to keep the 
project for the next cycle. The project should not have active cores from one 
company in the amount greater then 45% of the active core membership. If that 
number is higher, the project is given notice they are under diverse and have 6 
months of remaining in the big tent to show they are attempting to increase 
diversity by shifting the ratio to a more diverse active core membership. The 
active core membership percentage by the over represented company, called X%, 
will be shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%). 
If the criteria is met, the project can remain in the big tent and a new cycle 
will begin. (another notification and 6 months if still out of compliance)

This should allow projects that are, or become under diverse a path towards 
working on project membership diversity. It gives projects that are very far 
out of wack a while to fix it. It basically gives projects over represented:
 * (80%, 100%] -  gets 18 months to fix it
 * (60%, 80%] - gets 12 months
 * (45%, 60%] - gets 6 months

Thoughts? The numbers should be fairly easy to change to make for different 
amounts of grace period.

Thanks,
Kevin

From: Doug Hellmann [d...@doughellmann.com]
Sent: Sunday, July 31, 2016 7:16 AM
To: openstack-dev
Subject: [openstack-dev] [tc] persistently single-vendor projects

Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"

Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
> Doug Hellmann wrote:
> > 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.
>
> Reading this thread after a week off, I'd like to +1 Doug's
> interpretation since it was referenced to describe the status quo.
>
> As others have said, we wouldn't even have that discussion if the new
> repositories didn't use "fuel" as part of the naming. We probably
> wouldn't have that discussion either if the Fuel team affiliation was
> more diverse and the new repositories were an experiment of a specific
> subgroup of that team.
>
> NB: I *do* have some concerns about single-vendor OpenStack projects
> that don't grow more diverse affiliations over time, but that's a
> completely separate topic.

I'm starting to think that perhaps we should add some sort of
expectation of a time-frame for projects that join the big tent as
single-vendor to attract other contributors.

We removed the requirement that new projects need to have some
minimal level of diversity when they join because projects asserted
that they would have a better chance of attracting other contributors
after becoming official. It might focus the team's efforts on that
priority if we said that after a year or 18 months without any
increased diversity, the project would be removed from the big tent.

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

__
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] [tc] persistently single-vendor projects

[Doug Hellmann]

Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"

Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
> Doug Hellmann wrote:
> > 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.
> 
> Reading this thread after a week off, I'd like to +1 Doug's
> interpretation since it was referenced to describe the status quo.
> 
> As others have said, we wouldn't even have that discussion if the new
> repositories didn't use "fuel" as part of the naming. We probably
> wouldn't have that discussion either if the Fuel team affiliation was
> more diverse and the new repositories were an experiment of a specific
> subgroup of that team.
> 
> NB: I *do* have some concerns about single-vendor OpenStack projects
> that don't grow more diverse affiliations over time, but that's a
> completely separate topic.

I'm starting to think that perhaps we should add some sort of
expectation of a time-frame for projects that join the big tent as
single-vendor to attract other contributors.

We removed the requirement that new projects need to have some
minimal level of diversity when they join because projects asserted
that they would have a better chance of attracting other contributors
after becoming official. It might focus the team's efforts on that
priority if we said that after a year or 18 months without any
increased diversity, the project would be removed from the big tent.

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

[Sebastien Badia]

On Thu, Jul 28, 2016 at 11:16:17AM (-0400), 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.

Hi!

I'm not puppet-openstack core anymore, but I already worked with Sofer, and
I think it's very valuable for the team to have him as core!

Thanks Sofer for all your work and engagement since the beginning!

A big +1 for me!

Seb

-- 
Sebastien Badia


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

[openstack-dev] [infra] [TripleO] ntp-wait issue breaks TripleO jobs

[Sagi Shnaidman]

Hi infra and TripleO cores,

I'd like to ask you for review+merge of bugfix which limits ntp-wait tries
to 100 instead of current 1000. These long tries cause timeout of 100
minutes and breaks TripleO jobs.

More details are in the bug: https://bugs.launchpad.net/tripleo/+bug/1608226
The patch: https://review.openstack.org/#/c/349261

Thanks

-- 
Best regards
Sagi Shnaidman
__
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] weird behavior of neutron create port with extra dhcp option

[Gary Kotton]

Hi,
This also seems related - https://review.openstack.org/345717 and 
https://review.openstack.org/345720
Thanks
Gary

On 7/30/16, 12:49 AM, "Moshe Levi"  wrote:

Hi,
I encounter a weird behavior with neutron create port command.
I am using neutron master.

When I run this neutron create-port command 
stack@r-dcs88:/opt/devstack$ neutron port-create 
--device-id=984b4a6d-a66d-4db7-8acc-1113cd1097ef --device-owner=baremetal:none 
--mac-address 7c:fe:90:29:22:4e --extra-dhcp-opt 
'opt_value'='ff:00:00:00:00:00:02:00:00:02:c9:00:7c:fe:90:03:00:29:22:4e','opt_name'='client-id'
 --admin_state_up=True private
port is created as expected see [1]

when I create a port with the following command:
stack@r-dcs88:/opt/devstack$ neutron port-create 
--device-id=984b4a6d-a66d-4db7-8acc-1113cd1097ef --device-owner=baremetal:none 
--mac-address 7c:fe:90:29:22:4e --extra-dhcp-opt 
'opt_value'='ff:00:00:00:00:00:02:00:00:02:c9:00:7c:fe:90:03:00:29:22:4e','opt_name'='client-id'
 --vnic_type=baremetal --admin_state_up=True private
port is created but in neutron client  show the extra_dhcp_opts attribute 
without the options. The only difference in the command is that I added 
--vnic_type=baremetal to it.
I looked in the neutron database and I can see the extra_dhcp_opts in the 
table.

I debugged the neutron server and the problem is with 

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_neutron_blob_master_neutron_plugins_ml2_plugin.py-23L1217=CwICAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc=NK7N9hNHtDeWUv7zz2bSdzSl9vcPX6zcxEyxfJ6o4vw=hbtQu6retP3sM2NcUcu-dUT0ysPA6dAQJ_MpYwYkRck=
  that calling the _extend_port_dict_extra_dhcp_opt and clearing the 
extra_dhcp_opts from the result variable. If I comment this 
line(_apply_dict_extend_functions)  I will get the correct result.
Commenting it don't seem to me as the correct fix and I have a hard time 
understating the code.
It seems that the dhcp opt extend the result in 2 places  here [3] and here 
[4].

Does anyone know what is the proper way to fix this issue? Help would be 
much appreciated 


[1] - http://paste.openstack.org/show/544013/
[2] - http://paste.openstack.org/show/544014/ 
[3] - 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_neutron_blob_master_neutron_db_extradhcpopt-5Fdb.py-23L37-2DL53=CwICAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc=NK7N9hNHtDeWUv7zz2bSdzSl9vcPX6zcxEyxfJ6o4vw=f3iiNIAfJJDgEuxyDUJ3R4wzduAs4jtIQQN2TBL1aSU=
 
[4] - 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_neutron_blob_1fd1b505ca0a4dcaa7184df02dbd53ba63355083_neutron_db_extradhcpopt-5Fdb.py-23L116-2DL121=CwICAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc=NK7N9hNHtDeWUv7zz2bSdzSl9vcPX6zcxEyxfJ6o4vw=TQ3P-nBoomj9g6UoZkRgAqXoBTfYFMGdOnzPCl85Xl0=
 



__
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] [neutron][dvr][fip] fg device allocated private ip address

[huangdenghui]

Hi
   Now we have spec named subnet service types, which provides a capability of 
allowing different port of a network to allocate ip address from different 
subnet. In current implementation of DVR, fip also is distributed on every 
compute node, floating ip and fg's ip are both allocated from external 
network's subnets. In large public cloud deployment, current implementation 
will consume lots of public ip address. Do we need a RFE to apply subnet 
service types spec to resolve this problem. Any thoughts?
__
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

[Thierry Carrez]

Doug Hellmann wrote:
> 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.

Reading this thread after a week off, I'd like to +1 Doug's
interpretation since it was referenced to describe the status quo.

As others have said, we wouldn't even have that discussion if the new
repositories didn't use "fuel" as part of the naming. We probably
wouldn't have that discussion either if the Fuel team affiliation was
more diverse and the new repositories were an experiment of a specific
subgroup of that team.

NB: I *do* have some concerns about single-vendor OpenStack projects
that don't grow more diverse affiliations over time, but that's a
completely separate topic.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] Reviewing coverage jobs set up

[Andreas Jaeger]

The following coverage jobs are still wrongly setup, I've proposed a
change now to remove them from our infra setup [1]:

* cloudkitty-dashboard
* murano-agent
* nova-docker
* os-net-config
* poppy
* sahara-dashboard
* solum-dashboard
* trove-dashboard
* turbo-hipster

https://review.openstack.org/349242

Andreas

On 07/18/2016 08:09 PM, Andreas Jaeger wrote:
> While looking at coverage jobs to enable them to allow use of
> constraints in post jobs (something which has just been introduced and
> needs some more testing before we take on the other jobs), I noticed
> that we have quite a few coverage
> jobs that are failing.
> 
> In general, I think coverage jobs should be run as check job so
> that you know how the coverage changes. Running them only in the post
> job means that in practice nobody sees the output of the job.
> 
> Out of 83 jobs having a post coverage job, 19 failed. See
> below for list of failures and a list of all repos that have a coverage
> post job setup.
> 
> I suggest that projects review their coverage setup and decide whether
> they want to run it as part of the check queue, fix it, or remove it.
> 
> Btw. if you want to get the output of the post job, check the git SHA.
> logs are found at ``http://logs.openstack.org/ commit SHA>/``. For example, if a change is committed with
> the sha 'deadbeef123456', the logs will be found at
> ``http://logs.openstack.org/de/deadbeef123456``.
> 
> Here're the failures (including some that run successful but coverage
> did not collect any data):
> 
> cloudkitty-dashboard:
> http://logs.openstack.org/11/113209883e3e9131602f35593bc0cb8880db19b9/post/cloudkitty-dashboard-coverage/c390a24/
> 
> designate-dashboard:
> http://logs.openstack.org/56/5627ddb4a6eedb751fecced56d277961aac92436/post/designate-dashboard-coverage/73650dc/
> 
> horizon:
> http://logs.openstack.org/8f/8f35c43bc5b4182d6e82a67cdc2beccd2364da8a/post/horizon-coverage/5535457/
> 
> monasca-ui:
> http://logs.openstack.org/f0/f05e4992fb6ce722ac00c4aa6ad30ff89b453476/post/monasca-ui-coverage/af5105e/
> 
> murano-agent:
> http://logs.openstack.org/14/1450eb39fb9f6dcbe1b70167d23d16e74f28dbd5/post/murano-agent-coverage/ee9c33a/
> 
> nodepool:
> http://logs.openstack.org/e3/e345107476a82ddad82ea99e184398e0d0e7e85a/post/nodepool-coverage-db/8a0ee23/
> 
> nova:
> http://logs.openstack.org/3f/3f700b5a5a498ba08e77378d34f059c3fa6845d8/post/nova-coverage-db/2bdabf8/
> 
> nova-docker:
> http://logs.openstack.org/03/034a4842fc1ebba5912e02cff8cd197ae81eb0c3/post/nova-docker-coverage/879d790/
> 
> os-net-config:
> http://logs.openstack.org/6b/6bb8412ef3d3f163d91f2884081b743f07a78f18/post/os-net-config-coverage/cba622a/
> 
> poppy:
> http://logs.openstack.org/09/0948c854e4b8543f01d909437f09cfb23e71a5b0/post/poppy-coverage/ccbc8ad/
> 
> python-aodhclient:
> http://logs.openstack.org/65/65d2e625ee3b359bae154a5da3931f48b48fe720/post/python-aodhclient-coverage/2d8a169/
> 
> python-gnocchiclient:
> http://logs.openstack.org/81/81e1b91beb3d85760e574951e240a381d6a4d008/post/python-gnocchiclient-coverage/2d9a414/
> 
> python-monascaclient (this should be fixed with the enabling of
> constraints):
> http://logs.openstack.org/17/17b9eaa1ede715344ac9cb2049c63e25604476cb/post/python-monascaclient-coverage/2b44b1b/
> 
> sahara-dashboard:
> http://logs.openstack.org/bc/bcf8e2938d7085799a3754a9ff6d245d73ec33ff/post/sahara-dashboard-coverage/7807a4e/console.html.gz
> 
> sahara-tests:
> http://logs.openstack.org/91/914bf0646f4de85107324f0aa05e856961bb0ee6/post/sahara-tests-coverage/b65352b/
> 
> solum-dashboard:
> http://logs.openstack.org/82/8235df5a5ab0d48a6b407931c1d998102050b1b9/post/solum-dashboard-coverage/8d23679/
> 
> trove:
> http://logs.openstack.org/4a/4ad0dfe88c6362356c8083d167f43ab495da661d/post/trove-coverage-db/990fd71/
> 
> trove-dashboard:
> http://logs.openstack.org/01/01815715539fad40e06e974d6fdf840957051b69/post/trove-dashboard-coverage/908f8df/
> 
> turbo-hipster:
> http://logs.openstack.org/7e/7ef12b758020176fb3e13e5bb0154084b1456797/post/turbo-hipster-coverage/ab2d17a/
> 
> 
> Full list of repos with coverage job defined:
> 
> openstack-dev/hacking hacking-coverage
> openstack-dev/pbr pbr-coverage
> openstack-infra/bindep bindep-coverage
> openstack-infra/grafyaml grafyaml-coverage
> openstack-infra/jenkins-job-builder jenkins-job-builder-coverage
> openstack-infra/nodepool nodepool-coverage-db
> openstack-infra/python-storyboardclient python-storyboardclient-coverage
> openstack-infra/shade shade-coverage
> openstack-infra/storyboard storyboard-coverage-db
> openstack-infra/zuul zuul-coverage-db
> openstack/ara ara-coverage
> openstack/ceilometermiddleware ceilometermiddleware-coverage
> openstack/cloudbase-init cloudbase-init-coverage
> openstack/cloudkitty cloudkitty-coverage
> openstack/cloudkitty-dashboard cloudkitty-dashboard-coverage
> openstack/designate designate-coverage-db
> openstack/designate-dashboard designate-dashboard-coverage
> openstack/heat heat-coverage-db
> 

Re: [openstack-dev] [octavia]redirection and barbican config

[Michael Johnson]

Hi Akshay,

For 80 to 443 redirection, you can accomplish this using the new L7
rules capability.  You would setup a listener on port 80 that has a
redirect rule to the 443 URL.

On the barbican question, if you are using the octavia driver, you
will need to set the required settings in the octavia.conf file for
proper barbican access.
Those settings are called out here:
http://docs.openstack.org/developer/octavia/config-reference/octavia-config-table.html

Michael


On Thu, Jul 28, 2016 at 1:02 PM, Akshay Kumar Sanghai
 wrote:
> 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
>

__
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