Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

I've completed this work. The two patches to migrate the code over and
one additional bug fix are:

Horizon: Copy os-nova-servers from searchlight ui
  https://review.openstack.org/#/c/444095/

Searchlight UI: Remove os-nova-servers resource type
  https://review.openstack.org/#/c/450067/   (depends-on 444095)

Searchlight UI: Resource detail views have moved
  https://review.openstack.org/#/c/450068/

I have tested Searchlight UI and it doesn't break with the additional
resource type registered, however:

1. There is duplication of actions in the action dropdown for instances rows.
2. The details page link is broken, which is addressed in the separate
bug patch above.
3. The Horizon-side instances list is confused when an unmodified
Searchlight UI is installed - table columns are also duplicated.


Richard

__
OpenStack Development Mailing 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][searchlight] Sharing resource type implementations

[Richard Jones]

Hi folks,

I've completed the work in Horizon space
(https://review.openstack.org/#/c/444095/) but I've just tried to run
up a devstack with searchlight enabled to test the searchlight-ui side
and put together a patch there, but the devstack plugin for
searchlight appears to be broken at the moment (I think because of bug
https://bugs.launchpad.net/searchlight/+bug/1648255).


 Richard


On 14 March 2017 at 09:43, Richard Jones <r1chardj0...@gmail.com> wrote:
> I'll definitely be looking at getting a searchlight-ui patch up for
> the mirror side of my Horizon patch.
>
> Double registration largely depends on which particular aspect of the
> resource type is being looked at. Most of the resource type
> registration will just be replaced (with identical information) but
> the kicker will be table columns and actions which are added by append
> (via extensible service), so they'll all be duplicated if both
> registrations run. So ideally both searchlight-ui and Horizon would be
> updated at the same time.
>
>
>  Richard
>
> On 11 March 2017 at 04:34, Tripp, Travis S <travis.tr...@hpe.com> wrote:
>> Hi Richard,
>>
>> I’m headed out for vacation so won’t be able to look through it until I get 
>> back.  However, can you also please get an install of searchlight-ui running 
>> so that you can see if anything breaks?  I know you don’t typically use 
>> devstack, but the searchlight devstack plugin installs searchlight UI. [0]
>>
>> The one thing I’m not sure about is how the resource registry handles 
>> potential double registrations.  So, if the resource is registered both code 
>> bases, I don’t know what would get loaded.
>>
>> https://review.openstack.org/#/c/444095/2/openstack_dashboard/static/app/core/instances/instances.module.js
>> https://github.com/openstack/searchlight-ui/blob/master/searchlight_ui/static/resources/os-nova-servers/os-nova-servers.module.js#L57
>>
>> [0] https://github.com/openstack/searchlight/tree/master/devstack
>>
>> Thanks,
>> Travis
>>
>> On 3/9/17, 10:58 PM, "Richard Jones" <r1chardj0...@gmail.com> wrote:
>>
>> Thanks, Steve!
>>
>> I've put together an initial patch
>> https://review.openstack.org/#/c/444095/ which pulls in the
>> os-nova-servers module and a little extra to make it work in Horizon's
>> codebase. I've tried to make minimal edits to the actual code -
>> predominantly just editing module names. I've tested it and it mostly
>> works on Horizon's side \o/
>>
>>
>>  Richard
>>
>> On 10 March 2017 at 14:40, McLellan, Steven <steve.mclel...@hpe.com> 
>> wrote:
>> > My expertise in this area is deeply suspect but as long as we maintain 
>> the
>> > mapping from the resource type names that searchlight uses 
>> (os-nova-servers)
>> > to the modules we'll be OK. If you or Rob put a patch up against 
>> horizon I
>> > (or a willing victim/volunteer) can test a searchlight-ui patch 
>> against it.
>>     >
>> >
>> >  Original message 
>> > From: Richard Jones <r1chardj0...@gmail.com>
>> > Date: 3/9/17 21:13 (GMT-06:00)
>> > To: "OpenStack Development Mailing List (not for usage questions)"
>> > <openstack-dev@lists.openstack.org>
>> > Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource 
>> type
>> > implementations
>> >
>> > Hey folks,
>> >
>> > Another potential issue is that the searchlight module structure and
>> > Horizon's module structure are different in a couple of respects. I
>> > could just retain the module structure from searchlight
>> > ('resources.os-nova-servers') or, preferably, I could rename those
>> > modules to match the Horizon structure more closely
>> > ('horizon.app.resources.os-nova-servers') or more strictly
>> > ('horizon.app.core.instances').
>> >
>> > As far as I can tell none of the module names are referenced directly
>> > outside of the module (apart from resources.module.js of course) so
>> > moving the modules shouldn't affect any existing usage in searchlight
>> > ui.
>> >
>> > We could bikeshed this for ages, so if I could just get Rob and Steve
>> > to wrestle over it or something, that'd be good. Rob's pretty scrappy.
>> >
>> >
>> >   Richard
>> >
>> >
>

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

I'll definitely be looking at getting a searchlight-ui patch up for
the mirror side of my Horizon patch.

Double registration largely depends on which particular aspect of the
resource type is being looked at. Most of the resource type
registration will just be replaced (with identical information) but
the kicker will be table columns and actions which are added by append
(via extensible service), so they'll all be duplicated if both
registrations run. So ideally both searchlight-ui and Horizon would be
updated at the same time.


 Richard

On 11 March 2017 at 04:34, Tripp, Travis S <travis.tr...@hpe.com> wrote:
> Hi Richard,
>
> I’m headed out for vacation so won’t be able to look through it until I get 
> back.  However, can you also please get an install of searchlight-ui running 
> so that you can see if anything breaks?  I know you don’t typically use 
> devstack, but the searchlight devstack plugin installs searchlight UI. [0]
>
> The one thing I’m not sure about is how the resource registry handles 
> potential double registrations.  So, if the resource is registered both code 
> bases, I don’t know what would get loaded.
>
> https://review.openstack.org/#/c/444095/2/openstack_dashboard/static/app/core/instances/instances.module.js
> https://github.com/openstack/searchlight-ui/blob/master/searchlight_ui/static/resources/os-nova-servers/os-nova-servers.module.js#L57
>
> [0] https://github.com/openstack/searchlight/tree/master/devstack
>
> Thanks,
> Travis
>
> On 3/9/17, 10:58 PM, "Richard Jones" <r1chardj0...@gmail.com> wrote:
>
> Thanks, Steve!
>
> I've put together an initial patch
> https://review.openstack.org/#/c/444095/ which pulls in the
> os-nova-servers module and a little extra to make it work in Horizon's
> codebase. I've tried to make minimal edits to the actual code -
> predominantly just editing module names. I've tested it and it mostly
> works on Horizon's side \o/
>
>
>  Richard
>
> On 10 March 2017 at 14:40, McLellan, Steven <steve.mclel...@hpe.com> 
> wrote:
> > My expertise in this area is deeply suspect but as long as we maintain 
> the
> > mapping from the resource type names that searchlight uses 
> (os-nova-servers)
> > to the modules we'll be OK. If you or Rob put a patch up against 
> horizon I
> > (or a willing victim/volunteer) can test a searchlight-ui patch against 
> it.
> >
> >
> >  Original message 
> > From: Richard Jones <r1chardj0...@gmail.com>
>     > Date: 3/9/17 21:13 (GMT-06:00)
>     > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource 
> type
> > implementations
> >
> > Hey folks,
> >
> > Another potential issue is that the searchlight module structure and
> > Horizon's module structure are different in a couple of respects. I
> > could just retain the module structure from searchlight
> > ('resources.os-nova-servers') or, preferably, I could rename those
> > modules to match the Horizon structure more closely
> > ('horizon.app.resources.os-nova-servers') or more strictly
> > ('horizon.app.core.instances').
> >
> > As far as I can tell none of the module names are referenced directly
> > outside of the module (apart from resources.module.js of course) so
> > moving the modules shouldn't affect any existing usage in searchlight
> > ui.
> >
> > We could bikeshed this for ages, so if I could just get Rob and Steve
> > to wrestle over it or something, that'd be good. Rob's pretty scrappy.
> >
> >
> >   Richard
> >
> >
> > On 10 March 2017 at 09:56, Richard Jones <r1chardj0...@gmail.com> wrote:
> >> OK, I will work on a plan that migrates the code into Horizon, thanks
> >> everyone!
> >>
> >> Travis, can the searchlight details page stuff be done through
> >> extending the base resource type in Horizon? If not, is that perhaps a
> >> limitation of the extensible service?
> >>
> >>
> >>  Richard
> >>
> >>
> >> On 10 March 2017 at 02:20, McLellan, Steven <steve.mclel...@hpe.com>
> >> wrote:
> >>> I concur; option 4 is the only one makes sense to me and was what was
> >>> intended originally. As long as we can do it in one fell swoop in

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Tripp, Travis S]

Hi Richard,

I’m headed out for vacation so won’t be able to look through it until I get 
back.  However, can you also please get an install of searchlight-ui running so 
that you can see if anything breaks?  I know you don’t typically use devstack, 
but the searchlight devstack plugin installs searchlight UI. [0]

The one thing I’m not sure about is how the resource registry handles potential 
double registrations.  So, if the resource is registered both code bases, I 
don’t know what would get loaded. 

https://review.openstack.org/#/c/444095/2/openstack_dashboard/static/app/core/instances/instances.module.js
https://github.com/openstack/searchlight-ui/blob/master/searchlight_ui/static/resources/os-nova-servers/os-nova-servers.module.js#L57

[0] https://github.com/openstack/searchlight/tree/master/devstack

Thanks,
Travis

On 3/9/17, 10:58 PM, "Richard Jones" <r1chardj0...@gmail.com> wrote:

Thanks, Steve!

I've put together an initial patch
https://review.openstack.org/#/c/444095/ which pulls in the
os-nova-servers module and a little extra to make it work in Horizon's
codebase. I've tried to make minimal edits to the actual code -
predominantly just editing module names. I've tested it and it mostly
works on Horizon's side \o/


 Richard

On 10 March 2017 at 14:40, McLellan, Steven <steve.mclel...@hpe.com> wrote:
> My expertise in this area is deeply suspect but as long as we maintain the
> mapping from the resource type names that searchlight uses 
(os-nova-servers)
> to the modules we'll be OK. If you or Rob put a patch up against horizon I
> (or a willing victim/volunteer) can test a searchlight-ui patch against 
it.
>
>
>  Original message 
> From: Richard Jones <r1chardj0...@gmail.com>
> Date: 3/9/17 21:13 (GMT-06:00)
> To: "OpenStack Development Mailing List (not for usage questions)"
    > <openstack-dev@lists.openstack.org>
    > Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource type
> implementations
>
> Hey folks,
>
> Another potential issue is that the searchlight module structure and
> Horizon's module structure are different in a couple of respects. I
> could just retain the module structure from searchlight
> ('resources.os-nova-servers') or, preferably, I could rename those
> modules to match the Horizon structure more closely
> ('horizon.app.resources.os-nova-servers') or more strictly
> ('horizon.app.core.instances').
>
> As far as I can tell none of the module names are referenced directly
> outside of the module (apart from resources.module.js of course) so
> moving the modules shouldn't affect any existing usage in searchlight
> ui.
>
> We could bikeshed this for ages, so if I could just get Rob and Steve
> to wrestle over it or something, that'd be good. Rob's pretty scrappy.
>
>
>   Richard
>
>
> On 10 March 2017 at 09:56, Richard Jones <r1chardj0...@gmail.com> wrote:
>> OK, I will work on a plan that migrates the code into Horizon, thanks
>> everyone!
>>
>> Travis, can the searchlight details page stuff be done through
>> extending the base resource type in Horizon? If not, is that perhaps a
>> limitation of the extensible service?
>>
>>
>>  Richard
>>
>>
>> On 10 March 2017 at 02:20, McLellan, Steven <steve.mclel...@hpe.com>
>> wrote:
>>> I concur; option 4 is the only one makes sense to me and was what was
>>> intended originally. As long as we can do it in one fell swoop in one 
cyclle
>>> (preferably sooner than later) there should be no issues.
>>>
>>>
>>>
>>>
>>> On 3/9/17, 8:35 AM, "Tripp, Travis S" <travis.tr...@hpe.com> wrote:
>>>
>>>>Let me get Matt B in on this discussion, but basically, option 4 is my
>>>> initial feeling as Rob stated.
>>>>
>>>>One downside we saw with this approach is that we weren’t going to be
>>>> able to take advantage of searchlight capabilities in details pages if
>>>> everything was in native horizon.  Although, I suppose that could be 
done by
>>>> using the hz-if-services directive [0] if horizon will allow 
searchlight
>>>> optimized code to be in the horizon repo.
>>>>
>>>>[0]
>>>> 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

Thanks, Steve!

I've put together an initial patch
https://review.openstack.org/#/c/444095/ which pulls in the
os-nova-servers module and a little extra to make it work in Horizon's
codebase. I've tried to make minimal edits to the actual code -
predominantly just editing module names. I've tested it and it mostly
works on Horizon's side \o/


 Richard

On 10 March 2017 at 14:40, McLellan, Steven <steve.mclel...@hpe.com> wrote:
> My expertise in this area is deeply suspect but as long as we maintain the
> mapping from the resource type names that searchlight uses (os-nova-servers)
> to the modules we'll be OK. If you or Rob put a patch up against horizon I
> (or a willing victim/volunteer) can test a searchlight-ui patch against it.
>
>
>  Original message 
> From: Richard Jones <r1chardj0...@gmail.com>
> Date: 3/9/17 21:13 (GMT-06:00)
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource type
> implementations
>
> Hey folks,
>
> Another potential issue is that the searchlight module structure and
> Horizon's module structure are different in a couple of respects. I
> could just retain the module structure from searchlight
> ('resources.os-nova-servers') or, preferably, I could rename those
> modules to match the Horizon structure more closely
> ('horizon.app.resources.os-nova-servers') or more strictly
> ('horizon.app.core.instances').
>
> As far as I can tell none of the module names are referenced directly
> outside of the module (apart from resources.module.js of course) so
> moving the modules shouldn't affect any existing usage in searchlight
> ui.
>
> We could bikeshed this for ages, so if I could just get Rob and Steve
> to wrestle over it or something, that'd be good. Rob's pretty scrappy.
>
>
>   Richard
>
>
> On 10 March 2017 at 09:56, Richard Jones <r1chardj0...@gmail.com> wrote:
>> OK, I will work on a plan that migrates the code into Horizon, thanks
>> everyone!
>>
>> Travis, can the searchlight details page stuff be done through
>> extending the base resource type in Horizon? If not, is that perhaps a
>> limitation of the extensible service?
>>
>>
>>  Richard
>>
>>
>> On 10 March 2017 at 02:20, McLellan, Steven <steve.mclel...@hpe.com>
>> wrote:
>>> I concur; option 4 is the only one makes sense to me and was what was
>>> intended originally. As long as we can do it in one fell swoop in one cyclle
>>> (preferably sooner than later) there should be no issues.
>>>
>>>
>>>
>>>
>>> On 3/9/17, 8:35 AM, "Tripp, Travis S" <travis.tr...@hpe.com> wrote:
>>>
>>>>Let me get Matt B in on this discussion, but basically, option 4 is my
>>>> initial feeling as Rob stated.
>>>>
>>>>One downside we saw with this approach is that we weren’t going to be
>>>> able to take advantage of searchlight capabilities in details pages if
>>>> everything was in native horizon.  Although, I suppose that could be done 
>>>> by
>>>> using the hz-if-services directive [0] if horizon will allow searchlight
>>>> optimized code to be in the horizon repo.
>>>>
>>>>[0]
>>>> https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>>>>
>>>>-Travis
>>>>
>>>>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)" <rcres...@cisco.com>
>>>> wrote:
>>>>
>>>>I tried searching the meeting logs but couldn’t find where we
>>>> discussed this in the Searchlight meeting. The conclusion at the time was
>>>> option 4 IIRC. The main thing is to make sure we get it done within one
>>>> cycle, even if it isn’t default. this means searchlight-ui doesn’t have to
>>>> carry some horrible workarounds and can just remove the code from their
>>>> repo.
>>>>
>>>>Basically; start putting the code in the Horizon repo, and when its
>>>> done, Searchlight-UI can remove it from their repo.
>>>>
>>>>Rob
>>>>
>>>>
>>>>> On 9 Mar 2017, at 04:22, Richard Jones <r1chardj0...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi Searchlight and Horizon folks,
>>>>>
>>>>> I'd like to re-use the wonderful resource type code from
>>>>   

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[McLellan, Steven]

My expertise in this area is deeply suspect but as long as we maintain the 
mapping from the resource type names that searchlight uses (os-nova-servers) to 
the modules we'll be OK. If you or Rob put a patch up against horizon I (or a 
willing victim/volunteer) can test a searchlight-ui patch against it.

 Original message 
From: Richard Jones <r1chardj0...@gmail.com>
Date: 3/9/17 21:13 (GMT-06:00)
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource type 
implementations

Hey folks,

Another potential issue is that the searchlight module structure and
Horizon's module structure are different in a couple of respects. I
could just retain the module structure from searchlight
('resources.os-nova-servers') or, preferably, I could rename those
modules to match the Horizon structure more closely
('horizon.app.resources.os-nova-servers') or more strictly
('horizon.app.core.instances').

As far as I can tell none of the module names are referenced directly
outside of the module (apart from resources.module.js of course) so
moving the modules shouldn't affect any existing usage in searchlight
ui.

We could bikeshed this for ages, so if I could just get Rob and Steve
to wrestle over it or something, that'd be good. Rob's pretty scrappy.


  Richard


On 10 March 2017 at 09:56, Richard Jones <r1chardj0...@gmail.com> wrote:
> OK, I will work on a plan that migrates the code into Horizon, thanks 
> everyone!
>
> Travis, can the searchlight details page stuff be done through
> extending the base resource type in Horizon? If not, is that perhaps a
> limitation of the extensible service?
>
>
>  Richard
>
>
> On 10 March 2017 at 02:20, McLellan, Steven <steve.mclel...@hpe.com> wrote:
>> I concur; option 4 is the only one makes sense to me and was what was 
>> intended originally. As long as we can do it in one fell swoop in one cyclle 
>> (preferably sooner than later) there should be no issues.
>>
>>
>>
>>
>> On 3/9/17, 8:35 AM, "Tripp, Travis S" <travis.tr...@hpe.com> wrote:
>>
>>>Let me get Matt B in on this discussion, but basically, option 4 is my 
>>>initial feeling as Rob stated.
>>>
>>>One downside we saw with this approach is that we weren’t going to be able 
>>>to take advantage of searchlight capabilities in details pages if everything 
>>>was in native horizon.  Although, I suppose that could be done by using the 
>>>hz-if-services directive [0] if horizon will allow searchlight optimized 
>>>code to be in the horizon repo.
>>>
>>>[0] 
>>>https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>>>
>>>-Travis
>>>
>>>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)" <rcres...@cisco.com> wrote:
>>>
>>>I tried searching the meeting logs but couldn’t find where we discussed 
>>> this in the Searchlight meeting. The conclusion at the time was option 4 
>>> IIRC. The main thing is to make sure we get it done within one cycle, even 
>>> if it isn’t default. this means searchlight-ui doesn’t have to carry some 
>>> horrible workarounds and can just remove the code from their repo.
>>>
>>>Basically; start putting the code in the Horizon repo, and when its 
>>> done, Searchlight-UI can remove it from their repo.
>>>
>>>Rob
>>>
>>>
>>>> On 9 Mar 2017, at 04:22, Richard Jones <r1chardj0...@gmail.com> wrote:
>>>>
>>>> Hi Searchlight and Horizon folks,
>>>>
>>>> I'd like to re-use the wonderful resource type code from
>>>> searchlight-ui (in particular os-nova-servers right now but
>>>> potentially others down the track) and was wondering whether you'd had
>>>> any thoughts about how we might share that code? Off the top of my
>>>> head I see a few options:
>>>>
>>>> 1. We depend on the searchlight-ui as a Horizon requirement; this is
>>>> pretty unlikely to happen (depending on any optional panel means it's
>>>> not really optional any longer ;-)
>>>> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
>>> terrible.
>>>> 3. We move the code from searchlight-ui into a separate project that
>>>> both Horizon and searchlight-ui depend upon; this could be made to
>>>> work, though it's Yet Another

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

Hey folks,

Another potential issue is that the searchlight module structure and
Horizon's module structure are different in a couple of respects. I
could just retain the module structure from searchlight
('resources.os-nova-servers') or, preferably, I could rename those
modules to match the Horizon structure more closely
('horizon.app.resources.os-nova-servers') or more strictly
('horizon.app.core.instances').

As far as I can tell none of the module names are referenced directly
outside of the module (apart from resources.module.js of course) so
moving the modules shouldn't affect any existing usage in searchlight
ui.

We could bikeshed this for ages, so if I could just get Rob and Steve
to wrestle over it or something, that'd be good. Rob's pretty scrappy.


  Richard


On 10 March 2017 at 09:56, Richard Jones  wrote:
> OK, I will work on a plan that migrates the code into Horizon, thanks 
> everyone!
>
> Travis, can the searchlight details page stuff be done through
> extending the base resource type in Horizon? If not, is that perhaps a
> limitation of the extensible service?
>
>
>  Richard
>
>
> On 10 March 2017 at 02:20, McLellan, Steven  wrote:
>> I concur; option 4 is the only one makes sense to me and was what was 
>> intended originally. As long as we can do it in one fell swoop in one cyclle 
>> (preferably sooner than later) there should be no issues.
>>
>>
>>
>>
>> On 3/9/17, 8:35 AM, "Tripp, Travis S"  wrote:
>>
>>>Let me get Matt B in on this discussion, but basically, option 4 is my 
>>>initial feeling as Rob stated.
>>>
>>>One downside we saw with this approach is that we weren’t going to be able 
>>>to take advantage of searchlight capabilities in details pages if everything 
>>>was in native horizon.  Although, I suppose that could be done by using the 
>>>hz-if-services directive [0] if horizon will allow searchlight optimized 
>>>code to be in the horizon repo.
>>>
>>>[0] 
>>>https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>>>
>>>-Travis
>>>
>>>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)"  wrote:
>>>
>>>I tried searching the meeting logs but couldn’t find where we discussed 
>>> this in the Searchlight meeting. The conclusion at the time was option 4 
>>> IIRC. The main thing is to make sure we get it done within one cycle, even 
>>> if it isn’t default. this means searchlight-ui doesn’t have to carry some 
>>> horrible workarounds and can just remove the code from their repo.
>>>
>>>Basically; start putting the code in the Horizon repo, and when its 
>>> done, Searchlight-UI can remove it from their repo.
>>>
>>>Rob
>>>
>>>
>>>> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
>>>>
>>>> Hi Searchlight and Horizon folks,
>>>>
>>>> I'd like to re-use the wonderful resource type code from
>>>> searchlight-ui (in particular os-nova-servers right now but
>>>> potentially others down the track) and was wondering whether you'd had
>>>> any thoughts about how we might share that code? Off the top of my
>>>> head I see a few options:
>>>>
>>>> 1. We depend on the searchlight-ui as a Horizon requirement; this is
>>>> pretty unlikely to happen (depending on any optional panel means it's
>>>> not really optional any longer ;-)
>>>> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
>>> terrible.
>>>> 3. We move the code from searchlight-ui into a separate project that
>>>> both Horizon and searchlight-ui depend upon; this could be made to
>>>> work, though it's Yet Another Project.
>>>> 4. We move the code from searchlight-ui into Horizon. I think this is
>>>> most likely to work.
>>>>
>>>> What are your thoughts? Have I missed an option in this list that you
>>>> think is a better one? Have I missed the mark in my analysis of the
>>>> options I've presented?
>>>>
>>>>
>>>>  Richard
>>>>
>>>> 
>>> __
>>>> OpenStack Development Mailing 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

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

OK, I will work on a plan that migrates the code into Horizon, thanks everyone!

Travis, can the searchlight details page stuff be done through
extending the base resource type in Horizon? If not, is that perhaps a
limitation of the extensible service?


 Richard


On 10 March 2017 at 02:20, McLellan, Steven  wrote:
> I concur; option 4 is the only one makes sense to me and was what was 
> intended originally. As long as we can do it in one fell swoop in one cyclle 
> (preferably sooner than later) there should be no issues.
>
>
>
>
> On 3/9/17, 8:35 AM, "Tripp, Travis S"  wrote:
>
>>Let me get Matt B in on this discussion, but basically, option 4 is my 
>>initial feeling as Rob stated.
>>
>>One downside we saw with this approach is that we weren’t going to be able to 
>>take advantage of searchlight capabilities in details pages if everything was 
>>in native horizon.  Although, I suppose that could be done by using the 
>>hz-if-services directive [0] if horizon will allow searchlight optimized code 
>>to be in the horizon repo.
>>
>>[0] 
>>https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>>
>>-Travis
>>
>>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)"  wrote:
>>
>>I tried searching the meeting logs but couldn’t find where we discussed 
>> this in the Searchlight meeting. The conclusion at the time was option 4 
>> IIRC. The main thing is to make sure we get it done within one cycle, even 
>> if it isn’t default. this means searchlight-ui doesn’t have to carry some 
>> horrible workarounds and can just remove the code from their repo.
>>
>>Basically; start putting the code in the Horizon repo, and when its done, 
>> Searchlight-UI can remove it from their repo.
>>
>>Rob
>>
>>
>>> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
>>>
>>> Hi Searchlight and Horizon folks,
>>>
>>> I'd like to re-use the wonderful resource type code from
>>> searchlight-ui (in particular os-nova-servers right now but
>>> potentially others down the track) and was wondering whether you'd had
>>> any thoughts about how we might share that code? Off the top of my
>>> head I see a few options:
>>>
>>> 1. We depend on the searchlight-ui as a Horizon requirement; this is
>>> pretty unlikely to happen (depending on any optional panel means it's
>>> not really optional any longer ;-)
>>> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
>> terrible.
>>> 3. We move the code from searchlight-ui into a separate project that
>>> both Horizon and searchlight-ui depend upon; this could be made to
>>> work, though it's Yet Another Project.
>>> 4. We move the code from searchlight-ui into Horizon. I think this is
>>> most likely to work.
>>>
>>> What are your thoughts? Have I missed an option in this list that you
>>> think is a better one? Have I missed the mark in my analysis of the
>>> options I've presented?
>>>
>>>
>>>  Richard
>>>
>>> 
>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>__
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>__
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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][searchlight] Sharing resource type implementations

[McLellan, Steven]

I concur; option 4 is the only one makes sense to me and was what was intended 
originally. As long as we can do it in one fell swoop in one cyclle (preferably 
sooner than later) there should be no issues.




On 3/9/17, 8:35 AM, "Tripp, Travis S"  wrote:

>Let me get Matt B in on this discussion, but basically, option 4 is my initial 
>feeling as Rob stated.
>
>One downside we saw with this approach is that we weren’t going to be able to 
>take advantage of searchlight capabilities in details pages if everything was 
>in native horizon.  Although, I suppose that could be done by using the 
>hz-if-services directive [0] if horizon will allow searchlight optimized code 
>to be in the horizon repo.
>
>[0] 
>https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>
>-Travis
>
>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)"  wrote:
>
>I tried searching the meeting logs but couldn’t find where we discussed 
> this in the Searchlight meeting. The conclusion at the time was option 4 
> IIRC. The main thing is to make sure we get it done within one cycle, even if 
> it isn’t default. this means searchlight-ui doesn’t have to carry some 
> horrible workarounds and can just remove the code from their repo.
>
>Basically; start putting the code in the Horizon repo, and when its done, 
> Searchlight-UI can remove it from their repo.
>
>Rob
>
>
>> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
>> 
>> Hi Searchlight and Horizon folks,
>> 
>> I'd like to re-use the wonderful resource type code from
>> searchlight-ui (in particular os-nova-servers right now but
>> potentially others down the track) and was wondering whether you'd had
>> any thoughts about how we might share that code? Off the top of my
>> head I see a few options:
>> 
>> 1. We depend on the searchlight-ui as a Horizon requirement; this is
>> pretty unlikely to happen (depending on any optional panel means it's
>> not really optional any longer ;-)
>> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
> terrible.
>> 3. We move the code from searchlight-ui into a separate project that
>> both Horizon and searchlight-ui depend upon; this could be made to
>> work, though it's Yet Another Project.
>> 4. We move the code from searchlight-ui into Horizon. I think this is
>> most likely to work.
>> 
>> What are your thoughts? Have I missed an option in this list that you
>> think is a better one? Have I missed the mark in my analysis of the
>> options I've presented?
>> 
>> 
>>  Richard
>> 
>> 
> __
>> OpenStack Development Mailing 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][searchlight] Sharing resource type implementations

[Tripp, Travis S]

Let me get Matt B in on this discussion, but basically, option 4 is my initial 
feeling as Rob stated.

One downside we saw with this approach is that we weren’t going to be able to 
take advantage of searchlight capabilities in details pages if everything was 
in native horizon.  Although, I suppose that could be done by using the 
hz-if-services directive [0] if horizon will allow searchlight optimized code 
to be in the horizon repo.

[0] 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js

-Travis

On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)"  wrote:

I tried searching the meeting logs but couldn’t find where we discussed 
this in the Searchlight meeting. The conclusion at the time was option 4 IIRC. 
The main thing is to make sure we get it done within one cycle, even if it 
isn’t default. this means searchlight-ui doesn’t have to carry some horrible 
workarounds and can just remove the code from their repo.

Basically; start putting the code in the Horizon repo, and when its done, 
Searchlight-UI can remove it from their repo.

Rob


> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
> 
> Hi Searchlight and Horizon folks,
> 
> I'd like to re-use the wonderful resource type code from
> searchlight-ui (in particular os-nova-servers right now but
> potentially others down the track) and was wondering whether you'd had
> any thoughts about how we might share that code? Off the top of my
> head I see a few options:
> 
> 1. We depend on the searchlight-ui as a Horizon requirement; this is
> pretty unlikely to happen (depending on any optional panel means it's
> not really optional any longer ;-)
> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
terrible.
> 3. We move the code from searchlight-ui into a separate project that
> both Horizon and searchlight-ui depend upon; this could be made to
> work, though it's Yet Another Project.
> 4. We move the code from searchlight-ui into Horizon. I think this is
> most likely to work.
> 
> What are your thoughts? Have I missed an option in this list that you
> think is a better one? Have I missed the mark in my analysis of the
> options I've presented?
> 
> 
>  Richard
> 
> __
> OpenStack Development Mailing 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][searchlight] Sharing resource type implementations

[Rob Cresswell (rcresswe)]

I tried searching the meeting logs but couldn’t find where we discussed this in 
the Searchlight meeting. The conclusion at the time was option 4 IIRC. The main 
thing is to make sure we get it done within one cycle, even if it isn’t 
default. this means searchlight-ui doesn’t have to carry some horrible 
workarounds and can just remove the code from their repo.

Basically; start putting the code in the Horizon repo, and when its done, 
Searchlight-UI can remove it from their repo.

Rob


> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
> 
> Hi Searchlight and Horizon folks,
> 
> I'd like to re-use the wonderful resource type code from
> searchlight-ui (in particular os-nova-servers right now but
> potentially others down the track) and was wondering whether you'd had
> any thoughts about how we might share that code? Off the top of my
> head I see a few options:
> 
> 1. We depend on the searchlight-ui as a Horizon requirement; this is
> pretty unlikely to happen (depending on any optional panel means it's
> not really optional any longer ;-)
> 2. We copy the code from searchlight-ui into Horizon; this is pretty terrible.
> 3. We move the code from searchlight-ui into a separate project that
> both Horizon and searchlight-ui depend upon; this could be made to
> work, though it's Yet Another Project.
> 4. We move the code from searchlight-ui into Horizon. I think this is
> most likely to work.
> 
> What are your thoughts? Have I missed an option in this list that you
> think is a better one? Have I missed the mark in my analysis of the
> options I've presented?
> 
> 
>  Richard
> 
> __
> OpenStack Development Mailing 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