[openstack-dev] [Horizon][searchlight] Sharing resource type implementations
Tripp, Travis S
travis.tripp at hpe.com
Fri Mar 10 17:34:20 UTC 2017
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" <r1chardj0n3s at 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.mclellan at 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 <r1chardj0n3s at gmail.com>
> Date: 3/9/17 21:13 (GMT-06:00)
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at 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 <r1chardj0n3s at 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.mclellan at 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.tripp at 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)" <rcresswe at 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 <r1chardj0n3s at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list