Re: [openstack-dev] [horizon] Do we want new meeting time?

[Ivan Kolodyazhny]

Hi all,

Due to the low activity on our weekly meeting, I would like to raise this
question again.

Do we want a new meeting day and/or time? I'm available any day except
Tuesday and Wednesday. I'm going to get some feedback before I create a
new poll.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Thu, Apr 5, 2018 at 1:42 PM Ivan Kolodyazhny  wrote:

> Hi team,
>
> It's a friendly reminder that we've got voting open [1] until next
> meeting. If you would like to attend Horizon meetings, please, select
> comfortable options for you.
>
> [1] https://doodle.com/poll/ei5gstt73d8v3a35
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Wed, Mar 21, 2018 at 6:40 PM, Ivan Kolodyazhny  wrote:
>
>> Hi team,
>>
>> As was discussed at PTG, usually we've got a very few participants on our
>> weekly meetings. I hope, mostly it's because of not comfort meeting time
>> for many of us.
>>
>> Let's try to re-schedule Horizon weekly meetings and get more attendees
>> there. I've created a doodle for it [1]. Please, vote for the best time for
>> you.
>>
>>
>> [1] https://doodle.com/poll/ei5gstt73d8v3a35
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>
>
__
OpenStack Development Mailing 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] how to get horizon related logs to syslog?

[Doug Hellmann]

Akihiro Motoki  writes:

> Hi,
>
> Horizon logging depends on Django configuration which supports full python
> logging [1].
> [1] does not provide enough examples.
> Perhaps [2] will help you (though I haven't tested it).

Based on https://docs.djangoproject.com/en/2.1/topics/logging/ it looks
like it should be possible to have Horizon's settings module disable
Django's logging configuration and call oslo.log to do that
configuration. I wonder if it would make sense to do that, for
consistency with the other services?

Doug


>
> [1] https://docs.djangoproject.com/en/2.0/topics/logging/
> [2]
> https://www.simonkrueger.com/2015/05/27/logging-django-apps-to-syslog.html
>
> Thanks,
> Akihiro
>
> 2018年11月16日(金) 18:47 Tikkanen, Viktor (Nokia - FI/Espoo) <
> viktor.tikka...@nokia.com>:
>
>> Hi!
>>
>> For most openstack parts (e.g. Aodh, Cinder, Glance, Heat, Ironic,
>> Keystone, Neutron, Nova) it was easy to get logs to syslog.
>>
>> For example for Heat something similar to this (into file
>> templates/heat.conf.j2):
>>
>> # Syslog usage
>> {% if heat_syslog_enabled %}
>> use_syslog = True
>> syslog_log_facility = LOG_LOCAL3
>> {% else %}
>> log_file = /var/log/heat/heat.log
>> {% endif %}
>>
>> But how to get Horizon related logs to syslog?
>>
>> -V.
>>
>> __
>> OpenStack Development Mailing 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

-- 
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] [horizon] how to get horizon related logs to syslog?

[Akihiro Motoki]

Hi,

Horizon logging depends on Django configuration which supports full python
logging [1].
[1] does not provide enough examples.
Perhaps [2] will help you (though I haven't tested it).

[1] https://docs.djangoproject.com/en/2.0/topics/logging/
[2]
https://www.simonkrueger.com/2015/05/27/logging-django-apps-to-syslog.html

Thanks,
Akihiro

2018年11月16日(金) 18:47 Tikkanen, Viktor (Nokia - FI/Espoo) <
viktor.tikka...@nokia.com>:

> Hi!
>
> For most openstack parts (e.g. Aodh, Cinder, Glance, Heat, Ironic,
> Keystone, Neutron, Nova) it was easy to get logs to syslog.
>
> For example for Heat something similar to this (into file
> templates/heat.conf.j2):
>
> # Syslog usage
> {% if heat_syslog_enabled %}
> use_syslog = True
> syslog_log_facility = LOG_LOCAL3
> {% else %}
> log_file = /var/log/heat/heat.log
> {% endif %}
>
> But how to get Horizon related logs to syslog?
>
> -V.
>
> __
> OpenStack Development Mailing 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] [horizon] how to get horizon related logs to syslog?

[Tikkanen, Viktor (Nokia - FI/Espoo)]

Hi!

For most openstack parts (e.g. Aodh, Cinder, Glance, Heat, Ironic, Keystone, 
Neutron, Nova) it was easy to get logs to syslog.

For example for Heat something similar to this (into file 
templates/heat.conf.j2):

# Syslog usage
{% if heat_syslog_enabled %}
use_syslog = True
syslog_log_facility = LOG_LOCAL3
{% else %}
log_file = /var/log/heat/heat.log
{% endif %}

But how to get Horizon related logs to syslog?

-V.

__
OpenStack Development Mailing 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] [horizon] No meeting this week

[Ivan Kolodyazhny]

Hi team,

Let's skip the meeting tomorrow due to the OpenStack Summit.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] [horizon][tc] Seeking feedback on the OpenStack cloud vision

[Zane Bitter]

Greetings, Horizon team!
As you may be aware, I've been working with other folks in the community 
on documenting a vision for OpenStack clouds (formerly known as the 
'Technical Vision') - essentially to interpret the mission statement in 
long-form, in a way that we can use to actually help guide decisions. 
You can read the latest draft here: https://review.openstack.org/592205


We're trying to get feedback from as many people as possible - in many 
ways the value is in the process of coming together to figure out what 
we're trying to achieve as a community with OpenStack and how we can 
work together to build it. The document is there to help us remember 
what we decided so we don't have to do it all again over and over.


The vision is structured with two sections that apply broadly to every 
project in OpenStack - describing the principles that we believe are 
essential to every cloud, and the ones that make OpenStack different 
from some other clouds. The third section is a list of design goals that 
we want OpenStack as a whole to be able to meet - ideally each project 
would be contributing toward one or more of these design goals.


We have said that other kinds of user interface, e.g. the CLI, are out 
of scope for the document (though not for OpenStack, of course!). After 
some discussion, we decided that Horizon being a service was more 
important to its categorisation than it being a user interface, so I 
wrote the Graphical User Interface design goal to ensure that it is 
covered. However, I'm sure y'all have spent much more time thinking 
about what Horizon contributes to OpenStack than I, so your feedback and 
suggestions are needed.


That is not the only way in which I think this document is relevant to 
the Horizon team: one of my goals with the exercise is to encourage the 
service projects to make sure their APIs make all of the 
operationally-relevant information available and legible to 
applications. That would include e.g. surfacing events, which I know is 
something that Horizon has wanted for a long time, and hopefully this 
will lead to easier ways to build a GUI without as much polling.


If you would like me or another TC member to join one of your team IRC 
meetings to discuss further what the vision means for your team, please 
reply to this thread to set it up. You are also welcome to bring up any 
questions in the TC IRC channel, #openstack-tc - there's more of us 
around during Office Hours 
(https://governance.openstack.org/tc/#office-hours), but you can talk to 
us at any time.


Feedback can also happen either in this thread or on the review 
https://review.openstack.org/592205


If the team is generally happy with the vision as it is and doesn't have 
any specific feedback, that's cool but I'd like to request that at least 
the PTL leave a vote on the review. It's important to know whether we 
are actually developing a consensus in the community or just talking to 
ourselves :)


many thanks,
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] [horizon][plugins] Horizon plugins validation on CI

[Ivan Kolodyazhny]

Hi Tony,

I like the idea to get functional tests instead of tempest. We can extend
our functional tests to plugins.

Personally, I don't have a strong opinion on what way we should go forward.
I'll support any community decision which helps us to get cross projects CI
up and running.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Thu, Oct 18, 2018 at 4:55 AM Tony Breeds  wrote:

> On Wed, Oct 17, 2018 at 04:18:26PM +0300, Ivan Kolodyazhny wrote:
> > Hi all,
> >
> > We discussed this topic at PTG both with Horizon and other teams. Sounds
> > like everybody is interested to have some cross-project CI jobs to verify
> > that plugins are not broken with the latest Horizon changes.
> >
> > The initial idea was to use tempest plugins for this effort like we do
> for
> > Horizon [1]. We've got a very simple test to verify that Horizon is up
> and
> > running and a user is able to login.
> >
> > It's easy to implement such tests for any existing horizon plugin. I
> tried
> > it for Heat and Manila dashboards.
>
> Given that I know very little about this but isn't it just as simple as
> running the say the octavia-dashboard[1] npm tests on all horizon changes?
> This would be similar to the way we run the nova[2] functional tests on all
> constraints changes in openstack/requirements.
>
> Yours Tony.
>
> [1] Of course all dashbaords/plugins
> [2] Not just nova but you get the idea
> __
> OpenStack Development Mailing 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] [horizon] xstatic-bootstrap-datepicker and twitter-bootstrap dependency

[Thomas Goirand]

Hi,

The python3-xstatic-bootstrap-datepicker Debian package runtime depends
on libjs-twitter-bootstrap-datepicker which itself depends on
libjs-twitter-bootstrap, which is produced by the twitter-bootstrap
source package. The twitter-bootstrap will go away from Debian Buster,
as per https://bugs.debian.org/907724

So a few questions here:
- Do I really need to have libjs-twitter-bootstrap-datepicker depend on
libjs-twitter-bootstrap (which is version 2 of bootstrap)?
- Is Horizon using bootstrap 3?
- What action does the Horizon team suggest to keep Horizon working in
Debian?

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] [horizon][plugins] Horizon plugins validation on CI

[Tony Breeds]

On Wed, Oct 17, 2018 at 04:18:26PM +0300, Ivan Kolodyazhny wrote:
> Hi all,
> 
> We discussed this topic at PTG both with Horizon and other teams. Sounds
> like everybody is interested to have some cross-project CI jobs to verify
> that plugins are not broken with the latest Horizon changes.
> 
> The initial idea was to use tempest plugins for this effort like we do for
> Horizon [1]. We've got a very simple test to verify that Horizon is up and
> running and a user is able to login.
> 
> It's easy to implement such tests for any existing horizon plugin. I tried
> it for Heat and Manila dashboards.

Given that I know very little about this but isn't it just as simple as
running the say the octavia-dashboard[1] npm tests on all horizon changes?
This would be similar to the way we run the nova[2] functional tests on all
constraints changes in openstack/requirements.

Yours Tony.

[1] Of course all dashbaords/plugins
[2] Not just nova but you get the idea


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] [horizon][plugins] Horizon plugins validation on CI

[Michael Johnson]

Hi Ivan,

As Octavia PTL I have no issue with adding a tempest-plugin repository
for the octavia-dashboard. I think we have had examples with the main
tempest tests and plugins where trying to do a suite of tests in one
repository becomes messy.

We may also want to consider doing a horizon-tempest-lib type of
repository that can host common code/tools for the dashboard plugins
to leverage. I'm thinking things like login code, etc.

Michael
On Wed, Oct 17, 2018 at 6:19 AM Ivan Kolodyazhny  wrote:
>
> Hi all,
>
> We discussed this topic at PTG both with Horizon and other teams. Sounds like 
> everybody is interested to have some cross-project CI jobs to verify that 
> plugins are not broken with the latest Horizon changes.
>
> The initial idea was to use tempest plugins for this effort like we do for 
> Horizon [1]. We've got a very simple test to verify that Horizon is up and 
> running and a user is able to login.
>
> It's easy to implement such tests for any existing horizon plugin. I tried it 
> for Heat and Manila dashboards.
>
> If I understand correctly how tempest plugins work, for such case we've got 
> such options:
>
> a) to create the same tempest plugins for each plugin - it this case, we need 
> to maintain new repos for tempest plugins
> b) add these tests to Horizon tempest plugin - in such case, it will be 
> harder for plugin maintainers to support these tests.
>
> If we don't want to go forward with tempest plugins, we can create similar 
> tests based on Horizon functional tests.
>
> I want to get more feedback both from Horizon and plugins teams on which 
> direction we should go and start implementation.
>
>
> [1] 
> https://github.com/openstack/tempest-horizon/blob/master/tempest_horizon/tests/scenario/test_dashboard_basic_ops.py#L138
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps

[Matt Riedemann]

On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote:


As you may know, unfortunately, Horizon doesn't support all features 
provided by APIs. That's why we created feature gaps list [1].


I'd got a lot of great conversations with projects teams during the PTG 
and we tried to figure out what should be done prioritize these tasks. 
It's really helpful for Horizon to get feedback from other teams to 
understand what features should be implemented next.


While I'm filling launchpad with new bugs and blueprints for [1], it 
would be good to review this list again and find some volunteers to 
decrease feature gaps.


[1] https://etherpad.openstack.org/p/horizon-feature-gap

Thanks everybody for any of your contributions to Horizon.


+openstack-sigs
+openstack-operators

I've left some notes for nova. This looks very similar to the compute 
API OSC gap analysis I did [1]. Unfortunately it's hard to prioritize 
what to really work on without some user/operator feedback - maybe we 
can get the user work group involved in trying to help prioritize what 
people really want that is missing from horizon, at least for compute?


[1] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc

--

Thanks,

Matt

__
OpenStack Development Mailing 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] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps

[Ivan Kolodyazhny]

Hi teams,

As you may know, unfortunately, Horizon doesn't support all features
provided by APIs. That's why we created feature gaps list [1].

I'd got a lot of great conversations with projects teams during the PTG and
we tried to figure out what should be done prioritize these tasks. It's
really helpful for Horizon to get feedback from other teams to understand
what features should be implemented next.

While I'm filling launchpad with new bugs and blueprints for [1], it
would be good to review this list again and find some volunteers to
decrease feature gaps.

[1] https://etherpad.openstack.org/p/horizon-feature-gap

Thanks everybody for any of your contributions to Horizon.


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] [horizon][plugins] Horizon plugins validation on CI

[Ivan Kolodyazhny]

Hi all,

We discussed this topic at PTG both with Horizon and other teams. Sounds
like everybody is interested to have some cross-project CI jobs to verify
that plugins are not broken with the latest Horizon changes.

The initial idea was to use tempest plugins for this effort like we do for
Horizon [1]. We've got a very simple test to verify that Horizon is up and
running and a user is able to login.

It's easy to implement such tests for any existing horizon plugin. I tried
it for Heat and Manila dashboards.

If I understand correctly how tempest plugins work, for such case we've got
such options:

a) to create the same tempest plugins for each plugin - it this case, we
need to maintain new repos for tempest plugins
b) add these tests to Horizon tempest plugin - in such case, it will be
harder for plugin maintainers to support these tests.

If we don't want to go forward with tempest plugins, we can create similar
tests based on Horizon functional tests.

I want to get more feedback both from Horizon and plugins teams on which
direction we should go and start implementation.


[1]
https://github.com/openstack/tempest-horizon/blob/master/tempest_horizon/tests/scenario/test_dashboard_basic_ops.py#L138

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] Horizon tutorial didn`t work

[Ivan Kolodyazhny]

Hi Jea-Min,

I filed a bug [1] and proposed a fix for it [2]

[1] https://bugs.launchpad.net/horizon/+bug/1796312
[2] https://review.openstack.org/608274

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Tue, Oct 2, 2018 at 6:55 AM Jea-Min Lim  wrote:

> Thanks for the reply.
>
> If you need any detailed information, let me know.
>
> Regards,
>
> 2018년 10월 1일 (월) 오후 6:53, Ivan Kolodyazhny 님이 작성:
>
>> Hi  Jea-Min,
>>
>> Thank you for your report. I'll check the manual and fix it asap.
>>
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>>
>> On Mon, Oct 1, 2018 at 9:38 AM Jea-Min Lim  wrote:
>>
>>> Hello everyone,
>>>
>>> I`m following a tutorial of Building a Dashboard using Horizon.
>>> (link:
>>> https://docs.openstack.org/horizon/latest/contributor/tutorials/dashboard.html#tutorials-dashboard
>>> )
>>>
>>> However, provided custom management command doesn't create boilerplate
>>> code.
>>>
>>> I typed tox -e manage -- startdash mydashboard --target
>>> openstack_dashboard/dashboards/mydashboard
>>>
>>> and the attached screenshot file is the execution result.
>>>
>>> Are there any recommendations to solve this problem?
>>>
>>> Regards.
>>>
>>> [image: result_jmlim.PNG]
>>>
>>> __
>>> OpenStack Development Mailing 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] [horizon][plugins] npm jobs fail due to new XStatic-jQuery release (was: Horizon gates are broken)

[Ivan Kolodyazhny]

Thanks for working on it, Shu.

Let's unblock gates and find a better long-term solution

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Mon, Oct 1, 2018 at 7:55 PM Duc Truong  wrote:

> Hi Shu,
>
> Thanks for proposing your fix.  It looks good to me.  I have submitted
> a similar patch for senlin-dashboard to unblock the broken gate test [1].
>
> [1] https://review.openstack.org/#/c/607003/
>
> Regards,
>
> Duc (dtruong)
> On Fri, Sep 28, 2018 at 2:24 AM Shu M.  wrote:
> >
> > Hi Ivan,
> >
> > Thank you for your help to our plugins and sorry for bothering you.
> > I found problem on installing horizon in "post-install", e.g. we should
> install horizon with upper-constraints.txt in "post-install".
> > I proposed patch[1] in zun-ui, please check it. If we can merge this, I
> will expand it the other remaining plugins.
> >
> > [1] https://review.openstack.org/#/c/606010/
> >
> > Thanks,
> > Shu Muto
> >
> > 2018年9月28日(金) 3:34 Ivan Kolodyazhny :
> >>
> >> Hi,
> >>
> >> Unfortunately, this issue affects some of the plugins too :(. At least
> gates for the magnum-ui, senlin-dashboard, zaqar-ui and zun-ui are broken
> now. I'm working both with project teams to fix it asap. Let's wait if [5]
> helps for senlin-dashboard and fix all the rest of plugins.
> >>
> >>
> >> [5] https://review.openstack.org/#/c/605826/
> >>
> >> Regards,
> >> Ivan Kolodyazhny,
> >> http://blog.e0ne.info/
> >>
> >>
> >> On Wed, Sep 26, 2018 at 4:50 PM Ivan Kolodyazhny 
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> Patch [1]  is merged and our gates are un-blocked now. I went throw
> review list and post 'recheck' where it was needed.
> >>>
> >>> We need to cherry-pick this fix to stable releases too. I'll do it asap
> >>>
> >>> Regards,
> >>> Ivan Kolodyazhny,
> >>> http://blog.e0ne.info/
> >>>
> >>>
> >>> On Mon, Sep 24, 2018 at 11:18 AM Ivan Kolodyazhny 
> wrote:
> 
>  Hi team,
> 
>  Unfortunately, horizon gates are broken now. We can't merge any patch
> due to the -1 from CI.
>  I don't want to disable tests now, that's why I proposed a fix [1].
> 
>  We'd got released some of XStatic-* packages last week. At least new
> XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for
> requirements repo [4] to prevent such issues in the future.
> 
>  Please, do not try 'recheck' until [1] will be merged.
> 
>  [1] https://review.openstack.org/#/c/604611/
>  [2] https://pypi.org/project/XStatic-jQuery/#history
>  [3] https://bugs.launchpad.net/horizon/+bug/1794028
>  [4] https://review.openstack.org/#/c/604613/
> 
>  Regards,
>  Ivan Kolodyazhny,
>  http://blog.e0ne.info/
> >>
> >>
> __
> >> OpenStack Development Mailing 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] [Horizon] Horizon tutorial didn`t work

[Jea-Min Lim]

Thanks for the reply.

If you need any detailed information, let me know.

Regards,

2018년 10월 1일 (월) 오후 6:53, Ivan Kolodyazhny 님이 작성:

> Hi  Jea-Min,
>
> Thank you for your report. I'll check the manual and fix it asap.
>
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
>
> On Mon, Oct 1, 2018 at 9:38 AM Jea-Min Lim  wrote:
>
>> Hello everyone,
>>
>> I`m following a tutorial of Building a Dashboard using Horizon.
>> (link:
>> https://docs.openstack.org/horizon/latest/contributor/tutorials/dashboard.html#tutorials-dashboard
>> )
>>
>> However, provided custom management command doesn't create boilerplate
>> code.
>>
>> I typed tox -e manage -- startdash mydashboard --target
>> openstack_dashboard/dashboards/mydashboard
>>
>> and the attached screenshot file is the execution result.
>>
>> Are there any recommendations to solve this problem?
>>
>> Regards.
>>
>> [image: result_jmlim.PNG]
>> __
>> OpenStack Development Mailing 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] [horizon][plugins] npm jobs fail due to new XStatic-jQuery release (was: Horizon gates are broken)

[Duc Truong]

Hi Shu,

Thanks for proposing your fix.  It looks good to me.  I have submitted
a similar patch for senlin-dashboard to unblock the broken gate test [1].

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

Regards,

Duc (dtruong)
On Fri, Sep 28, 2018 at 2:24 AM Shu M.  wrote:
>
> Hi Ivan,
>
> Thank you for your help to our plugins and sorry for bothering you.
> I found problem on installing horizon in "post-install", e.g. we should 
> install horizon with upper-constraints.txt in "post-install".
> I proposed patch[1] in zun-ui, please check it. If we can merge this, I will 
> expand it the other remaining plugins.
>
> [1] https://review.openstack.org/#/c/606010/
>
> Thanks,
> Shu Muto
>
> 2018年9月28日(金) 3:34 Ivan Kolodyazhny :
>>
>> Hi,
>>
>> Unfortunately, this issue affects some of the plugins too :(. At least gates 
>> for the magnum-ui, senlin-dashboard, zaqar-ui and zun-ui are broken now. I'm 
>> working both with project teams to fix it asap. Let's wait if [5] helps for 
>> senlin-dashboard and fix all the rest of plugins.
>>
>>
>> [5] https://review.openstack.org/#/c/605826/
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>>
>> On Wed, Sep 26, 2018 at 4:50 PM Ivan Kolodyazhny  wrote:
>>>
>>> Hi all,
>>>
>>> Patch [1]  is merged and our gates are un-blocked now. I went throw review 
>>> list and post 'recheck' where it was needed.
>>>
>>> We need to cherry-pick this fix to stable releases too. I'll do it asap
>>>
>>> Regards,
>>> Ivan Kolodyazhny,
>>> http://blog.e0ne.info/
>>>
>>>
>>> On Mon, Sep 24, 2018 at 11:18 AM Ivan Kolodyazhny  wrote:

 Hi team,

 Unfortunately, horizon gates are broken now. We can't merge any patch due 
 to the -1 from CI.
 I don't want to disable tests now, that's why I proposed a fix [1].

 We'd got released some of XStatic-* packages last week. At least new 
 XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for 
 requirements repo [4] to prevent such issues in the future.

 Please, do not try 'recheck' until [1] will be merged.

 [1] https://review.openstack.org/#/c/604611/
 [2] https://pypi.org/project/XStatic-jQuery/#history
 [3] https://bugs.launchpad.net/horizon/+bug/1794028
 [4] https://review.openstack.org/#/c/604613/

 Regards,
 Ivan Kolodyazhny,
 http://blog.e0ne.info/
>>
>> __
>> OpenStack Development Mailing 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] [Horizon] Horizon tutorial didn`t work

[Ivan Kolodyazhny]

Hi  Jea-Min,

Thank you for your report. I'll check the manual and fix it asap.


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Mon, Oct 1, 2018 at 9:38 AM Jea-Min Lim  wrote:

> Hello everyone,
>
> I`m following a tutorial of Building a Dashboard using Horizon.
> (link:
> https://docs.openstack.org/horizon/latest/contributor/tutorials/dashboard.html#tutorials-dashboard
> )
>
> However, provided custom management command doesn't create boilerplate
> code.
>
> I typed tox -e manage -- startdash mydashboard --target
> openstack_dashboard/dashboards/mydashboard
>
> and the attached screenshot file is the execution result.
>
> Are there any recommendations to solve this problem?
>
> Regards.
>
> [image: result_jmlim.PNG]
> __
> OpenStack Development Mailing 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] [Horizon] Horizon tutorial didn`t work

[Jea-Min Lim]

Hello everyone,

I`m following a tutorial of Building a Dashboard using Horizon.
(link:
https://docs.openstack.org/horizon/latest/contributor/tutorials/dashboard.html#tutorials-dashboard
)

However, provided custom management command doesn't create boilerplate
code.

I typed tox -e manage -- startdash mydashboard --target
openstack_dashboard/dashboards/mydashboard

and the attached screenshot file is the execution result.

Are there any recommendations to solve this problem?

Regards.

[image: result_jmlim.PNG]
__
OpenStack Development Mailing 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][plugins] npm jobs fail due to new XStatic-jQuery release (was: Horizon gates are broken)

[Shu M.]

Hi Ivan,

Thank you for your help to our plugins and sorry for bothering you.
I found problem on installing horizon in "post-install", e.g. we should
install horizon with upper-constraints.txt in "post-install".
I proposed patch[1] in zun-ui, please check it. If we can merge this, I
will expand it the other remaining plugins.

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

Thanks,
Shu Muto

2018年9月28日(金) 3:34 Ivan Kolodyazhny :

> Hi,
>
> Unfortunately, this issue affects some of the plugins too :(. At least
> gates for the magnum-ui, senlin-dashboard, zaqar-ui and zun-ui are broken
> now. I'm working both with project teams to fix it asap. Let's wait if [5]
> helps for senlin-dashboard and fix all the rest of plugins.
>
>
> [5] https://review.openstack.org/#/c/605826/
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
>
> On Wed, Sep 26, 2018 at 4:50 PM Ivan Kolodyazhny  wrote:
>
>> Hi all,
>>
>> Patch [1]  is merged and our gates are un-blocked now. I went throw
>> review list and post 'recheck' where it was needed.
>>
>> We need to cherry-pick this fix to stable releases too. I'll do it asap
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>>
>> On Mon, Sep 24, 2018 at 11:18 AM Ivan Kolodyazhny  wrote:
>>
>>> Hi team,
>>>
>>> Unfortunately, horizon gates are broken now. We can't merge any patch
>>> due to the -1 from CI.
>>> I don't want to disable tests now, that's why I proposed a fix [1].
>>>
>>> We'd got released some of XStatic-* packages last week. At least new
>>> XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for
>>> requirements repo [4] to prevent such issues in the future.
>>>
>>> Please, do not try 'recheck' until [1] will be merged.
>>>
>>> [1] https://review.openstack.org/#/c/604611/
>>> [2] https://pypi.org/project/XStatic-jQuery/#history
>>> [3] https://bugs.launchpad.net/horizon/+bug/1794028
>>> [4] https://review.openstack.org/#/c/604613/
>>>
>>> Regards,
>>> Ivan Kolodyazhny,
>>> http://blog.e0ne.info/
>>>
>> __
> OpenStack Development Mailing 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] [horizon][plugins] npm jobs fail due to new XStatic-jQuery release (was: Horizon gates are broken)

[Ivan Kolodyazhny]

Hi,

Unfortunately, this issue affects some of the plugins too :(. At least
gates for the magnum-ui, senlin-dashboard, zaqar-ui and zun-ui are broken
now. I'm working both with project teams to fix it asap. Let's wait if [5]
helps for senlin-dashboard and fix all the rest of plugins.


[5] https://review.openstack.org/#/c/605826/

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Wed, Sep 26, 2018 at 4:50 PM Ivan Kolodyazhny  wrote:

> Hi all,
>
> Patch [1]  is merged and our gates are un-blocked now. I went throw review
> list and post 'recheck' where it was needed.
>
> We need to cherry-pick this fix to stable releases too. I'll do it asap
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
>
> On Mon, Sep 24, 2018 at 11:18 AM Ivan Kolodyazhny  wrote:
>
>> Hi team,
>>
>> Unfortunately, horizon gates are broken now. We can't merge any patch due
>> to the -1 from CI.
>> I don't want to disable tests now, that's why I proposed a fix [1].
>>
>> We'd got released some of XStatic-* packages last week. At least new
>> XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for
>> requirements repo [4] to prevent such issues in the future.
>>
>> Please, do not try 'recheck' until [1] will be merged.
>>
>> [1] https://review.openstack.org/#/c/604611/
>> [2] https://pypi.org/project/XStatic-jQuery/#history
>> [3] https://bugs.launchpad.net/horizon/+bug/1794028
>> [4] https://review.openstack.org/#/c/604613/
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>
__
OpenStack Development Mailing 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] Horizon gates are broken

[Ivan Kolodyazhny]

Hi all,

Patch [1]  is merged and our gates are un-blocked now. I went throw review
list and post 'recheck' where it was needed.

We need to cherry-pick this fix to stable releases too. I'll do it asap

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Mon, Sep 24, 2018 at 11:18 AM Ivan Kolodyazhny  wrote:

> Hi team,
>
> Unfortunately, horizon gates are broken now. We can't merge any patch due
> to the -1 from CI.
> I don't want to disable tests now, that's why I proposed a fix [1].
>
> We'd got released some of XStatic-* packages last week. At least new
> XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for
> requirements repo [4] to prevent such issues in the future.
>
> Please, do not try 'recheck' until [1] will be merged.
>
> [1] https://review.openstack.org/#/c/604611/
> [2] https://pypi.org/project/XStatic-jQuery/#history
> [3] https://bugs.launchpad.net/horizon/+bug/1794028
> [4] https://review.openstack.org/#/c/604613/
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
__
OpenStack Development Mailing 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] [horizon] Horizon gates are broken

[Ivan Kolodyazhny]

Hi team,

Unfortunately, horizon gates are broken now. We can't merge any patch due
to the -1 from CI.
I don't want to disable tests now, that's why I proposed a fix [1].

We'd got released some of XStatic-* packages last week. At least new
XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for
requirements repo [4] to prevent such issues in the future.

Please, do not try 'recheck' until [1] will be merged.

[1] https://review.openstack.org/#/c/604611/
[2] https://pypi.org/project/XStatic-jQuery/#history
[3] https://bugs.launchpad.net/horizon/+bug/1794028
[4] https://review.openstack.org/#/c/604613/

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] [horizon][plugins] Development environment for Horizon plugins

[Ivan Kolodyazhny]

Hi team,

Some time ago we've found an issue that there is no simple way to test
Horizon plugin locally with the current version of Horizon [1], [2].

It leads to the situation when plugins developers use the latest released
Horizon version instead of the latest master during new features
development. This issue is not reproduced on CI because Zuul does a great
job here.

We discussed this issue at the PTG [2] (line #163) and decided to go
forward with a such [3] solution for now instead of a custom solution in
each plugin like [4].

If anybody has any other ideas or concerns, please let me know.



[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html
[2] https://etherpad.openstack.org/p/horizon-ptg-planning-denver-2018
[3] https://review.openstack.org/#/c/601836/
[4] https://github.com/openstack/magnum-ui/blob/master/tox.ini#L23


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] [horizon] No meeting next week

[Ivan Kolodyazhny]

Hi team,

A lot of us will attend PTG in Denver next week so we skip the meeting on
9/12.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] [horizon][stable] Removing Inactive Cores

[Ivan Kolodyazhny]

Hi team,

Since we're at the beginning of Stein release cycle, I think it's a good
time to do some cleanup in our core teams.

First of all, I would like to say a big Thank you to everybody who
contributed as Core Reviewer to Horizon.

Unfortunately, some people became inactive as reviewers during the last few
cycles, that's why I propose to remove them from Horizon Core and Horizon
Stable Core teams. I'm pretty sure that you could be added to the teams
again once your contribution will be active again.

Changes to horizon-core team:
- Kenji Ishii
- Tatiana Ovchinnikova
- Ying Zuo

Changes to horizon-stable-maint team:
- Doug Fish
- Lin Hua Cheng
- Matthias Runge
- Richard Jones
- Rob Cresswell
- Thai Tran
- Ying Zuo





Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] horizon 14.0.0.0rc2 (rocky)

[no-reply]

Hello everyone,

A new release candidate for horizon for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/horizon/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

https://git.openstack.org/cgit/openstack/horizon/log/?h=stable/rocky

Release notes for horizon can be found at:

https://docs.openstack.org/releasenotes/horizon/




__
OpenStack Development Mailing 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] horizon 14.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

A new release candidate for horizon for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/horizon/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/horizon/log/?h=stable/rocky

Release notes for horizon can be found at:

http://docs.openstack.org/releasenotes/horizon/




__
OpenStack Development Mailing 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] [horizon] PTL on vacation: what to do with meeting and RC1?

[Ivan Kolodyazhny]

Hi team,

I'll be on PTO next week. Are we OK to cancel the next meeting?

I remember that next week is a deadline for RC1, so I'm going to propose a
patch to release it
a bit later next week: Tuesday or Wednesday.

In an emergency case, please, reach me via e-mail because I'll have a
limited internet access
so I'll be mostly offline in IRC.


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] [horizon] Planning Etherpad for Denver PTG

[Ivan Kolodyazhny]

Hi team,

I've created an etherpad [1] to gather topics for PTG discussions in
Denver.

Please, do not hesitate to add any topic you think is valuable even you
won't
attend PTG.


I hope to see all of you in September!


[1] https://etherpad.openstack.org/p/horizon-ptg-planning-denver-2018

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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][plugins] Introduce horizonlib (again)

[Ivan Kolodyazhny]

Hi Doug,

We discussed this option a bit too. Maybe we need to think about this again.

>From my point of view, it would be better to keep current release model for
now,
because we've got a very small amount of active horizon contributors, so
current release
model helps us deliver the project in time. From the other side, your
option is less
complicated and could be easier to implement.

Let's get more feedback from the team before further discussion.



Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, Jun 13, 2018 at 6:43 PM, Doug Hellmann 
wrote:

> Excerpts from Ivan Kolodyazhny's message of 2018-06-13 18:01:26 +0300:
> > Hi team,
> >
> > Last week on the Horizon meeting we discussed [1] possible options for
> > Horizon release model to address current issues for plugins maintainers.
> > Some background could be found here [2].
> >
> > The main issue is that we should have some stable API for plugins and be
> > able to release it as needed. We're trying to cover several use cases
> with
> > this effort. E.g:
> > - do not break plugins with Horizon changes (cross-project CI would help
> > with some issues here too)
> > - provide an easy way to develop plugins which require specific Horizon
> > version and features
> >
> > For now, most of the plugins use 'horizon' package to implement
> > dashboard extensions. Some plugins use parts of 'openstack_dashboard'
> > package. In such case, it becomes complicated to develop plugins based on
> > current master and have CI up and running.
> >
> > The idea is to introduce something like 'horizonlib' or 'horizon-sdk'
> with
> > a stable API for plugin development. We're going to collect everything
> > needed for this library, so plugins developers could consume only it and
> do
> > not relate on any internal Horizon things.
> >
> > We'd got horizonlib in the past. Unfortunately, we missed information
> about
> > what was good or bad but we'll do our best to succeed in this.
> >
> >
> > If you have any comments or questions, please do not hesitate to drop few
> > words into this conversation or ping me in IRC. We're going to collect as
> > much feedback as we can before we'll discuss it in details during the
> next
> > PTG.
> >
> >
> > [1]
> > http://eavesdrop.openstack.org/meetings/horizon/2018/
> horizon.2018-06-06-15.01.log.html#l-29
> > [2]
> > http://lists.openstack.org/pipermail/openstack-dev/2018-
> March/128310.html
> >
> > Regards,
> > Ivan Kolodyazhny,
> > http://blog.e0ne.info/
>
> Another solution that may end up being less work is to release Horizon
> using the cycle-with-intermediary model and publish the releases to
> PyPI. Those two changes would let you release changes at any point in
> the cycle, to support your plugin authors, and would not require
> reorganizing the code in Horizon to build a new release artifact.
>
> The release team would be happy to offer advice about how to make the
> changes, if you want to talk about it.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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][plugins] Third-party JavaScript libraries and Xstatic Python packages

[Ivan Kolodyazhny]

Fixed horizon tag in the subject :(

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Mon, Jun 18, 2018 at 4:11 PM, Ivan Kolodyazhny  wrote:

> Hi team,
>
> As you may know, Horizon uses both Python and JavaScript dependencies as
> well. All of our JS dependencies are packed into the xstatic-* packages
> which could be installed like a regular python package. All current
> xstatic-* packages could be found on the Horizon's deliverables list [1].
>
> We need all of these things to make development and packaging processes
> easier.
>
> Of course, we can't cover all cases and JS libs, so there is a manual on
> how to create new xstatic package [2].
>
>
> Historically, all xstatic-* projects were maintained by Horizon Core
> team. Probably, they were introduced even before we've got plugins
> implemented but it doesn't matter at this point.
>
> Today, when we've got dozens of horizon plugins [3], some of them would
> like to use new xstatic packages which are not existing at the moment. E.g.:
> - heat-dashboard uses some JS libs which are nor required by Horizon
> itself.
> - vitrage-dashboard team is going to use React in their plugin.
>
> We discussed it briefly on the last meeting [4], As Horizon team, we don't
> want to forbid using some 3rd-party JS lib if it's acceptable by license.
> From the other side, Horizon Core team can't maintain all xstatic-*
> packages which could be needed by plugins. That's why we decided to add
> some folks form heat-dashboard team to xstatic-* core for that projects,
> which are used only be Heat Dashboard now. IMO, it looks like a reasonable
> and fair enough solution.
>
> I think we're OK if plugin teams will share the responsibility to maintain
> their xstatic-* dependencies both with Horizon team following current
> guidelines [2].
>
> Maintaining xstatic-* project means:
> - create this repo according to the current guidelines
> - follow community rules according to stable policy
> - publish a new version of xstatic project if it's required by bugfixes,
> security fixes, new features
> - help other teams to integrate this project into their plugin.
>
>
> I hope if we agree on things above it helps both Horizon and plugin teams
> to deliver new versions faster with a limited teams capacity.
>
>
>
> [1] https://governance.openstack.org/tc/reference/projects/horizon.html#
> deliverables
> [2] https://docs.openstack.org/horizon/latest/contributor/
> contributing.html#javascript-and-css-libraries-using-xstatic
> [3] https://docs.openstack.org/horizon/latest/install/plugin-registry.html
> [4] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-06-
> 13-15.04.log.html#l-124
>
>
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
__
OpenStack Development Mailing 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][plugins] Introduce horizonlib (again)

[Doug Hellmann]

Excerpts from Ivan Kolodyazhny's message of 2018-06-13 18:01:26 +0300:
> Hi team,
> 
> Last week on the Horizon meeting we discussed [1] possible options for
> Horizon release model to address current issues for plugins maintainers.
> Some background could be found here [2].
> 
> The main issue is that we should have some stable API for plugins and be
> able to release it as needed. We're trying to cover several use cases with
> this effort. E.g:
> - do not break plugins with Horizon changes (cross-project CI would help
> with some issues here too)
> - provide an easy way to develop plugins which require specific Horizon
> version and features
> 
> For now, most of the plugins use 'horizon' package to implement
> dashboard extensions. Some plugins use parts of 'openstack_dashboard'
> package. In such case, it becomes complicated to develop plugins based on
> current master and have CI up and running.
> 
> The idea is to introduce something like 'horizonlib' or 'horizon-sdk' with
> a stable API for plugin development. We're going to collect everything
> needed for this library, so plugins developers could consume only it and do
> not relate on any internal Horizon things.
> 
> We'd got horizonlib in the past. Unfortunately, we missed information about
> what was good or bad but we'll do our best to succeed in this.
> 
> 
> If you have any comments or questions, please do not hesitate to drop few
> words into this conversation or ping me in IRC. We're going to collect as
> much feedback as we can before we'll discuss it in details during the next
> PTG.
> 
> 
> [1]
> http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-06-06-15.01.log.html#l-29
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html
> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/

Another solution that may end up being less work is to release Horizon
using the cycle-with-intermediary model and publish the releases to
PyPI. Those two changes would let you release changes at any point in
the cycle, to support your plugin authors, and would not require
reorganizing the code in Horizon to build a new release artifact.

The release team would be happy to offer advice about how to make the
changes, if you want to talk about it.

Doug

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

[openstack-dev] [horizon][plugins] Introduce horizonlib (again)

[Ivan Kolodyazhny]

Hi team,

Last week on the Horizon meeting we discussed [1] possible options for
Horizon release model to address current issues for plugins maintainers.
Some background could be found here [2].

The main issue is that we should have some stable API for plugins and be
able to release it as needed. We're trying to cover several use cases with
this effort. E.g:
- do not break plugins with Horizon changes (cross-project CI would help
with some issues here too)
- provide an easy way to develop plugins which require specific Horizon
version and features

For now, most of the plugins use 'horizon' package to implement
dashboard extensions. Some plugins use parts of 'openstack_dashboard'
package. In such case, it becomes complicated to develop plugins based on
current master and have CI up and running.

The idea is to introduce something like 'horizonlib' or 'horizon-sdk' with
a stable API for plugin development. We're going to collect everything
needed for this library, so plugins developers could consume only it and do
not relate on any internal Horizon things.

We'd got horizonlib in the past. Unfortunately, we missed information about
what was good or bad but we'll do our best to succeed in this.


If you have any comments or questions, please do not hesitate to drop few
words into this conversation or ping me in IRC. We're going to collect as
much feedback as we can before we'll discuss it in details during the next
PTG.


[1]
http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-06-06-15.01.log.html#l-29
[2]
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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

[Radomir Dopieralski]

Some of our xstatic packages require an elaborate build process, as they
use various javascript-based tools to do the build. In this case, it's more
than just minification — it's macros and includes, basically a
pre-processor, and it would be very hard to re-create that in Python. Thus,
we did some exceptions and included the minified files in those cases. But
when it's just about minifying, then the application serving the files is
responsible for that, and the xstatic package shouldn't contain those files.

On Wed, Jun 6, 2018 at 5:45 AM, Akihiro Motoki  wrote:

> 2018年6月6日(水) 11:54 Xinni Ge :
>
>> Hi, akihiro and other guys,
>>
>> I understand why minified is considered to be non-free, but I was
>> confused about the statement
>> "At the very least, a non-minified version should be present next to the
>> minified version" [1]
>> in the documentation.
>>
>> Actually in existing xstatic repo, I observed several minified files in
>> angular_fileupload, jquery-migrate, or bootstrap_scss.
>> So, I uploaded those minified files as in the release package of
>>  angular/material.
>>
>
> Good point. My interpretation is:
> - Basically minified files should not be included in xstatic deliverables.
> - Even though not suggested, if minified files are included, corresponding
> non-minified version must be included.
>
> Considering this, I believe we should not include minified files for new
> xstatic deliverables.
> Makes sense?
>
>
>>
>> Personally I don't insist on minified files, and I will delete all
>> minified files and re-upload the patch.
>> Thanks a lot for the advice.
>>
>
> Thanks for understanding and your patience.
> Let's land pending reviews soon :)
>
> Akihiro
>
>
>>
>> [1] https://docs.openstack.org/horizon/latest/contributor/
>> topics/packaging.html#minified-javascript-policy
>>
>> 
>> Ge Xinni
>> Email: xinni.ge1...@gmail.com
>> 
>>
>> On Tue, Jun 5, 2018 at 8:59 PM, Akihiro Motoki  wrote:
>>
>>> Hi,
>>>
>>> Sorry for re-using the ancient ML thread.
>>> Looking at recent xstatic-* repo reviews, I am a bit afraid that
>>> xstatic-cores do not have a common understanding on the principle of
>>> xstatic packages.
>>> I hope all xstatic-cores re-read "Packing Software" in the horizon
>>> contributor docs [1], especially "Minified Javascript policy" [2],
>>> carefully.
>>>
>>> Thanks,
>>> Akihiro
>>>
>>> [1] https://docs.openstack.org/horizon/latest/contributor/
>>> topics/packaging.html
>>> [2] https://docs.openstack.org/horizon/latest/
>>> contributor/topics/packaging.html#minified-javascript-policy
>>>
>>>
>>> 2018年4月4日(水) 14:35 Xinni Ge :
>>>
 Hi Ivan and other Horizon team member,

 Thanks for adding us into xstatic-core group.
 But I still need your opinion and help to release the newly-added
 xstatic packages to pypi index.

 Current `xstatic-core` group doesn't have the permission to PUSH SIGNED
 TAG, and I cannot release the first non-trivial version.

 If I (or maybe Kaz) could be added into xstatic-release group, we can
 release all the 8 packages by ourselves.

 Or, we are very appreciate if any member of xstatic-release could help
 to do it.

 Just for your quick access, here is the link of access permission page
 of one xstatic package.
 https://review.openstack.org/#/admin/projects/openstack/
 xstatic-angular-material,access

 --
 Best Regards,
 Xinni

 On Thu, Mar 29, 2018 at 9:59 AM, Kaz Shinohara 
 wrote:

> Hi Ivan,
>
>
> Thank you very much.
> I've confirmed that all of us have been added to xstatic-core.
>
> As discussed, we will focus on the followings what we added for
> heat-dashboard, will not touch other xstatic repos as core.
>
> xstatic-angular-material
> xstatic-angular-notify
> xstatic-angular-uuid
> xstatic-angular-vis
> xstatic-filesaver
> xstatic-js-yaml
> xstatic-json2yaml
> xstatic-vis
>
> Regards,
> Kaz
>
> 2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny :
> > Hi Kuz,
> >
> > Don't worry, we're on the same page with you. I added both you,
> Xinni and
> > Keichii to the xstatic-core group. Thank you for your contributions!
> >
> > Regards,
> > Ivan Kolodyazhny,
> > http://blog.e0ne.info/
> >
> > On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara 
> wrote:
> >>
> >> Hi Ivan & Horizon folks
> >>
> >>
> >> AFAIK, Horizon team had conclusion that you will add the specific
> >> members to xstatic-core, correct ?
> >> Can I ask you to add the following members ?
> >> # All of tree are heat-dashboard core.
> >>
> >> Kazunori Shinohara / ksnhr.t...@gmail.com #myself
> >> Xinni Ge / xinni.ge1...@gmail.com
> >> Keiichi Hikita / keiichi.hik...@gmail.com
> >>
> >> Please give me a shout, if we are not on same page or any concern.
> >>
> >> Regar

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

[Akihiro Motoki]

2018年6月6日(水) 11:54 Xinni Ge :

> Hi, akihiro and other guys,
>
> I understand why minified is considered to be non-free, but I was confused
> about the statement
> "At the very least, a non-minified version should be present next to the
> minified version" [1]
> in the documentation.
>
> Actually in existing xstatic repo, I observed several minified files in
> angular_fileupload, jquery-migrate, or bootstrap_scss.
> So, I uploaded those minified files as in the release package of
>  angular/material.
>

Good point. My interpretation is:
- Basically minified files should not be included in xstatic deliverables.
- Even though not suggested, if minified files are included, corresponding
non-minified version must be included.

Considering this, I believe we should not include minified files for new
xstatic deliverables.
Makes sense?


>
> Personally I don't insist on minified files, and I will delete all
> minified files and re-upload the patch.
> Thanks a lot for the advice.
>

Thanks for understanding and your patience.
Let's land pending reviews soon :)

Akihiro


>
> [1]
> https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html#minified-javascript-policy
>
> 
> Ge Xinni
> Email: xinni.ge1...@gmail.com
> 
>
> On Tue, Jun 5, 2018 at 8:59 PM, Akihiro Motoki  wrote:
>
>> Hi,
>>
>> Sorry for re-using the ancient ML thread.
>> Looking at recent xstatic-* repo reviews, I am a bit afraid that
>> xstatic-cores do not have a common understanding on the principle of
>> xstatic packages.
>> I hope all xstatic-cores re-read "Packing Software" in the horizon
>> contributor docs [1], especially "Minified Javascript policy" [2],
>> carefully.
>>
>> Thanks,
>> Akihiro
>>
>> [1]
>> https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html
>> [2]
>> https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html#minified-javascript-policy
>>
>>
>> 2018年4月4日(水) 14:35 Xinni Ge :
>>
>>> Hi Ivan and other Horizon team member,
>>>
>>> Thanks for adding us into xstatic-core group.
>>> But I still need your opinion and help to release the newly-added
>>> xstatic packages to pypi index.
>>>
>>> Current `xstatic-core` group doesn't have the permission to PUSH SIGNED
>>> TAG, and I cannot release the first non-trivial version.
>>>
>>> If I (or maybe Kaz) could be added into xstatic-release group, we can
>>> release all the 8 packages by ourselves.
>>>
>>> Or, we are very appreciate if any member of xstatic-release could help
>>> to do it.
>>>
>>> Just for your quick access, here is the link of access permission page
>>> of one xstatic package.
>>>
>>> https://review.openstack.org/#/admin/projects/openstack/xstatic-angular-material,access
>>>
>>>
>>> --
>>> Best Regards,
>>> Xinni
>>>
>>> On Thu, Mar 29, 2018 at 9:59 AM, Kaz Shinohara 
>>> wrote:
>>>
 Hi Ivan,


 Thank you very much.
 I've confirmed that all of us have been added to xstatic-core.

 As discussed, we will focus on the followings what we added for
 heat-dashboard, will not touch other xstatic repos as core.

 xstatic-angular-material
 xstatic-angular-notify
 xstatic-angular-uuid
 xstatic-angular-vis
 xstatic-filesaver
 xstatic-js-yaml
 xstatic-json2yaml
 xstatic-vis

 Regards,
 Kaz

 2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny :
 > Hi Kuz,
 >
 > Don't worry, we're on the same page with you. I added both you, Xinni
 and
 > Keichii to the xstatic-core group. Thank you for your contributions!
 >
 > Regards,
 > Ivan Kolodyazhny,
 > http://blog.e0ne.info/
 >
 > On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara 
 wrote:
 >>
 >> Hi Ivan & Horizon folks
 >>
 >>
 >> AFAIK, Horizon team had conclusion that you will add the specific
 >> members to xstatic-core, correct ?
 >> Can I ask you to add the following members ?
 >> # All of tree are heat-dashboard core.
 >>
 >> Kazunori Shinohara / ksnhr.t...@gmail.com #myself
 >> Xinni Ge / xinni.ge1...@gmail.com
 >> Keiichi Hikita / keiichi.hik...@gmail.com
 >>
 >> Please give me a shout, if we are not on same page or any concern.
 >>
 >> Regards,
 >> Kaz
 >>
 >>
 >> 2018-03-21 22:29 GMT+09:00 Kaz Shinohara :
 >> > Hi Ivan, Akihiro,
 >> >
 >> >
 >> > Thanks for your kind arrangement.
 >> > Looking forward to hearing your decision soon.
 >> >
 >> > Regards,
 >> > Kaz
 >> >
 >> > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
 >> >> HI Team,
 >> >>
 >> >> From my perspective, I'm OK both with #2 and #3 options. I agree
 that
 >> >> #4
 >> >> could be too complicated for us. Anyway, we've got this topic on
 the
 >> >> meeting
 >> >> agenda [1] so we'll discuss it there too. I'll share our decision
 after
 >> >> the
 >> >> meeting.
 >> >>
 >> >> [1] http

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

[Xinni Ge]

Hi, akihiro and other guys,

I understand why minified is considered to be non-free, but I was confused
about the statement
"At the very least, a non-minified version should be present next to the
minified version" [1]
in the documentation.

Actually in existing xstatic repo, I observed several minified files in
angular_fileupload, jquery-migrate, or bootstrap_scss.
So, I uploaded those minified files as in the release package of
 angular/material.

Personally I don't insist on minified files, and I will delete all minified
files and re-upload the patch.
Thanks a lot for the advice.

[1]
https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html#minified-javascript-policy


Ge Xinni
Email: xinni.ge1...@gmail.com


On Tue, Jun 5, 2018 at 8:59 PM, Akihiro Motoki  wrote:

> Hi,
>
> Sorry for re-using the ancient ML thread.
> Looking at recent xstatic-* repo reviews, I am a bit afraid that
> xstatic-cores do not have a common understanding on the principle of
> xstatic packages.
> I hope all xstatic-cores re-read "Packing Software" in the horizon
> contributor docs [1], especially "Minified Javascript policy" [2],
> carefully.
>
> Thanks,
> Akihiro
>
> [1] https://docs.openstack.org/horizon/latest/contributor/
> topics/packaging.html
> [2] https://docs.openstack.org/horizon/latest/
> contributor/topics/packaging.html#minified-javascript-policy
>
>
> 2018年4月4日(水) 14:35 Xinni Ge :
>
>> Hi Ivan and other Horizon team member,
>>
>> Thanks for adding us into xstatic-core group.
>> But I still need your opinion and help to release the newly-added xstatic
>> packages to pypi index.
>>
>> Current `xstatic-core` group doesn't have the permission to PUSH SIGNED
>> TAG, and I cannot release the first non-trivial version.
>>
>> If I (or maybe Kaz) could be added into xstatic-release group, we can
>> release all the 8 packages by ourselves.
>>
>> Or, we are very appreciate if any member of xstatic-release could help to
>> do it.
>>
>> Just for your quick access, here is the link of access permission page of
>> one xstatic package.
>> https://review.openstack.org/#/admin/projects/openstack/
>> xstatic-angular-material,access
>>
>> --
>> Best Regards,
>> Xinni
>>
>> On Thu, Mar 29, 2018 at 9:59 AM, Kaz Shinohara 
>> wrote:
>>
>>> Hi Ivan,
>>>
>>>
>>> Thank you very much.
>>> I've confirmed that all of us have been added to xstatic-core.
>>>
>>> As discussed, we will focus on the followings what we added for
>>> heat-dashboard, will not touch other xstatic repos as core.
>>>
>>> xstatic-angular-material
>>> xstatic-angular-notify
>>> xstatic-angular-uuid
>>> xstatic-angular-vis
>>> xstatic-filesaver
>>> xstatic-js-yaml
>>> xstatic-json2yaml
>>> xstatic-vis
>>>
>>> Regards,
>>> Kaz
>>>
>>> 2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny :
>>> > Hi Kuz,
>>> >
>>> > Don't worry, we're on the same page with you. I added both you, Xinni
>>> and
>>> > Keichii to the xstatic-core group. Thank you for your contributions!
>>> >
>>> > Regards,
>>> > Ivan Kolodyazhny,
>>> > http://blog.e0ne.info/
>>> >
>>> > On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara 
>>> wrote:
>>> >>
>>> >> Hi Ivan & Horizon folks
>>> >>
>>> >>
>>> >> AFAIK, Horizon team had conclusion that you will add the specific
>>> >> members to xstatic-core, correct ?
>>> >> Can I ask you to add the following members ?
>>> >> # All of tree are heat-dashboard core.
>>> >>
>>> >> Kazunori Shinohara / ksnhr.t...@gmail.com #myself
>>> >> Xinni Ge / xinni.ge1...@gmail.com
>>> >> Keiichi Hikita / keiichi.hik...@gmail.com
>>> >>
>>> >> Please give me a shout, if we are not on same page or any concern.
>>> >>
>>> >> Regards,
>>> >> Kaz
>>> >>
>>> >>
>>> >> 2018-03-21 22:29 GMT+09:00 Kaz Shinohara :
>>> >> > Hi Ivan, Akihiro,
>>> >> >
>>> >> >
>>> >> > Thanks for your kind arrangement.
>>> >> > Looking forward to hearing your decision soon.
>>> >> >
>>> >> > Regards,
>>> >> > Kaz
>>> >> >
>>> >> > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
>>> >> >> HI Team,
>>> >> >>
>>> >> >> From my perspective, I'm OK both with #2 and #3 options. I agree
>>> that
>>> >> >> #4
>>> >> >> could be too complicated for us. Anyway, we've got this topic on
>>> the
>>> >> >> meeting
>>> >> >> agenda [1] so we'll discuss it there too. I'll share our decision
>>> after
>>> >> >> the
>>> >> >> meeting.
>>> >> >>
>>> >> >> [1] https://wiki.openstack.org/wiki/Meetings/Horizon
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> Regards,
>>> >> >> Ivan Kolodyazhny,
>>> >> >> http://blog.e0ne.info/
>>> >> >>
>>> >> >> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki <
>>> amot...@gmail.com>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Hi Kaz and Ivan,
>>> >> >>>
>>> >> >>> Yeah, it is worth discussed officially in the horizon team
>>> meeting or
>>> >> >>> the
>>> >> >>> mailing list thread to get a consensus.
>>> >> >>> Hopefully you can add this topic to the horizon meeting agenda.
>>> >> >>>
>>> >> >>> After sending the previous mail, I noticed anther option. I see
>>> the

Re: [openstack-dev] [horizon][plugins][heat][searchlight][murano][sahara][watcher] Use default Django test runner instead of nose

[Kaz Shinohara]

Thanks Ivan, will check your patch soon.

Regards,
Kaz(Heat)


2018-06-05 22:59 GMT+09:00 Akihiro Motoki :

> This is an important step to drop nose and nosehtmloutput :)
> We plan to switch the test runner and then re-enable integration tests
> (with selenium) for cross project testing.
>
> In addition, we horizon team are trying to minimize gate breakage in
> horizon plugins for recent changes (this and django 2.0).
> Hopefully pending related patches will land soon.
>
>
> 2018年6月5日(火) 22:52 Doug Hellmann :
>
>> Excerpts from Ivan Kolodyazhny's message of 2018-06-05 16:32:22 +0300:
>> > Hi team,
>> >
>> > In Horizon, we're going to get rid of unsupported Nose and use Django
>> Test
>> > Runner instead of it [1]. Nose has some issues and limitations which
>> blocks
>> > us in our testing improvement efforts.
>> >
>> > Nose has different test discovery mechanism than Django does. So, there
>> was
>> > a chance to break some Horizon Plugins:(. Unfortunately, we haven't
>> > cross-project CI yet (TBH, I'm working on it and it's one of the first
>> > steps to get it done), that's why I tested this change [2] against all
>> > known plugins [3].
>> >
>> > Most of the projects don't need any changes. I proposed few changed to
>> > plugins repositories [4] and most of them are merged already. Thanks a
>> lot
>> > to everybody who helped me with it. Patches for heat-dashboard [5] and
>> > searchlight-ui [6] are under review.
>> >
>> > Additional efforts are needed for murano-dashboard, sahara-dashboard,
>> and
>> > watcher-dashboard projects. murano-dashboard has Nose test runner
>> enabled
>> > in the config, so Horizon change won't affect it.
>> >
>> > I proposed patches for sahara-dashboard [7] and watcher-dashboard [8] to
>> > explicitly enable Nose test runner there until we'll fix all related
>> > issues. I hope we'll have a good number of cross-project activities with
>> > these teams.
>> >
>> > Once all patches above will be merged, we'll be ready to the next step
>> to
>> > make Horizon and plugins CI better.
>> >
>> >
>> > [1] https://review.openstack.org/#/c/544296/
>> > [2]
>> > https://docs.google.com/spreadsheets/d/17Yiso6JLeRHBSqJhAiQYkqIAvQhvN
>> FM8NgTkrPxovMo/edit?usp=sharing
>> > [3] https://docs.openstack.org/horizon/latest/install/plugin-
>> registry.html
>> > [4]
>> > https://review.openstack.org/#/q/topic:bp/improve-horizon-
>> testing+(status:open+OR+status:merged)
>> > [5] https://review.openstack.org/572095
>> > [6] https://review.openstack.org/572124
>> > [7] https://review.openstack.org/572390
>> > [8] https://review.openstack.org/572391
>> >
>> >
>> >
>> > Regards,
>> > Ivan Kolodyazhny,
>> > http://blog.e0ne.info/
>>
>> Nice work! Thanks for taking the initiative on updating our tooling.
>>
>> 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 Development Mailing 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][plugins][heat][searchlight][murano][sahara][watcher] Use default Django test runner instead of nose

[Akihiro Motoki]

This is an important step to drop nose and nosehtmloutput :)
We plan to switch the test runner and then re-enable integration tests
(with selenium) for cross project testing.

In addition, we horizon team are trying to minimize gate breakage in
horizon plugins for recent changes (this and django 2.0).
Hopefully pending related patches will land soon.


2018年6月5日(火) 22:52 Doug Hellmann :

> Excerpts from Ivan Kolodyazhny's message of 2018-06-05 16:32:22 +0300:
> > Hi team,
> >
> > In Horizon, we're going to get rid of unsupported Nose and use Django
> Test
> > Runner instead of it [1]. Nose has some issues and limitations which
> blocks
> > us in our testing improvement efforts.
> >
> > Nose has different test discovery mechanism than Django does. So, there
> was
> > a chance to break some Horizon Plugins:(. Unfortunately, we haven't
> > cross-project CI yet (TBH, I'm working on it and it's one of the first
> > steps to get it done), that's why I tested this change [2] against all
> > known plugins [3].
> >
> > Most of the projects don't need any changes. I proposed few changed to
> > plugins repositories [4] and most of them are merged already. Thanks a
> lot
> > to everybody who helped me with it. Patches for heat-dashboard [5] and
> > searchlight-ui [6] are under review.
> >
> > Additional efforts are needed for murano-dashboard, sahara-dashboard, and
> > watcher-dashboard projects. murano-dashboard has Nose test runner enabled
> > in the config, so Horizon change won't affect it.
> >
> > I proposed patches for sahara-dashboard [7] and watcher-dashboard [8] to
> > explicitly enable Nose test runner there until we'll fix all related
> > issues. I hope we'll have a good number of cross-project activities with
> > these teams.
> >
> > Once all patches above will be merged, we'll be ready to the next step to
> > make Horizon and plugins CI better.
> >
> >
> > [1] https://review.openstack.org/#/c/544296/
> > [2]
> >
> https://docs.google.com/spreadsheets/d/17Yiso6JLeRHBSqJhAiQYkqIAvQhvNFM8NgTkrPxovMo/edit?usp=sharing
> > [3]
> https://docs.openstack.org/horizon/latest/install/plugin-registry.html
> > [4]
> >
> https://review.openstack.org/#/q/topic:bp/improve-horizon-testing+(status:open+OR+status:merged)
> > [5] https://review.openstack.org/572095
> > [6] https://review.openstack.org/572124
> > [7] https://review.openstack.org/572390
> > [8] https://review.openstack.org/572391
> >
> >
> >
> > Regards,
> > Ivan Kolodyazhny,
> > http://blog.e0ne.info/
>
> Nice work! Thanks for taking the initiative on updating our tooling.
>
> 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

Re: [openstack-dev] [horizon][plugins][heat][searchlight][murano][sahara][watcher] Use default Django test runner instead of nose

[Doug Hellmann]

Excerpts from Ivan Kolodyazhny's message of 2018-06-05 16:32:22 +0300:
> Hi team,
> 
> In Horizon, we're going to get rid of unsupported Nose and use Django Test
> Runner instead of it [1]. Nose has some issues and limitations which blocks
> us in our testing improvement efforts.
> 
> Nose has different test discovery mechanism than Django does. So, there was
> a chance to break some Horizon Plugins:(. Unfortunately, we haven't
> cross-project CI yet (TBH, I'm working on it and it's one of the first
> steps to get it done), that's why I tested this change [2] against all
> known plugins [3].
> 
> Most of the projects don't need any changes. I proposed few changed to
> plugins repositories [4] and most of them are merged already. Thanks a lot
> to everybody who helped me with it. Patches for heat-dashboard [5] and
> searchlight-ui [6] are under review.
> 
> Additional efforts are needed for murano-dashboard, sahara-dashboard, and
> watcher-dashboard projects. murano-dashboard has Nose test runner enabled
> in the config, so Horizon change won't affect it.
> 
> I proposed patches for sahara-dashboard [7] and watcher-dashboard [8] to
> explicitly enable Nose test runner there until we'll fix all related
> issues. I hope we'll have a good number of cross-project activities with
> these teams.
> 
> Once all patches above will be merged, we'll be ready to the next step to
> make Horizon and plugins CI better.
> 
> 
> [1] https://review.openstack.org/#/c/544296/
> [2]
> https://docs.google.com/spreadsheets/d/17Yiso6JLeRHBSqJhAiQYkqIAvQhvNFM8NgTkrPxovMo/edit?usp=sharing
> [3] https://docs.openstack.org/horizon/latest/install/plugin-registry.html
> [4]
> https://review.openstack.org/#/q/topic:bp/improve-horizon-testing+(status:open+OR+status:merged)
> [5] https://review.openstack.org/572095
> [6] https://review.openstack.org/572124
> [7] https://review.openstack.org/572390
> [8] https://review.openstack.org/572391
> 
> 
> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/

Nice work! Thanks for taking the initiative on updating our tooling.

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-dev] [horizon][plugins][heat][searchlight][murano][sahara][watcher] Use default Django test runner instead of nose

[Ivan Kolodyazhny]

Hi team,

In Horizon, we're going to get rid of unsupported Nose and use Django Test
Runner instead of it [1]. Nose has some issues and limitations which blocks
us in our testing improvement efforts.

Nose has different test discovery mechanism than Django does. So, there was
a chance to break some Horizon Plugins:(. Unfortunately, we haven't
cross-project CI yet (TBH, I'm working on it and it's one of the first
steps to get it done), that's why I tested this change [2] against all
known plugins [3].

Most of the projects don't need any changes. I proposed few changed to
plugins repositories [4] and most of them are merged already. Thanks a lot
to everybody who helped me with it. Patches for heat-dashboard [5] and
searchlight-ui [6] are under review.

Additional efforts are needed for murano-dashboard, sahara-dashboard, and
watcher-dashboard projects. murano-dashboard has Nose test runner enabled
in the config, so Horizon change won't affect it.

I proposed patches for sahara-dashboard [7] and watcher-dashboard [8] to
explicitly enable Nose test runner there until we'll fix all related
issues. I hope we'll have a good number of cross-project activities with
these teams.

Once all patches above will be merged, we'll be ready to the next step to
make Horizon and plugins CI better.


[1] https://review.openstack.org/#/c/544296/
[2]
https://docs.google.com/spreadsheets/d/17Yiso6JLeRHBSqJhAiQYkqIAvQhvNFM8NgTkrPxovMo/edit?usp=sharing
[3] https://docs.openstack.org/horizon/latest/install/plugin-registry.html
[4]
https://review.openstack.org/#/q/topic:bp/improve-horizon-testing+(status:open+OR+status:merged)
[5] https://review.openstack.org/572095
[6] https://review.openstack.org/572124
[7] https://review.openstack.org/572390
[8] https://review.openstack.org/572391



Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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

[Akihiro Motoki]

Hi,

Sorry for re-using the ancient ML thread.
Looking at recent xstatic-* repo reviews, I am a bit afraid that
xstatic-cores do not have a common understanding on the principle of
xstatic packages.
I hope all xstatic-cores re-read "Packing Software" in the horizon
contributor docs [1], especially "Minified Javascript policy" [2],
carefully.

Thanks,
Akihiro

[1]
https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html
[2]
https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html#minified-javascript-policy


2018年4月4日(水) 14:35 Xinni Ge :

> Hi Ivan and other Horizon team member,
>
> Thanks for adding us into xstatic-core group.
> But I still need your opinion and help to release the newly-added xstatic
> packages to pypi index.
>
> Current `xstatic-core` group doesn't have the permission to PUSH SIGNED
> TAG, and I cannot release the first non-trivial version.
>
> If I (or maybe Kaz) could be added into xstatic-release group, we can
> release all the 8 packages by ourselves.
>
> Or, we are very appreciate if any member of xstatic-release could help to
> do it.
>
> Just for your quick access, here is the link of access permission page of
> one xstatic package.
>
> https://review.openstack.org/#/admin/projects/openstack/xstatic-angular-material,access
>
>
> --
> Best Regards,
> Xinni
>
> On Thu, Mar 29, 2018 at 9:59 AM, Kaz Shinohara 
> wrote:
>
>> Hi Ivan,
>>
>>
>> Thank you very much.
>> I've confirmed that all of us have been added to xstatic-core.
>>
>> As discussed, we will focus on the followings what we added for
>> heat-dashboard, will not touch other xstatic repos as core.
>>
>> xstatic-angular-material
>> xstatic-angular-notify
>> xstatic-angular-uuid
>> xstatic-angular-vis
>> xstatic-filesaver
>> xstatic-js-yaml
>> xstatic-json2yaml
>> xstatic-vis
>>
>> Regards,
>> Kaz
>>
>> 2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny :
>> > Hi Kuz,
>> >
>> > Don't worry, we're on the same page with you. I added both you, Xinni
>> and
>> > Keichii to the xstatic-core group. Thank you for your contributions!
>> >
>> > Regards,
>> > Ivan Kolodyazhny,
>> > http://blog.e0ne.info/
>> >
>> > On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara 
>> wrote:
>> >>
>> >> Hi Ivan & Horizon folks
>> >>
>> >>
>> >> AFAIK, Horizon team had conclusion that you will add the specific
>> >> members to xstatic-core, correct ?
>> >> Can I ask you to add the following members ?
>> >> # All of tree are heat-dashboard core.
>> >>
>> >> Kazunori Shinohara / ksnhr.t...@gmail.com #myself
>> >> Xinni Ge / xinni.ge1...@gmail.com
>> >> Keiichi Hikita / keiichi.hik...@gmail.com
>> >>
>> >> Please give me a shout, if we are not on same page or any concern.
>> >>
>> >> Regards,
>> >> Kaz
>> >>
>> >>
>> >> 2018-03-21 22:29 GMT+09:00 Kaz Shinohara :
>> >> > Hi Ivan, Akihiro,
>> >> >
>> >> >
>> >> > Thanks for your kind arrangement.
>> >> > Looking forward to hearing your decision soon.
>> >> >
>> >> > Regards,
>> >> > Kaz
>> >> >
>> >> > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
>> >> >> HI Team,
>> >> >>
>> >> >> From my perspective, I'm OK both with #2 and #3 options. I agree
>> that
>> >> >> #4
>> >> >> could be too complicated for us. Anyway, we've got this topic on the
>> >> >> meeting
>> >> >> agenda [1] so we'll discuss it there too. I'll share our decision
>> after
>> >> >> the
>> >> >> meeting.
>> >> >>
>> >> >> [1] https://wiki.openstack.org/wiki/Meetings/Horizon
>> >> >>
>> >> >>
>> >> >>
>> >> >> Regards,
>> >> >> Ivan Kolodyazhny,
>> >> >> http://blog.e0ne.info/
>> >> >>
>> >> >> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki > >
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Kaz and Ivan,
>> >> >>>
>> >> >>> Yeah, it is worth discussed officially in the horizon team meeting
>> or
>> >> >>> the
>> >> >>> mailing list thread to get a consensus.
>> >> >>> Hopefully you can add this topic to the horizon meeting agenda.
>> >> >>>
>> >> >>> After sending the previous mail, I noticed anther option. I see
>> there
>> >> >>> are
>> >> >>> several options now.
>> >> >>> (1) Keep xstatic-core and horizon-core same.
>> >> >>> (2) Add specific members to xstatic-core
>> >> >>> (3) Add specific horizon-plugin core to xstatic-core
>> >> >>> (4) Split core membership into per-repo basis (perhaps too
>> >> >>> complicated!!)
>> >> >>>
>> >> >>> My current vote is (2) as xstatic-core needs to understand what is
>> >> >>> xstatic
>> >> >>> and how it is maintained.
>> >> >>>
>> >> >>> Thanks,
>> >> >>> Akihiro
>> >> >>>
>> >> >>>
>> >> >>> 2018-03-20 17:17 GMT+09:00 Kaz Shinohara :
>> >> 
>> >>  Hi Akihiro,
>> >> 
>> >> 
>> >>  Thanks for your comment.
>> >>  The background of my request to add us to xstatic-core comes from
>> >>  Ivan's comment in last PTG's etherpad for heat-dashboard
>> discussion.
>> >> 
>> >> 
>> https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussion
>> >>  Line135, "we can share ownership if needed - e0ne"
>> >> 
>> >>  Just in case, could yo

Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Akihiro Motoki]

2018年6月3日(日) 10:56 Chuck Short :

> Hi
>
> On Sat, Jun 2, 2018 at 9:50 PM, Akihiro Motoki  wrote:
>
>> Updates on Django 2.0 support.
>>
>> * 18 of 29 affected repositories now support Django 2.0
>> * 4 repositories have pending patches.
>> * 3 repositories below need help from individual project teams as I don't
>> have actual running environments of them.
>>* heat-dashboard https://review.openstack.org/#/c/567591/
>>* murano-dashboard https://review.openstack.org/#/c/571950/
>>* watcher-dashboard
>> * 4 repositories below needs more help as there seems no python3 support
>> or projects looks inactive.
>>monasca-ui, cloudkitty-dashboard, karbor-dashboard,
>> group-based-policy-ui
>>
>>
> Monasca-ui has python3 support however the CI hasn't been enabled.
>

Considering my bandwidth, it would be nice if monasca-ui team can work on
django2.0 support.


>
>
>> global-requirements and upper-constraints changes are also proposed.
>> Considering good progress in general, I believe we can land requirements
>> changes soon.
>>
>> https://review.openstack.org/#/q/topic:django-version+(status:open+OR+status:merged)
>>
>> Detail progress is found at
>> https://etherpad.openstack.org/p/django20-support
>>
>> Thanks,
>> Akihiro
>>
>> 2018年5月15日(火) 4:21 Ivan Kolodyazhny :
>>
>>> Hi all,
>>>
>>> From the Horizon's perspective, it would be good to support Django 1.11
>>> as long as we can since it's an LTS release [2].
>>> Django 2.0 support is also extremely important because of it's the first
>>> step in a python3-only environment and step forward on supporting
>>> next Django 2.2 LTS release which will be released next April.
>>>
>>> We have to be careful to not break existing plugins and deployments by
>>> introducing new Django version requirement.
>>> We need to work more closely with plugins teams to getting everything
>>> ready for Django 2.0+ before we change our requirements.txt.
>>> I don't want to introduce any breaking changes for current plugins so we
>>> need to to be sure that each plugin supports Django 2.0. It means
>>> plugins have to have voting Django 2.0 jobs on their gates at least.
>>> I'll do my best on this effort and will work with plugins teams to do as
>>> much as we can in Rocky timeframe.
>>>
>>> [2] https://www.djangoproject.com/download/
>>>
>>> Regards,
>>> Ivan Kolodyazhny,
>>> http://blog.e0ne.info/
>>>
>>> On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki 
>>> wrote:
>>>


 2018年5月14日(月) 21:42 Doug Hellmann :

> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
> > 2018年5月12日(土) 3:04 Doug Hellmann :
> >
> > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33
> +0900:
> > > > Hi zigo and horizon plugin maintainers,
> > > >
> > > > Horizon itself already supports Django 2.0 and horizon unit test
> covers
> > > > Django 2.0 with Python 3.5.
> > > >
> > > > A question to all is whether we change the upper bound of Django
> from
> > > <2.0
> > > > to <2.1.
> > > > My proposal is to bump the upper bound of Django to <2.1 in
> Rocky-2.
> > > > (Note that Django 1.11 will continue to be used for python 2.7
> > > environment.)
> > >
> > > Do we need to cap it at all? We've been trying to express our
> > > dependencies without caps and rely on the constraints list to
> > > test using a common version because this offers the most
> flexibility as
> > > we move to newer versions over time.
> > >
> >
> > The main reason we cap django version so far is that django minor
> version
> > releases
> > contain some backward incompatible changes and also drop deprecated
> > features.
> > A new django minor version release like 1.11 usually breaks horizon
> and
> > plugins
> > as horizon developers are not always checking django deprecations.
>
> OK. Having the cap in place makes it more complicated to test
> upgrading, and then upgrade. Because we no longer synchronize
> requirements, changing openstack/requirements does not trigger the
> bot to propose the same change to all of the projects using the
> dependency. Someone will have to do that by hand in the future, as we
> are doing with eventlet right now
> (https://review.openstack.org/#/q/topic:uncap-eventlet).
>
> Without the cap, we can test the upgrade by proposing a constraint
> update and running the horizon (and/or plugin) unit tests. When those
> tests pass, we can then step forward all at once by approving the
> constraint change.
>

 Thanks for the detail context.

 Honestly I am not sure which is better to cap or uncap the django
 version.
 We can try uncapping now and see what happens in the community.

 cross-horizon-(py27|py35) jobs of openstack/requirements checks
 if horizon works with a new version. it works for horizon, but perhaps
 it pote

Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Chuck Short]

Hi

On Sat, Jun 2, 2018 at 9:50 PM, Akihiro Motoki  wrote:

> Updates on Django 2.0 support.
>
> * 18 of 29 affected repositories now support Django 2.0
> * 4 repositories have pending patches.
> * 3 repositories below need help from individual project teams as I don't
> have actual running environments of them.
>* heat-dashboard https://review.openstack.org/#/c/567591/
>* murano-dashboard https://review.openstack.org/#/c/571950/
>* watcher-dashboard
> * 4 repositories below needs more help as there seems no python3 support
> or projects looks inactive.
>monasca-ui, cloudkitty-dashboard, karbor-dashboard,
> group-based-policy-ui
>
>
Monasca-ui has python3 support however the CI hasn't been enabled.


> global-requirements and upper-constraints changes are also proposed.
> Considering good progress in general, I believe we can land requirements
> changes soon.
> https://review.openstack.org/#/q/topic:django-version+(
> status:open+OR+status:merged)
>
> Detail progress is found at https://etherpad.openstack.
> org/p/django20-support
>
> Thanks,
> Akihiro
>
> 2018年5月15日(火) 4:21 Ivan Kolodyazhny :
>
>> Hi all,
>>
>> From the Horizon's perspective, it would be good to support Django 1.11
>> as long as we can since it's an LTS release [2].
>> Django 2.0 support is also extremely important because of it's the first
>> step in a python3-only environment and step forward on supporting
>> next Django 2.2 LTS release which will be released next April.
>>
>> We have to be careful to not break existing plugins and deployments by
>> introducing new Django version requirement.
>> We need to work more closely with plugins teams to getting everything
>> ready for Django 2.0+ before we change our requirements.txt.
>> I don't want to introduce any breaking changes for current plugins so we
>> need to to be sure that each plugin supports Django 2.0. It means
>> plugins have to have voting Django 2.0 jobs on their gates at least. I'll
>> do my best on this effort and will work with plugins teams to do as
>> much as we can in Rocky timeframe.
>>
>> [2] https://www.djangoproject.com/download/
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>> On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki 
>> wrote:
>>
>>>
>>>
>>> 2018年5月14日(月) 21:42 Doug Hellmann :
>>>
 Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
 > 2018年5月12日(土) 3:04 Doug Hellmann :
 >
 > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
 > > > Hi zigo and horizon plugin maintainers,
 > > >
 > > > Horizon itself already supports Django 2.0 and horizon unit test
 covers
 > > > Django 2.0 with Python 3.5.
 > > >
 > > > A question to all is whether we change the upper bound of Django
 from
 > > <2.0
 > > > to <2.1.
 > > > My proposal is to bump the upper bound of Django to <2.1 in
 Rocky-2.
 > > > (Note that Django 1.11 will continue to be used for python 2.7
 > > environment.)
 > >
 > > Do we need to cap it at all? We've been trying to express our
 > > dependencies without caps and rely on the constraints list to
 > > test using a common version because this offers the most
 flexibility as
 > > we move to newer versions over time.
 > >
 >
 > The main reason we cap django version so far is that django minor
 version
 > releases
 > contain some backward incompatible changes and also drop deprecated
 > features.
 > A new django minor version release like 1.11 usually breaks horizon
 and
 > plugins
 > as horizon developers are not always checking django deprecations.

 OK. Having the cap in place makes it more complicated to test
 upgrading, and then upgrade. Because we no longer synchronize
 requirements, changing openstack/requirements does not trigger the
 bot to propose the same change to all of the projects using the
 dependency. Someone will have to do that by hand in the future, as we
 are doing with eventlet right now
 (https://review.openstack.org/#/q/topic:uncap-eventlet).

 Without the cap, we can test the upgrade by proposing a constraint
 update and running the horizon (and/or plugin) unit tests. When those
 tests pass, we can then step forward all at once by approving the
 constraint change.

>>>
>>> Thanks for the detail context.
>>>
>>> Honestly I am not sure which is better to cap or uncap the django
>>> version.
>>> We can try uncapping now and see what happens in the community.
>>>
>>> cross-horizon-(py27|py35) jobs of openstack/requirements checks
>>> if horizon works with a new version. it works for horizon, but perhaps
>>> it potentially
>>> break horizon plugins as it takes time to catch up with such changes.
>>> On the other hand, a version bump in upper-constraints.txt would be
>>> a good trigger for horizon plugin maintainers to sync all requirements.
>>>
>>> In addition, requirements a

Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Akihiro Motoki]

Updates on Django 2.0 support.

* 18 of 29 affected repositories now support Django 2.0
* 4 repositories have pending patches.
* 3 repositories below need help from individual project teams as I don't
have actual running environments of them.
   * heat-dashboard https://review.openstack.org/#/c/567591/
   * murano-dashboard https://review.openstack.org/#/c/571950/
   * watcher-dashboard
* 4 repositories below needs more help as there seems no python3 support or
projects looks inactive.
   monasca-ui, cloudkitty-dashboard, karbor-dashboard, group-based-policy-ui

global-requirements and upper-constraints changes are also proposed.
Considering good progress in general, I believe we can land requirements
changes soon.
https://review.openstack.org/#/q/topic:django-version+(status:open+OR+status:merged)

Detail progress is found at
https://etherpad.openstack.org/p/django20-support

Thanks,
Akihiro

2018年5月15日(火) 4:21 Ivan Kolodyazhny :

> Hi all,
>
> From the Horizon's perspective, it would be good to support Django 1.11 as
> long as we can since it's an LTS release [2].
> Django 2.0 support is also extremely important because of it's the first
> step in a python3-only environment and step forward on supporting
> next Django 2.2 LTS release which will be released next April.
>
> We have to be careful to not break existing plugins and deployments by
> introducing new Django version requirement.
> We need to work more closely with plugins teams to getting everything
> ready for Django 2.0+ before we change our requirements.txt.
> I don't want to introduce any breaking changes for current plugins so we
> need to to be sure that each plugin supports Django 2.0. It means
> plugins have to have voting Django 2.0 jobs on their gates at least. I'll
> do my best on this effort and will work with plugins teams to do as
> much as we can in Rocky timeframe.
>
> [2] https://www.djangoproject.com/download/
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki  wrote:
>
>>
>>
>> 2018年5月14日(月) 21:42 Doug Hellmann :
>>
>>> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
>>> > 2018年5月12日(土) 3:04 Doug Hellmann :
>>> >
>>> > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
>>> > > > Hi zigo and horizon plugin maintainers,
>>> > > >
>>> > > > Horizon itself already supports Django 2.0 and horizon unit test
>>> covers
>>> > > > Django 2.0 with Python 3.5.
>>> > > >
>>> > > > A question to all is whether we change the upper bound of Django
>>> from
>>> > > <2.0
>>> > > > to <2.1.
>>> > > > My proposal is to bump the upper bound of Django to <2.1 in
>>> Rocky-2.
>>> > > > (Note that Django 1.11 will continue to be used for python 2.7
>>> > > environment.)
>>> > >
>>> > > Do we need to cap it at all? We've been trying to express our
>>> > > dependencies without caps and rely on the constraints list to
>>> > > test using a common version because this offers the most flexibility
>>> as
>>> > > we move to newer versions over time.
>>> > >
>>> >
>>> > The main reason we cap django version so far is that django minor
>>> version
>>> > releases
>>> > contain some backward incompatible changes and also drop deprecated
>>> > features.
>>> > A new django minor version release like 1.11 usually breaks horizon and
>>> > plugins
>>> > as horizon developers are not always checking django deprecations.
>>>
>>> OK. Having the cap in place makes it more complicated to test
>>> upgrading, and then upgrade. Because we no longer synchronize
>>> requirements, changing openstack/requirements does not trigger the
>>> bot to propose the same change to all of the projects using the
>>> dependency. Someone will have to do that by hand in the future, as we
>>> are doing with eventlet right now
>>> (https://review.openstack.org/#/q/topic:uncap-eventlet).
>>>
>>> Without the cap, we can test the upgrade by proposing a constraint
>>> update and running the horizon (and/or plugin) unit tests. When those
>>> tests pass, we can then step forward all at once by approving the
>>> constraint change.
>>>
>>
>> Thanks for the detail context.
>>
>> Honestly I am not sure which is better to cap or uncap the django version.
>> We can try uncapping now and see what happens in the community.
>>
>> cross-horizon-(py27|py35) jobs of openstack/requirements checks
>> if horizon works with a new version. it works for horizon, but perhaps it
>> potentially
>> break horizon plugins as it takes time to catch up with such changes.
>> On the other hand, a version bump in upper-constraints.txt would be
>> a good trigger for horizon plugin maintainers to sync all requirements.
>>
>> In addition, requirements are not synchronized automatically,
>> so it seems not feasible to propose requirements changes per django
>> version change.
>>
>>
>>>
>>> >
>>> > I have a question on uncapping the django version.
>>> > How can users/operators know which versions are supported?
>>> > Do they need to ch

Re: [openstack-dev] [horizon] Font awesome currently broken with Debian Sid and Horizon

[Thomas Goirand]

On 05/30/2018 04:13 PM, Ivan Kolodyazhny wrote:
> Hi Thomas,
>  
> 
> As my python3-xstatic-font-awesome removes the embedded fonts
> 
> 
> It sounds like you broke xstatic-* packages for Debian and use something
> we don't test with Horizon at all.
> 
> Speaking about Rocky/master version, our upper-constraint
> XStatic-Font-Awesome===4.7.0.0 [1]. We don't test horizon with font
> awesome v 5.0.10.
> 
> 
> Second, it'd be nice if Horizon could adapt and use the new v5
> font-awesome, so that the problem is completely solved.
> 
> +1. I'll put my +2/A once somebody provides a patch for it with a
> detailed description how can I test it. Unfortunately, Horizon team has
> a very limited set of resources, so we can't adopt new version of
> xstatic-* fast :(.
> 
> [1] 
> https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L61
> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/

Ivan,

The point of Xstatic packages is so that, in distributions, they depend
on the asset which is packaged separately, so that there's no
duplication of data in the distro. In this case, the
python3-xstatic-font-awesome package depends on the fonts-font-awesome
package. And it is the later that got updated in Debian. I don't
maintain it, so it's not my fault. This broke many packages, including
the openstackdocstheme also.

Of course, I could revert what was previously done, and have
python3-xstatic-font-awesome to contain the fonts data again. But that's
not desirable.

What we really want is have Horizon fixed, and use a newer version of
font-awesome (ie: v5) if possible. Using only glyphs from fa-solid-900
will make it possible to have Horizon work with both v4 and v5, which
would be even better (of course, package maintainers would have to set
correct links to the right font file, but that's a packaging detail).

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] [horizon] Font awesome currently broken with Debian Sid and Horizon

[Ivan Kolodyazhny]

Hi Thomas,


> As my python3-xstatic-font-awesome removes the embedded fonts


It sounds like you broke xstatic-* packages for Debian and use something we
don't test with Horizon at all.

Speaking about Rocky/master version, our upper-constraint
XStatic-Font-Awesome===4.7.0.0 [1]. We don't test horizon with font awesome
v 5.0.10.


Second, it'd be nice if Horizon could adapt and use the new v5
> font-awesome, so that the problem is completely solved.

+1. I'll put my +2/A once somebody provides a patch for it with a detailed
description how can I test it. Unfortunately, Horizon team has a very
limited set of resources, so we can't adopt new version of xstatic-* fast
:(.

[1]
https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L61

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, May 30, 2018 at 4:27 PM, Thomas Goirand  wrote:

> Hi Radomir,
>
> I'm adding the debian bug as Cc.
>
> On 05/28/2018 08:35 AM, Radomir Dopieralski wrote:
> > I did a quick search for all the glyphs we are using:
> >
> > ~/dev/horizon(master)> ag 'fa-' | egrep -o 'fa-[a-z-]*' | sort | uniq
> > fa-
> > fa-angle-left
> > [...]
>
> Thanks for your investigation.
>
> I did a quick test, and loaded all of these glyphs into a test HTML
> page. As much as I can see, only 4 glyphs aren't in fa-solid-900:
>
> fa-cloud-upload
> fa-pencil
> fa-share-square-o
> fa-sign-out
>
> It'd be nice if we could replace these by glyphs present in fa-solid-900
> so we could simply replace the old v4 font by fa-solid-900 only.
>
> Your thoughts?
>
> 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

Re: [openstack-dev] [horizon] Font awesome currently broken with Debian Sid and Horizon

[Thomas Goirand]

Hi Radomir,

I'm adding the debian bug as Cc.

On 05/28/2018 08:35 AM, Radomir Dopieralski wrote:
> I did a quick search for all the glyphs we are using:
> 
> ~/dev/horizon(master)> ag 'fa-' | egrep -o 'fa-[a-z-]*' | sort | uniq
> fa-
> fa-angle-left
> [...]

Thanks for your investigation.

I did a quick test, and loaded all of these glyphs into a test HTML
page. As much as I can see, only 4 glyphs aren't in fa-solid-900:

fa-cloud-upload
fa-pencil
fa-share-square-o
fa-sign-out

It'd be nice if we could replace these by glyphs present in fa-solid-900
so we could simply replace the old v4 font by fa-solid-900 only.

Your thoughts?

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] [horizon] Font awesome currently broken with Debian Sid and Horizon

[Radomir Dopieralski]

I did a quick search for all the glyphs we are using:

~/dev/horizon(master)> ag 'fa-' | egrep -o 'fa-[a-z-]*' | sort | uniq
fa-
fa-angle-left
fa-angle-right
fa-arrow-down
fa-arrow-up
fa-asterisk
fa-b
fa-bars
fa-bolt
fa-bug
fa-calculator
fa-calendar
fa-caret-down
fa-caret-up
fa-check
fa-chevron-down
fa-chevron-right
fa-circle
fa-close
fa-cloud
fa-cloud-upload
fa-code
fa-cog
fa-desktop
fa-download
fa-exclamation
fa-exclamation-circle
fa-exclamation-triangle
fa-eye
fa-eye-slash
fa-font-path
fa-fw
fa-group
fa-home
fa-icon
fa-info-circle
fa-lg
fa-list-alt
fa-lock
fa-minus
fa-pencil
fa-plus
fa-question-circle
fa-refresh
fa-save
fa-search
fa-server
fa-share-square-o
fa-sign-out
fa-sort
fa-spin
fa-spinner
fa-square
fa-th
fa-th-large
fa-times
fa-trash
fa-unlock
fa-upload
fa-user
fa-var-check-square-o
fa-var-circle-o
fa-var-dot-circle-o
fa-var-sort
fa-var-sort-asc
fa-var-sort-desc
fa-var-square-o
fa-warning

The lone "fa-" comes from table actions, where the icon is defined in code,
and pretty much anything can be used —
since plugins can define their own actions with their own icons — but I
don't think we use anything exotic there.

On Sat, May 26, 2018 at 7:37 PM, Thomas Goirand  wrote:

> Hi Horizon team!
>
> I'm not sure if you're aware of that, but the upstream authors of
> fontawesome decided it was a good idea to break everyone. See this
> Debian bug entry:
>
> https://bugs.debian.org/899124
>
> So, what happened is that fontawesome-webfont has been split into 3 sets
> of fonts: solid, regular and brands fonts. Thus there is no drop in
> replacement for the old fontawesome-webfont.xxx.
>
> As my python3-xstatic-font-awesome removes the embedded fonts, and just
> points to /usr/share/fonts-font-awesome, Horizon is broken and cannot
> even be installed currently in Debian Sid. Of course, I'm considering
> reverting the removal of the data folder from the xstatic package, but
> it then defeats the purpose of Xstatic, which is avoiding duplication of
> static files already packaged in the distribution.
>
> So, ideally, I would like to know first if I can use the fa-solid-900
> for Horizon, or if other glyphs are in use (it's very much possible that
> only fa-solid-900 stuff are in use, but I really don't know how to check
> for that the correct way). If that's the case, then I can workaround the
> issue (at least temporarily), and synlink stuff in the data folder to
> the new fa-solid-900 files.
>
> Second, it'd be nice if Horizon could adapt and use the new v5
> font-awesome, so that the problem is completely solved.
>
> 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] [horizon] Font awesome currently broken with Debian Sid and Horizon

[Thomas Goirand]

Hi Horizon team!

I'm not sure if you're aware of that, but the upstream authors of
fontawesome decided it was a good idea to break everyone. See this
Debian bug entry:

https://bugs.debian.org/899124

So, what happened is that fontawesome-webfont has been split into 3 sets
of fonts: solid, regular and brands fonts. Thus there is no drop in
replacement for the old fontawesome-webfont.xxx.

As my python3-xstatic-font-awesome removes the embedded fonts, and just
points to /usr/share/fonts-font-awesome, Horizon is broken and cannot
even be installed currently in Debian Sid. Of course, I'm considering
reverting the removal of the data folder from the xstatic package, but
it then defeats the purpose of Xstatic, which is avoiding duplication of
static files already packaged in the distribution.

So, ideally, I would like to know first if I can use the fa-solid-900
for Horizon, or if other glyphs are in use (it's very much possible that
only fa-solid-900 stuff are in use, but I really don't know how to check
for that the correct way). If that's the case, then I can workaround the
issue (at least temporarily), and synlink stuff in the data folder to
the new fa-solid-900 files.

Second, it'd be nice if Horizon could adapt and use the new v5
font-awesome, so that the problem is completely solved.

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-dev] [horizon] No meeting on May 23rd

[Ivan Kolodyazhny]

Hi all,

Some of the team will be attending the OpenStack summit in Vancouver,
so I am canceling the weekly IRC meeting for the 23rd.


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] Scheduling switch to django >= 2.0

[Thomas Goirand]

On 05/14/2018 03:30 PM, Akihiro Motoki wrote:
> Is Python 3 ever used for mod_wsgi? Does the WSGI setup code honor
> the variable that tells devstack to use Python 3?
> 
> 
> Ubuntu 16.04 provides py2 and py3 versions of mod_wsgi (libapache2-mod-wsgi
> and libapache2-mod-wsgi-py3) and as a quick look the only difference is
> a module
> specified in LoadModule apache directive.
> I haven't tested it yet, but it seems worth explored.
> 
> Akihiro

libapache2-mod-wsgi-py3 is what's in use in all Debian packages for
OpenStack, and it works well, including for Horizon.

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] [horizon] Scheduling switch to django >= 2.0

[Doug Hellmann]

Excerpts from Ivan Kolodyazhny's message of 2018-05-14 22:20:42 +0300:
> Hi all,
> 
> From the Horizon's perspective, it would be good to support Django 1.11 as
> long as we can since it's an LTS release [2].
> Django 2.0 support is also extremely important because of it's the first
> step in a python3-only environment and step forward on supporting
> next Django 2.2 LTS release which will be released next April.
> 
> We have to be careful to not break existing plugins and deployments by
> introducing new Django version requirement.
> We need to work more closely with plugins teams to getting everything ready
> for Django 2.0+ before we change our requirements.txt.
> I don't want to introduce any breaking changes for current plugins so we
> need to to be sure that each plugin supports Django 2.0. It means
> plugins have to have voting Django 2.0 jobs on their gates at least. I'll
> do my best on this effort and will work with plugins teams to do as
> much as we can in Rocky timeframe.

That sounds like a good plan, thanks Ivan.

Doug

> 
> [2] https://www.djangoproject.com/download/
> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
> 
> On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki  wrote:
> 
> >
> >
> > 2018年5月14日(月) 21:42 Doug Hellmann :
> >
> >> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
> >> > 2018年5月12日(土) 3:04 Doug Hellmann :
> >> >
> >> > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
> >> > > > Hi zigo and horizon plugin maintainers,
> >> > > >
> >> > > > Horizon itself already supports Django 2.0 and horizon unit test
> >> covers
> >> > > > Django 2.0 with Python 3.5.
> >> > > >
> >> > > > A question to all is whether we change the upper bound of Django
> >> from
> >> > > <2.0
> >> > > > to <2.1.
> >> > > > My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
> >> > > > (Note that Django 1.11 will continue to be used for python 2.7
> >> > > environment.)
> >> > >
> >> > > Do we need to cap it at all? We've been trying to express our
> >> > > dependencies without caps and rely on the constraints list to
> >> > > test using a common version because this offers the most flexibility
> >> as
> >> > > we move to newer versions over time.
> >> > >
> >> >
> >> > The main reason we cap django version so far is that django minor
> >> version
> >> > releases
> >> > contain some backward incompatible changes and also drop deprecated
> >> > features.
> >> > A new django minor version release like 1.11 usually breaks horizon and
> >> > plugins
> >> > as horizon developers are not always checking django deprecations.
> >>
> >> OK. Having the cap in place makes it more complicated to test
> >> upgrading, and then upgrade. Because we no longer synchronize
> >> requirements, changing openstack/requirements does not trigger the
> >> bot to propose the same change to all of the projects using the
> >> dependency. Someone will have to do that by hand in the future, as we
> >> are doing with eventlet right now
> >> (https://review.openstack.org/#/q/topic:uncap-eventlet).
> >>
> >> Without the cap, we can test the upgrade by proposing a constraint
> >> update and running the horizon (and/or plugin) unit tests. When those
> >> tests pass, we can then step forward all at once by approving the
> >> constraint change.
> >>
> >
> > Thanks for the detail context.
> >
> > Honestly I am not sure which is better to cap or uncap the django version.
> > We can try uncapping now and see what happens in the community.
> >
> > cross-horizon-(py27|py35) jobs of openstack/requirements checks
> > if horizon works with a new version. it works for horizon, but perhaps it
> > potentially
> > break horizon plugins as it takes time to catch up with such changes.
> > On the other hand, a version bump in upper-constraints.txt would be
> > a good trigger for horizon plugin maintainers to sync all requirements.
> >
> > In addition, requirements are not synchronized automatically,
> > so it seems not feasible to propose requirements changes per django
> > version change.
> >
> >
> >>
> >> >
> >> > I have a question on uncapping the django version.
> >> > How can users/operators know which versions are supported?
> >> > Do they need to check upper-constraints.txt?
> >>
> >> We do tell downstream consumers that the upper-constraints.txt file is
> >> the set of things we test with, and that any other combination of
> >> packages would need to be tested on their systems separately.
> >>
> >> >
> >> > > > There are several points we should consider:
> >> > > > - If we change it in global-requirements.txt, it means Django 2.0
> >> will be
> >> > > > used for python3.5 environment.
> >> > > > - Not a small number of horizon plugins still do not support Django
> >> 2.0,
> >> > > so
> >> > > > bumping the upper bound to <2.1 will break their py35 tests.
> >> > > > - From my experience of Django 2.0 support in some plugins, the
> >> required
> >> > > > changes are relatively simpl

Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Ivan Kolodyazhny]

Hi all,

>From the Horizon's perspective, it would be good to support Django 1.11 as
long as we can since it's an LTS release [2].
Django 2.0 support is also extremely important because of it's the first
step in a python3-only environment and step forward on supporting
next Django 2.2 LTS release which will be released next April.

We have to be careful to not break existing plugins and deployments by
introducing new Django version requirement.
We need to work more closely with plugins teams to getting everything ready
for Django 2.0+ before we change our requirements.txt.
I don't want to introduce any breaking changes for current plugins so we
need to to be sure that each plugin supports Django 2.0. It means
plugins have to have voting Django 2.0 jobs on their gates at least. I'll
do my best on this effort and will work with plugins teams to do as
much as we can in Rocky timeframe.

[2] https://www.djangoproject.com/download/

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki  wrote:

>
>
> 2018年5月14日(月) 21:42 Doug Hellmann :
>
>> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
>> > 2018年5月12日(土) 3:04 Doug Hellmann :
>> >
>> > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
>> > > > Hi zigo and horizon plugin maintainers,
>> > > >
>> > > > Horizon itself already supports Django 2.0 and horizon unit test
>> covers
>> > > > Django 2.0 with Python 3.5.
>> > > >
>> > > > A question to all is whether we change the upper bound of Django
>> from
>> > > <2.0
>> > > > to <2.1.
>> > > > My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
>> > > > (Note that Django 1.11 will continue to be used for python 2.7
>> > > environment.)
>> > >
>> > > Do we need to cap it at all? We've been trying to express our
>> > > dependencies without caps and rely on the constraints list to
>> > > test using a common version because this offers the most flexibility
>> as
>> > > we move to newer versions over time.
>> > >
>> >
>> > The main reason we cap django version so far is that django minor
>> version
>> > releases
>> > contain some backward incompatible changes and also drop deprecated
>> > features.
>> > A new django minor version release like 1.11 usually breaks horizon and
>> > plugins
>> > as horizon developers are not always checking django deprecations.
>>
>> OK. Having the cap in place makes it more complicated to test
>> upgrading, and then upgrade. Because we no longer synchronize
>> requirements, changing openstack/requirements does not trigger the
>> bot to propose the same change to all of the projects using the
>> dependency. Someone will have to do that by hand in the future, as we
>> are doing with eventlet right now
>> (https://review.openstack.org/#/q/topic:uncap-eventlet).
>>
>> Without the cap, we can test the upgrade by proposing a constraint
>> update and running the horizon (and/or plugin) unit tests. When those
>> tests pass, we can then step forward all at once by approving the
>> constraint change.
>>
>
> Thanks for the detail context.
>
> Honestly I am not sure which is better to cap or uncap the django version.
> We can try uncapping now and see what happens in the community.
>
> cross-horizon-(py27|py35) jobs of openstack/requirements checks
> if horizon works with a new version. it works for horizon, but perhaps it
> potentially
> break horizon plugins as it takes time to catch up with such changes.
> On the other hand, a version bump in upper-constraints.txt would be
> a good trigger for horizon plugin maintainers to sync all requirements.
>
> In addition, requirements are not synchronized automatically,
> so it seems not feasible to propose requirements changes per django
> version change.
>
>
>>
>> >
>> > I have a question on uncapping the django version.
>> > How can users/operators know which versions are supported?
>> > Do they need to check upper-constraints.txt?
>>
>> We do tell downstream consumers that the upper-constraints.txt file is
>> the set of things we test with, and that any other combination of
>> packages would need to be tested on their systems separately.
>>
>> >
>> > > > There are several points we should consider:
>> > > > - If we change it in global-requirements.txt, it means Django 2.0
>> will be
>> > > > used for python3.5 environment.
>> > > > - Not a small number of horizon plugins still do not support Django
>> 2.0,
>> > > so
>> > > > bumping the upper bound to <2.1 will break their py35 tests.
>> > > > - From my experience of Django 2.0 support in some plugins, the
>> required
>> > > > changes are relatively simple like [1].
>> > > >
>> > > > I created an etherpad page to track Django 2.0 support in horizon
>> > > plugins.
>> > > > https://etherpad.openstack.org/p/django20-support
>> > > >
>> > > > I proposed Django 2.0 support patches to several projects which I
>> think
>> > > are
>> > > > major.
>> > > > # Do not blame me if I don't cover your project :)
>> >

Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Akihiro Motoki]

2018年5月14日(月) 21:42 Doug Hellmann :

> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
> > 2018年5月12日(土) 3:04 Doug Hellmann :
> >
> > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
> > > > Hi zigo and horizon plugin maintainers,
> > > >
> > > > Horizon itself already supports Django 2.0 and horizon unit test
> covers
> > > > Django 2.0 with Python 3.5.
> > > >
> > > > A question to all is whether we change the upper bound of Django from
> > > <2.0
> > > > to <2.1.
> > > > My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
> > > > (Note that Django 1.11 will continue to be used for python 2.7
> > > environment.)
> > >
> > > Do we need to cap it at all? We've been trying to express our
> > > dependencies without caps and rely on the constraints list to
> > > test using a common version because this offers the most flexibility as
> > > we move to newer versions over time.
> > >
> >
> > The main reason we cap django version so far is that django minor version
> > releases
> > contain some backward incompatible changes and also drop deprecated
> > features.
> > A new django minor version release like 1.11 usually breaks horizon and
> > plugins
> > as horizon developers are not always checking django deprecations.
>
> OK. Having the cap in place makes it more complicated to test
> upgrading, and then upgrade. Because we no longer synchronize
> requirements, changing openstack/requirements does not trigger the
> bot to propose the same change to all of the projects using the
> dependency. Someone will have to do that by hand in the future, as we
> are doing with eventlet right now
> (https://review.openstack.org/#/q/topic:uncap-eventlet).
>
> Without the cap, we can test the upgrade by proposing a constraint
> update and running the horizon (and/or plugin) unit tests. When those
> tests pass, we can then step forward all at once by approving the
> constraint change.
>

Thanks for the detail context.

Honestly I am not sure which is better to cap or uncap the django version.
We can try uncapping now and see what happens in the community.

cross-horizon-(py27|py35) jobs of openstack/requirements checks
if horizon works with a new version. it works for horizon, but perhaps it
potentially
break horizon plugins as it takes time to catch up with such changes.
On the other hand, a version bump in upper-constraints.txt would be
a good trigger for horizon plugin maintainers to sync all requirements.

In addition, requirements are not synchronized automatically,
so it seems not feasible to propose requirements changes per django version
change.


>
> >
> > I have a question on uncapping the django version.
> > How can users/operators know which versions are supported?
> > Do they need to check upper-constraints.txt?
>
> We do tell downstream consumers that the upper-constraints.txt file is
> the set of things we test with, and that any other combination of
> packages would need to be tested on their systems separately.
>
> >
> > > > There are several points we should consider:
> > > > - If we change it in global-requirements.txt, it means Django 2.0
> will be
> > > > used for python3.5 environment.
> > > > - Not a small number of horizon plugins still do not support Django
> 2.0,
> > > so
> > > > bumping the upper bound to <2.1 will break their py35 tests.
> > > > - From my experience of Django 2.0 support in some plugins, the
> required
> > > > changes are relatively simple like [1].
> > > >
> > > > I created an etherpad page to track Django 2.0 support in horizon
> > > plugins.
> > > > https://etherpad.openstack.org/p/django20-support
> > > >
> > > > I proposed Django 2.0 support patches to several projects which I
> think
> > > are
> > > > major.
> > > > # Do not blame me if I don't cover your project :)
> > > >
> > > > Thought?
> > >
> > > It seems like a good goal for the horizon-plugin author community
> > > to bring those projects up to date by supporting a current version
> > > of Django (and any other dependencies), especially as we discuss
> > > the impending switch over to python-3-first and then python-3-only.
> > >
> >
> > Yes, python 3 support is an important topic.
> > We also need to switch the default python version in mod_wsgi in DevStack
> > environment sooner or later.
>
> Is Python 3 ever used for mod_wsgi? Does the WSGI setup code honor
> the variable that tells devstack to use Python 3?
>

Ubuntu 16.04 provides py2 and py3 versions of mod_wsgi (libapache2-mod-wsgi
and libapache2-mod-wsgi-py3) and as a quick look the only difference is a
module
specified in LoadModule apache directive.
I haven't tested it yet, but it seems worth explored.

Akihiro


> >
> > > If this is an area where teams need help, updating that etherpad
> > > with notes and requests for assistance will help us split up the
> > > work.
> > >
> >
> > Each team can help testing in Django 2.0 and/or python 3 support.
> > We need to enable corresponding server projects in de

Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Doug Hellmann]

Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
> 2018年5月12日(土) 3:04 Doug Hellmann :
> 
> > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
> > > Hi zigo and horizon plugin maintainers,
> > >
> > > Horizon itself already supports Django 2.0 and horizon unit test covers
> > > Django 2.0 with Python 3.5.
> > >
> > > A question to all is whether we change the upper bound of Django from
> > <2.0
> > > to <2.1.
> > > My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
> > > (Note that Django 1.11 will continue to be used for python 2.7
> > environment.)
> >
> > Do we need to cap it at all? We've been trying to express our
> > dependencies without caps and rely on the constraints list to
> > test using a common version because this offers the most flexibility as
> > we move to newer versions over time.
> >
> 
> The main reason we cap django version so far is that django minor version
> releases
> contain some backward incompatible changes and also drop deprecated
> features.
> A new django minor version release like 1.11 usually breaks horizon and
> plugins
> as horizon developers are not always checking django deprecations.

OK. Having the cap in place makes it more complicated to test
upgrading, and then upgrade. Because we no longer synchronize
requirements, changing openstack/requirements does not trigger the
bot to propose the same change to all of the projects using the
dependency. Someone will have to do that by hand in the future, as we
are doing with eventlet right now
(https://review.openstack.org/#/q/topic:uncap-eventlet).

Without the cap, we can test the upgrade by proposing a constraint
update and running the horizon (and/or plugin) unit tests. When those
tests pass, we can then step forward all at once by approving the
constraint change.

> 
> I have a question on uncapping the django version.
> How can users/operators know which versions are supported?
> Do they need to check upper-constraints.txt?

We do tell downstream consumers that the upper-constraints.txt file is
the set of things we test with, and that any other combination of
packages would need to be tested on their systems separately.

> 
> > > There are several points we should consider:
> > > - If we change it in global-requirements.txt, it means Django 2.0 will be
> > > used for python3.5 environment.
> > > - Not a small number of horizon plugins still do not support Django 2.0,
> > so
> > > bumping the upper bound to <2.1 will break their py35 tests.
> > > - From my experience of Django 2.0 support in some plugins, the required
> > > changes are relatively simple like [1].
> > >
> > > I created an etherpad page to track Django 2.0 support in horizon
> > plugins.
> > > https://etherpad.openstack.org/p/django20-support
> > >
> > > I proposed Django 2.0 support patches to several projects which I think
> > are
> > > major.
> > > # Do not blame me if I don't cover your project :)
> > >
> > > Thought?
> >
> > It seems like a good goal for the horizon-plugin author community
> > to bring those projects up to date by supporting a current version
> > of Django (and any other dependencies), especially as we discuss
> > the impending switch over to python-3-first and then python-3-only.
> >
> 
> Yes, python 3 support is an important topic.
> We also need to switch the default python version in mod_wsgi in DevStack
> environment sooner or later.

Is Python 3 ever used for mod_wsgi? Does the WSGI setup code honor
the variable that tells devstack to use Python 3?

> 
> > If this is an area where teams need help, updating that etherpad
> > with notes and requests for assistance will help us split up the
> > work.
> >
> 
> Each team can help testing in Django 2.0 and/or python 3 support.
> We need to enable corresponding server projects in development environments,
> but it is not easy to setup all projects by horizon team. Individual
> projects must be
> more familiar with their own projects.
> I sent several patches,  but I actually tested them by unit tests.
> 
> Thanks,
> Akihiro
> 
> >
> > Doug
> >
> > >
> > > Thanks,
> > > Akihiro
> > >
> > > [1] https://review.openstack.org/#/c/566476/
> > >
> > > 2018年5月8日(火) 17:45 Thomas Goirand :
> > >
> > > > Hi,
> > > >
> > > > It has been decided that, in Debian, we'll switch to Django 2.0 after
> > > > Buster will be released. Buster is to be frozen next February. This
> > > > means that we have roughly one more year before Django 1.x goes away.
> > > >
> > > > Hopefully, Horizon will be ready for it, right?
> > > >
> > > > Hoping this helps,
> > > > 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] [horizon] Scheduling switch to django >= 2.0

[Akihiro Motoki]

2018年5月12日(土) 3:04 Doug Hellmann :

> Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
> > Hi zigo and horizon plugin maintainers,
> >
> > Horizon itself already supports Django 2.0 and horizon unit test covers
> > Django 2.0 with Python 3.5.
> >
> > A question to all is whether we change the upper bound of Django from
> <2.0
> > to <2.1.
> > My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
> > (Note that Django 1.11 will continue to be used for python 2.7
> environment.)
>
> Do we need to cap it at all? We've been trying to express our
> dependencies without caps and rely on the constraints list to
> test using a common version because this offers the most flexibility as
> we move to newer versions over time.
>

The main reason we cap django version so far is that django minor version
releases
contain some backward incompatible changes and also drop deprecated
features.
A new django minor version release like 1.11 usually breaks horizon and
plugins
as horizon developers are not always checking django deprecations.

I have a question on uncapping the django version.
How can users/operators know which versions are supported?
Do they need to check upper-constraints.txt?



> > There are several points we should consider:
> > - If we change it in global-requirements.txt, it means Django 2.0 will be
> > used for python3.5 environment.
> > - Not a small number of horizon plugins still do not support Django 2.0,
> so
> > bumping the upper bound to <2.1 will break their py35 tests.
> > - From my experience of Django 2.0 support in some plugins, the required
> > changes are relatively simple like [1].
> >
> > I created an etherpad page to track Django 2.0 support in horizon
> plugins.
> > https://etherpad.openstack.org/p/django20-support
> >
> > I proposed Django 2.0 support patches to several projects which I think
> are
> > major.
> > # Do not blame me if I don't cover your project :)
> >
> > Thought?
>
> It seems like a good goal for the horizon-plugin author community
> to bring those projects up to date by supporting a current version
> of Django (and any other dependencies), especially as we discuss
> the impending switch over to python-3-first and then python-3-only.
>

Yes, python 3 support is an important topic.
We also need to switch the default python version in mod_wsgi in DevStack
environment sooner or later.


> If this is an area where teams need help, updating that etherpad
> with notes and requests for assistance will help us split up the
> work.
>

Each team can help testing in Django 2.0 and/or python 3 support.
We need to enable corresponding server projects in development environments,
but it is not easy to setup all projects by horizon team. Individual
projects must be
more familiar with their own projects.
I sent several patches,  but I actually tested them by unit tests.

Thanks,
Akihiro


>
> Doug
>
> >
> > Thanks,
> > Akihiro
> >
> > [1] https://review.openstack.org/#/c/566476/
> >
> > 2018年5月8日(火) 17:45 Thomas Goirand :
> >
> > > Hi,
> > >
> > > It has been decided that, in Debian, we'll switch to Django 2.0 after
> > > Buster will be released. Buster is to be frozen next February. This
> > > means that we have roughly one more year before Django 1.x goes away.
> > >
> > > Hopefully, Horizon will be ready for it, right?
> > >
> > > Hoping this helps,
> > > 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 Development Mailing 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] Scheduling switch to django >= 2.0

[Thomas Goirand]

On 05/11/2018 05:14 PM, Akihiro Motoki wrote:
> Hi zigo and horizon plugin maintainers,
> 
> Horizon itself already supports Django 2.0 and horizon unit test covers
> Django 2.0 with Python 3.5.
> 
> A question to all is whether we change the upper bound of Django from
> <2.0 to <2.1.
> My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
> (Note that Django 1.11 will continue to be used for python 2.7 environment.)

All this is nice, thanks for working on Django 2.x. But Debian Buster
will be released with Django 1.11 and Python 3.6. So what I need, as far
as Debian is concerned is:

- Python 3.6 & Django 1.11 for Rocky (that's for Debian Buster).
- Python 3.6, probably even 3.7 and Django 2.0 for Stein (that's for
after Buster is released).

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] [horizon] Scheduling switch to django >= 2.0

[Doug Hellmann]

Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
> Hi zigo and horizon plugin maintainers,
> 
> Horizon itself already supports Django 2.0 and horizon unit test covers
> Django 2.0 with Python 3.5.
> 
> A question to all is whether we change the upper bound of Django from <2.0
> to <2.1.
> My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
> (Note that Django 1.11 will continue to be used for python 2.7 environment.)

Do we need to cap it at all? We've been trying to express our
dependencies without caps and rely on the constraints list to
test using a common version because this offers the most flexibility as
we move to newer versions over time.

> There are several points we should consider:
> - If we change it in global-requirements.txt, it means Django 2.0 will be
> used for python3.5 environment.
> - Not a small number of horizon plugins still do not support Django 2.0, so
> bumping the upper bound to <2.1 will break their py35 tests.
> - From my experience of Django 2.0 support in some plugins, the required
> changes are relatively simple like [1].
> 
> I created an etherpad page to track Django 2.0 support in horizon plugins.
> https://etherpad.openstack.org/p/django20-support
> 
> I proposed Django 2.0 support patches to several projects which I think are
> major.
> # Do not blame me if I don't cover your project :)
> 
> Thought?

It seems like a good goal for the horizon-plugin author community
to bring those projects up to date by supporting a current version
of Django (and any other dependencies), especially as we discuss
the impending switch over to python-3-first and then python-3-only.

If this is an area where teams need help, updating that etherpad
with notes and requests for assistance will help us split up the
work.

Doug

> 
> Thanks,
> Akihiro
> 
> [1] https://review.openstack.org/#/c/566476/
> 
> 2018年5月8日(火) 17:45 Thomas Goirand :
> 
> > Hi,
> >
> > It has been decided that, in Debian, we'll switch to Django 2.0 after
> > Buster will be released. Buster is to be frozen next February. This
> > means that we have roughly one more year before Django 1.x goes away.
> >
> > Hopefully, Horizon will be ready for it, right?
> >
> > Hoping this helps,
> > 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

Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Akihiro Motoki]

Hi zigo and horizon plugin maintainers,

Horizon itself already supports Django 2.0 and horizon unit test covers
Django 2.0 with Python 3.5.

A question to all is whether we change the upper bound of Django from <2.0
to <2.1.
My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
(Note that Django 1.11 will continue to be used for python 2.7 environment.)

There are several points we should consider:
- If we change it in global-requirements.txt, it means Django 2.0 will be
used for python3.5 environment.
- Not a small number of horizon plugins still do not support Django 2.0, so
bumping the upper bound to <2.1 will break their py35 tests.
- From my experience of Django 2.0 support in some plugins, the required
changes are relatively simple like [1].

I created an etherpad page to track Django 2.0 support in horizon plugins.
https://etherpad.openstack.org/p/django20-support

I proposed Django 2.0 support patches to several projects which I think are
major.
# Do not blame me if I don't cover your project :)

Thought?

Thanks,
Akihiro

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

2018年5月8日(火) 17:45 Thomas Goirand :

> Hi,
>
> It has been decided that, in Debian, we'll switch to Django 2.0 after
> Buster will be released. Buster is to be frozen next February. This
> means that we have roughly one more year before Django 1.x goes away.
>
> Hopefully, Horizon will be ready for it, right?
>
> Hoping this helps,
> 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] [horizon] Scheduling switch to django >= 2.0

[Thomas Goirand]

Hi,

It has been decided that, in Debian, we'll switch to Django 2.0 after
Buster will be released. Buster is to be frozen next February. This
means that we have roughly one more year before Django 1.x goes away.

Hopefully, Horizon will be ready for it, right?

Hoping this helps,
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-dev] [horizon] No meeting this week

[Ivan Kolodyazhny]

Hi team,

Due to the Victory Day, I won't be able to chair the meeting this week.
After a short conversation in the IRC, we decided to skip this meeting.
Feel free to add your topic to
https://wiki.openstack.org/wiki/Meetings/Horizon and see you next week!

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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][nova][cinder] Horizon support for multiattach volumes

[Ivan Kolodyazhny]

Matt, thank you for all your efforts!

I'm going to work on Horizon blueprint soon to get it implemented in Rocky

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, Apr 25, 2018 at 4:57 PM, Matt Riedemann  wrote:

> I wanted to advertise the need for some help in adding multiattach volume
> support to Horizon. There is a blueprint tracking the changes [1]. I
> started the ball rolling with [2] but there is more work to do, listed in
> the work items section of the blueprint.
>
> [2] was I think my first real code contribution to Horizon and it wasn't
> terrible (thanks for Akihiro's patience), so I'm sure others could easily
> jump in here and slice this up if we have people looking for something to
> hack on.
>
> [1] https://blueprints.launchpad.net/horizon/+spec/multi-attach-volume
> [2] https://review.openstack.org/#/c/547856/
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing 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] [horizon][nova][cinder] Horizon support for multiattach volumes

[Matt Riedemann]

I wanted to advertise the need for some help in adding multiattach 
volume support to Horizon. There is a blueprint tracking the changes 
[1]. I started the ball rolling with [2] but there is more work to do, 
listed in the work items section of the blueprint.


[2] was I think my first real code contribution to Horizon and it wasn't 
terrible (thanks for Akihiro's patience), so I'm sure others could 
easily jump in here and slice this up if we have people looking for 
something to hack on.


[1] https://blueprints.launchpad.net/horizon/+spec/multi-attach-volume
[2] https://review.openstack.org/#/c/547856/

--

Thanks,

Matt

__
OpenStack Development Mailing 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] Release of openstack/xstatic-angular-vis failed

[Andreas Jaeger]

On 2018-04-23 21:45, Sean McGinnis wrote:
> See below for logs from a failed xstatic release job. It appears something is
> not set up right with this job.
> 
> "can't open file 'xstatic_check_version.py': [Errno 2] No such file or
> directory"
> 
> I missed it initially, but this release did not actually contain any 
> functional
> change, so I think it is fine that it failed. We can just hold off on doing
> anything with it until there are actual changes made that need to be 
> delivered.
> 
> But it did at least act as a good pipecleaner in that it found this job
> failure. I don't know enough about the release job itself, but please feel 
> free
> to reach out in the #openstack-release channel if there is anything the 
> release
> team can do to help get this sorted out and ready for when an actual release 
> is
> needed.

https://review.openstack.org/563752 should fix it,

Andreas

> Thanks,
> Sean
> 
> - Forwarded message from z...@openstack.org -
> 
> Date: Mon, 23 Apr 2018 17:03:18 +
> From: z...@openstack.org
> To: release-job-failu...@lists.openstack.org
> Subject: [Release-job-failures] Release of openstack/xstatic-angular-vis 
> failed
> Reply-To: openstack-dev@lists.openstack.org
> 
> Build failed.
> 
> - xstatic-check-version 
> http://logs.openstack.org/59/591c61a6bf706434e19de85809f4c37adc612280/release/xstatic-check-version/613f7fc/
>  : FAILURE in 2m 23s
> - release-openstack-python release-openstack-python : SKIPPED
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
> 
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
> 
> - End forwarded message -
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: 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

[openstack-dev] [horizon] Release of openstack/xstatic-angular-vis failed

[Sean McGinnis]

See below for logs from a failed xstatic release job. It appears something is
not set up right with this job.

"can't open file 'xstatic_check_version.py': [Errno 2] No such file or
directory"

I missed it initially, but this release did not actually contain any functional
change, so I think it is fine that it failed. We can just hold off on doing
anything with it until there are actual changes made that need to be delivered.

But it did at least act as a good pipecleaner in that it found this job
failure. I don't know enough about the release job itself, but please feel free
to reach out in the #openstack-release channel if there is anything the release
team can do to help get this sorted out and ready for when an actual release is
needed.

Thanks,
Sean

- Forwarded message from z...@openstack.org -

Date: Mon, 23 Apr 2018 17:03:18 +
From: z...@openstack.org
To: release-job-failu...@lists.openstack.org
Subject: [Release-job-failures] Release of openstack/xstatic-angular-vis failed
Reply-To: openstack-dev@lists.openstack.org

Build failed.

- xstatic-check-version 
http://logs.openstack.org/59/591c61a6bf706434e19de85809f4c37adc612280/release/xstatic-check-version/613f7fc/
 : FAILURE in 2m 23s
- release-openstack-python release-openstack-python : SKIPPED
- announce-release announce-release : SKIPPED
- propose-update-constraints propose-update-constraints : SKIPPED

___
Release-job-failures mailing list
release-job-failu...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

- End forwarded message -

__
OpenStack Development Mailing 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][plugins] mox -> mock migration

[Akihiro Motoki]

Hi horizon plugin developers,

As I announced in the quoted mail, Rocky-1 was released and mox is NOT
prepared in the horizon test helpers by default now [1].
If your horizon plugin still depends on mox, please ensure to set use_mox =
True in your test classes.

> 2) After Rocky-1, use_mox of openstack_dashboard.test.helpers.TestCase will
be changed from True to False.
>  This means your plugin needs to set use_mox to True explicitly if your
unit tests still depends on mox.
>  Our suggestion is to set use_mox=True until Rocky-1 milestone if your
tests depends on mox not to break your gate.

[1] https://review.openstack.org/558048

Thanks,
Akihiro Motoki (amotoki)

2018-03-18 17:54 GMT+09:00 Akihiro Motoki :

> Hi horizon plugin developers,
>
> As you know, mox-removal is one of the community goal in Rocky and
> horizon team is working on removing usage of mox [1].
>
> This mail announces the plan of dropping mox dependencies in horizon
> test helpers (horizon.test.helpers.TestCase and/or
> openstack_dashboard.test.helpers.TestCase).
>
> 1) The first step is to introduce "use_mox" flag in
> horizon.test.helpers.TestCase. The flag is available now.
> If you set the flag to False, you can run your plugin test without mox.
> The default value of use_mox is False for
> horizon.test.helpers.TestCase [2] and True for
> openstack_dashboard.test.helpers.TestCase [3].
>
> 2) After Rocky-1, use_mox of openstack_dashboard.test.helpers.TestCase
> will be changed from True to False.
>  This means your plugin needs to set use_mox to True explicitly if
> your unit tests still depends on mox.
>  Our suggestion is to set use_mox=True until Rocky-1 milestone if
> your tests depends on mox not to break your gate.
>
> 3) After Rocky RC1 is released, "use_mox" flag in the horizon repo
> will be dropped.
> This means use_mox flag will no longer be in effect.
> If your plugin tests still depends on mox at this stage, your
> plugin test needs to set up mox explicitly.
>
> Thanks,
> Akihiro Motoki (amotoki)
>
> [1] https://blueprints.launchpad.net/horizon/+spec/mock-
> framework-in-unit-tests
> [2] https://github.com/openstack/horizon/blob/
> 6e29fdde1edc67a6797eba2c3f9c557f840d4ea7/horizon/test/helpers.py#L138
> [3] https://github.com/openstack/horizon/blob/
> 6e29fdde1edc67a6797eba2c3f9c557f840d4ea7/openstack_
> dashboard/test/helpers.py#L257
>
__
OpenStack Development Mailing 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] Meeting time and location are changed

[Ivan Kolodyazhny]

Hi,

It's just a reminder that we've got our meeting today at 15.00UTC at
openstack-meeting-alt channel.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Mon, Apr 16, 2018 at 12:01 PM, Ivan Kolodyazhny  wrote:

> Hi team,
>
> Please be informed that Horizon meeting time has been changed [1]. We'll
> have our weekly meetings at 15.00 UTC starting this week at
> 'openstack-meeting-alt' channel. We had to change meeting channel too due
> to the conflict with others.
>
>
> [1] https://review.openstack.org/#/c/560979/
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
__
OpenStack Development Mailing 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] [horizon] Meeting time and location are changed

[Ivan Kolodyazhny]

Hi team,

Please be informed that Horizon meeting time has been changed [1]. We'll
have our weekly meetings at 15.00 UTC starting this week at
'openstack-meeting-alt' channel. We had to change meeting channel too due
to the conflict with others.


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

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] [horizon][plugins] Improve Horizon testing

[Ivan Kolodyazhny]

Hi all,

Let me introduce my proposal about Horizon testing improvements[1]. We
started this discussion at the last PTG [2] and had a good conversation at
the previous meeting [3].

The idea is simple: to have CI that verifies Horizon changes across
supported plugins. As a side-effect of this activity, we'll have a list of
maintained and supported plugins per each release. For now, we have
a static list in Horizon Install Guide only [4]

We don't have Selenium-based tests now. the selenium-headless job always
reports
success. Integration tests are totally broken and we even don't run them on
gates. We need to fix selenium-headless job and integration tests too.

It would be great to have new gate job per each plugin per any
Horizon code change to be sure that we don't break anything. The same job
with
plugin-specific selenium or integration tests should be executed against
each
Horizon plugin's change request.

To make this happen, we need to fix horizon's selenium and integration
tests first. One of the first steps is to get rid of nose from Horizon and
plugins. Initially, I tried to use Django Test Runner but XMLTestRunner [5]
looks better for me because of it generates a report in xunit format.
Ideally, it would be great to use pytest for it, but it requires more
efforts now. stestr requires some work to get it working with Django too.

I know that Horizon team already introduced some new things in Rocky which
require action from plugins developers like moving to Mock (it's one of the
community goals for this release for all projects) and support
Django<2.0,>=1.11. That's why I'm ready to help plugins with test runner
migration and propose a patch for each plugin in a list [4].

Since it's supposed to be a cross-project activity, I would like to get
feedback from Horizon Plugins developers.



[1] https://blueprints.launchpad.net/horizon/+spec/improve-horizon-testing
[2] https://etherpad.openstack.org/p/horizon-ptg-rocky
[3]
http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-04-04-20.01.log.html#l-25
[4] https://docs.openstack.org/horizon/latest/install/plugin-registry.html
[5] https://review.openstack.org/#/c/544296/


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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][xstatic]How to handle xstatic if upstream files are modified

[Xinni Ge]

Hi Radomir, Ivan,

Thanks a lot for your advice.
I will update the xstatic files just as the upstream.
As for the customized lines, I will try to find a better way to solve it,
maybe override the original functions inside the project.

Best regards,
Xinni

On Tue, Apr 10, 2018 at 4:58 AM, Ivan Kolodyazhny  wrote:

> Hi, Xinni,
>
> I absolutely agree with Radomir. We should keep xstatic files without
> modifications. We don't know if they are used outside of OpenStack or not,
> so they should be the same as NPM packages
>
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Mon, Apr 9, 2018 at 12:32 PM, Radomir Dopieralski <
> openst...@sheep.art.pl> wrote:
>
>> The whole idea about xstatic files is that they are generic, not specific
>> to Horizon or OpenStack, usable by other projects that need those static
>> files. In fact, at the time we started using xstatic, it was being used by
>> the MoinMoin wiki project (which is now dead, sadly). The modifications you
>> made are very specific to your usecase and would make it impossible to
>> reuse the packages by other applications (or even by other Horizon
>> plugins). The whole idea of a library is that you are using it as it is
>> provided, and not modifying it.
>>
>> We generally try to use all the libraries as they are, and if there are
>> any modifications necessary, we push them upstream, to the original
>> library. Otherwise there would be quite a bit of maintenance overhead
>> necessary to keep all our downstream patches. When considerable
>> modification is necessary that can't be pushed upstream, we fork the
>> library either into its own repository, or include it in the repository of
>> the application that is using it.
>>
>> On Mon, Apr 9, 2018 at 2:54 AM, Xinni Ge  wrote:
>>
>>> Hello, team.
>>>
>>> Sorry for talking about xstatic repo for so many times.
>>>
>>> I didn't realize xstatic repositories should be provided with exactly
>>> the same file as upstream, and should have talked about it at very first.
>>>
>>> I modified several upstream files because some of them files couldn't be
>>> used directly under my expectation.
>>>
>>> For example,  {{ }} are used in some original files as template tags,
>>> but Horizon adopts {$ $} in angular module, so I modified them to be
>>> recognized properly.
>>>
>>> Another major modification is that css files are converted into scss
>>> files to solve some css import issue previously.
>>> Besides, after collecting statics, some png file paths in css cannot be
>>> referenced properly and shown as 404 errors, I also modified css itself to
>>> handle this issues.
>>>
>>> I will recheck all the un-matched xstatic repositories and try to
>>> replace with upstream  files as much as I can.
>>> But I if I really have to modify some original files, is it acceptable
>>> to still use it as embedded files with license info appeared at the top?
>>>
>>>
>>> Best Regards,
>>> Xinni Ge
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> 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
>
>


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

Re: [openstack-dev] [horizon][xstatic]How to handle xstatic if upstream files are modified

[Ivan Kolodyazhny]

Hi, Xinni,

I absolutely agree with Radomir. We should keep xstatic files without
modifications. We don't know if they are used outside of OpenStack or not,
so they should be the same as NPM packages


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Mon, Apr 9, 2018 at 12:32 PM, Radomir Dopieralski  wrote:

> The whole idea about xstatic files is that they are generic, not specific
> to Horizon or OpenStack, usable by other projects that need those static
> files. In fact, at the time we started using xstatic, it was being used by
> the MoinMoin wiki project (which is now dead, sadly). The modifications you
> made are very specific to your usecase and would make it impossible to
> reuse the packages by other applications (or even by other Horizon
> plugins). The whole idea of a library is that you are using it as it is
> provided, and not modifying it.
>
> We generally try to use all the libraries as they are, and if there are
> any modifications necessary, we push them upstream, to the original
> library. Otherwise there would be quite a bit of maintenance overhead
> necessary to keep all our downstream patches. When considerable
> modification is necessary that can't be pushed upstream, we fork the
> library either into its own repository, or include it in the repository of
> the application that is using it.
>
> On Mon, Apr 9, 2018 at 2:54 AM, Xinni Ge  wrote:
>
>> Hello, team.
>>
>> Sorry for talking about xstatic repo for so many times.
>>
>> I didn't realize xstatic repositories should be provided with exactly the
>> same file as upstream, and should have talked about it at very first.
>>
>> I modified several upstream files because some of them files couldn't be
>> used directly under my expectation.
>>
>> For example,  {{ }} are used in some original files as template tags, but
>> Horizon adopts {$ $} in angular module, so I modified them to be recognized
>> properly.
>>
>> Another major modification is that css files are converted into scss
>> files to solve some css import issue previously.
>> Besides, after collecting statics, some png file paths in css cannot be
>> referenced properly and shown as 404 errors, I also modified css itself to
>> handle this issues.
>>
>> I will recheck all the un-matched xstatic repositories and try to replace
>> with upstream  files as much as I can.
>> But I if I really have to modify some original files, is it acceptable to
>> still use it as embedded files with license info appeared at the top?
>>
>>
>> Best Regards,
>> Xinni Ge
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [horizon][xstatic]How to handle xstatic if upstream files are modified

[Radomir Dopieralski]

The whole idea about xstatic files is that they are generic, not specific
to Horizon or OpenStack, usable by other projects that need those static
files. In fact, at the time we started using xstatic, it was being used by
the MoinMoin wiki project (which is now dead, sadly). The modifications you
made are very specific to your usecase and would make it impossible to
reuse the packages by other applications (or even by other Horizon
plugins). The whole idea of a library is that you are using it as it is
provided, and not modifying it.

We generally try to use all the libraries as they are, and if there are any
modifications necessary, we push them upstream, to the original library.
Otherwise there would be quite a bit of maintenance overhead necessary to
keep all our downstream patches. When considerable modification is
necessary that can't be pushed upstream, we fork the library either into
its own repository, or include it in the repository of the application that
is using it.

On Mon, Apr 9, 2018 at 2:54 AM, Xinni Ge  wrote:

> Hello, team.
>
> Sorry for talking about xstatic repo for so many times.
>
> I didn't realize xstatic repositories should be provided with exactly the
> same file as upstream, and should have talked about it at very first.
>
> I modified several upstream files because some of them files couldn't be
> used directly under my expectation.
>
> For example,  {{ }} are used in some original files as template tags, but
> Horizon adopts {$ $} in angular module, so I modified them to be recognized
> properly.
>
> Another major modification is that css files are converted into scss files
> to solve some css import issue previously.
> Besides, after collecting statics, some png file paths in css cannot be
> referenced properly and shown as 404 errors, I also modified css itself to
> handle this issues.
>
> I will recheck all the un-matched xstatic repositories and try to replace
> with upstream  files as much as I can.
> But I if I really have to modify some original files, is it acceptable to
> still use it as embedded files with license info appeared at the top?
>
>
> 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

[openstack-dev] [horizon][xstatic]How to handle xstatic if upstream files are modified

[Xinni Ge]

Hello, team.

Sorry for talking about xstatic repo for so many times.

I didn't realize xstatic repositories should be provided with exactly the
same file as upstream, and should have talked about it at very first.

I modified several upstream files because some of them files couldn't be
used directly under my expectation.

For example,  {{ }} are used in some original files as template tags, but
Horizon adopts {$ $} in angular module, so I modified them to be recognized
properly.

Another major modification is that css files are converted into scss files
to solve some css import issue previously.
Besides, after collecting statics, some png file paths in css cannot be
referenced properly and shown as 404 errors, I also modified css itself to
handle this issues.

I will recheck all the un-matched xstatic repositories and try to replace
with upstream  files as much as I can.
But I if I really have to modify some original files, is it acceptable to
still use it as embedded files with license info appeared at the top?


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

Re: [openstack-dev] [horizon] Do we want new meeting time?

[Ivan Kolodyazhny]

Hi team,

It's a friendly reminder that we've got voting open [1] until next meeting.
If you would like to attend Horizon meetings, please, select comfortable
options for you.

[1] https://doodle.com/poll/ei5gstt73d8v3a35

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, Mar 21, 2018 at 6:40 PM, Ivan Kolodyazhny  wrote:

> Hi team,
>
> As was discussed at PTG, usually we've got a very few participants on our
> weekly meetings. I hope, mostly it's because of not comfort meeting time
> for many of us.
>
> Let's try to re-schedule Horizon weekly meetings and get more attendees
> there. I've created a doodle for it [1]. Please, vote for the best time for
> you.
>
>
> [1] https://doodle.com/poll/ei5gstt73d8v3a35
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
__
OpenStack Development Mailing 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

[Akihiro Motoki]

Hi Xinni,

There is no need that you push a tag manually for official deliverables.
You can propose a patch to openstack/releases repository.
Horizon PTL or release liaison (at now both Ivan) can confirm it and the
release team will approve it.
Once it is approved, a release tag will be added and a deliverable will be
published automatically by the infra script (if you've setup project-config
appropriately).

Akihiro

2018-04-04 14:34 GMT+09:00 Xinni Ge :

> Hi Ivan and other Horizon team member,
>
> Thanks for adding us into xstatic-core group.
> But I still need your opinion and help to release the newly-added xstatic
> packages to pypi index.
>
> Current `xstatic-core` group doesn't have the permission to PUSH SIGNED
> TAG, and I cannot release the first non-trivial version.
>
> If I (or maybe Kaz) could be added into xstatic-release group, we can
> release all the 8 packages by ourselves.
>
> Or, we are very appreciate if any member of xstatic-release could help to
> do it.
>
> Just for your quick access, here is the link of access permission page of
> one xstatic package.
> https://review.openstack.org/#/admin/projects/openstack/
> xstatic-angular-material,access
>
> --
> Best Regards,
> Xinni
>
> On Thu, Mar 29, 2018 at 9:59 AM, Kaz Shinohara 
> wrote:
>
>> Hi Ivan,
>>
>>
>> Thank you very much.
>> I've confirmed that all of us have been added to xstatic-core.
>>
>> As discussed, we will focus on the followings what we added for
>> heat-dashboard, will not touch other xstatic repos as core.
>>
>> xstatic-angular-material
>> xstatic-angular-notify
>> xstatic-angular-uuid
>> xstatic-angular-vis
>> xstatic-filesaver
>> xstatic-js-yaml
>> xstatic-json2yaml
>> xstatic-vis
>>
>> Regards,
>> Kaz
>>
>> 2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny :
>> > Hi Kuz,
>> >
>> > Don't worry, we're on the same page with you. I added both you, Xinni
>> and
>> > Keichii to the xstatic-core group. Thank you for your contributions!
>> >
>> > Regards,
>> > Ivan Kolodyazhny,
>> > http://blog.e0ne.info/
>> >
>> > On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara 
>> wrote:
>> >>
>> >> Hi Ivan & Horizon folks
>> >>
>> >>
>> >> AFAIK, Horizon team had conclusion that you will add the specific
>> >> members to xstatic-core, correct ?
>> >> Can I ask you to add the following members ?
>> >> # All of tree are heat-dashboard core.
>> >>
>> >> Kazunori Shinohara / ksnhr.t...@gmail.com #myself
>> >> Xinni Ge / xinni.ge1...@gmail.com
>> >> Keiichi Hikita / keiichi.hik...@gmail.com
>> >>
>> >> Please give me a shout, if we are not on same page or any concern.
>> >>
>> >> Regards,
>> >> Kaz
>> >>
>> >>
>> >> 2018-03-21 22:29 GMT+09:00 Kaz Shinohara :
>> >> > Hi Ivan, Akihiro,
>> >> >
>> >> >
>> >> > Thanks for your kind arrangement.
>> >> > Looking forward to hearing your decision soon.
>> >> >
>> >> > Regards,
>> >> > Kaz
>> >> >
>> >> > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
>> >> >> HI Team,
>> >> >>
>> >> >> From my perspective, I'm OK both with #2 and #3 options. I agree
>> that
>> >> >> #4
>> >> >> could be too complicated for us. Anyway, we've got this topic on the
>> >> >> meeting
>> >> >> agenda [1] so we'll discuss it there too. I'll share our decision
>> after
>> >> >> the
>> >> >> meeting.
>> >> >>
>> >> >> [1] https://wiki.openstack.org/wiki/Meetings/Horizon
>> >> >>
>> >> >>
>> >> >>
>> >> >> Regards,
>> >> >> Ivan Kolodyazhny,
>> >> >> http://blog.e0ne.info/
>> >> >>
>> >> >> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki > >
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Kaz and Ivan,
>> >> >>>
>> >> >>> Yeah, it is worth discussed officially in the horizon team meeting
>> or
>> >> >>> the
>> >> >>> mailing list thread to get a consensus.
>> >> >>> Hopefully you can add this topic to the horizon meeting agenda.
>> >> >>>
>> >> >>> After sending the previous mail, I noticed anther option. I see
>> there
>> >> >>> are
>> >> >>> several options now.
>> >> >>> (1) Keep xstatic-core and horizon-core same.
>> >> >>> (2) Add specific members to xstatic-core
>> >> >>> (3) Add specific horizon-plugin core to xstatic-core
>> >> >>> (4) Split core membership into per-repo basis (perhaps too
>> >> >>> complicated!!)
>> >> >>>
>> >> >>> My current vote is (2) as xstatic-core needs to understand what is
>> >> >>> xstatic
>> >> >>> and how it is maintained.
>> >> >>>
>> >> >>> Thanks,
>> >> >>> Akihiro
>> >> >>>
>> >> >>>
>> >> >>> 2018-03-20 17:17 GMT+09:00 Kaz Shinohara :
>> >> 
>> >>  Hi Akihiro,
>> >> 
>> >> 
>> >>  Thanks for your comment.
>> >>  The background of my request to add us to xstatic-core comes from
>> >>  Ivan's comment in last PTG's etherpad for heat-dashboard
>> discussion.
>> >> 
>> >>  https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-
>> discussion
>> >>  Line135, "we can share ownership if needed - e0ne"
>> >> 
>> >>  Just in case, could you guys confirm unified opinion on this
>> matter
>> >>  as
>> >>  Horizon team ?
>> >> 
>> >>  Frankly sp

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

[Ivan Kolodyazhny]

Hi Xinni,

Please, send me a list of packages which should be released.

In general, release-* groups are different from core-*. We should discuss
how to go forward with it

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, Apr 4, 2018 at 8:34 AM, Xinni Ge  wrote:

> Hi Ivan and other Horizon team member,
>
> Thanks for adding us into xstatic-core group.
> But I still need your opinion and help to release the newly-added xstatic
> packages to pypi index.
>
> Current `xstatic-core` group doesn't have the permission to PUSH SIGNED
> TAG, and I cannot release the first non-trivial version.
>
> If I (or maybe Kaz) could be added into xstatic-release group, we can
> release all the 8 packages by ourselves.
>
> Or, we are very appreciate if any member of xstatic-release could help to
> do it.
>
> Just for your quick access, here is the link of access permission page of
> one xstatic package.
> https://review.openstack.org/#/admin/projects/openstack/
> xstatic-angular-material,access
>
> --
> Best Regards,
> Xinni
>
> On Thu, Mar 29, 2018 at 9:59 AM, Kaz Shinohara 
> wrote:
>
>> Hi Ivan,
>>
>>
>> Thank you very much.
>> I've confirmed that all of us have been added to xstatic-core.
>>
>> As discussed, we will focus on the followings what we added for
>> heat-dashboard, will not touch other xstatic repos as core.
>>
>> xstatic-angular-material
>> xstatic-angular-notify
>> xstatic-angular-uuid
>> xstatic-angular-vis
>> xstatic-filesaver
>> xstatic-js-yaml
>> xstatic-json2yaml
>> xstatic-vis
>>
>> Regards,
>> Kaz
>>
>> 2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny :
>> > Hi Kuz,
>> >
>> > Don't worry, we're on the same page with you. I added both you, Xinni
>> and
>> > Keichii to the xstatic-core group. Thank you for your contributions!
>> >
>> > Regards,
>> > Ivan Kolodyazhny,
>> > http://blog.e0ne.info/
>> >
>> > On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara 
>> wrote:
>> >>
>> >> Hi Ivan & Horizon folks
>> >>
>> >>
>> >> AFAIK, Horizon team had conclusion that you will add the specific
>> >> members to xstatic-core, correct ?
>> >> Can I ask you to add the following members ?
>> >> # All of tree are heat-dashboard core.
>> >>
>> >> Kazunori Shinohara / ksnhr.t...@gmail.com #myself
>> >> Xinni Ge / xinni.ge1...@gmail.com
>> >> Keiichi Hikita / keiichi.hik...@gmail.com
>> >>
>> >> Please give me a shout, if we are not on same page or any concern.
>> >>
>> >> Regards,
>> >> Kaz
>> >>
>> >>
>> >> 2018-03-21 22:29 GMT+09:00 Kaz Shinohara :
>> >> > Hi Ivan, Akihiro,
>> >> >
>> >> >
>> >> > Thanks for your kind arrangement.
>> >> > Looking forward to hearing your decision soon.
>> >> >
>> >> > Regards,
>> >> > Kaz
>> >> >
>> >> > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
>> >> >> HI Team,
>> >> >>
>> >> >> From my perspective, I'm OK both with #2 and #3 options. I agree
>> that
>> >> >> #4
>> >> >> could be too complicated for us. Anyway, we've got this topic on the
>> >> >> meeting
>> >> >> agenda [1] so we'll discuss it there too. I'll share our decision
>> after
>> >> >> the
>> >> >> meeting.
>> >> >>
>> >> >> [1] https://wiki.openstack.org/wiki/Meetings/Horizon
>> >> >>
>> >> >>
>> >> >>
>> >> >> Regards,
>> >> >> Ivan Kolodyazhny,
>> >> >> http://blog.e0ne.info/
>> >> >>
>> >> >> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki > >
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Kaz and Ivan,
>> >> >>>
>> >> >>> Yeah, it is worth discussed officially in the horizon team meeting
>> or
>> >> >>> the
>> >> >>> mailing list thread to get a consensus.
>> >> >>> Hopefully you can add this topic to the horizon meeting agenda.
>> >> >>>
>> >> >>> After sending the previous mail, I noticed anther option. I see
>> there
>> >> >>> are
>> >> >>> several options now.
>> >> >>> (1) Keep xstatic-core and horizon-core same.
>> >> >>> (2) Add specific members to xstatic-core
>> >> >>> (3) Add specific horizon-plugin core to xstatic-core
>> >> >>> (4) Split core membership into per-repo basis (perhaps too
>> >> >>> complicated!!)
>> >> >>>
>> >> >>> My current vote is (2) as xstatic-core needs to understand what is
>> >> >>> xstatic
>> >> >>> and how it is maintained.
>> >> >>>
>> >> >>> Thanks,
>> >> >>> Akihiro
>> >> >>>
>> >> >>>
>> >> >>> 2018-03-20 17:17 GMT+09:00 Kaz Shinohara :
>> >> 
>> >>  Hi Akihiro,
>> >> 
>> >> 
>> >>  Thanks for your comment.
>> >>  The background of my request to add us to xstatic-core comes from
>> >>  Ivan's comment in last PTG's etherpad for heat-dashboard
>> discussion.
>> >> 
>> >>  https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-
>> discussion
>> >>  Line135, "we can share ownership if needed - e0ne"
>> >> 
>> >>  Just in case, could you guys confirm unified opinion on this
>> matter
>> >>  as
>> >>  Horizon team ?
>> >> 
>> >>  Frankly speaking I'm feeling the benefit to make us xstatic-core
>> >>  because it's easier & smoother to manage what we are taking for
>> >>  heat-dashboard.
>> >>  On the other hand,

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

[Xinni Ge]

Hi Ivan and other Horizon team member,

Thanks for adding us into xstatic-core group.
But I still need your opinion and help to release the newly-added xstatic
packages to pypi index.

Current `xstatic-core` group doesn't have the permission to PUSH SIGNED
TAG, and I cannot release the first non-trivial version.

If I (or maybe Kaz) could be added into xstatic-release group, we can
release all the 8 packages by ourselves.

Or, we are very appreciate if any member of xstatic-release could help to
do it.

Just for your quick access, here is the link of access permission page of
one xstatic package.
https://review.openstack.org/#/admin/projects/openstack/xstatic-angular-material,access


--
Best Regards,
Xinni

On Thu, Mar 29, 2018 at 9:59 AM, Kaz Shinohara  wrote:

> Hi Ivan,
>
>
> Thank you very much.
> I've confirmed that all of us have been added to xstatic-core.
>
> As discussed, we will focus on the followings what we added for
> heat-dashboard, will not touch other xstatic repos as core.
>
> xstatic-angular-material
> xstatic-angular-notify
> xstatic-angular-uuid
> xstatic-angular-vis
> xstatic-filesaver
> xstatic-js-yaml
> xstatic-json2yaml
> xstatic-vis
>
> Regards,
> Kaz
>
> 2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny :
> > Hi Kuz,
> >
> > Don't worry, we're on the same page with you. I added both you, Xinni and
> > Keichii to the xstatic-core group. Thank you for your contributions!
> >
> > Regards,
> > Ivan Kolodyazhny,
> > http://blog.e0ne.info/
> >
> > On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara 
> wrote:
> >>
> >> Hi Ivan & Horizon folks
> >>
> >>
> >> AFAIK, Horizon team had conclusion that you will add the specific
> >> members to xstatic-core, correct ?
> >> Can I ask you to add the following members ?
> >> # All of tree are heat-dashboard core.
> >>
> >> Kazunori Shinohara / ksnhr.t...@gmail.com #myself
> >> Xinni Ge / xinni.ge1...@gmail.com
> >> Keiichi Hikita / keiichi.hik...@gmail.com
> >>
> >> Please give me a shout, if we are not on same page or any concern.
> >>
> >> Regards,
> >> Kaz
> >>
> >>
> >> 2018-03-21 22:29 GMT+09:00 Kaz Shinohara :
> >> > Hi Ivan, Akihiro,
> >> >
> >> >
> >> > Thanks for your kind arrangement.
> >> > Looking forward to hearing your decision soon.
> >> >
> >> > Regards,
> >> > Kaz
> >> >
> >> > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
> >> >> HI Team,
> >> >>
> >> >> From my perspective, I'm OK both with #2 and #3 options. I agree that
> >> >> #4
> >> >> could be too complicated for us. Anyway, we've got this topic on the
> >> >> meeting
> >> >> agenda [1] so we'll discuss it there too. I'll share our decision
> after
> >> >> the
> >> >> meeting.
> >> >>
> >> >> [1] https://wiki.openstack.org/wiki/Meetings/Horizon
> >> >>
> >> >>
> >> >>
> >> >> Regards,
> >> >> Ivan Kolodyazhny,
> >> >> http://blog.e0ne.info/
> >> >>
> >> >> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki 
> >> >> wrote:
> >> >>>
> >> >>> Hi Kaz and Ivan,
> >> >>>
> >> >>> Yeah, it is worth discussed officially in the horizon team meeting
> or
> >> >>> the
> >> >>> mailing list thread to get a consensus.
> >> >>> Hopefully you can add this topic to the horizon meeting agenda.
> >> >>>
> >> >>> After sending the previous mail, I noticed anther option. I see
> there
> >> >>> are
> >> >>> several options now.
> >> >>> (1) Keep xstatic-core and horizon-core same.
> >> >>> (2) Add specific members to xstatic-core
> >> >>> (3) Add specific horizon-plugin core to xstatic-core
> >> >>> (4) Split core membership into per-repo basis (perhaps too
> >> >>> complicated!!)
> >> >>>
> >> >>> My current vote is (2) as xstatic-core needs to understand what is
> >> >>> xstatic
> >> >>> and how it is maintained.
> >> >>>
> >> >>> Thanks,
> >> >>> Akihiro
> >> >>>
> >> >>>
> >> >>> 2018-03-20 17:17 GMT+09:00 Kaz Shinohara :
> >> 
> >>  Hi Akihiro,
> >> 
> >> 
> >>  Thanks for your comment.
> >>  The background of my request to add us to xstatic-core comes from
> >>  Ivan's comment in last PTG's etherpad for heat-dashboard
> discussion.
> >> 
> >>  https://etherpad.openstack.org/p/heat-dashboard-ptg-
> rocky-discussion
> >>  Line135, "we can share ownership if needed - e0ne"
> >> 
> >>  Just in case, could you guys confirm unified opinion on this matter
> >>  as
> >>  Horizon team ?
> >> 
> >>  Frankly speaking I'm feeling the benefit to make us xstatic-core
> >>  because it's easier & smoother to manage what we are taking for
> >>  heat-dashboard.
> >>  On the other hand, I can understand what Akihiro you are saying,
> the
> >>  newly added repos belong to Horizon project & being managed by not
> >>  Horizon core is not consistent.
> >>  Also having exception might make unexpected confusion in near
> future.
> >> 
> >>  Eventually we will follow your opinion, let me hear Horizon team's
> >>  conclusion.
> >> 
> >>  Regards,
> >>  Kaz
> >> 
> >> 
> >>  2018-03-20 12:58 GMT+09:00 Aki

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

[Kaz Shinohara]

Hi Ivan,


Thank you very much.
I've confirmed that all of us have been added to xstatic-core.

As discussed, we will focus on the followings what we added for
heat-dashboard, will not touch other xstatic repos as core.

xstatic-angular-material
xstatic-angular-notify
xstatic-angular-uuid
xstatic-angular-vis
xstatic-filesaver
xstatic-js-yaml
xstatic-json2yaml
xstatic-vis

Regards,
Kaz

2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny :
> Hi Kuz,
>
> Don't worry, we're on the same page with you. I added both you, Xinni and
> Keichii to the xstatic-core group. Thank you for your contributions!
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara  wrote:
>>
>> Hi Ivan & Horizon folks
>>
>>
>> AFAIK, Horizon team had conclusion that you will add the specific
>> members to xstatic-core, correct ?
>> Can I ask you to add the following members ?
>> # All of tree are heat-dashboard core.
>>
>> Kazunori Shinohara / ksnhr.t...@gmail.com #myself
>> Xinni Ge / xinni.ge1...@gmail.com
>> Keiichi Hikita / keiichi.hik...@gmail.com
>>
>> Please give me a shout, if we are not on same page or any concern.
>>
>> Regards,
>> Kaz
>>
>>
>> 2018-03-21 22:29 GMT+09:00 Kaz Shinohara :
>> > Hi Ivan, Akihiro,
>> >
>> >
>> > Thanks for your kind arrangement.
>> > Looking forward to hearing your decision soon.
>> >
>> > Regards,
>> > Kaz
>> >
>> > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
>> >> HI Team,
>> >>
>> >> From my perspective, I'm OK both with #2 and #3 options. I agree that
>> >> #4
>> >> could be too complicated for us. Anyway, we've got this topic on the
>> >> meeting
>> >> agenda [1] so we'll discuss it there too. I'll share our decision after
>> >> the
>> >> meeting.
>> >>
>> >> [1] https://wiki.openstack.org/wiki/Meetings/Horizon
>> >>
>> >>
>> >>
>> >> Regards,
>> >> Ivan Kolodyazhny,
>> >> http://blog.e0ne.info/
>> >>
>> >> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki 
>> >> wrote:
>> >>>
>> >>> Hi Kaz and Ivan,
>> >>>
>> >>> Yeah, it is worth discussed officially in the horizon team meeting or
>> >>> the
>> >>> mailing list thread to get a consensus.
>> >>> Hopefully you can add this topic to the horizon meeting agenda.
>> >>>
>> >>> After sending the previous mail, I noticed anther option. I see there
>> >>> are
>> >>> several options now.
>> >>> (1) Keep xstatic-core and horizon-core same.
>> >>> (2) Add specific members to xstatic-core
>> >>> (3) Add specific horizon-plugin core to xstatic-core
>> >>> (4) Split core membership into per-repo basis (perhaps too
>> >>> complicated!!)
>> >>>
>> >>> My current vote is (2) as xstatic-core needs to understand what is
>> >>> xstatic
>> >>> and how it is maintained.
>> >>>
>> >>> Thanks,
>> >>> Akihiro
>> >>>
>> >>>
>> >>> 2018-03-20 17:17 GMT+09:00 Kaz Shinohara :
>> 
>>  Hi Akihiro,
>> 
>> 
>>  Thanks for your comment.
>>  The background of my request to add us to xstatic-core comes from
>>  Ivan's comment in last PTG's etherpad for heat-dashboard discussion.
>> 
>>  https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussion
>>  Line135, "we can share ownership if needed - e0ne"
>> 
>>  Just in case, could you guys confirm unified opinion on this matter
>>  as
>>  Horizon team ?
>> 
>>  Frankly speaking I'm feeling the benefit to make us xstatic-core
>>  because it's easier & smoother to manage what we are taking for
>>  heat-dashboard.
>>  On the other hand, I can understand what Akihiro you are saying, the
>>  newly added repos belong to Horizon project & being managed by not
>>  Horizon core is not consistent.
>>  Also having exception might make unexpected confusion in near future.
>> 
>>  Eventually we will follow your opinion, let me hear Horizon team's
>>  conclusion.
>> 
>>  Regards,
>>  Kaz
>> 
>> 
>>  2018-03-20 12:58 GMT+09:00 Akihiro Motoki :
>>  > Hi Kaz,
>>  >
>>  > These repositories are under horizon project. It looks better to
>>  > keep
>>  > the
>>  > current core team.
>>  > It potentially brings some confusion if we treat some horizon
>>  > plugin
>>  > team
>>  > specially.
>>  > Reviewing xstatic repos would be a small burden, wo I think it
>>  > would
>>  > work
>>  > without problem even if only horizon-core can approve xstatic
>>  > reviews.
>>  >
>>  >
>>  > 2018-03-20 10:02 GMT+09:00 Kaz Shinohara :
>>  >>
>>  >> Hi Ivan, Horizon folks,
>>  >>
>>  >>
>>  >> Now totally 8 xstatic-** repos for heat-dashboard have been
>>  >> landed.
>>  >>
>>  >> In project-config for them, I've set same acl-config as the
>>  >> existing
>>  >> xstatic repos.
>>  >> It means only "xstatic-core" can manage the newly created repos on
>>  >> gerrit.
>>  >> Could you kindly add "heat-dashboard-core" into "xstatic-core"
>>  >> like as
>>  >> what hor

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

[Ivan Kolodyazhny]

Hi Kuz,

Don't worry, we're on the same page with you. I added both you, Xinni and
Keichii to the xstatic-core group. Thank you for your contributions!

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara  wrote:

> Hi Ivan & Horizon folks
>
>
> AFAIK, Horizon team had conclusion that you will add the specific
> members to xstatic-core, correct ?
> Can I ask you to add the following members ?
> # All of tree are heat-dashboard core.
>
> Kazunori Shinohara / ksnhr.t...@gmail.com #myself
> Xinni Ge / xinni.ge1...@gmail.com
> Keiichi Hikita / keiichi.hik...@gmail.com
>
> Please give me a shout, if we are not on same page or any concern.
>
> Regards,
> Kaz
>
>
> 2018-03-21 22:29 GMT+09:00 Kaz Shinohara :
> > Hi Ivan, Akihiro,
> >
> >
> > Thanks for your kind arrangement.
> > Looking forward to hearing your decision soon.
> >
> > Regards,
> > Kaz
> >
> > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
> >> HI Team,
> >>
> >> From my perspective, I'm OK both with #2 and #3 options. I agree that #4
> >> could be too complicated for us. Anyway, we've got this topic on the
> meeting
> >> agenda [1] so we'll discuss it there too. I'll share our decision after
> the
> >> meeting.
> >>
> >> [1] https://wiki.openstack.org/wiki/Meetings/Horizon
> >>
> >>
> >>
> >> Regards,
> >> Ivan Kolodyazhny,
> >> http://blog.e0ne.info/
> >>
> >> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki 
> wrote:
> >>>
> >>> Hi Kaz and Ivan,
> >>>
> >>> Yeah, it is worth discussed officially in the horizon team meeting or
> the
> >>> mailing list thread to get a consensus.
> >>> Hopefully you can add this topic to the horizon meeting agenda.
> >>>
> >>> After sending the previous mail, I noticed anther option. I see there
> are
> >>> several options now.
> >>> (1) Keep xstatic-core and horizon-core same.
> >>> (2) Add specific members to xstatic-core
> >>> (3) Add specific horizon-plugin core to xstatic-core
> >>> (4) Split core membership into per-repo basis (perhaps too
> complicated!!)
> >>>
> >>> My current vote is (2) as xstatic-core needs to understand what is
> xstatic
> >>> and how it is maintained.
> >>>
> >>> Thanks,
> >>> Akihiro
> >>>
> >>>
> >>> 2018-03-20 17:17 GMT+09:00 Kaz Shinohara :
> 
>  Hi Akihiro,
> 
> 
>  Thanks for your comment.
>  The background of my request to add us to xstatic-core comes from
>  Ivan's comment in last PTG's etherpad for heat-dashboard discussion.
> 
>  https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussion
>  Line135, "we can share ownership if needed - e0ne"
> 
>  Just in case, could you guys confirm unified opinion on this matter as
>  Horizon team ?
> 
>  Frankly speaking I'm feeling the benefit to make us xstatic-core
>  because it's easier & smoother to manage what we are taking for
>  heat-dashboard.
>  On the other hand, I can understand what Akihiro you are saying, the
>  newly added repos belong to Horizon project & being managed by not
>  Horizon core is not consistent.
>  Also having exception might make unexpected confusion in near future.
> 
>  Eventually we will follow your opinion, let me hear Horizon team's
>  conclusion.
> 
>  Regards,
>  Kaz
> 
> 
>  2018-03-20 12:58 GMT+09:00 Akihiro Motoki :
>  > Hi Kaz,
>  >
>  > These repositories are under horizon project. It looks better to
> keep
>  > the
>  > current core team.
>  > It potentially brings some confusion if we treat some horizon plugin
>  > team
>  > specially.
>  > Reviewing xstatic repos would be a small burden, wo I think it would
>  > work
>  > without problem even if only horizon-core can approve xstatic
> reviews.
>  >
>  >
>  > 2018-03-20 10:02 GMT+09:00 Kaz Shinohara :
>  >>
>  >> Hi Ivan, Horizon folks,
>  >>
>  >>
>  >> Now totally 8 xstatic-** repos for heat-dashboard have been landed.
>  >>
>  >> In project-config for them, I've set same acl-config as the
> existing
>  >> xstatic repos.
>  >> It means only "xstatic-core" can manage the newly created repos on
>  >> gerrit.
>  >> Could you kindly add "heat-dashboard-core" into "xstatic-core"
> like as
>  >> what horizon-core is doing ?
>  >>
>  >> xstatic-core
>  >> https://review.openstack.org/#/admin/groups/385,members
>  >>
>  >> heat-dashboard-core
>  >> https://review.openstack.org/#/admin/groups/1844,members
>  >>
>  >> Of course, we will surely touch only what we made, just would like
> to
>  >> manage them smoothly by ourselves.
>  >> In case we need to touch the other ones, will ask Horizon team for
>  >> help.
>  >>
>  >> Thanks in advance.
>  >>
>  >> Regards,
>  >> Kaz
>  >>
>  >>
>  >> 2018-03-14 15:12 GMT+09:00 Xinni Ge :
>  >> > Hi Horizon Team,
>  >> >
>  >> > I reported a bug about lack

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

[Kaz Shinohara]

Hi Ivan & Horizon folks


AFAIK, Horizon team had conclusion that you will add the specific
members to xstatic-core, correct ?
Can I ask you to add the following members ?
# All of tree are heat-dashboard core.

Kazunori Shinohara / ksnhr.t...@gmail.com #myself
Xinni Ge / xinni.ge1...@gmail.com
Keiichi Hikita / keiichi.hik...@gmail.com

Please give me a shout, if we are not on same page or any concern.

Regards,
Kaz


2018-03-21 22:29 GMT+09:00 Kaz Shinohara :
> Hi Ivan, Akihiro,
>
>
> Thanks for your kind arrangement.
> Looking forward to hearing your decision soon.
>
> Regards,
> Kaz
>
> 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
>> HI Team,
>>
>> From my perspective, I'm OK both with #2 and #3 options. I agree that #4
>> could be too complicated for us. Anyway, we've got this topic on the meeting
>> agenda [1] so we'll discuss it there too. I'll share our decision after the
>> meeting.
>>
>> [1] https://wiki.openstack.org/wiki/Meetings/Horizon
>>
>>
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki  wrote:
>>>
>>> Hi Kaz and Ivan,
>>>
>>> Yeah, it is worth discussed officially in the horizon team meeting or the
>>> mailing list thread to get a consensus.
>>> Hopefully you can add this topic to the horizon meeting agenda.
>>>
>>> After sending the previous mail, I noticed anther option. I see there are
>>> several options now.
>>> (1) Keep xstatic-core and horizon-core same.
>>> (2) Add specific members to xstatic-core
>>> (3) Add specific horizon-plugin core to xstatic-core
>>> (4) Split core membership into per-repo basis (perhaps too complicated!!)
>>>
>>> My current vote is (2) as xstatic-core needs to understand what is xstatic
>>> and how it is maintained.
>>>
>>> Thanks,
>>> Akihiro
>>>
>>>
>>> 2018-03-20 17:17 GMT+09:00 Kaz Shinohara :

 Hi Akihiro,


 Thanks for your comment.
 The background of my request to add us to xstatic-core comes from
 Ivan's comment in last PTG's etherpad for heat-dashboard discussion.

 https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussion
 Line135, "we can share ownership if needed - e0ne"

 Just in case, could you guys confirm unified opinion on this matter as
 Horizon team ?

 Frankly speaking I'm feeling the benefit to make us xstatic-core
 because it's easier & smoother to manage what we are taking for
 heat-dashboard.
 On the other hand, I can understand what Akihiro you are saying, the
 newly added repos belong to Horizon project & being managed by not
 Horizon core is not consistent.
 Also having exception might make unexpected confusion in near future.

 Eventually we will follow your opinion, let me hear Horizon team's
 conclusion.

 Regards,
 Kaz


 2018-03-20 12:58 GMT+09:00 Akihiro Motoki :
 > Hi Kaz,
 >
 > These repositories are under horizon project. It looks better to keep
 > the
 > current core team.
 > It potentially brings some confusion if we treat some horizon plugin
 > team
 > specially.
 > Reviewing xstatic repos would be a small burden, wo I think it would
 > work
 > without problem even if only horizon-core can approve xstatic reviews.
 >
 >
 > 2018-03-20 10:02 GMT+09:00 Kaz Shinohara :
 >>
 >> Hi Ivan, Horizon folks,
 >>
 >>
 >> Now totally 8 xstatic-** repos for heat-dashboard have been landed.
 >>
 >> In project-config for them, I've set same acl-config as the existing
 >> xstatic repos.
 >> It means only "xstatic-core" can manage the newly created repos on
 >> gerrit.
 >> Could you kindly add "heat-dashboard-core" into "xstatic-core" like as
 >> what horizon-core is doing ?
 >>
 >> xstatic-core
 >> https://review.openstack.org/#/admin/groups/385,members
 >>
 >> heat-dashboard-core
 >> https://review.openstack.org/#/admin/groups/1844,members
 >>
 >> Of course, we will surely touch only what we made, just would like to
 >> manage them smoothly by ourselves.
 >> In case we need to touch the other ones, will ask Horizon team for
 >> help.
 >>
 >> Thanks in advance.
 >>
 >> Regards,
 >> Kaz
 >>
 >>
 >> 2018-03-14 15:12 GMT+09:00 Xinni Ge :
 >> > Hi Horizon Team,
 >> >
 >> > I reported a bug about lack of ``ADD_XSTATIC_MODULES`` plugin
 >> > option,
 >> >  and submitted a patch for it.
 >> > Could you please help to review the patch.
 >> >
 >> > https://bugs.launchpad.net/horizon/+bug/1755339
 >> > https://review.openstack.org/#/c/552259/
 >> >
 >> > Thank you very much.
 >> >
 >> > Best Regards,
 >> > Xinni
 >> >
 >> > On Tue, Mar 13, 2018 at 6:41 PM, Ivan Kolodyazhny 
 >> > wrote:
 >> >>
 >> >> Hi Kaz,
 >> >>
 >> >> Thanks for cleaning this up. I put +1 on both of these patches
 >>

Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Boden Russell]

On 3/14/18 6:59 PM, Tony Breeds wrote:
> On Thu, Mar 15, 2018 at 07:16:11AM +0900, Akihiro Motoki wrote:
>> (1) it makes difficult to run tests in local environment
>> We have only released version of neutron/horizon on PyPI. It means
>> PyPI version (i.e. queens) is installed when we run tox in our local
>> development. Most neutron stadium projects and horizon plugins depends
>> on the latest master. Test run in local environment will be broken. We
>> need to install the latest neutron/horizon manually. This confuses
>> most developers. We need to ensure that tox can run successfully in a
>> same manner in our CI and local environments.
> 
> This is an issue I agree and one we need to think about but it will be
> somewhat mitigated for local development by pbr siblings[1]
> 
> In the short term, developers can do something like:
> 
> for env in pep8,py35,py27 ; do
>tox -e $env --notest
>.tox/$env/bin/pip install -e /path/to/{horizon,neutron}
>tox -e $env
> done
> 
> Which is far from ideal but gives as a little breathing room to decide
> if we need to revert and try again in a while or persist with the plan
> as it stands.
> 
> pbr siblings wont fix all the issues we have and still makes consumption of
> neutron and horizon (and plugins / stadium projects) difficult outside
> of test.

Unless I'm missing something, devstack is also impacted in these
scenarios and doesn't account for installing master branches of select
dependencies. As a result we are seeing failures in our external CI jobs
(that use devstack) due to invalid package versions.

Is the proper way to address this to specify the _REPO and _BRANCH in
our project's devstack lib sciprt(s) as needed so that devstack will
grab master for 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-dev] [horizon] Do we want new meeting time?

[Ivan Kolodyazhny]

Hi team,

As was discussed at PTG, usually we've got a very few participants on our
weekly meetings. I hope, mostly it's because of not comfort meeting time
for many of us.

Let's try to re-schedule Horizon weekly meetings and get more attendees
there. I've created a doodle for it [1]. Please, vote for the best time for
you.


[1] https://doodle.com/poll/ei5gstt73d8v3a35

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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

[Kaz Shinohara]

Hi Ivan, Akihiro,


Thanks for your kind arrangement.
Looking forward to hearing your decision soon.

Regards,
Kaz

2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny :
> HI Team,
>
> From my perspective, I'm OK both with #2 and #3 options. I agree that #4
> could be too complicated for us. Anyway, we've got this topic on the meeting
> agenda [1] so we'll discuss it there too. I'll share our decision after the
> meeting.
>
> [1] https://wiki.openstack.org/wiki/Meetings/Horizon
>
>
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki  wrote:
>>
>> Hi Kaz and Ivan,
>>
>> Yeah, it is worth discussed officially in the horizon team meeting or the
>> mailing list thread to get a consensus.
>> Hopefully you can add this topic to the horizon meeting agenda.
>>
>> After sending the previous mail, I noticed anther option. I see there are
>> several options now.
>> (1) Keep xstatic-core and horizon-core same.
>> (2) Add specific members to xstatic-core
>> (3) Add specific horizon-plugin core to xstatic-core
>> (4) Split core membership into per-repo basis (perhaps too complicated!!)
>>
>> My current vote is (2) as xstatic-core needs to understand what is xstatic
>> and how it is maintained.
>>
>> Thanks,
>> Akihiro
>>
>>
>> 2018-03-20 17:17 GMT+09:00 Kaz Shinohara :
>>>
>>> Hi Akihiro,
>>>
>>>
>>> Thanks for your comment.
>>> The background of my request to add us to xstatic-core comes from
>>> Ivan's comment in last PTG's etherpad for heat-dashboard discussion.
>>>
>>> https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussion
>>> Line135, "we can share ownership if needed - e0ne"
>>>
>>> Just in case, could you guys confirm unified opinion on this matter as
>>> Horizon team ?
>>>
>>> Frankly speaking I'm feeling the benefit to make us xstatic-core
>>> because it's easier & smoother to manage what we are taking for
>>> heat-dashboard.
>>> On the other hand, I can understand what Akihiro you are saying, the
>>> newly added repos belong to Horizon project & being managed by not
>>> Horizon core is not consistent.
>>> Also having exception might make unexpected confusion in near future.
>>>
>>> Eventually we will follow your opinion, let me hear Horizon team's
>>> conclusion.
>>>
>>> Regards,
>>> Kaz
>>>
>>>
>>> 2018-03-20 12:58 GMT+09:00 Akihiro Motoki :
>>> > Hi Kaz,
>>> >
>>> > These repositories are under horizon project. It looks better to keep
>>> > the
>>> > current core team.
>>> > It potentially brings some confusion if we treat some horizon plugin
>>> > team
>>> > specially.
>>> > Reviewing xstatic repos would be a small burden, wo I think it would
>>> > work
>>> > without problem even if only horizon-core can approve xstatic reviews.
>>> >
>>> >
>>> > 2018-03-20 10:02 GMT+09:00 Kaz Shinohara :
>>> >>
>>> >> Hi Ivan, Horizon folks,
>>> >>
>>> >>
>>> >> Now totally 8 xstatic-** repos for heat-dashboard have been landed.
>>> >>
>>> >> In project-config for them, I've set same acl-config as the existing
>>> >> xstatic repos.
>>> >> It means only "xstatic-core" can manage the newly created repos on
>>> >> gerrit.
>>> >> Could you kindly add "heat-dashboard-core" into "xstatic-core" like as
>>> >> what horizon-core is doing ?
>>> >>
>>> >> xstatic-core
>>> >> https://review.openstack.org/#/admin/groups/385,members
>>> >>
>>> >> heat-dashboard-core
>>> >> https://review.openstack.org/#/admin/groups/1844,members
>>> >>
>>> >> Of course, we will surely touch only what we made, just would like to
>>> >> manage them smoothly by ourselves.
>>> >> In case we need to touch the other ones, will ask Horizon team for
>>> >> help.
>>> >>
>>> >> Thanks in advance.
>>> >>
>>> >> Regards,
>>> >> Kaz
>>> >>
>>> >>
>>> >> 2018-03-14 15:12 GMT+09:00 Xinni Ge :
>>> >> > Hi Horizon Team,
>>> >> >
>>> >> > I reported a bug about lack of ``ADD_XSTATIC_MODULES`` plugin
>>> >> > option,
>>> >> >  and submitted a patch for it.
>>> >> > Could you please help to review the patch.
>>> >> >
>>> >> > https://bugs.launchpad.net/horizon/+bug/1755339
>>> >> > https://review.openstack.org/#/c/552259/
>>> >> >
>>> >> > Thank you very much.
>>> >> >
>>> >> > Best Regards,
>>> >> > Xinni
>>> >> >
>>> >> > On Tue, Mar 13, 2018 at 6:41 PM, Ivan Kolodyazhny 
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi Kaz,
>>> >> >>
>>> >> >> Thanks for cleaning this up. I put +1 on both of these patches
>>> >> >>
>>> >> >> Regards,
>>> >> >> Ivan Kolodyazhny,
>>> >> >> http://blog.e0ne.info/
>>> >> >>
>>> >> >> On Tue, Mar 13, 2018 at 4:48 AM, Kaz Shinohara
>>> >> >> 
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Hi Ivan & Horizon folks,
>>> >> >>>
>>> >> >>>
>>> >> >>> Now we are submitting a couple of patches to have the new xstatic
>>> >> >>> modules.
>>> >> >>> Let me request you to have review the following patches.
>>> >> >>> We need Horizon PTL's +1 to move these forward.
>>> >> >>>
>>> >> >>> project-config
>>> >> >>> https://review.openstack.org/#/c/551978/
>>> >> >>>
>>> >> >>> governance
>>> >> >>> https://rev

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

[Ivan Kolodyazhny]

HI Team,

>From my perspective, I'm OK both with #2 and #3 options. I agree that #4
could be too complicated for us. Anyway, we've got this topic on the
meeting agenda [1] so we'll discuss it there too. I'll share our decision
after the meeting.

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



Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki  wrote:

> Hi Kaz and Ivan,
>
> Yeah, it is worth discussed officially in the horizon team meeting or the
> mailing list thread to get a consensus.
> Hopefully you can add this topic to the horizon meeting agenda.
>
> After sending the previous mail, I noticed anther option. I see there are
> several options now.
> (1) Keep xstatic-core and horizon-core same.
> (2) Add specific members to xstatic-core
> (3) Add specific horizon-plugin core to xstatic-core
> (4) Split core membership into per-repo basis (perhaps too complicated!!)
>
> My current vote is (2) as xstatic-core needs to understand what is xstatic
> and how it is maintained.
>
> Thanks,
> Akihiro
>
>
> 2018-03-20 17:17 GMT+09:00 Kaz Shinohara :
>
>> Hi Akihiro,
>>
>>
>> Thanks for your comment.
>> The background of my request to add us to xstatic-core comes from
>> Ivan's comment in last PTG's etherpad for heat-dashboard discussion.
>>
>> https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussion
>> Line135
>> ,
>> "we can share ownership if needed - e0ne"
>>
>> Just in case, could you guys confirm unified opinion on this matter as
>> Horizon team ?
>>
>> Frankly speaking I'm feeling the benefit to make us xstatic-core
>> because it's easier & smoother to manage what we are taking for
>> heat-dashboard.
>> On the other hand, I can understand what Akihiro you are saying, the
>> newly added repos belong to Horizon project & being managed by not
>> Horizon core is not consistent.
>> Also having exception might make unexpected confusion in near future.
>>
>> Eventually we will follow your opinion, let me hear Horizon team's
>> conclusion.
>>
>> Regards,
>> Kaz
>>
>>
>> 2018-03-20 12:58 GMT+09:00 Akihiro Motoki :
>> > Hi Kaz,
>> >
>> > These repositories are under horizon project. It looks better to keep
>> the
>> > current core team.
>> > It potentially brings some confusion if we treat some horizon plugin
>> team
>> > specially.
>> > Reviewing xstatic repos would be a small burden, wo I think it would
>> work
>> > without problem even if only horizon-core can approve xstatic reviews.
>> >
>> >
>> > 2018-03-20 10:02 GMT+09:00 Kaz Shinohara :
>> >>
>> >> Hi Ivan, Horizon folks,
>> >>
>> >>
>> >> Now totally 8 xstatic-** repos for heat-dashboard have been landed.
>> >>
>> >> In project-config for them, I've set same acl-config as the existing
>> >> xstatic repos.
>> >> It means only "xstatic-core" can manage the newly created repos on
>> gerrit.
>> >> Could you kindly add "heat-dashboard-core" into "xstatic-core" like as
>> >> what horizon-core is doing ?
>> >>
>> >> xstatic-core
>> >> https://review.openstack.org/#/admin/groups/385,members
>> >>
>> >> heat-dashboard-core
>> >> https://review.openstack.org/#/admin/groups/1844,members
>> >>
>> >> Of course, we will surely touch only what we made, just would like to
>> >> manage them smoothly by ourselves.
>> >> In case we need to touch the other ones, will ask Horizon team for
>> help.
>> >>
>> >> Thanks in advance.
>> >>
>> >> Regards,
>> >> Kaz
>> >>
>> >>
>> >> 2018-03-14 15:12 GMT+09:00 Xinni Ge :
>> >> > Hi Horizon Team,
>> >> >
>> >> > I reported a bug about lack of ``ADD_XSTATIC_MODULES`` plugin option,
>> >> >  and submitted a patch for it.
>> >> > Could you please help to review the patch.
>> >> >
>> >> > https://bugs.launchpad.net/horizon/+bug/1755339
>> >> > https://review.openstack.org/#/c/552259/
>> >> >
>> >> > Thank you very much.
>> >> >
>> >> > Best Regards,
>> >> > Xinni
>> >> >
>> >> > On Tue, Mar 13, 2018 at 6:41 PM, Ivan Kolodyazhny 
>> >> > wrote:
>> >> >>
>> >> >> Hi Kaz,
>> >> >>
>> >> >> Thanks for cleaning this up. I put +1 on both of these patches
>> >> >>
>> >> >> Regards,
>> >> >> Ivan Kolodyazhny,
>> >> >> http://blog.e0ne.info/
>> >> >>
>> >> >> On Tue, Mar 13, 2018 at 4:48 AM, Kaz Shinohara <
>> ksnhr.t...@gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Ivan & Horizon folks,
>> >> >>>
>> >> >>>
>> >> >>> Now we are submitting a couple of patches to have the new xstatic
>> >> >>> modules.
>> >> >>> Let me request you to have review the following patches.
>> >> >>> We need Horizon PTL's +1 to move these forward.
>> >> >>>
>> >> >>> project-config
>> >> >>> https://review.openstack.org/#/c/551978/
>> >> >>>
>> >> >>> governance
>> >> >>> https://review.openstack.org/#/c/551980/
>> >> >>>
>> >> >>> Thanks in advance:)
>> >> >>>
>> >> >>> Regards,
>> >> >>> Kaz
>> >> >>>
>> >> >>>
>> >> >>> 2018-03-12 20:00 GMT+09:00 Radomir Dopieralski
>> >> >>> :
>> >> >>> > Yes, please do that. We can then d

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

[Akihiro Motoki]

Hi Kaz and Ivan,

Yeah, it is worth discussed officially in the horizon team meeting or the
mailing list thread to get a consensus.
Hopefully you can add this topic to the horizon meeting agenda.

After sending the previous mail, I noticed anther option. I see there are
several options now.
(1) Keep xstatic-core and horizon-core same.
(2) Add specific members to xstatic-core
(3) Add specific horizon-plugin core to xstatic-core
(4) Split core membership into per-repo basis (perhaps too complicated!!)

My current vote is (2) as xstatic-core needs to understand what is xstatic
and how it is maintained.

Thanks,
Akihiro


2018-03-20 17:17 GMT+09:00 Kaz Shinohara :

> Hi Akihiro,
>
>
> Thanks for your comment.
> The background of my request to add us to xstatic-core comes from
> Ivan's comment in last PTG's etherpad for heat-dashboard discussion.
>
> https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussion
> Line135, "we can share ownership if needed - e0ne"
>
> Just in case, could you guys confirm unified opinion on this matter as
> Horizon team ?
>
> Frankly speaking I'm feeling the benefit to make us xstatic-core
> because it's easier & smoother to manage what we are taking for
> heat-dashboard.
> On the other hand, I can understand what Akihiro you are saying, the
> newly added repos belong to Horizon project & being managed by not
> Horizon core is not consistent.
> Also having exception might make unexpected confusion in near future.
>
> Eventually we will follow your opinion, let me hear Horizon team's
> conclusion.
>
> Regards,
> Kaz
>
>
> 2018-03-20 12:58 GMT+09:00 Akihiro Motoki :
> > Hi Kaz,
> >
> > These repositories are under horizon project. It looks better to keep the
> > current core team.
> > It potentially brings some confusion if we treat some horizon plugin team
> > specially.
> > Reviewing xstatic repos would be a small burden, wo I think it would work
> > without problem even if only horizon-core can approve xstatic reviews.
> >
> >
> > 2018-03-20 10:02 GMT+09:00 Kaz Shinohara :
> >>
> >> Hi Ivan, Horizon folks,
> >>
> >>
> >> Now totally 8 xstatic-** repos for heat-dashboard have been landed.
> >>
> >> In project-config for them, I've set same acl-config as the existing
> >> xstatic repos.
> >> It means only "xstatic-core" can manage the newly created repos on
> gerrit.
> >> Could you kindly add "heat-dashboard-core" into "xstatic-core" like as
> >> what horizon-core is doing ?
> >>
> >> xstatic-core
> >> https://review.openstack.org/#/admin/groups/385,members
> >>
> >> heat-dashboard-core
> >> https://review.openstack.org/#/admin/groups/1844,members
> >>
> >> Of course, we will surely touch only what we made, just would like to
> >> manage them smoothly by ourselves.
> >> In case we need to touch the other ones, will ask Horizon team for help.
> >>
> >> Thanks in advance.
> >>
> >> Regards,
> >> Kaz
> >>
> >>
> >> 2018-03-14 15:12 GMT+09:00 Xinni Ge :
> >> > Hi Horizon Team,
> >> >
> >> > I reported a bug about lack of ``ADD_XSTATIC_MODULES`` plugin option,
> >> >  and submitted a patch for it.
> >> > Could you please help to review the patch.
> >> >
> >> > https://bugs.launchpad.net/horizon/+bug/1755339
> >> > https://review.openstack.org/#/c/552259/
> >> >
> >> > Thank you very much.
> >> >
> >> > Best Regards,
> >> > Xinni
> >> >
> >> > On Tue, Mar 13, 2018 at 6:41 PM, Ivan Kolodyazhny 
> >> > wrote:
> >> >>
> >> >> Hi Kaz,
> >> >>
> >> >> Thanks for cleaning this up. I put +1 on both of these patches
> >> >>
> >> >> Regards,
> >> >> Ivan Kolodyazhny,
> >> >> http://blog.e0ne.info/
> >> >>
> >> >> On Tue, Mar 13, 2018 at 4:48 AM, Kaz Shinohara  >
> >> >> wrote:
> >> >>>
> >> >>> Hi Ivan & Horizon folks,
> >> >>>
> >> >>>
> >> >>> Now we are submitting a couple of patches to have the new xstatic
> >> >>> modules.
> >> >>> Let me request you to have review the following patches.
> >> >>> We need Horizon PTL's +1 to move these forward.
> >> >>>
> >> >>> project-config
> >> >>> https://review.openstack.org/#/c/551978/
> >> >>>
> >> >>> governance
> >> >>> https://review.openstack.org/#/c/551980/
> >> >>>
> >> >>> Thanks in advance:)
> >> >>>
> >> >>> Regards,
> >> >>> Kaz
> >> >>>
> >> >>>
> >> >>> 2018-03-12 20:00 GMT+09:00 Radomir Dopieralski
> >> >>> :
> >> >>> > Yes, please do that. We can then discuss in the review about
> >> >>> > technical
> >> >>> > details.
> >> >>> >
> >> >>> > On Mon, Mar 12, 2018 at 2:54 AM, Xinni Ge  >
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> 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
> >>

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

[Kaz Shinohara]

Hi Akihiro,


Thanks for your comment.
The background of my request to add us to xstatic-core comes from
Ivan's comment in last PTG's etherpad for heat-dashboard discussion.

https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussion
Line135, "we can share ownership if needed - e0ne"

Just in case, could you guys confirm unified opinion on this matter as
Horizon team ?

Frankly speaking I'm feeling the benefit to make us xstatic-core
because it's easier & smoother to manage what we are taking for
heat-dashboard.
On the other hand, I can understand what Akihiro you are saying, the
newly added repos belong to Horizon project & being managed by not
Horizon core is not consistent.
Also having exception might make unexpected confusion in near future.

Eventually we will follow your opinion, let me hear Horizon team's conclusion.

Regards,
Kaz


2018-03-20 12:58 GMT+09:00 Akihiro Motoki :
> Hi Kaz,
>
> These repositories are under horizon project. It looks better to keep the
> current core team.
> It potentially brings some confusion if we treat some horizon plugin team
> specially.
> Reviewing xstatic repos would be a small burden, wo I think it would work
> without problem even if only horizon-core can approve xstatic reviews.
>
>
> 2018-03-20 10:02 GMT+09:00 Kaz Shinohara :
>>
>> Hi Ivan, Horizon folks,
>>
>>
>> Now totally 8 xstatic-** repos for heat-dashboard have been landed.
>>
>> In project-config for them, I've set same acl-config as the existing
>> xstatic repos.
>> It means only "xstatic-core" can manage the newly created repos on gerrit.
>> Could you kindly add "heat-dashboard-core" into "xstatic-core" like as
>> what horizon-core is doing ?
>>
>> xstatic-core
>> https://review.openstack.org/#/admin/groups/385,members
>>
>> heat-dashboard-core
>> https://review.openstack.org/#/admin/groups/1844,members
>>
>> Of course, we will surely touch only what we made, just would like to
>> manage them smoothly by ourselves.
>> In case we need to touch the other ones, will ask Horizon team for help.
>>
>> Thanks in advance.
>>
>> Regards,
>> Kaz
>>
>>
>> 2018-03-14 15:12 GMT+09:00 Xinni Ge :
>> > Hi Horizon Team,
>> >
>> > I reported a bug about lack of ``ADD_XSTATIC_MODULES`` plugin option,
>> >  and submitted a patch for it.
>> > Could you please help to review the patch.
>> >
>> > https://bugs.launchpad.net/horizon/+bug/1755339
>> > https://review.openstack.org/#/c/552259/
>> >
>> > Thank you very much.
>> >
>> > Best Regards,
>> > Xinni
>> >
>> > On Tue, Mar 13, 2018 at 6:41 PM, Ivan Kolodyazhny 
>> > wrote:
>> >>
>> >> Hi Kaz,
>> >>
>> >> Thanks for cleaning this up. I put +1 on both of these patches
>> >>
>> >> Regards,
>> >> Ivan Kolodyazhny,
>> >> http://blog.e0ne.info/
>> >>
>> >> On Tue, Mar 13, 2018 at 4:48 AM, Kaz Shinohara 
>> >> wrote:
>> >>>
>> >>> Hi Ivan & Horizon folks,
>> >>>
>> >>>
>> >>> Now we are submitting a couple of patches to have the new xstatic
>> >>> modules.
>> >>> Let me request you to have review the following patches.
>> >>> We need Horizon PTL's +1 to move these forward.
>> >>>
>> >>> project-config
>> >>> https://review.openstack.org/#/c/551978/
>> >>>
>> >>> governance
>> >>> https://review.openstack.org/#/c/551980/
>> >>>
>> >>> Thanks in advance:)
>> >>>
>> >>> Regards,
>> >>> Kaz
>> >>>
>> >>>
>> >>> 2018-03-12 20:00 GMT+09:00 Radomir Dopieralski
>> >>> :
>> >>> > Yes, please do that. We can then discuss in the review about
>> >>> > technical
>> >>> > details.
>> >>> >
>> >>> > On Mon, Mar 12, 2018 at 2:54 AM, Xinni Ge 
>> >>> > wrote:
>> >>> >>
>> >>> >> 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
>> >>> >>> > rep

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

[Akihiro Motoki]

Hi Kaz,

These repositories are under horizon project. It looks better to keep the
current core team.
It potentially brings some confusion if we treat some horizon plugin team
specially.
Reviewing xstatic repos would be a small burden, wo I think it would work
without problem even if only horizon-core can approve xstatic reviews.


2018-03-20 10:02 GMT+09:00 Kaz Shinohara :

> Hi Ivan, Horizon folks,
>
>
> Now totally 8 xstatic-** repos for heat-dashboard have been landed.
>
> In project-config for them, I've set same acl-config as the existing
> xstatic repos.
> It means only "xstatic-core" can manage the newly created repos on gerrit.
> Could you kindly add "heat-dashboard-core" into "xstatic-core" like as
> what horizon-core is doing ?
>
> xstatic-core
> https://review.openstack.org/#/admin/groups/385,members
>
> heat-dashboard-core
> https://review.openstack.org/#/admin/groups/1844,members
>
> Of course, we will surely touch only what we made, just would like to
> manage them smoothly by ourselves.
> In case we need to touch the other ones, will ask Horizon team for help.
>
> Thanks in advance.
>
> Regards,
> Kaz
>
>
> 2018-03-14 15:12 GMT+09:00 Xinni Ge :
> > Hi Horizon Team,
> >
> > I reported a bug about lack of ``ADD_XSTATIC_MODULES`` plugin option,
> >  and submitted a patch for it.
> > Could you please help to review the patch.
> >
> > https://bugs.launchpad.net/horizon/+bug/1755339
> > https://review.openstack.org/#/c/552259/
> >
> > Thank you very much.
> >
> > Best Regards,
> > Xinni
> >
> > On Tue, Mar 13, 2018 at 6:41 PM, Ivan Kolodyazhny 
> wrote:
> >>
> >> Hi Kaz,
> >>
> >> Thanks for cleaning this up. I put +1 on both of these patches
> >>
> >> Regards,
> >> Ivan Kolodyazhny,
> >> http://blog.e0ne.info/
> >>
> >> On Tue, Mar 13, 2018 at 4:48 AM, Kaz Shinohara 
> >> wrote:
> >>>
> >>> Hi Ivan & Horizon folks,
> >>>
> >>>
> >>> Now we are submitting a couple of patches to have the new xstatic
> >>> modules.
> >>> Let me request you to have review the following patches.
> >>> We need Horizon PTL's +1 to move these forward.
> >>>
> >>> project-config
> >>> https://review.openstack.org/#/c/551978/
> >>>
> >>> governance
> >>> https://review.openstack.org/#/c/551980/
> >>>
> >>> Thanks in advance:)
> >>>
> >>> Regards,
> >>> Kaz
> >>>
> >>>
> >>> 2018-03-12 20:00 GMT+09:00 Radomir Dopieralski  >:
> >>> > Yes, please do that. We can then discuss in the review about
> technical
> >>> > details.
> >>> >
> >>> > On Mon, Mar 12, 2018 at 2:54 AM, Xinni Ge 
> >>> > wrote:
> >>> >>
> >>> >> 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 an

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

[Kaz Shinohara]

Hi Ivan, Horizon folks,


Now totally 8 xstatic-** repos for heat-dashboard have been landed.

In project-config for them, I've set same acl-config as the existing
xstatic repos.
It means only "xstatic-core" can manage the newly created repos on gerrit.
Could you kindly add "heat-dashboard-core" into "xstatic-core" like as
what horizon-core is doing ?

xstatic-core
https://review.openstack.org/#/admin/groups/385,members

heat-dashboard-core
https://review.openstack.org/#/admin/groups/1844,members

Of course, we will surely touch only what we made, just would like to
manage them smoothly by ourselves.
In case we need to touch the other ones, will ask Horizon team for help.

Thanks in advance.

Regards,
Kaz


2018-03-14 15:12 GMT+09:00 Xinni Ge :
> Hi Horizon Team,
>
> I reported a bug about lack of ``ADD_XSTATIC_MODULES`` plugin option,
>  and submitted a patch for it.
> Could you please help to review the patch.
>
> https://bugs.launchpad.net/horizon/+bug/1755339
> https://review.openstack.org/#/c/552259/
>
> Thank you very much.
>
> Best Regards,
> Xinni
>
> On Tue, Mar 13, 2018 at 6:41 PM, Ivan Kolodyazhny  wrote:
>>
>> Hi Kaz,
>>
>> Thanks for cleaning this up. I put +1 on both of these patches
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>> On Tue, Mar 13, 2018 at 4:48 AM, Kaz Shinohara 
>> wrote:
>>>
>>> Hi Ivan & Horizon folks,
>>>
>>>
>>> Now we are submitting a couple of patches to have the new xstatic
>>> modules.
>>> Let me request you to have review the following patches.
>>> We need Horizon PTL's +1 to move these forward.
>>>
>>> project-config
>>> https://review.openstack.org/#/c/551978/
>>>
>>> governance
>>> https://review.openstack.org/#/c/551980/
>>>
>>> Thanks in advance:)
>>>
>>> Regards,
>>> Kaz
>>>
>>>
>>> 2018-03-12 20:00 GMT+09:00 Radomir Dopieralski :
>>> > Yes, please do that. We can then discuss in the review about technical
>>> > details.
>>> >
>>> > On Mon, Mar 12, 2018 at 2:54 AM, Xinni Ge 
>>> > wrote:
>>> >>
>>> >> 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] [horizon][plugins] mox -> mock migration

[Akihiro Motoki]

Hi horizon plugin developers,

As you know, mox-removal is one of the community goal in Rocky and
horizon team is working on removing usage of mox [1].

This mail announces the plan of dropping mox dependencies in horizon
test helpers (horizon.test.helpers.TestCase and/or
openstack_dashboard.test.helpers.TestCase).

1) The first step is to introduce "use_mox" flag in
horizon.test.helpers.TestCase. The flag is available now.
If you set the flag to False, you can run your plugin test without mox.
The default value of use_mox is False for
horizon.test.helpers.TestCase [2] and True for
openstack_dashboard.test.helpers.TestCase [3].

2) After Rocky-1, use_mox of openstack_dashboard.test.helpers.TestCase
will be changed from True to False.
 This means your plugin needs to set use_mox to True explicitly if
your unit tests still depends on mox.
 Our suggestion is to set use_mox=True until Rocky-1 milestone if
your tests depends on mox not to break your gate.

3) After Rocky RC1 is released, "use_mox" flag in the horizon repo
will be dropped.
This means use_mox flag will no longer be in effect.
If your plugin tests still depends on mox at this stage, your
plugin test needs to set up mox explicitly.

Thanks,
Akihiro Motoki (amotoki)

[1] https://blueprints.launchpad.net/horizon/+spec/mock-framework-in-unit-tests
[2] 
https://github.com/openstack/horizon/blob/6e29fdde1edc67a6797eba2c3f9c557f840d4ea7/horizon/test/helpers.py#L138
[3] 
https://github.com/openstack/horizon/blob/6e29fdde1edc67a6797eba2c3f9c557f840d4ea7/openstack_dashboard/test/helpers.py#L257

__
OpenStack Development Mailing 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][neutron][kolla] tools/tox_install changes - breakage with constraints

[Jeffrey Zhang]

kolla install openstack packages through master tarball file on kolla
master branch[0]. like

  pip install -c upper-constraints.txt neutron-master.tar.gz

On stable branch, kolla install through neutron tag tarball. so it should
work.
But i think there will be also some issue here. How about i want to install
neutron-12.0.1.tar.gz, whereas neutron===12.0.0 exist in the
upper-constraints.txt file?

[0] http://tarballs.openstack.org/neutron/neutron-master.tar.gz


On Fri, Mar 16, 2018 at 6:57 PM, Andreas Jaeger  wrote:

> On 2018-03-16 11:49, Jeffrey Zhang wrote:
> > Now it breaks the kolla's master branch jobs. And have to remove the
> > "horizon"
> > and "neutron" in the upper-constraints.txt file. check[1][2].
> >
> > i wanna know what's the correct way to install horizon develop
> > branch with upper-constraints.txt file?
> >
> >
> > [1] https://review.openstack.org/#/c/549456/4/docker/
> neutron/neutron-base/Dockerfile.j2
> >  neutron-base/Dockerfile.j2>
> > [2] https://review.openstack.org/#/c/549456/4/docker/
> horizon/Dockerfile.j2
> > 
>
> Sorry, that is too much magic for me to be able to help you.
>
> What are those doing? How do you install today? Please give me some
> instructions
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: 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
>
>


-- 
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][neutron][kolla] tools/tox_install changes - breakage with constraints

[Andreas Jaeger]

On 2018-03-16 11:49, Jeffrey Zhang wrote:
> Now it breaks the kolla's master branch jobs. And have to remove the
> "horizon"
> and "neutron" in the upper-constraints.txt file. check[1][2]. 
> 
> i wanna know what's the correct way to install horizon develop
> branch with upper-constraints.txt file?
> 
> 
> [1] 
> https://review.openstack.org/#/c/549456/4/docker/neutron/neutron-base/Dockerfile.j2
> 
> [2] https://review.openstack.org/#/c/549456/4/docker/horizon/Dockerfile.j2
> 

Sorry, that is too much magic for me to be able to help you.

What are those doing? How do you install today? Please give me some
instructions

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: 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] [horizon][neutron][kolla] tools/tox_install changes - breakage with constraints

[Jeffrey Zhang]

Now it breaks the kolla's master branch jobs. And have to remove the
"horizon"
and "neutron" in the upper-constraints.txt file. check[1][2].

i wanna know what's the correct way to install horizon develop
branch with upper-constraints.txt file?


[1] https://review.openstack.org/#/c/549456/4/docker/neutron/neutron-base/
Dockerfile.j2
[2] https://review.openstack.org/#/c/549456/4/docker/horizon/Dockerfile.j2



On Thu, Mar 15, 2018 at 9:28 PM, Doug Hellmann 
wrote:

> Excerpts from Thomas Morin's message of 2018-03-15 10:15:38 +0100:
> > Hi Doug,
> >
> > Doug Hellmann, 2018-03-14 23:42:
> > > We keep doing lots of infra-related work to make it "easy" to do
> > >  when it comes to
> > > managing dependencies.  There are three ways to address the issue
> > > with horizon and neutron, and none of them involve adding features
> > > to pbr.
> > >
> > > 1. Things that are being used like libraries need to release like
> > >libraries. Real releases. With appropriate version numbers. So
> > >that other things that depend on them can express valid
> > > dependencies.
> > >
> > > 2. Extract the relevant code into libraries and release *those*.
> > >
> > > 3. Things that are not stable enough to be treated as a library
> > >shouldn't be used that way. Move the things that use the
> > > application
> > >code as library code back into the repo with the thing that they
> > >are tied to but that we don't want to (or can't) treat like a
> > >library.
> >
> > What about the case where there is co-development of features across
> > repos ? One specific case I have in mind is the Neutron stadium where
>
> We do that all the time with the Oslo libraries. It's not as easy as
> having everything in one repo, but we manage.
>
> > we sometimes have features in neutron repo that are worked on as a pre-
> > requisite for things that will be done in a neutron-* or networking-*
> > project. Another is a case for instance where we need to add in project
> > X a tempest test to validate the resolution of a bug for which the fix
> > actually happened in project B (and where B is not a library).
>
> If the tempest test can't live in B because it uses part of X, then I
> think X and B are really one thing and you're doing more work than you
> need to be doing to keep them in separate libraries.
>
> > My intuition is that it is not illegitimate to expect this kind of
> > development workflow to be feasible; but at the same time I read your
> > suggestion above as meaning that it belongs to the real of "things we
> > shouldn't be doing in the first place".  The only way I can reconcile
>
> You read me correctly.
>
> We install a bunch of components from source for integration tests
> in devstack-gate because we want the final releases to work together.
> But those things only interact via REST APIs, and don't import each
> other.  The cases with neutron and horizon are different. Even the
> *unit* tests of the add-ons require code from the "parent" app. That
> indicates a level of coupling that is not being properly addressed by
> the release model and code management practices for the parent apps.
>
> > the two would be to conclude we should collapse all the module in
> > neutron-*/networking-* into neutron, but doing that would have quite a
> > lot of side effects (yes, this is an understatement).
>
> That's not the only way to do it. The other way would be to properly
> decompose the shared code into a library and then provide *stable
> APIs* so code can be consumed by the add-on modules. That will make
> evolving things a little more difficult because of the stability
> requirement. So it's a trade off. I think the teams involved should
> make that trade off (in one direction or another), instead of
> building tools to continue to avoid dealing with it.
>
> So let's start by examining the root of the problem: Why are the things
> that need to import neutron/horizon not part of the neutron/horizon
> repositories in the first place?
>
> 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
>



-- 
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][neutron] tools/tox_install changes - breakage with constraints

[Doug Hellmann]

Excerpts from Thomas Morin's message of 2018-03-15 10:15:38 +0100:
> Hi Doug,
> 
> Doug Hellmann, 2018-03-14 23:42:
> > We keep doing lots of infra-related work to make it "easy" to do
> >  when it comes to
> > managing dependencies.  There are three ways to address the issue
> > with horizon and neutron, and none of them involve adding features
> > to pbr.
> > 
> > 1. Things that are being used like libraries need to release like
> >libraries. Real releases. With appropriate version numbers. So
> >that other things that depend on them can express valid
> > dependencies.
> > 
> > 2. Extract the relevant code into libraries and release *those*.
> > 
> > 3. Things that are not stable enough to be treated as a library
> >shouldn't be used that way. Move the things that use the
> > application
> >code as library code back into the repo with the thing that they
> >are tied to but that we don't want to (or can't) treat like a
> >library.
> 
> What about the case where there is co-development of features across
> repos ? One specific case I have in mind is the Neutron stadium where

We do that all the time with the Oslo libraries. It's not as easy as
having everything in one repo, but we manage.

> we sometimes have features in neutron repo that are worked on as a pre-
> requisite for things that will be done in a neutron-* or networking-*
> project. Another is a case for instance where we need to add in project
> X a tempest test to validate the resolution of a bug for which the fix
> actually happened in project B (and where B is not a library).

If the tempest test can't live in B because it uses part of X, then I
think X and B are really one thing and you're doing more work than you
need to be doing to keep them in separate libraries.

> My intuition is that it is not illegitimate to expect this kind of
> development workflow to be feasible; but at the same time I read your
> suggestion above as meaning that it belongs to the real of "things we
> shouldn't be doing in the first place".  The only way I can reconcile

You read me correctly.

We install a bunch of components from source for integration tests
in devstack-gate because we want the final releases to work together.
But those things only interact via REST APIs, and don't import each
other.  The cases with neutron and horizon are different. Even the
*unit* tests of the add-ons require code from the "parent" app. That
indicates a level of coupling that is not being properly addressed by
the release model and code management practices for the parent apps.

> the two would be to conclude we should collapse all the module in
> neutron-*/networking-* into neutron, but doing that would have quite a
> lot of side effects (yes, this is an understatement).

That's not the only way to do it. The other way would be to properly
decompose the shared code into a library and then provide *stable
APIs* so code can be consumed by the add-on modules. That will make
evolving things a little more difficult because of the stability
requirement. So it's a trade off. I think the teams involved should
make that trade off (in one direction or another), instead of
building tools to continue to avoid dealing with it.

So let's start by examining the root of the problem: Why are the things
that need to import neutron/horizon not part of the neutron/horizon
repositories in the first place?

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] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Andreas Jaeger]

On 2018-03-15 10:05, Thomas Morin wrote:
> Hi Andreas, all,
> 
> Andreas Jaeger, 2018-03-14 20:46:
>> Note that thanks to the tox-siblings feature, we really continue to
>> install neutron and horizon from git - and not use the versions in the
>> global-requirements constraints file.
> 
> This addresses my main concern, which was that by removing
> tools/tox_install.sh we would end up not pulling master from git.
> 
> The fact that we do keep pulling from git wasn't explicit AFAIK in any
> of the commit messages of the changes I had to look at to understand
> what was being modified.

Sorry for not mentioning that.

> I concur with Akihiro's comment, and would go slightly beyond that:
> ideally the solution chosen would not only technical work, but would
> reduce the ahah-there-is-magic-behind-the-scene effect, which is a pain
> I believe for many: people new to the community face a steeper learning
> curve, people inside the community need to spend time adjust, and infra
> folks end up having to document or explain more. In this precise case,
> the magic behind the scene (ie. the tox-siblings role) may lead to
> confusion for packagers (why our CI tests as valid is not what appears
> in requirements.txt) and perhaps people working in external communities
> (e.g. [1]).

The old way - included some magic as well ;(

I agree with Doug - we need to architect our dependencies better to
avoid these problems and hacks,

Andreas

> Best,
> 
> -Thomas
> 
> [1]
> http://docs.opnfv.org/en/latest/submodules/releng-xci/docs/xci-overview.html#xci-overview


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: 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] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Thomas Morin]

Hi Doug,

Doug Hellmann, 2018-03-14 23:42:
> We keep doing lots of infra-related work to make it "easy" to do
>  when it comes to
> managing dependencies.  There are three ways to address the issue
> with horizon and neutron, and none of them involve adding features
> to pbr.
> 
> 1. Things that are being used like libraries need to release like
>libraries. Real releases. With appropriate version numbers. So
>that other things that depend on them can express valid
> dependencies.
> 
> 2. Extract the relevant code into libraries and release *those*.
> 
> 3. Things that are not stable enough to be treated as a library
>shouldn't be used that way. Move the things that use the
> application
>code as library code back into the repo with the thing that they
>are tied to but that we don't want to (or can't) treat like a
>library.

What about the case where there is co-development of features across
repos ? One specific case I have in mind is the Neutron stadium where
we sometimes have features in neutron repo that are worked on as a pre-
requisite for things that will be done in a neutron-* or networking-*
project. Another is a case for instance where we need to add in project
X a tempest test to validate the resolution of a bug for which the fix
actually happened in project B (and where B is not a library).

My intuition is that it is not illegitimate to expect this kind of
development workflow to be feasible; but at the same time I read your
suggestion above as meaning that it belongs to the real of "things we
shouldn't be doing in the first place".  The only way I can reconcile
the two would be to conclude we should collapse all the module in
neutron-*/networking-* into neutron, but doing that would have quite a
lot of side effects (yes, this is an understatement).

-Thomas


__
OpenStack Development Mailing 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][neutron] tools/tox_install changes - breakage with constraints

[Thomas Morin]

Hi Andreas, all,
> Note that thanks to the tox-siblings feature, we really continue to
> install neutron and horizon from git - and not use the versions in
> the global-requirements constraints file.

This addresses my main concern, which was that by removing
tools/tox_install.sh we would end up not pulling master from git.

The fact that we do keep pulling from git wasn't explicit AFAIK in any
of the commit messages of the changes I had to look at to understand
what was being modified.

I concur with Akihiro's comment, and would go slightly beyond that:
ideally the solution chosen would not only technical work, but would
reduce the ahah-there-is-magic-behind-the-scene effect, which is a pain
I believe for many: people new to the community face a steeper learning
curve, people inside the community need to spend time adjust, and infra
folks end up having to document or explain more.  In this precise
case,  the magic behind the scene (ie. the tox-siblings role) may lead
to confusion for packagers (why our CI tests as valid is not what
appears
in requirements.txt) and perhaps people working in external communities
(e.g. [1]).
Best,

-Thomas

[1] http://docs.opnfv.org/en/latest/submodules/releng-xci/docs/xci-over
view.html#xci-overview

Andreas Jaeger, 2018-03-14 20: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] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-03-15 11:59:00 +1100:
> On Thu, Mar 15, 2018 at 07:16:11AM +0900, Akihiro Motoki wrote:
> > The current version of proposed patches which drops tox_install.sh
> > works in our CI. Even if we have neutron>=12.0.0 (queens) or
> > horizon>=13.0.0 (queens), if we have "required-projects" in zuul v3
> > config, tox-sibling role ensures to install the latest master of
> > neutron/horizon. It is okay in our CI.
> > 
> > On the other hand, this change brings a couple of problems. I think it
> > is worth discussed broadly here.
> > 
> > (1) it makes difficult to run tests in local environment
> > We have only released version of neutron/horizon on PyPI. It means
> > PyPI version (i.e. queens) is installed when we run tox in our local
> > development. Most neutron stadium projects and horizon plugins depends
> > on the latest master. Test run in local environment will be broken. We
> > need to install the latest neutron/horizon manually. This confuses
> > most developers. We need to ensure that tox can run successfully in a
> > same manner in our CI and local environments.
> 
> This is an issue I agree and one we need to think about but it will be
> somewhat mitigated for local development by pbr siblings[1]
> 
> In the short term, developers can do something like:
> 
> for env in pep8,py35,py27 ; do
>tox -e $env --notest
>.tox/$env/bin/pip install -e /path/to/{horizon,neutron}
>tox -e $env
> done
> 
> Which is far from ideal but gives as a little breathing room to decide
> if we need to revert and try again in a while or persist with the plan
> as it stands.
> 
> pbr siblings wont fix all the issues we have and still makes consumption of
> neutron and horizon (and plugins / stadium projects) difficult outside
> of test.
>  
> > (2) neutron/horizon version in requirements.txt is confusing
> > In the cycle-with-milestone model, a new version of neutron/horizon
> > will be released only when a release is shipped.
> > The code depends on the latest master, but requirements.txt says it
> > depends on queens or later. It sounds confusing.
> 
> Yes we either need to create a new release-model or switch
> neutron/horizon to the cycle-with-intermediary model and encourage
> appropriate releases.  I'd really like to avoid publishing daily to pypi.

We keep doing lots of infra-related work to make it "easy" to do
things we shouldn't be doing in the first place when it comes to
managing dependencies.  There are three ways to address the issue
with horizon and neutron, and none of them involve adding features
to pbr.

1. Things that are being used like libraries need to release like
   libraries. Real releases. With appropriate version numbers. So
   that other things that depend on them can express valid dependencies.

2. Extract the relevant code into libraries and release *those*.

3. Things that are not stable enough to be treated as a library
   shouldn't be used that way. Move the things that use the application
   code as library code back into the repo with the thing that they
   are tied to but that we don't want to (or can't) treat like a
   library.

Let's stop making things hard on ourselves and start managing this
code properly.

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] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Tony Breeds]

On Thu, Mar 15, 2018 at 07:16:11AM +0900, Akihiro Motoki wrote:
> The current version of proposed patches which drops tox_install.sh
> works in our CI. Even if we have neutron>=12.0.0 (queens) or
> horizon>=13.0.0 (queens), if we have "required-projects" in zuul v3
> config, tox-sibling role ensures to install the latest master of
> neutron/horizon. It is okay in our CI.
> 
> On the other hand, this change brings a couple of problems. I think it
> is worth discussed broadly here.
> 
> (1) it makes difficult to run tests in local environment
> We have only released version of neutron/horizon on PyPI. It means
> PyPI version (i.e. queens) is installed when we run tox in our local
> development. Most neutron stadium projects and horizon plugins depends
> on the latest master. Test run in local environment will be broken. We
> need to install the latest neutron/horizon manually. This confuses
> most developers. We need to ensure that tox can run successfully in a
> same manner in our CI and local environments.

This is an issue I agree and one we need to think about but it will be
somewhat mitigated for local development by pbr siblings[1]

In the short term, developers can do something like:

for env in pep8,py35,py27 ; do
   tox -e $env --notest
   .tox/$env/bin/pip install -e /path/to/{horizon,neutron}
   tox -e $env
done

Which is far from ideal but gives as a little breathing room to decide
if we need to revert and try again in a while or persist with the plan
as it stands.

pbr siblings wont fix all the issues we have and still makes consumption of
neutron and horizon (and plugins / stadium projects) difficult outside
of test.
 
> (2) neutron/horizon version in requirements.txt is confusing
> In the cycle-with-milestone model, a new version of neutron/horizon
> will be released only when a release is shipped.
> The code depends on the latest master, but requirements.txt says it
> depends on queens or later. It sounds confusing.

Yes we either need to create a new release-model or switch
neutron/horizon to the cycle-with-intermediary model and encourage
appropriate releases.  I'd really like to avoid publishing daily to pypi.

Yours Tony.

[1]
https://review.openstack.org/#/q/status:open+project:openstack-dev/pbr+branch:master+topic:fix-siblings-entrypoints


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] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Paul Belanger]

On Wed, Mar 14, 2018 at 10:25:49PM +, Chris Dent wrote:
> On Thu, 15 Mar 2018, Akihiro Motoki wrote:
> 
> > (1) it makes difficult to run tests in local environment
> > We have only released version of neutron/horizon on PyPI. It means
> > PyPI version (i.e. queens) is installed when we run tox in our local
> > development. Most neutron stadium projects and horizon plugins depends
> > on the latest master. Test run in local environment will be broken. We
> > need to install the latest neutron/horizon manually. This confuses
> > most developers. We need to ensure that tox can run successfully in a
> > same manner in our CI and local environments.
> 
> Assuming that ^ is actually the case then:
> 
> This sounds like a really critical issue. We need to be really
> careful about automating the human out of the equation to the point
> where people are submitting broken code just so they can get a good
> test run. That's not great if we'd like to encourage various forms
> of TDD and the like and we also happen to have a limited supply of
> CI resources.
> 
> (Which is not to say that tox-siblings isn't an awesome feature. I
> hadn't really known about it until today and it's a great thing.)
> 
If ansible is our interface for developers to use, it shouldn't be difficult to
reproduce the environments locally to get master. This does mean changing the
developer workflow to use ansible, which I can understand might not be what
people want to do.

The main reason for removing install_tox.sh, is to remove zuul-cloner from our
DIB images, as zuulv3 no longer includes this command. Even running that
locally, would no longer work against git.o.o.

I agree, we should see how to make the migration for local developer
environments better.

Paul

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