Re: [openstack-dev] [mistral] PTG Summary

[Renat Akhmerov]

On 7 Mar 2018, 16:29 +0700, Dougal Matthews , wrote:
> Hey Mistralites (maybe?),
>
> I have been through the etherpad from the PTG and attempted to expand on the 
> topics with details that I remember. If I have missed anything or you have 
> any questions, please get in touch. I want to update it while the memory is 
> as fresh as possible.
>
> For each main topic I have added a "champion" and a "goal". These are not all 
> complete yet and can be adjusted. I did add names next to champion for people 
> that discussed that topic at the PTG. The goal should summarise what we need 
> to do.
>
> Note: "Champion" does not mean you need to do all the work - just you are 
> leading that effort and helping rally people around the issue. Essentially it 
> is a collaboration role, but you can still lead the implementation if that 
> makes sense. For example, I put myself as the Documentation champion. I do 
> not plan on writing all the documentation, rather I want to setup better 
> foundations and a better process for writing documentation. This will likely 
> be a team effort I need to coordinate.
>
> Etherpad:
> https://etherpad.openstack.org/p/mistral-ptg-rocky
>

Thanks Dougal, looks nice )

> It was unfortunate that the "Beast from the East" (the weather, not Renat!) 
> stopped things a bit early on Thursday.

Haha :) I probably wouldn’t be even offended if you meant me ;)

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

Re: [openstack-dev] [kolla][vote] core nomination for caoyuan

[Jeffrey Zhang]

sorry for a typo.

The vote is open for 7 days until Mar 19th.

On Mon, Mar 12, 2018 at 10:06 AM, Jeffrey Zhang 
wrote:

> ​​Kolla core reviewer team,
>
> It is my pleasure to nominate caoyuan for kolla core team.
>
> caoyuan's output is fantastic over the last cycle. And he is the most
> active non-core contributor on Kolla project for last 180 days[1]. He
> focuses on configuration optimize and improve the pre-checks feature.
>
> Consider this nomination a +1 vote from me.
>
> A +1 vote indicates you are in favor of caoyuan as a candidate, a -1
> is a veto. Voting is open for 7 days until Mar 12th, or a unanimous
> response is reached or a veto vote occurs.
>
> [1] http://stackalytics.com/report/contribution/kolla-group/180
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>



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

[openstack-dev] [kolla][vote] core nomination for caoyuan

[Jeffrey Zhang]

​​Kolla core reviewer team,

It is my pleasure to nominate caoyuan for kolla core team.

caoyuan's output is fantastic over the last cycle. And he is the most
active non-core contributor on Kolla project for last 180 days[1]. He
focuses on configuration optimize and improve the pre-checks feature.

Consider this nomination a +1 vote from me.

A +1 vote indicates you are in favor of caoyuan as a candidate, a -1
is a veto. Voting is open for 7 days until Mar 12th, or a unanimous
response is reached or a veto vote occurs.

[1] http://stackalytics.com/report/contribution/kolla-group/180
-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules

[Xinni Ge]

Hi, Akihiro

Thanks for the quick reply.

I agree with your opinion that BASE_XSTATIC_MODULES should not be modified.
It is much better to enhance horizon plugin settings,
 and I think maybe there could be one option like ADD_XSTATIC_MODULES.
This option adds the plugin's xstatic files in STATICFILES_DIRS.
I am considering to add a bug report to describe it at first, and give a
patch later maybe.
Is that ok with the Horizon team?

Best Regards.
Xinni

On Fri, Mar 9, 2018 at 11:47 PM, Akihiro Motoki  wrote:

> Hi Xinni,
>
> 2018-03-09 12:05 GMT+09:00 Xinni Ge :
> > Hello Horizon Team,
> >
> > I would like to hear about your opinions about how to add new xstatic
> > modules to horizon settings.
> >
> > As for Heat-dashboard project embedded 3rd-party files issue, thanks for
> > your advices in Dublin PTG, we are now removing them and referencing as
> new
> > xstatic-* libs.
>
> Thanks for moving this forward.
>
> > So we installed the new xstatic files (not uploaded as openstack official
> > repos yet) in our development environment now, but hesitate to decide
> how to
> > add the new installed xstatic lib path to STATICFILES_DIRS in
> > openstack_dashboard.settings so that the static files could be
> automatically
> > collected by *collectstatic* process.
> >
> > Currently Horizon defines BASE_XSTATIC_MODULES in
> > openstack_dashboard/utils/settings.py and the relevant static fils are
> added
> > to STATICFILES_DIRS before it updates any Horizon plugin dashboard.
> > We may want new plugin setting keywords ( something similar to
> ADD_JS_FILES)
> > to update horizon XSTATIC_MODULES (or directly update STATICFILES_DIRS).
>
> IMHO it is better to allow horizon plugins to add xstatic modules
> through horizon plugin settings. I don't think it is a good idea to
> add a new entry in BASE_XSTATIC_MODULES based on horizon plugin
> usages. It makes difficult to track why and where a xstatic module in
> BASE_XSTATIC_MODULES is used.
> Multiple horizon plugins can add a same entry, so horizon code to
> handle plugin settings should merge multiple entries to a single one
> hopefully.
> My vote is to enhance the horizon plugin settings.
>
> Akihiro
>
> >
> > Looking forward to hearing any suggestions from you guys, and
> > Best Regards,
> >
> > Xinni Ge
> >
> > 
> __
> > 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
>



-- 
葛馨霓 Xinni Ge
__
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] [tricircle] Nominate change in tricircle core team

[joehuang]

+1. Baisen has contributed lots of patches in Tricircle.

Best Regards
Chaoyi Huang (joehuang)

From: Vega Cai [luckyveg...@gmail.com]
Sent: 12 March 2018 9:04
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle] Nominate change in tricircle core team

Hi team, I would like to nominate Baisen Song (songbaisen) for tricircle core 
reviewer. Baisen has actively joined the discussion of feature development and 
has contributed important patches since Queens, like resource deletion 
reliability and openstack-sdk new version adaption. I really think his 
experience will help us substantially improve tricircle.

BR
Zhiyuan
--
BR
Zhiyuan
__
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] [tricircle] Nominate change in tricircle core team

[Vega Cai]

Hi team, I would like to nominate Baisen Song (songbaisen) for tricircle
core reviewer. Baisen has actively joined the discussion of feature
development and has contributed important patches since Queens, like
resource deletion reliability and openstack-sdk new version adaption. I
really think his experience will help us substantially improve tricircle.

BR
Zhiyuan
-- 
BR
Zhiyuan
__
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] placement update 18-10

[Tetsuro Nakamura]

# Questions
> What's the status of shared resource providers? Did we even talk
> about that in Dublin?


In terms of bug fixes related to allocation candidates, I'll try to answer
that question :)
Most of the bugs that have been reported in
https://bugs.launchpad.net/nova/+bug/1731072 are sorted out and already
fixed in Queens.

But we have some items left.

* https://review.openstack.org/#/c/533396
AllocationCandidates.get_by_filters ignores shared RPs when the RC exists
in both places

* https://review.openstack.org/#/c/519601/
* https://review.openstack.org/#/c/533437/
AllocationCandidates.get_by_filters does not handle indirectly connected
sharing RPs
-> In the PTG, we discussed if we need “anchor” RPs in the response of the
API, and if I get it correctly the agreement was "let’s re-open this once
we face a concrete use case." I have updated the patches according to that
conclusion.

* https://review.openstack.org/#/c/533195/
Placement returns no allocation candidate for request that needs both
compute resources and custom shared resources
-> This is already fixed, and trivial comment fix is left and ready for
review.

* No fix proposed - https://bugs.launchpad.net/nova/+bug/1724633
AllocationCandidates.get_by_filters hits incorrectly when traits are split
across the main RP and aggregates
-> This is hard to fix as long as traits belong not to resource classes but
to resource providers. While the current design allows a consumer to pick
resource classes from multiple resource providers (in the same aggregate),
we have no way to know which trait corresponds to which resource class.

Besides these bugs, how we collaborate and merge existing logic of shared
resource provider and now being constructed logic of nested resource
provider remains one of the challenges in Rocky in my understanding.

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

Re: [openstack-dev] [keystone] Keystone failing with error 104 (connection reset by peer) if using uwsgi

[Thomas Goirand]

On 03/11/2018 08:12 PM, Lance Bragstad wrote:
> Hey Thomas, 
> 
> Outside of the uwsgi config, are you following a specific guide for your
> install?

Under the packages that I maintain in Debian, there's nothing more to do
than "apt-get install keystone", reply to a few Debconf questions, and
you get a working installation. That is to say, I don't think I did any
mistake here.

> I'd like to try and recreate the issue.

If you wish, I can build a package for you to try, if you're ok with
that. Would that be ok? Would you prefer to use Sid or Stretch? It's
rather easy to do, as the revert to Apache is just a single git commit.

> Do you happen to have any more logging information?

That's what was really frustrating: no log at all on the server side,
just the client...

Cheers,

Thomas Goirand (zigo)

__
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] [Senlin] Nominate changing in Senlin core team

[x Lyn]

+1 to both!

Ethan

> On 9 Mar 2018, at 5:28 PM, liu.xuefe...@zte.com.cn wrote:
> 
> 
> 
> Hi team,
> 
> I would like to propose adding chenyb and DucTruong to the Senlin core 
> team.
> 
> Chenyb has been working on Openstack more than 3 years, with the 
> responsibility of intergation Nova, Senlin and Ceilometer cloud production.  
> He has finished many features and bugs for Senlin project, now he is the most 
> active non-core contributor on Senlin group projects.
> 
> DucTruong works for Blizzard Entertainment, Blizzard company is an active 
> user of Senlin project. Duc and his colleagues have  finished some useful 
> features for Senlin, from this feautres they also got a good understand about 
> Senlin. Now Duc is a active code reviewer on Senlin.
> 
> 
> 
> 
> -- 
> Thanks
> XueFeng   
> 
> 
> 
> __
> 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] [keystone] Keystone failing with error 104 (connection reset by peer) if using uwsgi

[Lance Bragstad]

Hey Thomas,

Outside of the uwsgi config, are you following a specific guide for your
install? I'd like to try and recreate the issue.

Do you happen to have any more logging information?

Thanks

On Mar 11, 2018 06:10, "Thomas Goirand"  wrote:

> Hi,
>
> I've attempted to switch Keystone to using uwsgi instead of Apache in
> the Debian packages for Queens. Unfortunately, I had random failure with
> error 104 in both output of the client and keystone logs. 104 is in fact
> "TCP connection reset by peer" (and this shows in the logs). So I've
> switched back, but I'd prefer using uwsgi if possible.
>
> Here's the parameters I had in the .ini for uwsgi:
>
> http-socket = :35357
> wsgi-file = /usr/bin/keystone-wsgi-admin
> buffer-size = 65535
> master = true
> enable-threads = true
> processes = 12
> thunder-lock = true
> plugins = python3
> lazy-apps = true
> paste-logger = true
> logto = /var/log/keystone/keystone-admin.log
> name = keystone-admin
> uid = keystone
> gid = keystone
> chdir = /var/lib/keystone
> die-on-term = true
>
> Has this happened to anyone else? Is there one option above which is
> wrong? Why is this happening?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> 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] [openstack][charms] Openstack + OVN

[Aakash Kt]

Hi,

I had previously put in a mail about the development for openstack-ovn
charm. Sorry it took me this long to get back, was involved in other
projects.

I have submitted a charm spec for the above charm.
Here is the review link : https://review.openstack.org/#/c/551800/

Please look in to it and we can further discuss how to proceed.

Thank you,
Aakash
OVN4NFV (OPNFV)
__
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] [keystone] Keystone failing with error 104 (connection reset by peer) if using uwsgi

[Thomas Goirand]

Hi,

I've attempted to switch Keystone to using uwsgi instead of Apache in
the Debian packages for Queens. Unfortunately, I had random failure with
error 104 in both output of the client and keystone logs. 104 is in fact
"TCP connection reset by peer" (and this shows in the logs). So I've
switched back, but I'd prefer using uwsgi if possible.

Here's the parameters I had in the .ini for uwsgi:

http-socket = :35357
wsgi-file = /usr/bin/keystone-wsgi-admin
buffer-size = 65535
master = true
enable-threads = true
processes = 12
thunder-lock = true
plugins = python3
lazy-apps = true
paste-logger = true
logto = /var/log/keystone/keystone-admin.log
name = keystone-admin
uid = keystone
gid = keystone
chdir = /var/lib/keystone
die-on-term = true

Has this happened to anyone else? Is there one option above which is
wrong? Why is this happening?

Cheers,

Thomas Goirand (zigo)

__
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