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

lookaside: Dehardcode some assumptions #170

Merged
merged 1 commit into from Oct 28, 2014
Merged

lookaside: Dehardcode some assumptions #170

merged 1 commit into from Oct 28, 2014

Conversation

bochecha
Copy link
Contributor

The current code assumes that:

  1. the message contains a 'md5sum' key, which is going to go away when
    we move to a different hash algorithm,
  2. it knows the path to the file on the lookaside cache, which is going
    to change very soon.

The solution this change implements is to simply take the path to the
uploaded source file entirely from the message.

However, the lookaside cache doesn't emit messages like this yet, so the
current code is kept as a fallback.

https://fedorahosted.org/rel-eng/ticket/5846

try:
path = msg['msg']['path']

except KeyError:
Copy link
Contributor

Choose a reason for hiding this comment

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

I really don't like the idea of try-than-fail.
How about just checking "'path' in msg['msg']"?

@puiterwijk
Copy link
Contributor

I'm not sure I prefer sending messages with just the path embedded completely: how about if people want to parse the filename or hashsum etc? I'd rather avoid having to tell them "just parse the path" if we have the information available when sending the message.

I think a better way might be to replace the md5hash thing by something like
{
hash: 'XXXXX',
type: 'md5',
}

This way, we could switch the hash algorithm without any trouble, and we would still get the information everywhere.

@bochecha
Copy link
Contributor Author

I wasn't thinking of removing the informations currently in the message. People and tools trying to obtain informations like the checksum or the file name won't ever have to parse the path, they will continue to get them from the messages.

What I'm doing here is remove broken assumptions in a particular consumer (this project), not remove data from the messages emitted.

What you suggest (which is what I was already going to do on the emitter side actually) only helps for one assumption: the hash type.

However, there is a second assumption, which is just as broken: that the path to the file is made of "{prefix}/{name}/{filename}/{md5sum}/{filename}".

This second assumption is only true now, but it will be false when we finish the migration to another hash than MD5. (the hash type will be part of the directory structure, like so: "{prefix}/{name}/{filename}/{hash_type}/{checksum}/{filename}").

Realistically, only the lookaside server truely knows its path structure, consumers should not assume they can recreate from what they think are its components.

@bochecha
Copy link
Contributor Author

@pypingou just made an interesting observation: the fallback code can never ever be eliminated as we need to be able to parse old messages.

So, as much as I prefer the « try new then fallback on the old in except » code (« it's easier to ask for forgiveness than permission »), it means that if we ever change again the messages in the future, we're going to have to deal with multiple exception levels.

In such a case, asking for permission does make much more sense, so here's an updated pull request which does just that. 😃

@puiterwijk
Copy link
Contributor

Thanks for fixing that, and for re-assuring me that the checksum and filename etc attributes aren't removed.
In that case, I'm 👍 to this change.

The current code assumes that:

1. the message contains a 'md5sum' key, which is going to go away when
   we move to a different hash algorithm,
2. it knows the path to the file on the lookaside cache, which is going
   to change very soon.

The solution this change implements is to simply take the path to the
uploaded source file entirely from the message.

However, the lookaside cache doesn't emit messages like this yet, so the
current code is kept as a fallback.

https://fedorahosted.org/rel-eng/ticket/5846
@bochecha
Copy link
Contributor Author

Heh, turns out I broke the tests with a stupid syntax error. 😄

Fixed now (I just added a missing :), let's wait for Travis to finish before merging.

@ralphbean
Copy link
Contributor

if we ever change again the messages in the future, we're going to have to deal with multiple exception levels.

Yeah, this is already the case with some of the other processors. ;)

@ralphbean
Copy link
Contributor

👍 from me to merge. Thanks @bochecha, @puiterwijk, and @pypingou.

bochecha pushed a commit that referenced this pull request Oct 28, 2014
lookaside: Dehardcode some assumptions
@bochecha bochecha merged commit 526d283 into fedora-infra:develop Oct 28, 2014
@bochecha bochecha deleted the feature/lookasidemsgs branch October 28, 2014 13:38
henrysher pushed a commit to henrysher/fedora-infra-ansible that referenced this pull request Feb 9, 2015
This is the counterpart of this change:

fedora-infra/fedmsg_meta_fedora_infrastructure#170

Now that is has been deployed, we can start emitting the new messages.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants