You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With 2.0 coming around the corner we should also make Amulet a little more 2.0 friendly by releasing Amulet 2.0!
First off, this is a chance for us to address several flaws in Amulet's original design that have festered over the years. Also, this should be something that, while breaks amulet 1.x should not deprecate amulet 1.x right away. There are a lot of charms written to use amulet 1.x and we shouldn't mess with that support, but also gently nudge authors to move in an amulet 2.0 direction.
This issue is meant to be a blueprint for this work, comments and suggestions will be incorporated into this body and work split out into separate issues.
Deployment
Items to be considered for Deployment class
Rename to Model
Going forward, in a Juju 2.0 world, we no longer have Deployments or Environments, but a controller that we can create models for. The testing harness should create a model for tests to run against, so Deployment will instead be the representation of a Model.
juju-deployer deprecation
Juju 2.0 will support bundles natively, including support for paths as a valid charm url. Given this, deployer is no longer needed and Amulet should interact directly with Juju via it's API/CLI.
Language update
Several methods in Deployment don't align with Juju verbiage. These should be updated to better reflect actual commands in juju.
Deployment.add
This should become Model.deploy to align with juju
Missing features
There are A LOT of new features in 2.0 which need to be represented in Amulet, spaces, storage, budget, resources.
Resources
This is vital for amulet to be used in CI/CD pipeline for bundles and charms
UnitSentry & Talisman
Going forward an overhaul of Talisman and UnitSentry should take place. Over the years it's become prickly to update and interact with
With 2.0 coming around the corner we should also make Amulet a little more 2.0 friendly by releasing Amulet 2.0!
First off, this is a chance for us to address several flaws in Amulet's original design that have festered over the years. Also, this should be something that, while breaks amulet 1.x should not deprecate amulet 1.x right away. There are a lot of charms written to use amulet 1.x and we shouldn't mess with that support, but also gently nudge authors to move in an amulet 2.0 direction.
This issue is meant to be a blueprint for this work, comments and suggestions will be incorporated into this body and work split out into separate issues.
Deployment
Items to be considered for Deployment class
Rename to Model
Going forward, in a Juju 2.0 world, we no longer have Deployments or Environments, but a controller that we can create models for. The testing harness should create a model for tests to run against, so Deployment will instead be the representation of a Model.
juju-deployer deprecation
Juju 2.0 will support bundles natively, including support for paths as a valid charm url. Given this, deployer is no longer needed and Amulet should interact directly with Juju via it's API/CLI.
Language update
Several methods in
Deployment
don't align with Juju verbiage. These should be updated to better reflect actual commands in juju.Deployment.add
This should become
Model.deploy
to align with jujuMissing features
There are A LOT of new features in 2.0 which need to be represented in Amulet, spaces, storage, budget, resources.
Resources
This is vital for amulet to be used in CI/CD pipeline for bundles and charms
UnitSentry & Talisman
Going forward an overhaul of Talisman and UnitSentry should take place. Over the years it's become prickly to update and interact with
UnitSentry
Code examples
The text was updated successfully, but these errors were encountered: