we've had some discussions internally and with customers recently and have decided to adjust how the operator registers deployments. the code is here:
|
pub(super) async fn register_service_with_restate( |
|
&self, |
|
ctx: &Context, |
|
service_endpoint: &Url, |
|
use_http11: Option<bool>, |
|
) -> Result<String> { |
|
debug!( |
|
"Registering endpoint '{service_endpoint}' to Restate at '{}'", |
|
&self.spec.restate.register |
|
); |
|
|
|
#[derive(Deserialize)] |
|
struct DeploymentResponse { |
|
id: String, |
|
} |
|
|
|
let mut payload = serde_json::json!({ |
|
"uri": service_endpoint, |
|
}); |
|
|
|
if let Some(use_http11) = use_http11 { |
|
payload["use_http_11"] = serde_json::Value::Bool(use_http11); |
|
} |
|
|
|
let resp = ctx |
|
.request(Method::POST, &self.spec.restate.register, "/deployments")? |
|
.json(&payload) |
|
.send() |
|
.await |
|
.map_err(Error::AdminCallFailed)?; |
|
let resp: DeploymentResponse = check_admin_response(resp) |
|
.await? |
|
.json() |
|
.await |
|
.map_err(Error::AdminCallFailed)?; |
|
|
|
let deployment_id = &resp.id; |
|
info!( |
|
deployment_id = %deployment_id, |
|
url = %service_endpoint, |
|
"Successfully registered Restate deployment" |
|
); |
|
|
|
Ok(resp.id) |
|
} |
on the CLI, --breaking defaults to true. in the operator it does not. this is fine for a stable, rarely-changing production setup, but for rapid iteration and development it introduces a good deal of friction. #100 helped with the detective work of discovering what was going on when it failed, but it is surprising still.
we've decided to switch to enabling --breaking in the operator and providing a path to toggling that off, e.g. envvar/CLI/CR.
we'd be adding something like this around line 828:
if let Some(force) = force {
payload["force"] = serde_json::Value::Bool(force);
}
we've had some discussions internally and with customers recently and have decided to adjust how the operator registers deployments. the code is here:
restate-operator/src/controllers/restatedeployment/controller.rs
Lines 805 to 849 in ae11b96
on the CLI,
--breakingdefaults totrue. in the operator it does not. this is fine for a stable, rarely-changing production setup, but for rapid iteration and development it introduces a good deal of friction. #100 helped with the detective work of discovering what was going on when it failed, but it is surprising still.we've decided to switch to enabling
--breakingin the operator and providing a path to toggling that off, e.g. envvar/CLI/CR.we'd be adding something like this around line 828: