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

azure: agent-less ephemeral disk support #97

Closed
arithx opened this issue Dec 13, 2018 · 15 comments
Closed

azure: agent-less ephemeral disk support #97

arithx opened this issue Dec 13, 2018 · 15 comments
Labels
cloud* related to public/private clouds

Comments

@arithx
Copy link
Contributor

arithx commented Dec 13, 2018

Related: #65

Two of the main benefits of WALA (https://github.com/Azure/WALinuxAgent), for immutable hosts, are checking in to Azure to confirm the machine has finished creation (see more info in the comments of #65) and ephemeral disks support.

Ephemeral disks are not pre-formatted and most disks have a single partition unless they're >4TB. Which disk is the ephemeral disk must be performed and the method of detection differs between gen 1 & gen 2 VMs (cloud-init has udev rules to handle both gens). Additionally this check is going to have to run each boot as a new ephemeral disk can be given to a VM if it is moved to a new host.

@lucab
Copy link
Contributor

lucab commented Dec 13, 2018

@arithx in CL we carry https://github.com/coreos/init/blob/master/udev/rules.d/66-azure-storage.rules and WALA has https://github.com/Azure/WALinuxAgent/blob/master/config/66-azure-storage.rules (which seems to be the same). Assuming we will carry that on agent-less FCOS too, which other config/binaries are we missing for ephemeral disks? Are we concerned with detection/symlink only or do we have something higher-level to configure and support?

@arithx
Copy link
Contributor Author

arithx commented Dec 13, 2018

@lucab My understanding is that we'd want to the detection/symlink as well as the formatting (if they aren't pre-formatted).

As far as the udev rules I haven't personally looked into it. They do look like they cover both the gen 1 ID based disks & gen 2 specific SCSI controller cases though.

@bgilbert might have some additional thoughts.

@dustymabe dustymabe added the cloud* related to public/private clouds label Dec 13, 2018
@dustymabe
Copy link
Member

@lucab My understanding is that we'd want to the detection/symlink as well as the formatting (if they aren't pre-formatted).

is there a reason we couldn't just rely on the user to know/handle this part using ignition-disks?

@arithx
Copy link
Contributor Author

arithx commented Dec 13, 2018 via email

@dustymabe
Copy link
Member

@dustymabe a new ephemeral disk that is not formatted can happen when the machine moves to a new host on Azure which could happen during a reboot.

sure, but doesn't that represent a change the user requested ? (i.e. "Give me a new ephemeral disk"). It seems like we should be able to get by with leaving this to the user. The two questions I would ask are:

  • What do people on other cloud platforms do in this same situation?
  • Will it be a huge drop in user experience that we don't automatically do something here whereas other OS that include the agent do do something here.

@arithx
Copy link
Contributor Author

arithx commented Dec 13, 2018 via email

@dustymabe
Copy link
Member

If Azure does this as well there could be a scenario where the user reboots for say an update and Azure rebalances and moves the VM to a new host thus giving it a new ephemeral disk.

What does Azure do here differently, than say AWS ?

@arithx
Copy link
Contributor Author

arithx commented Dec 13, 2018

AWS can move machines to different hosts while they're offline. I believe the main difference is probably just that the ephemeral disks on AWS aren't NTFS formatted by default.

@dustymabe
Copy link
Member

Would one option here be to wait until someone from the community identifies it as a need?

@arithx
Copy link
Contributor Author

arithx commented Dec 13, 2018

Personally I think it would be fair to ship FCOS without ephemeral disks support initially.

@ajeddeloh
Copy link
Contributor

Personally I think it would be fair to ship FCOS without ephemeral disks support initially.

Agreed. When we do want to add support we could add a systemd unit that depends on the well known path(s) of the ephemeral disks and reformats them if they are ntfs. We could ship that unit by default via Ignition then let users mask it.

@arithx Did you ever find out if there will be more than one ephemeral disk?

@arithx
Copy link
Contributor Author

arithx commented Dec 13, 2018

@ajeddeloh I did not. I briefly searched through to see if I could find more info but nothing popped out.

@dustymabe
Copy link
Member

It seems like we are circling on not shipping this functionality. If a user requests it we can revisit.

@arithx - can we open a PR to the design doc to document this decision?

arithx added a commit to arithx/fedora-coreos-tracker that referenced this issue Dec 19, 2018
arithx added a commit to arithx/fedora-coreos-tracker that referenced this issue Dec 19, 2018
arithx added a commit to arithx/fedora-coreos-tracker that referenced this issue Dec 19, 2018
arithx added a commit to arithx/fedora-coreos-tracker that referenced this issue Dec 19, 2018
@dustymabe
Copy link
Member

with #102 should we close this out as decided?

@arithx
Copy link
Contributor Author

arithx commented Dec 20, 2018

@dustymabe yeah, we cover the decision in that PR.

@arithx arithx closed this as completed Dec 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cloud* related to public/private clouds
Projects
None yet
Development

No branches or pull requests

4 participants