[openstack-dev] [Horizon][searchlight] Sharing resource type implementations
Richard Jones
r1chardj0n3s at gmail.com
Thu Mar 23 06:02:09 UTC 2017
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 <r1chardj0n3s at 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.tripp at 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" <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
>>
>>
>> __________________________________________________________________________
>> 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