Some comments:

• This has merged conflicts.
• Does it need an alembic upgrade for the db change?
• Does it need a significant rebase in light of #75? My thought here is that mapping a single Event to a single compose-id might not fit anymore (since a compose could conceivably be associated with multiple events?) I'm not clear on this. Let me know if my hunch is wrong.

Fixed the first two comment. I'v been looking into the changes introduced in PR#75, so far I'm not sure whether one event one compose id should work. Keep looking at it. @jkaluza any suggestion?

One event - one compose id can work. We can reuse the compose_id of the "extra" event which should be handled together with current event.

Let's continue with the example of RHSA-1 and RHSA-2 where RHSA-1 rebuild has been already handled by Freshmaker and RHSA-2 rebuild is going to be handled.

In that case, with the #75, we find out that we need to create ODCS compose for both RHSA-1 and RHSA-2. RHSA-1 will have the compose_id already set from previous rebuild and since ODCS can "renew" the compose, we can just ask ODCS to do that without changing the compose_id of RHSA-1.

For RHSA-2, we will ask for new compose.

What we are missing here is some reference from RHSA-2 to RHSA-1 and this is something we probably have to add. I originally didn't want to make the database schema complex, but it seems we will need to have dependencies between events to express that some event includes another event. @cqi could probably work on this part during next sprint?