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

Add CustomButton event emiter #17764

Merged
merged 1 commit into from
Aug 20, 2018
Merged

Conversation

tumido
Copy link
Member

@tumido tumido commented Jul 26, 2018

When CustomButton is invoked, let's create a CustomEvent logging the activity.

Tracked data:

  • requester (user, group, tenant)
  • target (id, class)
  • source (UI or API - currently UI only)
  • event type (button.trigger.start)
  • full data (task args, entry point for automate)

Design: GDoc
RFE: BUGZILLA 1511126
Related: ManageIQ/manageiq-ui-classic#4363

@tumido
Copy link
Member Author

tumido commented Jul 26, 2018

@miq-bot add_label events, enhancement, automate

@tumido
Copy link
Member Author

tumido commented Jul 26, 2018

@gmcculloug , @Fryguy can you please review and let me know if this would suit the needs of this RFE? Is CustomEvent the right record type or should I use rather MiqEvent?

@bronaghs
Copy link

@miq-bot assign @gmcculloug

@tumido
Copy link
Member Author

tumido commented Jul 26, 2018

cc @skateman

:args => args,
:automate_entry_point => resource_action.ae_path
}
)
Copy link
Member

Choose a reason for hiding this comment

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

The CustomEvent model and its parent EventStream is a little bit unclear for me. In the UI we're using EventMixin#has_events? for enabling/disabling timeline buttons for a given entity. This invokes an event_where_clause on the entity that doesn't always operate with the target. For example for providers, it's checking the ems_id that this method doesn't even set. For VMs it's a little trickier, depending on the event type, it checks the vm_or_template_id or the target.

So this is a little confusing ... the ugly solution would be to edit all the event_where_clause methods, but I really hope 🙏 🙏 there's a better solution for this.

Copy link
Member

Choose a reason for hiding this comment

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

ping @bronaghs as @tumido is on PTO and you will probably know who should I ask 😉

Copy link
Member

Choose a reason for hiding this comment

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

oh, probably @gmcculloug

Copy link
Member

Choose a reason for hiding this comment

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

These events are not intended to be displayed on the timelime. That might be the good and bad news. I'll updated the associated doc but the idea is to have a link from the item summary page that will show a list-view of these events.

As far as the modeling I would recommend creating a new event model that is derived from EventStream instead of using the CustomEvent model. Maybe CustomButtonEvent < EventStream

As this will be shared between a number of different models it would make sense to do most of this work in a new mixin.

cc @lfu

Copy link
Member

Choose a reason for hiding this comment

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

@dclarizio pinging you here as you asked me to do timelines 😉

@gmcculloug gmcculloug requested a review from lfu August 2, 2018 13:23
@dclarizio
Copy link

@gmcculloug I seem to recall that this was mainly for debugging purposes and that we had considered just logging these custom button events. Can we just do that? (Not sure which log, but that's just a detail 😄 )

@tumido
Copy link
Member Author

tumido commented Aug 7, 2018

@gmcculloug can you please give me any resolution on this? How this RFE should be implemented?

  1. Simple log entry, as @dclarizio suggests
  2. Add a new model CustomButtonEvent and push the event records in there

Both ways are fine with me, I just need to know which path I should follow.

@tumido
Copy link
Member Author

tumido commented Aug 7, 2018

Unless it is decided otherwise, I've added the CustomButtonEvent model and updated the emitter to use it.

@lfu
Copy link
Member

lfu commented Aug 7, 2018

@gmcculloug If the purpose of this PR is to keep track of what custom buttons have been executed for a VM, maybe we can use AuditEvent which would create an audit_event object in VMDB and leave a log message in audit.log.

These issues should be addressed If we continue with CustomButtonEvent model.

  • event_type is the identifier of an EventStream object which does not change once created for all other EventStream objects.
    :event_type => 'custom_button_event' would set all CustomButtonEvent objects with the same event_type. And seems it would be changed later to specify what playbook was launched.

  • CustomButtonEvent should be added into automate explorer under /System/Event.

@tumido
Copy link
Member Author

tumido commented Aug 9, 2018

@lfu, can you please explain me the first bullet point? I'm not sure what you're asking me to do. As the design document states this PR should cover the first step - catching the events.

To the second bullet point: I'm aware of this need, however I've decided to wait until we have a green light on the CustomButtomEvent model.

:message => 'Custom button launched',
:source => source,
:target_id => target.id,
:target_type => target.type,
Copy link
Member

Choose a reason for hiding this comment

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

The above two lines can be just:

      :target      => target,

:source => 'UI',
:target_id => vm.id,
:type => 'CustomButtonEvent',
:event_type => 'custom_button_event',
Copy link
Member

Choose a reason for hiding this comment

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

event_type is supposed to specify a uniq ID for the event instance. Now that we have a new class CustomButtonEvent, the event_type value seems redundant in this case.

We need to name event_type better for each CustomButtonEvent instance.

Copy link
Member Author

Choose a reason for hiding this comment

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

@lfu do you have any suggestions what we can do with that? I can't find any valid and reasonable information which would suit here and is available at the button invocation.

expect(CustomButtonEvent.count).to eq(1)
expect(CustomButtonEvent.first).to have_attributes(
:source => 'UI',
:target_id => vm.id,
Copy link
Member

Choose a reason for hiding this comment

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

We can also test :target_type here.

@lfu
Copy link
Member

lfu commented Aug 9, 2018

@tumido The first bullet point is more of a comment regarding the design doc.

Usually event_type is a uniq ID of the event instance. But in this case they would be the same for all CustomButtonEvent instances. And the doc mentioned event_type value would be changed later by automate.

@gmcculloug
Copy link
Member

The purpose of this is to show a history of custom button actions for a resource. It was discussed and we do not want to build this off of the AuditEvent. Visually the Summary screen for the resource should have a link that takes you to a list-view showing the basic event properties for that resource.

:target_id => vm.id,
:target_type => 'VmOrTemplate',
:type => 'CustomButtonEvent',
:event_type => 'custom_button_event',
Copy link
Member

Choose a reason for hiding this comment

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

event_type has changed.

@tumido
Copy link
Member Author

tumido commented Aug 14, 2018

@gmcculloug We've been discussing the event_type with @lfu here and on the automate PR ManageIQ/manageiq-content#398 a bit. What's your position on that?

We already have the event class named CustomButtonEvent and the event type should represent on kind of the event in that stream, do it seem redundant to have it named the same. Also in automate it looks silly to have System/Event/CustomButtonEvent with UI.class and custom_button_event in it.

These are the option we have:

  1. Keep custom_button_event
  2. Something else (my suggestion is button_triggered since this particular event is logging the invocation of a button)

What do you think?

@gmcculloug
Copy link
Member

@lfu I would not get caught up in the assumption that the design doc needs to be followed exactly. It was a first pass to get ideas written out for discussion and scoping. For example, automate changing the event_type is a potential future feature. It is not in scope for this initial implementations.

I would agree that the redundant naming does not make a lot of sense and like the idea of using it to identify that the event is for a "on_launch" or "triggered" action.

Maybe we following something like the OpenStack naming which has *.start and *.end events to support the possibility of having ending events later.

button.trigger.start for now and it could have a corresponding button.trigger.end in the future.

@lfu
Copy link
Member

lfu commented Aug 16, 2018

button.trigger.start is a good name 👍

@miq-bot
Copy link
Member

miq-bot commented Aug 16, 2018

Checked commit tumido@b9cc5a6 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
3 files checked, 0 offenses detected
Everything looks fine. 👍

Copy link
Member

@gmcculloug gmcculloug left a comment

Choose a reason for hiding this comment

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

@tumido This PR looks good. Are you planning to add an association between the resources and this new event class? Would that happen in a separate PR?

@tumido
Copy link
Member Author

tumido commented Aug 17, 2018

@gmcculloug, sorry I was not planning to do that. I'm actually not sure what's the complete list of resources to associate the events with. Since I'm on PTO next week, can you please delegate that to someone else? Thanks!

@gmcculloug
Copy link
Member

@tumido Thanks. I will discuss remaining backend work with @lfu.

@gmcculloug
Copy link
Member

Talk to @lfu. She is going to continue the backend work in another PR. 👍

@gmcculloug gmcculloug merged commit c08b60e into ManageIQ:master Aug 20, 2018
@gmcculloug gmcculloug added this to the Sprint 93 Ending Aug 27, 2018 milestone Aug 20, 2018
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.

7 participants