Andrew Scribner

Another thing we could standardize is how we name dev branches (the branches we use when we want to land more than one PR into a common feature or dev...

our repo settings themselves are also not standardized. There's automation (see obs) that can make this programatically defined (this might be out of scope - its more charm **repo** standardization)...

https://github.com/canonical/kubeflow-ci/issues/125 is also relevant here, where the goal is to standardize how CI generates logs

Also relevant is https://github.com/canonical/kubeflow-ci/issues/127, which suggests we should have automation enforce the standardizations and conventions we decide on

Hi @Daard, thanks for the report This feels like something is not right with your kubernetes cluster. I'm thinking that mainly because of the message: > 0/1 nodes are available:...

agreed! I think when we implement this should be just after 3.5 is released, so that'll work out perfectly

When combined with https://github.com/canonical/istio-operators/pull/277, this also means we no longer need to change `public-url` when enabling SSL

What the Kubeflow team has seen with istio-pilot is like what @carlcsaposs-canonical reports. In live Juju when handling a relation-broken event: 1. sometimes `event.app=DEPARTING_APP` (and I think `relation.app` is the...

Not a blocker but something to consider - we maintain a test suite that has shared code across multiple versions (to reduce the effort of actually maintaining it). For example,...

I don't think our other repos function exactly as described in the original post. Our charm repos: * `track` branches in our repos represent the code currently in `trackX/edge` *...