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

Support for notifications in Mistral #1516

Merged
merged 9 commits into from May 26, 2015
Merged

Conversation

Kami
Copy link
Member

@Kami Kami commented May 24, 2015

This pull request adds support for notifications in Mistral workflows. It works in exactly the same way it works in the action runner.

I also noticed mistral-v1 runner is still registered even though we removed the Python module quite a while ago. I removed the runnersregistrar entry and all the references to it.

Note: This PR is based on #1514.

Related PRs

Kami added 9 commits May 24, 2015 20:47
… string and

not a dict result.

Note: This only happens in some edge rare edge cases.
…h is

disabled and continue with the request.

If the auth is indeed enabled, but auth API is unavailable, request to the API
will fail with invalid credentials error.
Remove mistral-v1 runner from the available runner script and remove all the
references to it.
except requests.exceptions.ConnectionError as e:
LOG.warn('API server is not available, skipping authentication.')
LOG.exception(e)
return client
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this intentional? Why does this return a client?

EDIT: This is the case when auth is required cos user supplied username and password. If Auth API server is not available, we should bubble the exception all the way up?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, we still want to continue.

I was thinking about it, but bubbling the exception up instead of continuing makes it harder to test and switch between servers which have auth enabled and disabled.

Copy link
Contributor

Choose a reason for hiding this comment

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

I do see it. As a client, we have no idea if server is auth enabled or not. It looks like there needs to a handshake at the start to discover server capabilities. I am not proposing we do it now but it looks like we might soon need it.

Copy link
Contributor

Choose a reason for hiding this comment

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

That said, I am curious how would client.* operations would work if auth server died but auth is enabled in server. We'd keep getting 401s back?

Copy link
Member Author

Choose a reason for hiding this comment

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

It doesn't matter as long as you have a valid token. If the auth is down, but you have a valid token, all the operations will still work until the token expires.

@lakshmi-kannan
Copy link
Contributor

LGTM

Kami added a commit that referenced this pull request May 26, 2015
@Kami Kami merged commit 2211187 into master May 26, 2015
@Kami Kami deleted the mistral_notifications_support branch May 26, 2015 16:12
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

2 participants