Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

2017-03-26 Thread Richard Jones
I've completed this work. The two patches to migrate the code over and one additional bug fix are: Horizon: Copy os-nova-servers from searchlight ui https://review.openstack.org/#/c/444095/ Searchlight UI: Remove os-nova-servers resource type https://review.openstack.org/#/c/450067/

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

2017-03-23 Thread Richard Jones
t; 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

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

2017-03-13 Thread Richard Jones
rdj0...@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

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

2017-03-10 Thread Tripp, Travis S
iginal 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] [H

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

2017-03-09 Thread Richard Jones
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

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

2017-03-09 Thread McLellan, Steven
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]

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

2017-03-09 Thread Richard Jones
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

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

2017-03-09 Thread Richard Jones
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,

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

2017-03-09 Thread McLellan, Steven
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" wrote: >Let me get Matt B

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

2017-03-09 Thread Tripp, Travis S
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

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

2017-03-09 Thread Rob Cresswell (rcresswe)
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