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

Reply via email to