JHipster control center migration plan

[deepu105]

With JHipster 7 we need to provide a migration path for JHCC. I'm not in favor of removing all the admin screens as it will force people to use JHCC which is a separate app thus complicating situations for simple monoliths, which is still the majority of the apps created with JHipster. It will also make infra more complicated for them, not everyone needs microservices or complicated registries and stuff. People shouldn't be forced to use JHCC just to get some useful admin screens (Those screens are pretty popular)

So let's try the below approach

1. Add a question while generation "Do you want to use the JHipster control center for administration? This will remove the admin screens from generated application" - This question can be a replacement for the current Registry question
2. If the answer is yes, enable JHCC via docker and configure it and remove Admin modules from generated code
3. If this approach works well, i.e, no one complains and from stats, if we see more people use this rather than skipping it then make it default and remove admin modules for JHipster 8

@jhipster/developers WDYT?

[PierreBesson]

That's a good idea, however, I would like to still generate the JHCC docker compose file for all apps, in case people want to test the feature.

[deepu105]

ya that should be fine, since we do that already for a lot of stuff

[avdev4j]

Just like @PierreBesson I think we should add JHCC Docker compose anyway. Ok for adding a new question instead of the registry one, I'll try to do it as I'm on the JHCC for the moment (If you are ok).

[pascalgrimaud]

OK for adding JHCC by default for all generated app -> so no question about adding JHCC, but instead, what do you think about an option for removing all Admin screen. It would be a light version of application.

OK for changing/removing the question about Registry: but if I remember well, the Registry is used to scale monolith app with Hazelcast -> we need to check this behaviour before changing the question, can you @avdev4j ?

[avdev4j]

what do you think about an option for removing all Admin screen. It would be a light version of application.

It could be a mixed question like "Do you want to remove admin features in favor of JHipster control center?

if I remember well, the Registry is used to scale monolith app with Hazelcast

We discussed about that with @PierreBesson this afternoon. It seems that this feature is not really used and we though to remove it totally. (Only keep discovery choice for microservices).

[gmarziou]

Regarding future migrations (after initial release), how do you plan to ensure compatibility between apps and JHCC?

Wouldn't it be nice if the JHCC could request the managed apps to check whether their management API version is compatible with the JHCC version?

[deepu105]

There are few things to consider here

1. Adding docker-compose for JHCC is fine as long as we don't make it a requirement by default for monolith applications. Monolith apps should still be able to run standalone. JHCC can be enabled for microservices IMO.
2. For admin screens the question can be independent or tied to JHCC, the only advantage of tieing it to JHCC is we can also configure/enable JHCC if someone chooses that and we will get better stats on the adoption of JHCC
3. For the registry with microservices, we should look at the stats and see how much it is being used if usage is low, IMO we could just remove the support and keep it only for microservices, this will also help with deprecation and migration

[avdev4j]

I've started something on a separated branch, this is what I suggest according to different elements we have here:

• Delete registry question when we choose monolith application
• add question to enable admin module (screens, yes by default)
• If no, remove admin screens and add default logging file config to allow JHCC to display it

WDYT?

[jdubois]

Hey,

I’m worried this will break all applications using the registry to scale. Then, the current system is easy but not perfect -> it’s nearly impossible to do this well at our level, and it’s not good to provide a production option which isn’t working 100% fine.

So this would remove a great option, and push the scalability burden to our users, but in the end it might be better.

I just want to make sure we are all aware of this before removing this, then I’m ok with it.

Julien

Le jeu. 30 juil. 2020 à 17:17, Avdev4J notifications@github.com a écrit :

I've started something on a separated branch, this is what I suggest according to different elements we have here:

• Delete registry question when we choose monolith application

• add question to enable admin module (screens, yes by default)

• If no, remove admin screens and add default logging file config to allow JHCC to display it

WDYT?

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/12167#issuecomment-666445901, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACNLI5KQ5TAG2I2CGZC4KLR6GFHVANCNFSM4PKNQABA .

-- Julien Dubois

Twitter: @juliendubois http://twitter.com/#!/juliendubois

[pascalgrimaud]

Delete registry question when we choose monolith application

After thinking about it, we can keep this question. We don't have any issue on this since months/years, so I suppose it works well or not used at all :)

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[DanielFran]

@jhipster/developers since JHCC and jhipster-registry are deprecated (nobody is maintaining those projects), I will close this issue. I anyone disagree let's discuss about it and reopen the issue