Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

chore: allow terraform & echo built-in provisioners#13121

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
Emyrk merged 17 commits intomainfromstevenmasley/mem_provisioner
May 3, 2024

Conversation

Emyrk
Copy link
Member

@EmyrkEmyrk commentedMay 1, 2024
edited
Loading

What this does

Allows us to spin up terraform & echo provisioners as built-ins. This is to support e2e testing using both terraform & echo for different tests.

Also changed echo provisioners to not accept terraform template version jobs. Before, these jobs would just hang anyway.

To launch both:

coder server --provisioner-daemons 5 --provisioner-types="echo,terraform" #...

UI

Adds a UI element to the health page to indicate supported provisioner types for each provisioner.

Screenshot from 2024-05-01 16-26-22

Before

Before this--provisioner-daemons-echo=true was a boolean value and--provisioner-daemons told the number of provisioners. So theprovisioner-daemons-echo flag changes how the other flag works. Now they both work independently.

@EmyrkEmyrk marked this pull request as ready for reviewMay 1, 2024 22:11
@matifali
Copy link
Member

I wonder if we can use the echo provisioner to provision local(on the client machine) workspaces.

@spikecurtis
Copy link
Contributor

I wonder if we can use the echo provisioner to provision local(on the client machine) workspaces.

unlikely. The echo provisioner literally just echos a canned set of resources back to Coderd. It doesn't actuallyprovision anything.

matifali reacted with thumbs up emoji

cli/server.go Outdated
@@ -944,15 +944,27 @@ func (r *RootCmd) Server(newAPI func(context.Context, *coderd.Options) (*coderd.
var provisionerdWaitGroup sync.WaitGroup
defer provisionerdWaitGroup.Wait()
provisionerdMetrics := provisionerd.NewMetrics(options.PrometheusRegistry)
for i := int64(0); i < vals.Provisioner.Daemons.Value(); i++ {

// Create a list of daemon types. The length is the total number of built-in provisioners, and
Copy link
Contributor

Choose a reason for hiding this comment

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

So, at a high level,provisioner daemons don't have a type.Provisioners have a type, and a provisioner daemon can accept multiple provisioner types via theConnector map.

Do we really want/need to have a different number ofdaemons for echo and terraform? Or the choice really between: echo, terraform, or both? If so, maybe it makes sense to keep the flag about the number as is, and then add a flag (default true) that controls whether to include terraform provisioners.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

So, at a high level, provisioner daemons don't have a type. Provisioners have a type, and a provisioner daemon can accept multiple provisioner types via the Connector map.

Yes, but that assumes the provisioner implementation can support both types. Right now we have an echo provisioner daemon implementation, and a terraform. To unify those into a single daemon, we'd need a daemon implementation that can support both.

I think in practice, having provisioner daemons support 1 job type is reasonable if those jobs are unique enough. Example being if we add OpenTF as a new type, you could probably make theterraform provisioner support bothterraform andopen-tf.


For the flag. The status quo is you can have either terraform provisionersxor echo provisioners. For e2e testing, it makes sense to have both, as the echo provisioner obviously has less overhead for some of our tests.

I think it makes sense to be able to control whether you run terraform only (prod), both (e2e), just echo (unit testing). So the flags need to support these 3 cases.


The--provisioner-daemons flag is the flag our customers use today to control the number of built-in terraform provisioners. Given--provisioner-daemons-echo is hidden and only used in testing, it feels reasonable to give it the same functionality as it's production counterpart, just for echo provisioners instead.

@EmyrkEmyrk requested a review fromspikecurtisMay 2, 2024 16:30
@EmyrkEmyrkforce-pushed thestevenmasley/mem_provisioner branch from847090a to7defa52CompareMay 2, 2024 16:50
@EmyrkGraphite App
Copy link
MemberAuthor

Emyrk commentedMay 2, 2024
edited
Loading

This stack of pull requests is managed by Graphite.Learn more about stacking.

Join@Emyrk and the rest of your teammates onGraphiteGraphite

Comment on lines +1426 to +1438
Value: serpent.Validate(&c.Provisioner.DaemonTypes, func(values *serpent.StringArray) error {
if values == nil {
return nil
}

for _, value := range *values {
if err := ProvisionerTypeValid(value); err != nil {
return err
}
}

return nil
}),
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

some enum validation. This is case sensitive.

@EmyrkEmyrkforce-pushed thestevenmasley/mem_provisioner branch fromda51c9b to487f0a8CompareMay 2, 2024 23:15
Copy link
Contributor

@spikecurtisspikecurtis left a comment

Choose a reason for hiding this comment

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

LGTM

@EmyrkEmyrk merged commit94a3e3a intomainMay 3, 2024
@EmyrkEmyrk deleted the stevenmasley/mem_provisioner branchMay 3, 2024 15:14
@github-actionsgithub-actionsbot locked and limited conversation to collaboratorsMay 3, 2024
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.
Reviewers

@spikecurtisspikecurtisspikecurtis approved these changes

@aslilacaslilacAwaiting requested review from aslilac

Assignees

@EmyrkEmyrk

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

4 participants
@Emyrk@matifali@spikecurtis@aslilac

[8]ページ先頭

©2009-2025 Movatter.jp