<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>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. <br>
<br>
-------- Original message --------<br>
From: Richard Jones <r1chardj0n3s@gmail.com> <br>
Date: 3/9/17 21:13 (GMT-06:00) <br>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
<br>
Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations
<br>
<br>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hey folks,<br>
<br>
Another potential issue is that the searchlight module structure and<br>
Horizon's module structure are different in a couple of respects. I<br>
could just retain the module structure from searchlight<br>
('resources.os-nova-servers') or, preferably, I could rename those<br>
modules to match the Horizon structure more closely<br>
('horizon.app.resources.os-nova-servers') or more strictly<br>
('horizon.app.core.instances').<br>
<br>
As far as I can tell none of the module names are referenced directly<br>
outside of the module (apart from resources.module.js of course) so<br>
moving the modules shouldn't affect any existing usage in searchlight<br>
ui.<br>
<br>
We could bikeshed this for ages, so if I could just get Rob and Steve<br>
to wrestle over it or something, that'd be good. Rob's pretty scrappy.<br>
<br>
<br>
Richard<br>
<br>
<br>
On 10 March 2017 at 09:56, Richard Jones <r1chardj0n3s@gmail.com> wrote:<br>
> OK, I will work on a plan that migrates the code into Horizon, thanks everyone!<br>
><br>
> Travis, can the searchlight details page stuff be done through<br>
> extending the base resource type in Horizon? If not, is that perhaps a<br>
> limitation of the extensible service?<br>
><br>
><br>
> Richard<br>
><br>
><br>
> On 10 March 2017 at 02:20, McLellan, Steven <steve.mclellan@hpe.com> wrote:<br>
>> 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.<br>
>><br>
>><br>
>><br>
>><br>
>> On 3/9/17, 8:35 AM, "Tripp, Travis S" <travis.tripp@hpe.com> wrote:<br>
>><br>
>>>Let me get Matt B in on this discussion, but basically, option 4 is my initial feeling as Rob stated.<br>
>>><br>
>>>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.<br>
>>><br>
>>>[0] <a href="https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js">
https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js</a><br>
>>><br>
>>>-Travis<br>
>>><br>
>>>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)" <rcresswe@cisco.com> wrote:<br>
>>><br>
>>> 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.<br>
>>><br>
>>> Basically; start putting the code in the Horizon repo, and when its done, Searchlight-UI can remove it from their repo.<br>
>>><br>
>>> Rob<br>
>>><br>
>>><br>
>>> > On 9 Mar 2017, at 04:22, Richard Jones <r1chardj0n3s@gmail.com> wrote:<br>
>>> ><br>
>>> > Hi Searchlight and Horizon folks,<br>
>>> ><br>
>>> > I'd like to re-use the wonderful resource type code from<br>
>>> > searchlight-ui (in particular os-nova-servers right now but<br>
>>> > potentially others down the track) and was wondering whether you'd had<br>
>>> > any thoughts about how we might share that code? Off the top of my<br>
>>> > head I see a few options:<br>
>>> ><br>
>>> > 1. We depend on the searchlight-ui as a Horizon requirement; this is<br>
>>> > pretty unlikely to happen (depending on any optional panel means it's<br>
>>> > not really optional any longer ;-)<br>
>>> > 2. We copy the code from searchlight-ui into Horizon; this is pretty terrible.<br>
>>> > 3. We move the code from searchlight-ui into a separate project that<br>
>>> > both Horizon and searchlight-ui depend upon; this could be made to<br>
>>> > work, though it's Yet Another Project.<br>
>>> > 4. We move the code from searchlight-ui into Horizon. I think this is<br>
>>> > most likely to work.<br>
>>> ><br>
>>> > What are your thoughts? Have I missed an option in this list that you<br>
>>> > think is a better one? Have I missed the mark in my analysis of the<br>
>>> > options I've presented?<br>
>>> ><br>
>>> ><br>
>>> > Richard<br>
>>> ><br>
>>> > __________________________________________________________________________<br>
>>> > OpenStack Development Mailing List (not for usage questions)<br>
>>> > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
>>>__________________________________________________________________________<br>
>>>OpenStack Development Mailing List (not for usage questions)<br>
>>>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font>
</body>
</html>