fedmsg hotfix

[Michal Novotny]

Hello, I will deploy fedmsg hotfix tomorrow at 7:30am UTC. I am very sorry
for the inconvenience.

clime

[Pavel Raiskup]

On Tuesday, January 24, 2017 12:58:00 PM CET Michal Novotny wrote:
>  Hello, I will deploy fedmsg hotfix tomorrow at 7:30am UTC. I am very
> sorry
>  for the inconvenience. 
I'm very sorry too.  I failed with testing this against fedmsg because I was
even unable to connect to fedmsg.  And I did not realize that this could get to
production so quickly, I was kind of believed staging environment.

I'd like to propose follow-up patch for Michal's hot-fix;  to unify the
code so only one announce_job() (in super-class) is available.
I probably see reason why the announce_job() was added to FedMsg
sub-class, but we can still pretty easily fix the general "API" and fix
Red Hat's copr so it accepts different format of message (without touching
FedMsg's api anymore) ... rather than have two announce_job() implementations.

I'm just curious what happened with '{who}' part of the message?

But, ugh, I'm bit afraid of fixing the code now without being able to test
properly ... could I get a testing access to fedmsg so I can avoid similar
issues in future?

Thanks,
Pavel

[Pierre-Yves Chibon]

On Tue, Jan 24, 2017 at 03:08:52PM +0100, Pavel Raiskup wrote:
>  On Tuesday, January 24, 2017 12:58:00 PM CET Michal Novotny wrote:
>  > Hello, I will deploy fedmsg hotfix tomorrow at 7:30am UTC. I am very sorry
>  > for the inconvenience.
>  
>  I'm very sorry too.  I failed with testing this against fedmsg because I was
>  even unable to connect to fedmsg.  
Well, you can easily run you own/local fedmsg bus. All it takes is pretty much
running fedmsg-relay in one terminal and fedmsg-tail (to watch the bus) in
another terminal.
You might want to stop listening to the production bus by editing
/etc/fedmsg.d/endpoints.py to reduce the noise on fedmst-tail.

>  And I did not realize that this could get to
>  production so quickly, I was kind of believed staging environment. 
Does copr have a stg environment?
 
>  I'd like to propose follow-up patch for Michal's hot-fix;  to
> unify the
>  code so only one announce_job() (in super-class) is available.
>  I probably see reason why the announce_job() was added to FedMsg
>  sub-class, but we can still pretty easily fix the general "API" and fix
>  Red Hat's copr so it accepts different format of message (without touching
>  FedMsg's api anymore) ... rather than have two announce_job() implementations.
>  
>  I'm just curious what happened with '{who}' part of the message?
>  
>  But, ugh, I'm bit afraid of fixing the code now without being able to test
>  properly ... could I get a testing access to fedmsg so I can avoid similar
>  issues in future? 
There isn't really any testing access, we have two bus, the one in prod and the
one in stg but as copr doesn't (iirc) have a stg instance, it doesn't have
access to the stg bus.
The easiest really is to just run a local fedmsg-relay and see which messages
the app sends.

After that it's a matter of adjusting fedmsg_meta to process them.


Pierre