Conversation
oxide-reflector-bot
Bot
changed the title
oxide-reflector-bot
Bot
changed the title
oxide-reflector-bot
Bot
changed the title
oxide-reflector-bot
Bot
changed the title
oxide-reflector-bot
Bot
changed the title
oxide-reflector-bot
Bot
changed the title
oxide-reflector-bot
Bot
changed the title
oxide-reflector-bot
Bot
changed the title
| oxide vpc firewall-rules update | ||
| oxide vpc router route create | ||
| oxide vpc router route update | ||
| oxide alert receiver webhook create |
There was a problem hiding this comment.
this is due to secrets: Vec<String> being required in the body. We can/should update progenitor CLI to turn this into an arg that may be multiply specified e.g. --secret x --secret y
| // Alert subcommands | ||
| CliCommand::WebhookEventClassList => Some("alert class list"), | ||
| CliCommand::WebhookReceiverList => Some("alert receiver list"), | ||
| CliCommand::WebhookDeliveryList => Some("alert receiver log"), | ||
| CliCommand::WebhookReceiverProbe => Some("alert receiver probe"), | ||
| CliCommand::WebhookDeliveryResend => Some("alert receiver resend"), | ||
| CliCommand::WebhookReceiverView => Some("alert receiver view"), | ||
| CliCommand::WebhookReceiverDelete => Some("alert receiver delete"), | ||
| CliCommand::WebhookReceiverSubscriptionAdd => Some("alert receiver subscribe"), | ||
| CliCommand::WebhookReceiverSubscriptionRemove => Some("alert receiver unsubscribe"), | ||
|
|
||
| // Webhook specific subcommands (including secret management) | ||
| CliCommand::WebhookReceiverCreate => Some("alert receiver webhook create"), | ||
| CliCommand::WebhookReceiverUpdate => Some("alert receiver webhook update"), | ||
| CliCommand::WebhookSecretsList => Some("alert receiver webhook secret list"), | ||
| CliCommand::WebhookSecretsAdd => Some("alert receiver webhook secret add"), | ||
| CliCommand::WebhookSecretsDelete => Some("alert receiver webhook secret delete"), |
There was a problem hiding this comment.
@hawkw and @david-crespo would appreciate your review here
There was a problem hiding this comment.
I still feel kind of funny about the relationship between receivers and the webhook kind of receiver. I guess I get why the webhook subcommands are separate — webhook receiver create and update are specific to webhooks, while view and delete aren't (at least in their inputs — the output of view would have to be a union of the different types of receiver if there were more). It still doesn't feel quite natural or obvious, but maybe I just need to think about it more.
There was a problem hiding this comment.
I agree that it's a little speculative. My suggestion is that we pick something and hope it works out, but intend to reevaluate once we have a second kind of receiver.
There was a problem hiding this comment.
IMHO this feels right to me. I would expect the view to be a union of the various receiver types, while the mutation of the receiver is receiver-type-specific, with the exception of subscription management (which should apply to all receivers). Potentially, we might also add API methods to view/list receivers of a specific type only, with the view 404ing if the receiver is another type, but I think that would be more for the benefit of the web UI if it wants to have e.g. webhook-specific pages --- in the CLI, we can just always do the one that returns a union of receiver types and just display whatever comes back...
In the case of secrets specifically, I think it's possible that other receivers may also have a notion of secrets (perhaps you'd want to sign email alerts...) but others may not (a first-party Slack integration would probably have a Slack API key instead of an arbitrary string shared secret) so the semantics might differ substantially.
oxide-reflector-bot
Bot
changed the title
oxide-reflector-bot
Bot
changed the title
3 participants
Generated code against nexus.json
1848d183CLI docs updated against the updated CLI