small command to shortcut changing an instance type #276
Conversation
|
@mbailey any chance this can make it in? |
|
Possibly.
What’s the behaviour if you run the command against a running instance?
Do you need to restart the instance separately before it takes effect?
For consistency with most other commands:
- it would want instance-type to be the first arg and one or many instance
ids as remaining arguments.
- using skim-stdin would allow piping in instance-ids. Most of the instance
commands have examples of this. There’s a video on the doc site on how it
works.
- confirm msg (see instance-terminate) is probably in order given change
may be harmful and can act on multiple instances that may be provided via a
pipeline (and thus not shown otherwise)
…On Mon, 20 Apr 2020 at 8:00 pm, yaakov kuperman ***@***.***> wrote:
@mbailey <https://github.com/mbailey> any chance this can make it in?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#276 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAABCONAICA4PKELREWJPUDRNQMM3ANCNFSM4KINHNDA>
.
|
it will error out. the instance MUST be in the
yes
i can implement this next time i have a spare moment. if we're talking about automating multiple instances with a confirmation message, perhaps i will also make this do the stop/start |
|
Thanks for your reply
I wouldn’t make it stop/start instances as that could be a dangerous
surprise for other users.
Instance stop might be a good example of a function that implements pipe
skimming and confirmation.
One question, have you considered managing your instances using
Cloudformation? That would obviate the need to be manually changing
instance types (and give you a ton of other benefits from using config as
code).
Mike
…On Tue, 21 Apr 2020 at 11:46 pm, yaakov kuperman ***@***.***> wrote:
Possibly. What’s the behaviour if you run the command against a running
instance?
it will error out. the instance MUST be in the stopped state for this to
work. i COULD make it turn the instance off for you, but i personally
prefer to chain together instance-stop, this, and instance-start
Do you need to restart the instance separately before it takes effect?
yes
For consistency with most other commands: - it would want instance-type to
be the first arg and one or many instance ids as remaining arguments. -
using skim-stdin would allow piping in instance-ids. Most of the instance
commands have examples of this. There’s a video on the doc site on how it
works. - confirm msg (see instance-terminate) is probably in order given
change may be harmful and can act on multiple instances that may be
provided via a pipeline (and thus not shown otherwise)
i can implement this next time i have a spare moment. if we're talking
about automating multiple instances with a confirmation message, perhaps i
will also make this do the stop/start
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#276 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAABCOK7XOMFOOUKZHVO6XLRNWPU3ANCNFSM4KINHNDA>
.
|
|
We are a cloudformation shop transitioning rapidly to terraform. My need for this on top of an infra as code solution is because we need to do a controlled stop/start in order to do things like managing load balancers and gracefully draining connections. Infra as code doesn't easily support that, and cloudformation doesn't even let you import existing state back in to the template after a manual modification, which is a big reason we're switching to tf. |
|
Ah, OK. That's interesting.
Does ELB connection draining not meet your needs?
I've always avoided making changes outside of CloudFormation for the reason
you pointed out - CloudFormation will try to make the change again if you
update the template.
Does TerraForm inspect resources and update it's template or is it just a
matter of updating your terraform config, knowing it won't try to make a
change that was already made manually?
cheers,
Mike
…On Wed, 22 Apr 2020 at 07:06, yaakov kuperman ***@***.***> wrote:
We are a cloudformation shop transitioning rapidly to terraform. My need
for this on top of an infra as code solution is because we need to do a
controlled stop/start in order to do things like managing load balancers
and gracefully draining connections. Infra as code doesn't easily support
that, and cloudformation doesn't even let you import existing state back in
to the template after a manual modification, which is a big reason we're
switching to tf.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#276 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAABCOKCM5CPBTVQSTQPH7DRNYDD5ANCNFSM4KINHNDA>
.
|
|
Connection draining takes some time to do gracefully, but unless I missed something, I don't believe cloudformation will wait for it before doing its restart. There's a couple of ways terraform makes handling out of band changes easier. First, whereas cloudformation only really supports correcting drift by updating the live resources to match the configuration, terraform lets you update your configuration to match what's live, so if there's drift you can correct it in your repository and be done. Second, terraform supports an "import" function, which lets you specify that a given live resource maps to a given object in your configuration. So, for example, if you stood up a bunch of EC2 nodes manually and wanted to manage them in terraform, it's a matter of defining the resource in your terraform configuration, importing the resource into terraform, then tweaking your configuration to make sure that it reflects what's live so you don't accidentally change anything. https://www.terraform.io/docs/import/usage.html explains it pretty well If you'd like to geek out about TF, feel free to email me. I just put a public-friendly email address on my profile. I'm sure there's also a chat service out there we could sync up on. |
No description provided.