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

feat(notifications): add NotificationAgent extension point #962

Merged
merged 1 commit into from
Jul 15, 2020

Conversation

danielpeach
Copy link
Contributor

Adds NotificationAgent extension point.

Copy link
Contributor

@claymccoy claymccoy left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -30,8 +31,7 @@ abstract class AbstractEventNotificationAgent implements EventListener {
@Autowired
Front50Service front50Service

@Autowired(required = false)
protected ObjectMapper mapper
protected ObjectMapper mapper = EchoObjectMapper.getInstance()
Copy link
Contributor

Choose a reason for hiding this comment

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

Out of curiosity, why was this change needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I end up wiring up each ExtensionNotificationAgent manually in EchoCoreConfig (tricky to map an arbitrary number of NotificationAgent beans into ExtensionNotificationAgent beans). I was passing the mapper through, but noticed that as of #790, most of the object mappers in Echo come from EchoObjectMapper and figured I'd save myself the trouble.

As for the autowired Front50Service and spinnakerUrl... they actually aren't used.

Copy link
Member

Choose a reason for hiding this comment

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

As for the autowired Front50Service and spinnakerUrl... they actually aren't used.

Should we remove?

String application,
Event event,
Map<String, String> config,
String status);
Copy link
Contributor

Choose a reason for hiding this comment

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

Are there existing typed and constrained status values for pipelines and orchestrations rather than a String. I'm not too worried about enums when it is a platform concern.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The method signature is coming from this abstract class: https://github.com/spinnaker/echo/blob/master/echo-notifications/src/main/groovy/com/netflix/spinnaker/echo/notification/AbstractEventNotificationAgent.groovy#L139.

This change would become a lot larger if I refactored that method now, but I think it would be nice to come back and give more concrete types for a lot of these parameters.

Copy link
Member

Choose a reason for hiding this comment

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

Despite reading the method docs, I'm still not clear on the boundary between notificationConfig and config.

import com.netflix.spinnaker.echo.api.events.NotificationAgent
import org.pf4j.Extension

@Extension
Copy link
Contributor

Choose a reason for hiding this comment

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

This is just for testing right? Should it be in test rather than src? And maybe named something that denotes that it is for the test like TestNotificationAgentExtension?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just following the pattern for the other test extension points in this project (https://github.com/spinnaker/echo/tree/master/echo-plugins-test/src/main/kotlin/com/netflix/spinnaker/echo/plugins)


/** A NotificationAgent handles user-configured pipeline notifications. */
@Alpha
public interface NotificationAgent extends SpinnakerExtensionPoint {
Copy link
Member

Choose a reason for hiding this comment

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

Would like to see @Nonnull etc on parameters and return types (or @NonnullByDefault etc)

String application,
Event event,
Map<String, String> config,
String status);
Copy link
Member

Choose a reason for hiding this comment

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

Despite reading the method docs, I'm still not clear on the boundary between notificationConfig and config.

@@ -30,8 +31,7 @@ abstract class AbstractEventNotificationAgent implements EventListener {
@Autowired
Front50Service front50Service

@Autowired(required = false)
protected ObjectMapper mapper
protected ObjectMapper mapper = EchoObjectMapper.getInstance()
Copy link
Member

Choose a reason for hiding this comment

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

As for the autowired Front50Service and spinnakerUrl... they actually aren't used.

Should we remove?

Copy link
Contributor

@jonsie jonsie left a comment

Choose a reason for hiding this comment

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

@Nonnull annotations on parameters and return types in NotificationAgent would be nice to see. Also looks like a few conflicts need to be resolved. Otherwise, this is really cool and LGTM.

@danielpeach danielpeach merged commit 50c86c3 into spinnaker:master Jul 15, 2020
@danielpeach danielpeach deleted the dp/notification-agent branch July 15, 2020 19:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants