canonical / charm-cloudsupport

Support charm for OpenStack operations. It's main purpose is to package common tasks into easy-to-use actions.
Other
0 stars 2 forks source link

Support Juju 3.4 #21

Closed rgildein closed 6 months ago

rgildein commented 6 months ago

Switching CI run with Juju 3.4 on Juju 3.4 controller. To be able to support Juju 3.4, we need to get rid of nagios, however one test depend on it. I decide to switch to cos-proxy, since only think we need is to be able to create monitors relation.

Add workflow concurrency to avoid running multiple workflows on a single PR. Like this if new commit arrived the previous run will be canceled by new run.

Blocked until #655 is merged.

dashmage commented 6 months ago

Just a heads-up - the last run failed with a machine error and the zaza functest run command has the --keep-faulty-model flag added on. So every time this fails, there'll be a large model left behind in our PS6 env in need of manual cleanup.

rgildein commented 6 months ago

Switching to return-code from Code to fix test_20_create_instance test, however, I could not figure out why test_25_test_connectivity failed.

rgildein commented 6 months ago

@Pjack @jneo8 @aieri Do you think it's ok to merge this even if one test is failing? I reported an issue, and I do not think it's related with Juju 3.4.

aieri commented 6 months ago

@rgildein I think it's ok to merge. There are no practical changes in the charm code and we can deal with the functional test failure separately

samuelallan72 commented 4 months ago

Please don't merge with failing tests, unless we know for sure that the failures are completely unrelated. This was a real test failure caused by switching the CI to juju 3.4. See #27 for the fix for the root cause of the test_25_test_connectivity failure.

rgildein commented 4 months ago

Please don't merge with failing tests, unless we know for sure that the failures are completely unrelated. This was a real test failure caused by switching the CI to juju 3.4. See #27 for the fix for the root cause of the test_25_test_connectivity failure.

The functional test was failing even before this change, so I saw no reason to block this change.