search

CVNRneuroimaging / infrastructure

Issue tracking, system documentation and configs for operations side of the neuroimaging core @ Atlanta VA CVNR / Emory University
3 stars 2 forks source link

propagating changes to other deployed hosts/VMs, and VM master image #135

Closed stowler closed 8 years ago

stowler commented 8 years ago

Hi Keith and Rob @kmcgregor123456 @rrmm ,

When I make changes to each of these components of a deployed VM, what's the strategy for propagating the change to a) other deployed VMs/hosts, and b) the VM master image:

  1. apt sources configuration
  2. apt package state (installed/not installed)
  3. system-wide initialization files (/etc/bashrc, et al.)
  4. system-wide non-apt software (e.g. /opt/*)

Have you created mechanisms for propagating any of those four, or should I just open a ticket saying, "I changed and tested on host , please propagate to master VM image and all other deployed hosts".

Thanks, Stephen

kmcgregor123456 commented 8 years ago

In GENERAL: As part of the lab infrastructure, you have the ability to change the image as you see fit. If it is a significant improvement that warrants a rev of the master, then indeed, export to .ova and notify us on git. I will then inform everyone of the changes and make available to download via my 1TB google drive account. Users on personal machines (which are not recommended to be used on home infrastructure - i.e. comcast or att&t), should then download and update the VM after we test it for login/LDAP issues. This testing will not be exhaustive and should the image prove faulty, the previous version will be disseminated for download. Images should take the following name - BIRCXubuntu.ova . If you make more than one master in one day, then: A) you need a hobby and B) only the most current will be posted for download.

However, we cannot police all active VMs all of the time. We can set a zabbix client and monitor host login from corpus.

Taking these 1-4:

1) Addressed by GENERAL 2) Addressed by GENERAL 3) In RE: customization, the only customization we can provide is a base skeleton for the user directories. This can include a functional BIRC .bashrc, but users who want to customize their profile or rc scripts will have to manage these on their own (i.e. - I know many people don't like my chosen PROMPT, but if they want it changed, it's their playground). 4) If a user requires a very customized VM with additional software, then the user can update the image and store the .ova in their home directory for backup.

Otherwise, the image and software suite will be updated quarterly for upgrades and as necessary for security holes.

Keith McGregor, PhD VA RR&D Atlanta CoE Emory University 352.359.8084 www.varrd.emory.edu

From: Stephen Towler [notifications@github.com] Sent: Tuesday, August 11, 2015 7:34 PM To: CVNRneuroimaging/infrastructure Cc: Keith McGregor Subject: [infrastructure] propagating changes to other deployed hosts/VMs, and VM master image (#135)

Hi Keith and Rob @kmcgregor123456https://github.com/kmcgregor123456 @rrmmhttps://github.com/rrmm ,

When I make changes to each of these components of a deployed VM, what's the strategy for propagating the change to a) other deployed VMs/hosts, and b) the VM master image:

  1. apt sources configuration
  2. apt package state (installed/not installed)
  3. system-wide initialization files (/etc/bashrc, et al.)
  4. system-wide non-apt software (e.g. /opt/*)

Have you created mechanisms for propagating any of those four, or should I just open a ticket saying, "I changed and tested on host , please propagate to master VM image and all other deployed hosts".

Thanks, Stephen

— Reply to this email directly or view it on GitHubhttps://github.com/CVNRneuroimaging/infrastructure/issues/135.

This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited.

If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments).

stowler commented 8 years ago

Hi Keith @kmcgregor123456 and Rob @rrmm ,

Got it. (But unsolicited advice: you may want to maintain closer control of the master image than what you're suggesting.)

In preparation for our Friday group maintenance session I'll be doing some config and testing. I'll limit those changes to one physical host (qball4) and one VM (don't know which yet) and document any revisions that need to stick. We'll review those changes during Friday group maintenance.

Let's plan on a VM master revision and re-deployment shortly after the changes generated by our group maintenance session.

Thanks, Stephen