Disabling the "old" dashboard in the dashboard v2 pull request?

Disabling the "old" dashboard in the dashboard v2 pull request?

[Lenz Grimmer]

[-- Attachment #1.1: Type: text/plain, Size: 1123 bytes --]

Hi,

this question came up during our dashboard v2 sync call yesterday. The
first milestone for dashboard v2 is reaching feature parity with the
existing dashboard that is currently included in Luminous and master.

Once this point has been reached, we would like to submit our initial PR
against master for inclusion into the Mimic release.

Should this PR also take care of removing the existing dashboard code
and introduce dashboard v2 as the replacement? Currently, we develop the
code in parallel to the existing dashboard, using "dashboard_v2" as the
directory name and namespace in several places.

It would be much easier for us if we could start using the "dashboard"
namespace right away, rather than replacing that string in many places
after the PR was merged and we decided to retire the original dashboard.

Are there any objections/concerns about aiming at replacing the original
dashboard with the initial v2 submission?

Thanks,

Lenz

-- 
SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
GF:Felix Imendörffer,Jane Smithard,Graham Norton,HRB 21284 (AG Nürnberg)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Disabling the "old" dashboard in the dashboard v2 pull request?

[Joao Eduardo Luis]

On 02/14/2018 11:44 AM, Lenz Grimmer wrote:
> Are there any objections/concerns about aiming at replacing the original
> dashboard with the initial v2 submission?

I do think it makes sense to only have one dashboard, and to have v2 
replacing the current dashboard.

I do not think it needs to happen on the PR introducing `dashboard v2` 
to the ceph project though, especially because the act of "replacing" 
the dashboard (if it actually means a full removal) will entail a lot of 
deleted lines of code.

Instead, I'd suggest the initial PR to perform a

   `git mv dashboard dashboard_legacy`

or something similar, and introduce dashboard_v2 as the new dashboard. 
Once that's merged, then we can have a PR removing the current dashboard 
or whatever people are comfortable doing.

However, one thing comes to mind:

Given v2 is currently using the `dashboard_v2` namespace, which I'm 
guessing also means its own config-key namespace --different from 
`dashboard`--, we need to ensure that once v2 is renamed to `dashboard` 
it still plays nice with any and all things that have been set through 
config-key for the previous dashboard.

Maybe this is not a problem, but if the dashboard v2 code is currently 
using config-key to set options (I think at least the admin user/pass 
is, right?), I'd ensure that transitioning from the current dashboard to 
the new is as seamless as possible.


   -Joao

Re: Disabling the "old" dashboard in the dashboard v2 pull request?

[John Spray]

On Wed, Feb 14, 2018 at 2:40 PM, Joao Eduardo Luis <joao@suse.de> wrote:
> On 02/14/2018 11:44 AM, Lenz Grimmer wrote:
>>
>> Are there any objections/concerns about aiming at replacing the original
>> dashboard with the initial v2 submission?
>
>
> I do think it makes sense to only have one dashboard, and to have v2
> replacing the current dashboard.
>
> I do not think it needs to happen on the PR introducing `dashboard v2` to
> the ceph project though, especially because the act of "replacing" the
> dashboard (if it actually means a full removal) will entail a lot of deleted
> lines of code.
>
> Instead, I'd suggest the initial PR to perform a
>
>   `git mv dashboard dashboard_legacy`
>
> or something similar, and introduce dashboard_v2 as the new dashboard. Once
> that's merged, then we can have a PR removing the current dashboard or
> whatever people are comfortable doing.

Seems reasonable to me.  I'm happy for the "v1" dashboard code to go
away quickly, but yeah, there's no need to literally have all the
removal LOC in the same PR.

> However, one thing comes to mind:
>
> Given v2 is currently using the `dashboard_v2` namespace, which I'm guessing
> also means its own config-key namespace --different from `dashboard`--, we
> need to ensure that once v2 is renamed to `dashboard` it still plays nice
> with any and all things that have been set through config-key for the
> previous dashboard.
>
> Maybe this is not a problem, but if the dashboard v2 code is currently using
> config-key to set options (I think at least the admin user/pass is, right?),
> I'd ensure that transitioning from the current dashboard to the new is as
> seamless as possible.

Yep, this came up yesterday -- I'm expecting that the new dashboard
will just use the same setting names where it makes sense, and
magically inherit the configuration.

John

>
>
>   -Joao
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Disabling the "old" dashboard in the dashboard v2 pull request?

[Lenz Grimmer]

[-- Attachment #1.1: Type: text/plain, Size: 1287 bytes --]

Hi John,

On 02/14/2018 04:48 PM, John Spray wrote:

> On Wed, Feb 14, 2018 at 2:40 PM, Joao Eduardo Luis <joao@suse.de> 
> wrote:
> 
>> Instead, I'd suggest the initial PR to perform a
>> 
>> `git mv dashboard dashboard_legacy`
>> 
>> or something similar, and introduce dashboard_v2 as the new 
>> dashboard. Once that's merged, then we can have a PR removing the 
>> current dashboard or whatever people are comfortable doing.
> 
> Seems reasonable to me.  I'm happy for the "v1" dashboard code to go 
> away quickly, but yeah, there's no need to literally have all the 
> removal LOC in the same PR.

OK. We'll then perform the move of the original dashboard in our branch
and prepare a removal PR afterwards.

> Yep, this came up yesterday -- I'm expecting that the new dashboard 
> will just use the same setting names where it makes sense, and 
> magically inherit the configuration.

Yes, this is already the case. Dashboard v2 uses "server_addr",
"server_port" and "url_prefix" in the same way that the original
dashboard does it. Currently, we add "username", "password" and
"session-expire".

Lenz

-- 
SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
GF:Felix Imendörffer,Jane Smithard,Graham Norton,HRB 21284 (AG Nürnberg)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]