Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: fill in gaps from v15-16 #658

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

tmihoc
Copy link
Member

@tmihoc tmihoc commented Jan 28, 2025

Description

This PR fills in docs gaps from v15-16 and makes a few other small updates. Specifically, it:

  • adds how-to guides for all the resources and data sources that were not yet featured (this includes all the recent jaas bits but also all the data sources and things such as juju_kubernetes_cloud and also refactors content / creates new docs as needed, e.g., with jaas users are just one of 3 entities that can be given access to things, so I've reorganized all that content so it'll better reflect that)
  • updates the Juju links to point to the new Juju RTD
  • removes the Contributors section at the end of each how-to (the handles had no meaning outside of Discourse, plus Daniele we don't need to track manually anymore)

Type of change

Docs.

QA steps

In terraform-provider-juju/docs-rtd, run make run to preview the changes in a browser.

@tmihoc tmihoc force-pushed the docs-fill-in-gaps-from-v15-16 branch 3 times, most recently from a392e52 to aaeb786 Compare January 28, 2025 14:12
@hmlanigan hmlanigan self-requested a review January 28, 2025 15:35
@tmihoc tmihoc force-pushed the docs-fill-in-gaps-from-v15-16 branch from aaeb786 to 11fc2bc Compare January 29, 2025 15:22
Copy link
Member

@alesstimec alesstimec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with a few suggestions.. Thank you!


## Add a group

To add a group, in your Terraform plan create a resource of the `juju_jaas_group` type, specifying, at the very least, a name. For example:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
To add a group, in your Terraform plan create a resource of the `juju_jaas_group` type, specifying, at the very least, a name. For example:
To add a group, in your Terraform plan create a resource of the `juju_jaas_group` type, specifying its name. For example:

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

(manage-access-to-a-group)=
## Manage access to a group

When using Juju with JAAS, to grant one or more users, groups, and/or service accounts access to a group, in your Terraform plan add a resource type `juju_jaas_access_group`, specifying the group ID, the JAAS group access level, and the list of desired users, groups, and/or service accounts. For example:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking that maybe we should reword it to make it cleared that by "adding access to a group" we manage group membership.. "granting" somebody access to a group effectively makes them a member of that group.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, that is so only because the only valid access level is "member". Will that still be all in the future?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved the note about member being the only valid level higher, before the example, and rephrased it:

At present, the only valid JAAS group access level is member, so granting an entity access to a group effectively means making them a member of the group.


> See more: [`juju_offer`](https://registry.terraform.io/providers/juju/juju/latest/docs/resources/offer)
### Using Juju alone
When using Juju alone, to grant a user access to an offer, in your Terraform plan add a `juju_access_offer` resource, specifying the offer URL and setting the Juju access level to the list of users you want to grant that level. For example:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a suggestion for all Juju VS JAAS sections:
"When applying a Terraform plan to a Juju controller"
vs
"When applying a Terraform plan to a JAAS controller"

Because when you say "When using Juju alone" it sounds to me like you're using the Juju CLI, not the provider.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the section intro, subsection titles, and subsection intro lines to align with this.

## Remove an offer
> Who: User with [offer `admin` access](https://canonical-juju.readthedocs-hosted.com/en/latest/user/reference/user/#user-access-offer-admin).

To remove an offer, in your Terraform plan, remove its resource definition.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unless they used the offer data source in which case will need to use external tools to remove it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed in our call, I've updated the docs to not have any mention of data sources in the Remove an x sections. Also, for all entities that can be referenced through a data source, I've updated the Manage x > Reference... section to have the better phrasing we agreed upon ("outside of the current Terraform plan").

Copy link
Member Author

@tmihoc tmihoc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had a follow-up question about how to handle the remove sections (with the data source and resource split).


## Add a group

To add a group, in your Terraform plan create a resource of the `juju_jaas_group` type, specifying, at the very least, a name. For example:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

(manage-access-to-a-group)=
## Manage access to a group

When using Juju with JAAS, to grant one or more users, groups, and/or service accounts access to a group, in your Terraform plan add a resource type `juju_jaas_access_group`, specifying the group ID, the JAAS group access level, and the list of desired users, groups, and/or service accounts. For example:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, that is so only because the only valid access level is "member". Will that still be all in the future?

(manage-access-to-a-group)=
## Manage access to a group

When using Juju with JAAS, to grant one or more users, groups, and/or service accounts access to a group, in your Terraform plan add a resource type `juju_jaas_access_group`, specifying the group ID, the JAAS group access level, and the list of desired users, groups, and/or service accounts. For example:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved the note about member being the only valid level higher, before the example, and rephrased it:

At present, the only valid JAAS group access level is member, so granting an entity access to a group effectively means making them a member of the group.


> See more: [`juju_offer`](https://registry.terraform.io/providers/juju/juju/latest/docs/resources/offer)
### Using Juju alone
When using Juju alone, to grant a user access to an offer, in your Terraform plan add a `juju_access_offer` resource, specifying the offer URL and setting the Juju access level to the list of users you want to grant that level. For example:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the section intro, subsection titles, and subsection intro lines to align with this.

@tmihoc tmihoc force-pushed the docs-fill-in-gaps-from-v15-16 branch 2 times, most recently from bf3bb7f to 8ff09c9 Compare January 31, 2025 12:50
@tmihoc
Copy link
Member Author

tmihoc commented Jan 31, 2025

/merge

@tmihoc tmihoc force-pushed the docs-fill-in-gaps-from-v15-16 branch from 8ff09c9 to 5d84513 Compare January 31, 2025 15:40
@tmihoc
Copy link
Member Author

tmihoc commented Jan 31, 2025

/merge

2 similar comments
@tmihoc
Copy link
Member Author

tmihoc commented Jan 31, 2025

/merge

@tmihoc
Copy link
Member Author

tmihoc commented Jan 31, 2025

/merge

@kian99
Copy link
Contributor

kian99 commented Feb 3, 2025

@hmlanigan @alesstimec The test TestAcc_ResourceApplication_UpdatesRevisionConfig is failing, because the github-runner charm has changed and no longer has the runner-storage config valid.
From the test below, I see we are pinning a revision but it seems that it is pulling the charm from latest/edge where you can see the config values in my screenshot below.

func TestAcc_ResourceApplication_UpdatesRevisionConfig(t *testing.T) {
	if testingCloud != LXDCloudTesting {
		t.Skip(t.Name() + " only runs with LXD")
	}

	modelName := acctest.RandomWithPrefix("tf-test-application")
	appName := "github-runner"
	configParamName := "runner-storage"

	resource.ParallelTest(t, resource.TestCase{
		PreCheck:                 func() { testAccPreCheck(t) },
		ProtoV6ProviderFactories: frameworkProviderFactories,
		Steps: []resource.TestStep{
			{
				Config: testAccResourceApplicationWithRevisionAndConfig(modelName, appName, 88, "", "", ""),

image

@tmihoc tmihoc force-pushed the docs-fill-in-gaps-from-v15-16 branch from 5d84513 to ffc4f61 Compare February 4, 2025 08:26
@tmihoc tmihoc force-pushed the docs-fill-in-gaps-from-v15-16 branch from ffc4f61 to fbe123b Compare February 18, 2025 13:09
@tmihoc tmihoc force-pushed the docs-fill-in-gaps-from-v15-16 branch from 328dbff to 1d5911b Compare February 18, 2025 13:57
@alesstimec alesstimec added the state/codefreeze this pr cannot land until the code freeze has lifted. label Feb 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state/codefreeze this pr cannot land until the code freeze has lifted.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants