switch to info level

[lonre]

What's the purpose of this PR

XXXXX

Which issue(s) this PR fixes:

Fixes #

Brief changelog

XXXXX

Follow this checklist to help us incorporate your contribution quickly and easily:

• Read the Contributing Guide before making this pull request.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit tests to verify the code.
• Run mvn clean test to make sure this pull request doesn't break anything.
• Update the CHANGES log.

[lonre]

@nobodyiam can we make this change?

since k8s is popular today, meta service is optional

[codecov-commenter]

Codecov Report

Merging #3884 (8601336) into master (2e2919d) will decrease coverage by 0.04%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #3884      +/-   ##
============================================
- Coverage     50.14%   50.10%   -0.05%     
+ Complexity     2479     2478       -1     
============================================
  Files           485      485              
  Lines         14984    14984              
  Branches       1532     1532              
============================================
- Hits           7514     7508       -6     
- Misses         6938     6942       +4     
- Partials        532      534       +2     

Impacted Files	Coverage Δ
...amework/apollo/internals/ConfigServiceLocator.java	87.27% <100.00%> (ø)
...mework/apollo/portal/component/PortalSettings.java	57.81% <0.00%> (-7.82%)	⬇️
.../apollo/internals/RemoteConfigLongPollService.java	77.71% <0.00%> (-0.61%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2e2919d...8601336. Read the comment docs.

[nobodyiam]

I think we can either change it to info or leave it as warning, but what's the problem to leave to as warning?

[lonre]

I think we can either change it to info or leave it as warning, but what's the problem to leave to as warning?

It always show warning when starting project, it is annoying

[nobodyiam]

since k8s is popular today, meta service is optional

Currently we provide 2 ways to deploy apollo in k8s, one is based on native k8s service discovery and another is based on eureka service discovery. Both ways still use meta service to locate the config services, which avoids the use of specifying config services directly and we believe this is the preferred way.

What's the use in your side?

[lonre]

since k8s is popular today, meta service is optional

Currently we provide 2 ways to deploy apollo in k8s, one is based on native k8s service discovery and another is based on eureka service discovery. Both ways still use meta service to locate the config services, which avoids the use of specifying config services directly and we believe this is the preferred way.

What's the use in your side?

In k8s, maybe it is better to use config-service directly, we can define one k8s service url as config-service, this k8s service can point to multiple real config service pod, maybe there is no need to use meta service. the k8s service is better? @nobodyiam

[nobodyiam]

since k8s is popular today, meta service is optional

Currently we provide 2 ways to deploy apollo in k8s, one is based on native k8s service discovery and another is based on eureka service discovery. Both ways still use meta service to locate the config services, which avoids the use of specifying config services directly and we believe this is the preferred way.
What's the use in your side?

In k8s, maybe it is better to use config-service directly, we can define one k8s service url as config-service, this k8s service can point to multiple real config service pod, maybe there is no need to use meta service. the k8s service is better? @nobodyiam

You are right, and for native k8s service discovery, the meta service will return the service which point to multiple real config service pods. It's the same effect as you specify config service directly but we think it's better to keep the pattern with meta services, you may refer #3054 for more information.

[lonre]

since k8s is popular today, meta service is optional

Currently we provide 2 ways to deploy apollo in k8s, one is based on native k8s service discovery and another is based on eureka service discovery. Both ways still use meta service to locate the config services, which avoids the use of specifying config services directly and we believe this is the preferred way.
What's the use in your side?

In k8s, maybe it is better to use config-service directly, we can define one k8s service url as config-service, this k8s service can point to multiple real config service pod, maybe there is no need to use meta service. the k8s service is better? @nobodyiam

You are right, and for native k8s service discovery, the meta service will return the service which point to multiple real config service pods. It's the same effect as you specify config service directly but we think it's better to keep the pattern with meta services, you may refer #3054 for more information.

Thanks for the link, it seems that in order to reduce the impact to the client and portal, so the meta service kept.

But IMO, for the client side, since we can specify config service url separately, it is much better, because we can use the k8s native service discovery, and the client do not need to start new thread to refresh config service.

@nobodyiam

[nobodyiam]

I think your comment make sense in the context of using kubernetes native service discovery. As 1.9.0 is under release vote, let's hold this pr for a little longer.

[nobodyiam]

LGTM