Merged
Conversation
juju#448 This PR adds in the client for 2.9-beta1
This change allows us to easily mock the facade in tests.
…-for-applications juju#449 This PR adds support for granular, per-endpoint expose parameters to the expose/unexpose methods of the Application model as well as an example for using the new feature. For more details on using this feature please refer to https://discourse.juju.is/t/granular-control-of-application-expose-parameters-in-the-upcoming-2-9-juju-release/3597
juju#455 This is a clean merge from master to 2.9 to ensure that 2.9 is kept in sync.
The following updates the 2.9 branch to the latest schema. The generated python is the fallout from this.
The following PR ensures that all the URLs have the correct prefix, that way when we come to implement the charm-hub deployment workflow we do that without breaking the old tests. Eventually the cs: (charm-store) will be removed, but whilst we're in transition, we should still support it and the tests associated with them. The code is very mechanical and should show that a cs: prefix is mandatory if the user wants to contact the charm-store.
…refix juju#457 The following PR ensures that all the URLs have the correct prefix, that way when we come to implement the charm-hub deployment workflow we do that without breaking the old tests. Eventually the cs: (charm-store) will be removed, but whilst we're in transition, we should still support it and the tests associated with them. The code is very mechanical and should show that a cs: prefix is mandatory if the user wants to contact the charm-store.
juju#456 The following updates the 2.9 branch to the latest schema. The generated python is the fallout from this.
To remain consistent with juju nomenclature, the following redirects upgrade_charm to refresh. Once juju 3 is released upgrade_charm can be removed (along with other alias methods), to ensure a clean API. This is a purely mechanical change.
Application facade has a new method for calling configuration values on it. Use that instead of the old way. This is a breaking change if you're using it from pylibjuju and we should probably be aware of that in the future. Luckily the fix is to just use the latest pylibjuju with this fix in it.
…-refresh juju#459 To remain consistent with juju nomenclature, the following redirects upgrade_charm to refresh. Once juju 3 is released upgrade_charm can be removed (along with other alias methods), to ensure a clean API. This is a purely mechanical change.
The following introduces queries to the charmhub store API. Now that all requests go through a juju controller it makes it very trivial for other clients like pylibjuju to gain the same powers as the go CLI. The code is rather simple, it farms off a new type to encapsulate the charmhub related calls (info and find which will follow) as the model type is large and unwieldly, once there we just create a new facade and perform the query. Offically it would be nice to have to channel validation, but for now we'll let the controller handle that.
The following sends an empty channel instead of guessing, so that the controller can correctly determine the right channel for hinting.
juju#460 The following introduces queries to the charmhub store API. Now that all requests go through a juju controller it makes it very trivial for other clients like pylibjuju to gain the same powers as the go CLI. The code is rather simple, it farms off a new type to encapsulate the charmhub related calls (info and find which will follow) as the model type is large and unwieldly, once there we just create a new facade and perform the query. Offically it would be nice to have to channel validation, but for now we'll let the controller handle that.
The following adds the ability to query the charmhub repository. It uses the controller to query the charmhub repository so is really easy for clients to also use the same logic/code path as the go CLI.
Only looking over the code did I see that there already exists a charm store and so we should make it easier for others reading this to see that this exists along with charm hub. Extracting the contents into another file shows this. This is a mechanical change that helps with readability, nothing else.
The following starts to implement charm origin. These are required for the deploy commands where we're talking about origin, channels and platforms. If we make types of these then we can pass them around knowing exactly the correct types at hand. The code is pretty much a copy and pasted from juju itself with some modifications to channels that don't take into account branches.
The following cleans up some non-idiomatic code with in python.
juju#463 Requires juju#460 and juju#462 to land first The following starts to implement charm origin. These are required for the deploy commands where we're talking about origin, channels and platforms. If we make types of these then we can pass them around knowing exactly the correct types at hand. The code is pretty much a copy and pasted from juju itself with some modifications to channels that don't take into account branches.
The following introduces a charm URL, this will help when trying to ensure that what we get from the API is indeed a valid URL. The code is pretty much a lift from the juju/charm package, minus the FQDN charm URLs, which should never have been added to the charm package. The code is rather procedural and doesn't validate the name or series, but the controller can do that once we know the pattern is correct. Essentially we want the charm URL for the schema and the name, so rather than have methods that sort of do the job, we should replicate the exact same parsing layout so we don't get it wrong.
juju#464 Requires juju#463 to land, then rebase this on top. The following introduces a charm URL, this will help when trying to ensure that what we get from the API is indeed a valid URL. The code is pretty much a lift from the juju/charm package, minus the FQDN charm URLs, which should never have been added to the charm package. The code is rather procedural and doesn't validate the name or series, but the controller can do that once we know the pattern is correct. Essentially we want the charm URL for the schema and the name, so rather than have methods that sort of do the job, we should replicate the exact same parsing layout so we don't get it wrong.
juju#481 Merge 2.9 into master This is brings in 2.9-rc3 schema as well, so that we're dealing with the latest changes. Conflicts: _client3.py - just re-ran the `make client` as the code is autogenerated. 5e23162 (upstream/master) Merge pull request juju#480 from SimonRichardson/release-2.8.6 3e23b74 (origin/master, origin/HEAD, master) Merge pull request juju#479 from SimonRichardson/schema-update-2.8.10 7f96863 Merge pull request juju#478 from SimonRichardson/scale-typo fd1438c Merge pull request juju#475 from achilleasa/provide-accessor-for-machine-hostname-field 1015f4d Expand wait_for_idle to support waiting for status (juju#473) 7829fd0 Merge pull request juju#471 from SimonRichardson/release-2.8.5 fd36c8f Merge pull request juju#470 from juju/johnsca/bundle-charm-files-and-wait 3d91d6b Merge pull request juju#469 from juju/johnsca/accept-charm-files 4e4e108 Merge pull request juju#465 from juju/johnsca/update-websockets/py39 d696937 Merge pull request juju#467 from gnuoy/issue/466
The following adds the optional find parameters that are exposed in the API. The find API already existed, this is just to augment what was already there.
juju#482 The following adds the optional find parameters that are exposed in the API. The find API already existed, this is just to augment what was already there. It's now possible to just request bundles. ```py result = await model.charmhub.find("kuber", charm_type="bundle") ```
juju#490 Updating facades to Juju version 2.9.0
Specifically adds support for kubernetes api port forward proxies that appear in Juju 2.9
juju#491 Updates facades to Juju 2.9.1
The following change removes the workaround for the 2.2.3 release and subsequent 2.3-beta1 release. As these are older releases that users should have moved away from, it's time to remove the workarounds. The code in question was highly contentious anyway, as it was never awaited on the machine, so might not have been doing what we wanted it to do in the long run.
…round juju#493 The following change removes the workaround for the 2.2.3 release and subsequent 2.3-beta1 release. As these are older releases that users should have moved away from, it's time to remove the workarounds. The code in question was highly contentious anyway, as it was never awaited on the machine, so might not have been doing what we wanted it to do in the long run.
juju#492 Adds support for Kubernetes client proxies introduced in Juju 2.9. Relates to bug https://bugs.launchpad.net/juju/+bug/1926595
pengale
approved these changes
May 25, 2021
Contributor
pengale
left a comment
pengale
left a comment
There was a problem hiding this comment.
LGTM. It's time to do this.
Member
Author
|
|
2 similar comments
Member
Author
|
|
Member
Author
|
|
Member
Author
|
!!build!! |
3 similar comments
Member
Author
|
!!build!! |
Member
Author
|
!!build!! |
Member
Author
|
!!build!! |
Member
Author
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The following merges 2.9 into master.
eed19e4 (upstream/2.9, origin/2.9, 2.9) Merge pull request #492 from tlm/kube-proxy-support-2
ab33f33 Merge pull request #493 from SimonRichardson/remove-machine-workaround
5c2dfa9 Merge pull request #491 from tlm/2.9.1-facades
b24e750 Merge pull request #490 from tlm/kube-proxy-support-2
aaa651c Merge pull request #482 from SimonRichardson/find-parameters
bde724b Merge pull request #481 from SimonRichardson/merge-master-2.9
fa1b85f Merge pull request #464 from SimonRichardson/charm-hub-url
195191b Merge pull request #463 from SimonRichardson/charm-hub-origin
d6d157f Merge pull request #462 from SimonRichardson/charm-hub-find
6fab2ee Merge pull request #460 from SimonRichardson/charm-hub-info
5e61dd2 Merge pull request #459 from SimonRichardson/rename-upgrade-charm-refresh
73604c8 Merge pull request #456 from SimonRichardson/update-schema-2.9-rc3
6c0437a Merge pull request #457 from SimonRichardson/ensure-charm-store-prefix
eb849e4 Merge pull request #455 from SimonRichardson/2.9
1a77394 Merge pull request #449 from achilleasa/support-new-expose-params-for-applications
ad3c449 Merge pull request #448 from achilleasa/gen-2.9-beta-client