Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rds: make RouteConfigProvider unique_ptr #3967

Merged
merged 7 commits into from
Jul 31, 2018

Conversation

lizan
Copy link
Member

@lizan lizan commented Jul 27, 2018

Signed-off-by: Lizan Zhou zlizan@google.com

Description:
RouteConfigProvider is no longer shared ownership, make it unique_ptr.
Follow up of #3960.

Risk Level: Low
Testing: unit test, integration tests
Docs Changes: N/A
Release Notes: N/A

Signed-off-by: Lizan Zhou <zlizan@google.com>
Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, awesome cleanup.

* dynamic (RDS) RouteConfigProviders currently loaded.
*/
virtual std::vector<RouteConfigProviderSharedPtr> getRdsRouteConfigProviders() PURE;
virtual std::vector<RouteConfigProvider*> getRdsRouteConfigProviders() PURE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Can we potentially return std::reference_wrappers here and below? Since these can never be null it would be a bit cleaner.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is better to return list of RdsSubscription which is what the manager is holding. This function is only used for dumping RDS config. RdsSubscription is good enough

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RdsSubscription is not implementing the RouteConfigProvider interface and there is no corresponding interface.

Do we really need these two methods (get{Rds,Static}RouteConfigProviders) in RouteConfigProviderManager interface? It is only used in rds_impl_test and RouteConfigProviderManagerImpl itself to dump config. cc @jsedgwick @htuch

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't recall the entire history here. It's possible the methods are not needed anymore with iterative changes. Feel free to remove them if it's possible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, remove any methods from the interface that don't have external callers.

@mattklein123 mattklein123 self-assigned this Jul 30, 2018
- add more tests
- make dump config public

Signed-off-by: Lizan Zhou <zlizan@google.com>
}
TimestampUtil::systemClockToTimestamp(subscription->last_updated_,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if subscription did not receive its first config (config_info_ is empty case), I think we don't need to create a config_dump entry.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did this change intentionally as you want to know the RDS config is delivered but not received route from RDS. And it is easier to track how many RDS subscription Envoy has from config dump, thoughs?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, it will be useful to know there is such subscriptions that did not even receive the first responses.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure last_updated_ actually points to something meaningful here? Is it going to be 0 or the equivalent epoch? I guess I'm asking what will this actually output. :)

My preference would actually be to do this change in a follow up as a discrete change, and we should be consistent across all the xDS? Thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, prefer behavioral changes like this to be split out.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be initialized when the subscription started:

last_updated_(factory_context.systemTimeSource().currentTime()) {

Sure, I will make a separate PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reverted this part for this PR.

route_config_provider_manager_->getRdsRouteConfigProviders();
EXPECT_EQ(2UL, configured_providers.size());
EXPECT_EQ(2UL,
route_config_provider_manager_->dumpRouteConfigs()->dynamic_route_configs().size());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We only have one subscription, how can we have 2 dynamic route configs? Should it be 1?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have two RDS config, rds_ and rds2, they are keyed by full Rds message, not only the name, they have different cluster.

MOCK_METHOD2(createStaticRouteConfigProvider,
RouteConfigProviderPtr(const envoy::api::v2::RouteConfiguration& route_config,
Server::Configuration::FactoryContext& factory_context));
MOCK_METHOD0(getRdsRouteConfigProviders, std::vector<RouteConfigProvider*>());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why these two functions are still in the mock? I thought they are removed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

qiwzhang
qiwzhang previously approved these changes Jul 31, 2018
Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome cleanup, thanks. One question.

}
TimestampUtil::systemClockToTimestamp(subscription->last_updated_,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure last_updated_ actually points to something meaningful here? Is it going to be 0 or the equivalent epoch? I guess I'm asking what will this actually output. :)

My preference would actually be to do this change in a follow up as a discrete change, and we should be consistent across all the xDS? Thoughts?

Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM modulo comment.

}
TimestampUtil::systemClockToTimestamp(subscription->last_updated_,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, prefer behavioral changes like this to be split out.

Signed-off-by: Lizan Zhou <zlizan@google.com>
htuch
htuch previously approved these changes Jul 31, 2018
@mattklein123
Copy link
Member

@lizan LGTM but needs format fix.

lizan added 2 commits July 31, 2018 09:52
Signed-off-by: Lizan Zhou <zlizan@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants