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

Account for tagging the root volume after spot loss #102

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

tewfik-ghariani
Copy link
Contributor

Once a spot instance is lost or a spot request in cancelled, the root volume re-created is not appended to the block device mapping because the 'first_boot' was set to False. With this update, we are sure that all mapped volumes are consistently tagged
Other

  • Tag using root vol Name as depl name instead of description
  • Deletion of the condition to tag the volumes
  • Use of generic 'update_tags' method
  • Removal of first_boot ec2 attribute

Note: The branch is based on #101 so the changes can be confusing. You can view them in this single commit : 3fcecd4

tewfik-ghariani and others added 2 commits May 5, 2020 22:25
Once a spot instance is lost or a spot request in cancelled, the root volume re-
created is not appended to the block device mapping because the 'first_boot' was
 set to False. With this update, we are sure that all mapped volumes are consist
ently tagged
Other
- Tag using root vol Name as depl name instead of description
- Deletion of the condition to tag the volumes
- Use of generic 'update_tags' method
- Removal of first_boot ec2 attribute
for device_stored, v in self.block_device_mapping.items():
device_real = device_name_stored_to_real(device_stored)

if not (
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This has been reverted per 4584924
Thanks @PsyanticY for the call-out

@tewfik-ghariani
Copy link
Contributor Author

Well I'm second thinking this after reading the reason behind 'first_boot' : NixOS/nixops@ee60f04

cc @AmineChikhaoui Do you think that would break something and that I should follow a different approach?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant