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