So far all the events have the Event suffix in the name. This makes the name unique and it's clear what is event and what is its handler.

I'm thinking if manual=True should be set here or not. it probably makes sense to mark this event as manual, because it is not result of any UMB message. In the same time, the manual=True won't be most likely use in the handler of this event... On the other side setting manual=True will also not break anything.

I think you could also add dummy test for this handler in ./tests/handlers/internal/ which just tests the can_handle method.

@jkaluza Thanks for review. PR is updated.

PR is rebased onto master. A test is added for can_handle. In addition, also add the event parser and register it into conf.parsers.

How about remove "Freshmaker" from its name?

Wouldn't this create an error when running freshmaker?
Can we just add after the comment "pass"?

Wouldn't this create an error when running freshmaker?

No. It is valid syntax.

How about remove "Freshmaker" from its name?

Some other events have names with prefix Freshmaker. I guess that could mean the event is emitted by freshmaker itself for clarity. Anyway, IMO, I would prefer not to remove Freshmaker from this event name.

Looks good to me. +1
Maybe let's wait for Jan's new review too.

hm, can we keep the params consistent with the design doc?

rebuild_images => container_images
reuse_event_id => freshmaker_event_id

This will make it easier for later use in views since these names are also shared by the existing manual build.

^ I agree with qwan here. Otherwise +1.

Argument names are updated.

This is not updated yet after the name change

@qwan Fixed.

:thumbsup:

Let's merge this.