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] [Heat] : Query regarding bug 1769089

[Kaz Shinohara]

Hi,


First off, sorry for being late to response.

Looking at your comment,
your environment is Newton & AFAIK Newton is EOL, even if you will wait for
the fix, it will not be delivered to Newton.
https://releases.openstack.org/

Current my concern is that your raised issue may happen in Queens code too
(latest maintained)
Note: dashboard for heat is split out from Horizon since Queens.

Let me check if I could reproduce your issue at my environment(Queens)
first.
I will update my result at https://storyboard.openstack.org/#!/story/1769089

Cheers,
Kaz



2018-05-30 21:56 GMT+09:00 Ashika Meher Majety :

> Hello,
>
> We have raised a bug in launchpad and the bug link is as follows:
> https://bugs.launchpad.net/heat-dashboard/+bug/1769089 .
> Can anyone please provide a solution or fix for this issue since it's been
> 20 days since we have created this bug.
>
> Thanks,
> Ashika Meher
>
> __
> OpenStack Development Mailing 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] [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 <e...@e0ne.info>:
> 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 <ksnhr.t...@gmail.com> 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 <ksnhr.t...@gmail.com>:
>> > 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 <e...@e0ne.info>:
>> >> 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 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 <ksnhr.t...@gmail.com>:
>> >>>>
>> >>>> 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 proj

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 <ksnhr.t...@gmail.com>:
> 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 <e...@e0ne.info>:
>> 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 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 <ksnhr.t...@gmail.com>:
>>>>
>>>> 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 <amot...@gmail.com>:
>>>> > 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 <ksnhr.t...@gmail.com>:
>>>> >>
>>>> >> 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 

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 <e...@e0ne.info>:
> 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 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 <ksnhr.t...@gmail.com>:
>>>
>>> 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 <amot...@gmail.com>:
>>> > 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 <ksnhr.t...@gmail.com>:
>>> >>
>>> >> 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-0

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 <amot...@gmail.com>:
> 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 <ksnhr.t...@gmail.com>:
>>
>> 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 <xinni.ge1...@gmail.com>:
>> > 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 <e...@e0ne.info>
>> > 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
>> >>> <openst...@sheep.art.pl>:
>> >>> > 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 <xinni.ge1...@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> Hi, Akihiro
>> >>> >>
>> >>> >> Thanks for the quick reply.
>> >>> >>
>> >>> >> I agree with your opinion that

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 <xinni.ge1...@gmail.com>:
> 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 <e...@e0ne.info> 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 <openst...@sheep.art.pl>:
>>> > 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 <xinni.ge1...@gmail.com>
>>> > 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 <amot...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Hi Xinni,
>>> >>>
>>> >>> 2018-03-09 12:05 GMT+09:00 Xinni Ge <xinni.ge1...@gmail.com>:
>>> >>> > 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 s

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

[Kaz Shinohara]

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-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> 葛馨霓 Xinni Ge
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing 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] [heat] heat-dashboard is non-free, with broken unit test env

[Kaz Shinohara]

Hi,

Thank you very much for your quick response & kind comment :)

Yes, we are planning to backport some patches to stable/queens.
Also in the last PTG, had discussion with horizon team about how to
leverage xstatic repos to solve this issue.
Current our plan is to create a new xstatic-*** repo to support js
which are needed by only heat-dashboard.
For any other js, heat-dashboard will take the existing xstatic-***.
In the end, we will not have any embedded js in heat-dashboard repo, for sure.

Now Dublin's snow is pretty cleared, it's time to fly back to my home.
I don't like to see snow any more :P

Regards,
Kaz


2018-03-04 22:22 GMT+09:00 Thomas Goirand <z...@debian.org>:
> On 03/02/2018 07:28 PM, Kaz Shinohara wrote:
>> Hi Thomas(zigo),
>>
>> I found an issue which is included in
>> https://review.openstack.org/#/c/548924/ (you did cherry pick last
>> night)
>> In short, this issue makes it impossible to install heat-dashboard..
>>
>> I landed fix for this.  https://review.openstack.org/#/c/549214/
>>
>> Could you kindly pick up this for your package ?
>> Sorry again for your inconvenience.
>>
>> Regards,
>> Kaz(kazsh)
>
> Hi,
>
> I've added the patch, thanks for it.
>
> So now, I'm embedding that patch for fixing unit tests, plus:
> https://review.openstack.org/#/c/547468/
> https://review.openstack.org/#/c/549214/
>
> Indeed, it'd be nice to have all of them officially backported to
> Queens, as you suggested on IRC. It'd be even better to completely
> remove embedded stuff, and use xstatic packages. There's already an
> XStatic package for the font-awesome which can be used. I do believe it
> would be very much OK to add such a requirement to heat-dashboard, since
> it is already one of the requirements for Horizon.
>
> Altogether, thanks a lot for your care, as always, the OpenStack
> community turns out to be comprehensive, reactive and simply awesome! :)
>
> 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] [heat] heat-dashboard is non-free, with broken unit test env

[Kaz Shinohara]

Hi Thomas(zigo),

I found an issue which is included in
https://review.openstack.org/#/c/548924/ (you did cherry pick last
night)
In short, this issue makes it impossible to install heat-dashboard..

I landed fix for this.  https://review.openstack.org/#/c/549214/

Could you kindly pick up this for your package ?
Sorry again for your inconvenience.

Regards,
Kaz(kazsh)


2018-03-02 23:37 GMT+09:00 Akihiro Motoki :
> Thanks for clarification.
> I was a bit confused with the two things because the patch dropped
> some embedded stuffs like font-awesome.
> Let's address the "embedded" problem soon :)
>
> Akihiro
>
> 2018-03-02 14:27 GMT+00:00 Xinni Ge :
>> Hi, Akihiro,
>>
>> The patch I submitted previously didn't solve the embedded problem.
>> I would like to fix out the whole thing in several steps, because the
>> current status of static files arrangment is quite messy.
>>
>> I will upload the javascript and css style files as xstatic-* projects and
>> remove them from the code later on.
>>
>> I wanted to solve the unittest problem ASAP and assumed it will take some
>> time to create xstatic repos and get the approval from infra team,
>> so I just submitted this patch to let unittest go well at first.
>>
>> Thanks for asking, I am happy to hear from your all about the js and static
>> files issue.
>>
>> Best regards,
>>
>> Xinni
>>
>> On Fri, Mar 2, 2018 at 1:29 PM, Akihiro Motoki  wrote:
>>>
>>> Hi Xinni,
>>>
>>> I looked at your patch which drops the vendors stuffs, but I still
>>> have a question.
>>>
>>> The patch introduces some SCSS like:
>>> - bootstrap.scss
>>> - angular-notify.scss
>>> - angular-material.scss
>>>
>>> Aren't they another type of "vendors" stuffs?
>>> I don't understand why switching to SCSS solves the embedded "vendors"
>>> problem?
>>>
>>> I would like to know opinions from zigo and Corey.
>>>
>>> Thanks,
>>> Akihiro
>>>
>>>
>>> 2018-03-01 21:30 GMT+00:00 Xinni Ge :
>>> > Hi, there.
>>> >
>>> > This is a page of a similar unittest issue.
>>> > https://bugs.launchpad.net/heat-dashboard/+bug/1752527
>>> >
>>> > We merged the following patch to fix the issue, and hope it also fix the
>>> > trouble described here.
>>> >  https://review.openstack.org/#/c/548924/
>>> >
>>> > As for the minified javascript files, we are working on removing from
>>> > the
>>> > source code,
>>> >  and uploading as xstatic packages.
>>> > Just need a little more time to finish it.
>>> >
>>> >
>>> > Best regards,
>>> >
>>> > Xinni
>>> >
>>> > On Tue, Feb 27, 2018 at 10:48 AM, Thomas Goirand 
>>> > wrote:
>>> >>
>>> >> On 02/23/2018 09:29 AM, Xinni Ge wrote:
>>> >> > Hi there,
>>> >> >
>>> >> > We are aware of the javascript embedded issue, and working on it now,
>>> >> > the patch will be summited later.
>>> >> >
>>> >> > As for the unittest failure, we are still investigating it. We will
>>> >> > contant you as soon as we find out the cause.
>>> >> >
>>> >> > Sorry to bring troubles to you. We will be grateful if you could wait
>>> >> > for a little longer.
>>> >> >
>>> >> > Best Regards,
>>> >> >
>>> >> > Xinni
>>> >>
>>> >> Hi,
>>> >>
>>> >> Thanks for this message. This lowers the frustration! :)
>>> >> Let me know if there's any patch I could review.
>>> >>
>>> >> 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
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > 葛馨霓 Xinni Ge
>>> >
>>> >
>>> > __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> 葛馨霓 Xinni Ge
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing 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] [heat][ptg] PTG schedule

[Kaz Shinohara]

Hi Rico & team,


Thanks a lot for the schedule.
See you soon in Dublin :)

Regards,
Kaz



2018-02-24 20:53 GMT+09:00 Rico Lin :

> Dear all
>
> I can’t wait for see you all in Dublin.
>
> I put a draft version of PTG schedule in [1].
> We might change schedule after PTG started.
>
> Also we’re capable to set up real time video conference, so if you’re
> interested in join, please put your name in etherpad so I will know that I
> need to set up for it.
>
> And just for reminding, we will not host meeting next week.
>
> Hope you all have a nice flight
>
> [1] https://etherpad.openstack.org/p/heat-rocky-ptg
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] Collecting Queens demos

[Kaz Shinohara]

Hi Anne,


Noted with thanks.

We will make a demo  video & upload it to YouTube.
Let you know when it will be ready.

Cheers,
Kaz


2018-02-17 1:23 GMT+09:00 Anne Bertucio <a...@openstack.org>:
> Hi Kaz,
>
> Format is your choice, but we weren’t planning to host demos, just aggregate
> the links in a single place for readers, so you’ll want to upload to
> youtube/vimeo/etc and then send.
>
> Cheers,
> Anne Bertucio
> Marketing and Certification, OpenStack Foundation
> a...@openstack.org | 206-992-7961
>
>
>
>
> On Feb 15, 2018, at 8:03 PM, Kaz Shinohara <ksnhr.t...@gmail.com> wrote:
>
> Hi Anne,
>
>
> I'm wondering if I can send a demo video for heat-dashboard which is a
> new feature in Queens.
> Is there any format of the video ?
>
> Regards,
> Kaz
>
>
> 2018-02-16 8:09 GMT+09:00 Anne Bertucio <a...@openstack.org>:
>
> Hi all,
>
> We’re getting the Queens Release communications ready, and I’ve seen a
> handful of video demos and tutorials of new Queens features. We’d like to
> compile a list of these to share with the marketing community. If you have a
> demo, would you please send a link my way so we can make sure to include it?
>
> If you don’t have a demo and have the time, I’d encourage you to make one of
> a feature you’re really excited about! We’ve heard really positive feedback
> about what’s already out there; people love them!
>
>
> Cheers,
> Anne Bertucio
> OpenStack Foundation
> a...@openstack.org | 206-992-7961
>
>
>
>
>
> __
> OpenStack Development Mailing 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] [release] Collecting Queens demos

[Kaz Shinohara]

Hi Anne,


I'm wondering if I can send a demo video for heat-dashboard which is a
new feature in Queens.
Is there any format of the video ?

Regards,
Kaz


2018-02-16 8:09 GMT+09:00 Anne Bertucio :
> Hi all,
>
> We’re getting the Queens Release communications ready, and I’ve seen a
> handful of video demos and tutorials of new Queens features. We’d like to
> compile a list of these to share with the marketing community. If you have a
> demo, would you please send a link my way so we can make sure to include it?
>
> If you don’t have a demo and have the time, I’d encourage you to make one of
> a feature you’re really excited about! We’ve heard really positive feedback
> about what’s already out there; people love them!
>
>
> Cheers,
> Anne Bertucio
> OpenStack Foundation
> a...@openstack.org | 206-992-7961
>
>
>
>
>
> __
> OpenStack Development Mailing 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] [heat] No Meeting This week

[Kaz Shinohara]

Hi Rico,


Hope you and your family have good holidays:)

I have one thing hopefully before your off.
Looks heat-dashboard does not have stable/queens branch yet.
I got an indication about this from Horizon core and they are waiting for
that heat-dashboard will have it.
(we want to drop django <= 1.10 support along with Horizon for Rocky)
Cloud you kindly take care of this issue ?

Your response will be highly appreciated.

Regards,
Kaz (kazsh)


2018-02-12 23:35 GMT+09:00 Rico Lin :

> Hi all
> Good news first! We released queens last week, so well done everyone.
>
> This week is Chinese new year, and Wednesday happen to be new year eve, so
> I will not hosting the meeting this week.
>
> Let's skip this one if no important stuff to talk about.
>
> See you at next meeting
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> __
> OpenStack Development Mailing 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][heat] heat-dashboard is ready for Horizon team's review

[Kaz Shinohara]

Hi all,


I've confirmed a couple of things below.

- heat-dashboard is released in queens-2  Thx! Rico :)
  you can see the release tag 1.0.0 in
http://git.openstack.org/cgit/openstack/heat-dashboard/

- Dropped heat related code from horizon repo. Thx! Akihiro :)
  
http://git.openstack.org/cgit/openstack/horizon/commit/?id=b4fccffccca501388b0e1800375f3e6c7efaea81

Looks head-dashboard successfully takes over from horizon.
#opened bugs too ;) https://bugs.launchpad.net/heat-dashboard

Thank you very much for your cooperation so far.
And if I missed something to do, please kindly give me a shout.

Regards,
Kaz Shinohara


2017-12-06 23:30 GMT+09:00 Kaz Shinohara <ksnhr.t...@gmail.com>:
> Hi Akihiro, Horizon team,
>
>
> Thanks a lot for your help as always:)
>
>>> Thanks for updating the horizon patch. Is it ready to merge from the
>>> perspective of heat dashboard team?
> Yes, we think it's ready to be merged.
>
>>> Perhaps the system panel needs to be pluggable.
>>> As of now, it sounds no problem to remove the list of head services 
>>> temporarily.
> I had talked with Heat team & got no objection on this, looks it's ok
> to remove it temporarily.
> Making it pluggable sounds nice, hopefully we will have further
> discussion in next PTG.
>
>> IIRC about 25 bugs were forwarded. I hope heat-dashboard team can
>> investigate them.
> Thank you, we will work for them!
>
> Regards,
> Kaz
>
>
>
> 2017-12-06 15:49 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:
>> I have another announcement on heat-dashboard split out.
>>
>> I moved the horizon bugs related to heat to heat-dashboard launchpad
>> project last week.
>> IIRC about 25 bugs were forwarded. I hope heat-dashboard team can
>> investigate them.
>>
>> Akihiro
>>
>> 2017-12-06 15:46 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:
>>> Hi Kaz,
>>>
>>> 2017-12-05 18:45 GMT+09:00 Kaz Shinohara <ksnhr.t...@gmail.com>:
>>>> Hi Akihiro, Horizon & Heat team,
>>>>
>>>>
>>>> We've slightly updated your change for the split out, please check
>>>> https://review.openstack.org/#/c/523402/
>>>
>>> Thanks for updating the horizon patch. Is it ready to merge from the
>>> perspective of heat dashboard team?
>>>
>>>> One non-voting job failed but hopefully not related to this change.
>>>
>>> The failing non-voting job is not related to the patch.
>>> It is for Django 2.0 support but horizon has not support Django 2.0,
>>> so it always fails now.
>>>
>>>> In parallel, we could confirm that heat-dashboard works without any
>>>> issue along with this change.
>>>>
>>>> Also resolved the points what Akihiro kindly commented.
>>>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>>>
>>>> The thing we should discuss going forward is how to handle admin info
>>>> panel for Heat.
>>>> Personally information we can see from the panel is really limited,
>>>> just a list of heat engine services, so might be ok to be removed.
>>>> https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/info/tables.py#L256
>>>> I've never seen other dashboards supporting admin functions, better to
>>>> follow others & keep simplicity.
>>>> Any opinion will be welcome :)
>>>
>>> Yeah, it makes sense.
>>>
>>> Perhaps the system panel needs to be pluggable.
>>> As of now, it sounds no problem to remove the list of head services 
>>> temporarily.
>>>
>>> Thanks,
>>> Akihiro
>>>
>>>>
>>>> Regards,
>>>> Kaz
>>>>
>>>>
>>>> 2017-11-29 12:39 GMT+09:00 Kaz Shinohara <ksnhr.t...@gmail.com>:
>>>>> Hi Akihiro,
>>>>>
>>>>>
>>>>> Thanks for your quick response!
>>>>>
>>>>> As you requested, we will check & update your patch to slit out heat
>>>>> support from Horizon repo.
>>>>> https://review.openstack.org/#/c/523402/
>>>>>
>>>>> Also replied for your comment in our etherpad, please kindly check.
>>>>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>>>>
>>>>> Regards,
>>>>> Kaz
>>>>>
>>>>> 2017-11-28 21:08 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:
>>>>>> Hi Kaz,

Re: [openstack-dev] [horizon][heat] heat-dashboard is ready for Horizon team's review

[Kaz Shinohara]

Hi Akihiro, Horizon team,


Thanks a lot for your help as always:)

>> Thanks for updating the horizon patch. Is it ready to merge from the
>> perspective of heat dashboard team?
Yes, we think it's ready to be merged.

>> Perhaps the system panel needs to be pluggable.
>> As of now, it sounds no problem to remove the list of head services 
>> temporarily.
I had talked with Heat team & got no objection on this, looks it's ok
to remove it temporarily.
Making it pluggable sounds nice, hopefully we will have further
discussion in next PTG.

> IIRC about 25 bugs were forwarded. I hope heat-dashboard team can
> investigate them.
Thank you, we will work for them!

Regards,
Kaz



2017-12-06 15:49 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:
> I have another announcement on heat-dashboard split out.
>
> I moved the horizon bugs related to heat to heat-dashboard launchpad
> project last week.
> IIRC about 25 bugs were forwarded. I hope heat-dashboard team can
> investigate them.
>
> Akihiro
>
> 2017-12-06 15:46 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:
>> Hi Kaz,
>>
>> 2017-12-05 18:45 GMT+09:00 Kaz Shinohara <ksnhr.t...@gmail.com>:
>>> Hi Akihiro, Horizon & Heat team,
>>>
>>>
>>> We've slightly updated your change for the split out, please check
>>> https://review.openstack.org/#/c/523402/
>>
>> Thanks for updating the horizon patch. Is it ready to merge from the
>> perspective of heat dashboard team?
>>
>>> One non-voting job failed but hopefully not related to this change.
>>
>> The failing non-voting job is not related to the patch.
>> It is for Django 2.0 support but horizon has not support Django 2.0,
>> so it always fails now.
>>
>>> In parallel, we could confirm that heat-dashboard works without any
>>> issue along with this change.
>>>
>>> Also resolved the points what Akihiro kindly commented.
>>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>>
>>> The thing we should discuss going forward is how to handle admin info
>>> panel for Heat.
>>> Personally information we can see from the panel is really limited,
>>> just a list of heat engine services, so might be ok to be removed.
>>> https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/info/tables.py#L256
>>> I've never seen other dashboards supporting admin functions, better to
>>> follow others & keep simplicity.
>>> Any opinion will be welcome :)
>>
>> Yeah, it makes sense.
>>
>> Perhaps the system panel needs to be pluggable.
>> As of now, it sounds no problem to remove the list of head services 
>> temporarily.
>>
>> Thanks,
>> Akihiro
>>
>>>
>>> Regards,
>>> Kaz
>>>
>>>
>>> 2017-11-29 12:39 GMT+09:00 Kaz Shinohara <ksnhr.t...@gmail.com>:
>>>> Hi Akihiro,
>>>>
>>>>
>>>> Thanks for your quick response!
>>>>
>>>> As you requested, we will check & update your patch to slit out heat
>>>> support from Horizon repo.
>>>> https://review.openstack.org/#/c/523402/
>>>>
>>>> Also replied for your comment in our etherpad, please kindly check.
>>>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>>>
>>>> Regards,
>>>> Kaz
>>>>
>>>> 2017-11-28 21:08 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:
>>>>> Hi Kaz,
>>>>>
>>>>> Good hear the good progress of heat-dashboard. Thanks.
>>>>>
>>>>> I created a blueprint in horizon to track the effort (mainly in
>>>>> horizon side) and assign it to you:
>>>>> https://blueprints.launchpad.net/horizon/+spec/heat-dashboard-split-out
>>>>> I also left comments in your etherpad.
>>>>>
>>>>> I think it is time to prepare a patch which drops heat-dashboard code
>>>>> from horizon and test the new dashboard with it. Could you propose the
>>>>> patch?
>>>>>
>>>>> Thanks,
>>>>> Akihiro
>>>>>
>>>>>
>>>>> 2017-11-28 16:32 GMT+09:00 Kaz Shinohara <ksnhr.t...@gmail.com>:
>>>>>> Hi Horizon team,
>>>>>>
>>>>>>
>>>>>> As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
>>>>>> ready, please kindly review it.
>>>>>>
>>&g

Re: [openstack-dev] [horizon][heat] heat-dashboard is ready for Horizon team's review

[Kaz Shinohara]

Hi Akihiro, Horizon & Heat team,


We've slightly updated your change for the split out, please check
https://review.openstack.org/#/c/523402/
One non-voting job failed but hopefully not related to this change.
In parallel, we could confirm that heat-dashboard works without any
issue along with this change.

Also resolved the points what Akihiro kindly commented.
https://etherpad.openstack.org/p/heat-dashboard-review-point

The thing we should discuss going forward is how to handle admin info
panel for Heat.
Personally information we can see from the panel is really limited,
just a list of heat engine services, so might be ok to be removed.
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/info/tables.py#L256
I've never seen other dashboards supporting admin functions, better to
follow others & keep simplicity.
Any opinion will be welcome :)

Regards,
Kaz


2017-11-29 12:39 GMT+09:00 Kaz Shinohara <ksnhr.t...@gmail.com>:
> Hi Akihiro,
>
>
> Thanks for your quick response!
>
> As you requested, we will check & update your patch to slit out heat
> support from Horizon repo.
> https://review.openstack.org/#/c/523402/
>
> Also replied for your comment in our etherpad, please kindly check.
> https://etherpad.openstack.org/p/heat-dashboard-review-point
>
> Regards,
> Kaz
>
> 2017-11-28 21:08 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:
>> Hi Kaz,
>>
>> Good hear the good progress of heat-dashboard. Thanks.
>>
>> I created a blueprint in horizon to track the effort (mainly in
>> horizon side) and assign it to you:
>> https://blueprints.launchpad.net/horizon/+spec/heat-dashboard-split-out
>> I also left comments in your etherpad.
>>
>> I think it is time to prepare a patch which drops heat-dashboard code
>> from horizon and test the new dashboard with it. Could you propose the
>> patch?
>>
>> Thanks,
>> Akihiro
>>
>>
>> 2017-11-28 16:32 GMT+09:00 Kaz Shinohara <ksnhr.t...@gmail.com>:
>>> Hi Horizon team,
>>>
>>>
>>> As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
>>> ready, please kindly review it.
>>>
>>> http://git.openstack.org/cgit/openstack/heat-dashboard
>>>
>>> Also we described points to be clarified in this review, if you find
>>> anything to be noted/fixed, please feel free to put your comment on
>>> this etherpad, we will respond to them.
>>>
>>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>>
>>> We are planning to land heat-dashboard in queens-2, hopefully we will
>>> fix any issue until then.
>>>
>>> Your cooperation will be highly appreciated.
>>>
>>> Regards,
>>> Kaz Shinohara
>>>
>>> __
>>> OpenStack Development Mailing 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][heat] heat-dashboard is ready for Horizon team's review

[Kaz Shinohara]

Hi Akihiro,


Thanks for your quick response!

As you requested, we will check & update your patch to slit out heat
support from Horizon repo.
https://review.openstack.org/#/c/523402/

Also replied for your comment in our etherpad, please kindly check.
https://etherpad.openstack.org/p/heat-dashboard-review-point

Regards,
Kaz

2017-11-28 21:08 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:
> Hi Kaz,
>
> Good hear the good progress of heat-dashboard. Thanks.
>
> I created a blueprint in horizon to track the effort (mainly in
> horizon side) and assign it to you:
> https://blueprints.launchpad.net/horizon/+spec/heat-dashboard-split-out
> I also left comments in your etherpad.
>
> I think it is time to prepare a patch which drops heat-dashboard code
> from horizon and test the new dashboard with it. Could you propose the
> patch?
>
> Thanks,
> Akihiro
>
>
> 2017-11-28 16:32 GMT+09:00 Kaz Shinohara <ksnhr.t...@gmail.com>:
>> Hi Horizon team,
>>
>>
>> As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
>> ready, please kindly review it.
>>
>> http://git.openstack.org/cgit/openstack/heat-dashboard
>>
>> Also we described points to be clarified in this review, if you find
>> anything to be noted/fixed, please feel free to put your comment on
>> this etherpad, we will respond to them.
>>
>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>
>> We are planning to land heat-dashboard in queens-2, hopefully we will
>> fix any issue until then.
>>
>> Your cooperation will be highly appreciated.
>>
>> Regards,
>> Kaz Shinohara
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [horizon][heat] heat-dashboard is ready for Horizon team's review

[Kaz Shinohara]

Hi Horizon team,


As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
ready, please kindly review it.

http://git.openstack.org/cgit/openstack/heat-dashboard

Also we described points to be clarified in this review, if you find
anything to be noted/fixed, please feel free to put your comment on
this etherpad, we will respond to them.

https://etherpad.openstack.org/p/heat-dashboard-review-point

We are planning to land heat-dashboard in queens-2, hopefully we will
fix any issue until then.

Your cooperation will be highly appreciated.

Regards,
Kaz Shinohara

__
OpenStack Development Mailing 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] [heat][horizon] Migration to heat-dashboard: how can we move this forward?

[Kaz Shinohara]

Hi Akihiro,

Much appreciated for giving us the right direction.
We are totally on same page as you & will let you know when
heat-dashboard is ready.

> AFAIK, the only patch which landed after the heat-dashboard repo was created 
> is
> https://review.openstack.org/#/c/498838/
Thanks!  will pick up this later :)

Regards,
Kaz Shinohara

2017-10-27 0:27 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:
> Hi Kaz,
>
> Thanks for sharing the current status of heat-dashboard.
> Queens-2 sounds a reasonable milestone.
>
> I summarize the near-future below. Right?
>
> - heat-dashboard team is preparing for heat dashboard split-out.
>   The horizon parity (including stability) is the current focus.
> - Heat related bugs filed to horizon can be hold until the
> heat-dashboard is ready (around Q-2)
>   After it is ready, they will be forwarded to heat-dashboard from
> horizon launchpad
>   and we can fix them in the heat-dashboard repository.
> - Horizon team tries not to approve heat-related patches without strong 
> reasons.
>
>> Of course we will keep looking at what's going on in Horizon side &
>> will cherry-pick the leftovers if needed in the end.
>
> AFAIK, the only patch which landed after the heat-dashboard repo was created 
> is
> https://review.openstack.org/#/c/498838/
>
> Thanks,
> Akihiro
>
> 2017-10-25 13:11 GMT+09:00 Kaz Shinohara <ksnhr.t...@gmail.com>:
>>  Hi Akihiro,
>>
>>
>> Thanks for your kind following up :)
>>
>>> (1) Patch reviews and approvals in horizon
>> Could you please stop to accept heat-dashboard related patches without
>> critical ones ?
>> According to our discussion in the last PTG, we made heat-dashboard
>> repo taking horizon repo as upstream & now trying to land it in
>> queens-2.
>> Of course we will keep looking at what's going on in Horizon side &
>> will cherry-pick the leftovers if needed in the end.
>>
>>> (2) Bug Management
>> Yes we can take over those bugs, but now we are focusing to stabilize
>> heat-dashboard-self.
>> We would like to fix them after we will safely land heat-dashboard in 
>> queens-2.
>>
>> Regards,
>> Kaz Shinohara
>>
>> 2017-10-25 11:47 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:
>>> Hi Heat dashboard team,
>>>
>>> I noticed heat-dashboard repository was created.
>>> I have several questions from horizon side.
>>>
>>> A big question is "When does the switch happen?"
>>>
>>> This mainly affects two things:
>>>
>>> (1) Patch reviews and approvals in horizon
>>>
>>> Should the horizon team stop to accept heat-dashboard related patches
>>> into the horizon repo now?
>>> If you want to migrate in parallel, you need to take care of what
>>> happens in the horizon repo continuously.
>>> The simplest way is to stop any activities in horizon side.
>>>
>>> Note that one patch landed yesterday into the horizon repo.
>>> Perhaps the heat-dashboard team will cherry-pick it into your repository.
>>>
>>> (2) Bug Management
>>>
>>> Is it okay to forward heat-related bugs into heat-dashboard launchpad?
>>> When do we start?
>>> There are several number of existing bugs related to the heat dashboard.
>>> The horizon team now just adds 'heat' tag and is waiting for heat-dashboard.
>>> https://bugs.launchpad.net/horizon/+bugs?field.tag=heat
>>>
>>> Thanks,
>>> Akihiro
>>>
>>> __
>>> OpenStack Development Mailing 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] [heat][horizon] Migration to heat-dashboard: how can we move this forward?

[Kaz Shinohara]

 Hi Akihiro,


Thanks for your kind following up :)

> (1) Patch reviews and approvals in horizon
Could you please stop to accept heat-dashboard related patches without
critical ones ?
According to our discussion in the last PTG, we made heat-dashboard
repo taking horizon repo as upstream & now trying to land it in
queens-2.
Of course we will keep looking at what's going on in Horizon side &
will cherry-pick the leftovers if needed in the end.

> (2) Bug Management
Yes we can take over those bugs, but now we are focusing to stabilize
heat-dashboard-self.
We would like to fix them after we will safely land heat-dashboard in queens-2.

Regards,
Kaz Shinohara

2017-10-25 11:47 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:
> Hi Heat dashboard team,
>
> I noticed heat-dashboard repository was created.
> I have several questions from horizon side.
>
> A big question is "When does the switch happen?"
>
> This mainly affects two things:
>
> (1) Patch reviews and approvals in horizon
>
> Should the horizon team stop to accept heat-dashboard related patches
> into the horizon repo now?
> If you want to migrate in parallel, you need to take care of what
> happens in the horizon repo continuously.
> The simplest way is to stop any activities in horizon side.
>
> Note that one patch landed yesterday into the horizon repo.
> Perhaps the heat-dashboard team will cherry-pick it into your repository.
>
> (2) Bug Management
>
> Is it okay to forward heat-related bugs into heat-dashboard launchpad?
> When do we start?
> There are several number of existing bugs related to the heat dashboard.
> The horizon team now just adds 'heat' tag and is waiting for heat-dashboard.
> https://bugs.launchpad.net/horizon/+bugs?field.tag=heat
>
> Thanks,
> Akihiro
>
> __
> OpenStack Development Mailing 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] [heat] Deprecate/Remove deferred_auth_method=password config option

[Kaz Shinohara]

Hi,

> No, I think we still need this, because it is disabled by default -
> this option allows you to enable defeating token expiry via trusts,
My understanding for the current implementation is..
`deferred_auth_method=trust` triggers getting trust_id and storing it in the db.
`reauthentication_method=trust` triggers getting trust scoped token by
taking the trust id(Allow reauthentication)
Those looks somehow duplicated because trust_id is required only when
you want to get the trust scoped token, it's ok for heat to get
trust_id when he need to get trust scoped token, isn't it ?

In case of removing the password authentication, why don't we remove
`deferred_auth_method` from heat.conf and unify
'reauthentication_method' to triggers getting trust_id and getting
trust scoped token.

Cheers,
Kaz

2017-06-21 16:51 GMT+09:00 Steven Hardy <sha...@redhat.com>:
> On Fri, Jun 16, 2017 at 10:09 AM, Kaz Shinohara <ksnhr.t...@gmail.com> wrote:
>> Hi Rabi,
>>
>>
>> I still takes `deferred _auth_method=password` behalf of trusts because we
>> don't enable trusts in the Keystone side due to some internal reason.
>> The issues what you pointed are correct(e.g. user_domain_id), we don't use
>> the domain well and also added some patches to skip those issues.
>> But I guess that the majority of heat users already moved to trusts and it
>> is obviously better solution in terms of security and granular role control.
>> As the edge case(perhaps), if a user want to take password auth, it would be
>> too tricky for them to introduce it, therefore I agree your 2nd option.
>>
>> If we will remove the `deferred_auth_method=password` from heat.conf,
>> should we keep `deferred_auth_method` self or will replace it to a new
>> config option just to specify the trusts enable/disable ?  Do you have any
>> idea on this?
>
> I don't think it makes sense to have an enable/disable trusts config
> option unless there is an alternative (e.g we've discussed oauth in
> the past and in future there may be alternatives to trusts).
>
> I guess if there was sufficient interest we could have some option
> that blacklists all resources that require deferred authentication,
> but I'm not sure folks are actually asking for that right now?
>
> My preference is to deprecate deferred_auth_method, since right now
> there's not really any alternative that works for us.
>
>> Also I'm thinking that `reauthentication_method` also might be
>> changed/merged ?
>
> No, I think we still need this, because it is disabled by default -
> this option allows you to enable defeating token expiry via trusts,
> which is something an operator must opt-in to IMO (we should not
> enable this by default, as it's really only intended for certain edge
> cases such as TripleO where there are often very long running stack
> operations that may exceed the keystone token expiry).
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

[Kaz Shinohara]

Hi team,


>> Free advice: whatever reason you have for not enabling trusts, storing
>> user passwords in the Heat database is 100x worse.
Thank you, your point sounds reasonable.
Of course we don't like to store our customer's credentials in Heat
DB, event though those are encrypted.
This is one of the reason why I agree Rabi's option2.
We are seriously thinking to change it  to the trusts now.


>> Why aren't those upstream?
One of them already in review as Rabi attached.  My colleague raised :)
https://review.openstack.org/435213
If the discussion here will have a conclusion to keep the password auth,
it's pleasure for us to have any further contribution on this point.

Regards,
Kaz

2017-06-17 0:19 GMT+09:00 Pavlo Shchelokovskyy <pshchelokovs...@mirantis.com>:
> HI all,
>
> On Fri, Jun 16, 2017 at 4:33 PM, Zane Bitter <zbit...@redhat.com> wrote:
>>
>> On 16/06/17 05:09, Kaz Shinohara wrote:
>>>
>>> I still takes `deferred _auth_method=password` behalf of trusts because
>>> we don't enable trusts in the Keystone side due to some internal reason.
>>
>>
>> Free advice: whatever reason you have for not enabling trusts, storing
>> user passwords in the Heat database is 100x worse.
>>
>>> The issues what you pointed are correct(e.g. user_domain_id), we don't
>>> use the domain well and also added some patches to skip those issues.
>>
>>
>> Why aren't those upstream?
>>
>>> But I guess that the majority of heat users already moved to trusts and
>>> it is obviously better solution in terms of security and granular role
>>> control.
>>> As the edge case(perhaps), if a user want to take password auth, it would
>>> be too tricky for them to introduce it, therefore I agree your 2nd option.
>>>
>>> If we will remove the `deferred_auth_method=password` from heat.conf,
>>> should we keep `deferred_auth_method` self or will replace it to a new
>>> config option just to specify the trusts enable/disable ?  Do you have any
>>> idea on this?
>>> Also I'm thinking that `reauthentication_method` also might be
>>> changed/merged ?
>>>
>>> Regards,
>>> Kaz Shinohara
>>>
>>>
>>> 2017-06-16 14:11 GMT+09:00 Rabi Mishra <ramis...@redhat.com
>>> <mailto:ramis...@redhat.com>>:
>>
>>
>> [snip]
>>
>>> I'm not sure whether this works with keystone v2 and anyone is using
>>> it or not. Keeping in mind that heat-cli is deprecated and keystone
>>> v3 is now the default, we've 2 options
>>>
>>> 1. Continue to support 'deferred_auth_method=passsword' option and
>>> fix all the above issues.
>>>
>>> 2. Remove/deprecate the option in pike itlsef.
>>>
>>> I would prefer option 2, but probably I miss some history and use
>>> cases for it.
>>
>>
>> Am I right in thinking that any user (i.e. not just the [heat] service
>> user) can create a trust? I still see occasional requests about 'standalone
>> mode' for clouds that don't have Heat available to users (which I suspect is
>> broken, otherwise people wouldn't be asking), and I'm guessing that
>> standalone mode has heretofore required deferred_auth_method=password.
>
>
> When trusts are enabled, generally any user can create a trust to any other
> user, but only with itself as trustor  - there's a strict rule for that in
> default keystone policy.json [0]. The only other reason that might block
> this is when the user is already a trustee, and trust chaining is disabled
> or already exhausted for this trustee. A tiny problem might be that it seems
> you need to know both the user_id/project_id of trustor (can be resolved by
> trustor itself) and the user_id of trustee - which is generally impossible
> for non-admin users, so a trustee must give the trustor its id.
>
> [0]
> http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n138
>
>>
>> So if we're going to remove the option then we should probably either
>> officially disown standalone mode or rewrite the instructions such that it
>> can be used with the trusts method.
>>
>> cheers,
>> Zane.
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> Cheers,
> --
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing 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] [heat] Deprecate/Remove deferred_auth_method=password config option

[Kaz Shinohara]

Hi Rabi,


I still takes `deferred _auth_method=password` behalf of trusts because we
don't enable trusts in the Keystone side due to some internal reason.
The issues what you pointed are correct(e.g. user_domain_id), we don't use
the domain well and also added some patches to skip those issues.
But I guess that the majority of heat users already moved to trusts and it
is obviously better solution in terms of security and granular role
control.
As the edge case(perhaps), if a user want to take password auth, it would
be too tricky for them to introduce it, therefore I agree your 2nd option.

If we will remove the `deferred_auth_method=password` from heat.conf,
should we keep `deferred_auth_method` self or will replace it to a new
config option just to specify the trusts enable/disable ?  Do you have any
idea on this?
Also I'm thinking that `reauthentication_method` also might be
changed/merged ?

Regards,
Kaz Shinohara


2017-06-16 14:11 GMT+09:00 Rabi Mishra <ramis...@redhat.com>:

> Hi All,
>
> As we know,  'deferred_auth_method=trusts' being the default, we use
> trust_auth_plugin whenever a resource requires deferred_auth (any resource
> derived from SignalResponder and StackResource). We also support
> 'deferred_auth_method=password' where  'X-Auth-User'/username and
> 'X-Auth-Key'/password is passed in the request header and we then store
> them in 'user_creds' (rather than 'trust_id')  to create a 'password'
> auth_plugin when loading the stack with stored context for signalling. I
> assume for this very reason we've the '--include-pass' option in heat cli.
>
> However, when using keystone session(which is the default), we don't have
> the above implemented with SessionClient (i.e to pass the headers). There
> is a bug[1] and patch[2]  to add this to SessionClient in the review queue.
> Aslo, we don't have anything like '--include-pass' for osc.
>
> I've noticed that 'deferred_auth_method=password' is broken and does not
> work with keystone v3 at all. As we don't store the 'user_domain_id/name'
> in 'user_creds', we can not even intialize the 'password' auth_plugin when
> creating the StoredContext, as it would not be able to authenticate the
> user without the user_domain[3].
>
> I'm not sure whether this works with keystone v2 and anyone is using it or
> not. Keeping in mind that heat-cli is deprecated and keystone v3 is now the
> default, we've 2 options
>
> 1. Continue to support 'deferred_auth_method=passsword' option and fix
> all the above issues.
>
> 2. Remove/deprecate the option in pike itlsef.
>
> I would prefer option 2, but probably I miss some history and use cases
> for it.
>
> Thoughts?
>
>
> [1] https://bugs.launchpad.net/python-heatclient/+bug/1665321
>
> [2] https://review.openstack.org/435213
>
> [3] https://github.com/openstack/heat/blob/master/heat/common/
> context.py#L292
>
> --
> Regards,
> Rabi Mishra
>
>
> __
> OpenStack Development Mailing 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] [Heat] Heat template example repository

[Kaz Shinohara]

Hi Lico and team,


Let me show up in this thread again, because I think now is really good
timing to introduce myself.
My name is Kazunori Shinohara (Kaz) working for NTT Communications as
software engineer.
I'm taking Heat as public cloud's orchestration services by adding own
resource plugins and some patches, I do believe my experience on this
should help the further development of Heat and the relevant projects.

In the last summit, I got upstream institute and Heat onboarding session, I
guess I was next to Lance at there.
Now I've done my first contribution for a document bug with Zane and
Huang's help.
https://review.openstack.org/#/c/463154/
I will definitely keep contributing more*, esp..bug and blueprint part,
also I don't mind any tasks like as template example if I can help.*

> *tutorial*: We got some reports about the lack of tutorials for for for
features like software config/ rolling upgrade,
Yea I think so, honestly speaking I skipped software config function for
our public cloud because I could not figure out well how it works

> Also, we do hope to get more reports on how people use heat,
I will be able to have feedback from actual use case on our public cloud
going forward.

>(Wednesdays at 1500 UTC in #openstack-meeting-5) :)
I will join too.

Regards,

Kaz Shinohara
IRC: kazsh

2017-05-16 1:10 GMT+09:00 Steven Hardy <sha...@redhat.com>:

> On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote:
> > Hi Steve,
> >
> > I am happy to assist in any way to be honest.
> >
> > The backwards compatibility is not always correct as I have seen when
> > developing our library of templates on Liberty and then trying to deploy
> it
> > on Mitaka for example.
>
> Yeah, I guess it's true that there are sometimes deprecated resource
> interfaces that get removed on upgrade to a new OpenStack version, and that
> is independent of the HOT version.
>
> As we've proven, maintaining these templates has been a challenge given the
> available resources, so I guess I'm still in favor of not duplicating a
> bunch
> of templates, e.g perhaps we could focus on a target of CI testing
> templates on the current stable release as a first step?
>
> > As you guys mentioned in our discussions the Networking example I quoted
> is
> > not something you guys can deal with as the source project affects this.
> >
> > Unless we can use this exercise to test these and fix them then I am
> > happier.
> >
> > My vision would be to have a set of templates and examples that are
> tested
> > regularly against a running OS deployment so that we can make sure the
> > combinations still run. I am sure we can agree on a way to do this with
> CICD
> > so that we test the fetureset.
>
> Agreed, getting the approach to testing agreed seems like the first step -
> FYI we do already have automated scenario tests in the main heat tree that
> consume templates similar to many of the examples:
>
> https://github.com/openstack/heat/tree/master/heat_
> integrationtests/scenario
>
> So, in theory, getting a similar test running on heat_templates should be
> fairly simple, but getting all the existing templates working is likely to
> be a bigger challenge.
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Heat template example repository

[Kaz Shinohara]

Hi Lance,

I like it too.
We should keep them updated according to the latest spec and actual use
cases.

Regards,
Kaz Shinohara


2017-05-13 13:00 GMT+09:00 Foss Geek <thefossg...@gmail.com>:

> Hi Lance, I am also interested to assisting you on this.
>
> Thanks
> Mohan
> On 11-May-2017 2:25 am, "Lance Haig" <lnh...@gmail.com> wrote:
>
>> Hi,
>>
>> I would like to introduce myself to the heat team.
>>
>> My name is Lance Haig I currently work for Mirantis doing workload
>> onboarding to openstack.
>>
>> Part of my job is assisting customers with using the new Openstack cloud
>> they have been given.
>>
>> I recently gave a talk with a colleague Florin Stingaciu on LCM with heat
>> at the Boston Summit.
>>
>> I am interested in assisting the project.
>>
>> We have noticed that there are some outdated examples in the
>> heat-examples repository and I am not sure that they all still function.
>>
>> I was wondering if it would be valuable for me to take a look at these
>> and fix them or perhaps we can rethink how we present the examples.
>>
>> I am interested in what you guys think.
>>
>> Thanks
>>
>> Lance
>>
>> 
>> __
>> 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