Feature #2054
Implement a method to communicate oned from the guests
| Status: | Closed | Start date: | 05/15/2013 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Carlos Martín | % Done: | 0% | |
| Category: | Core & System | |||
| Target version: | Release 4.2 | |||
| Resolution: | fixed | Pull request: |
Description
Each VM will have an individual token that will authenticate them to the server. Things we could allow to do:
- Update the VM template. This way, an application running on the VM can set monitoring metrics.
- Get the VM information. This will be similar to the information we can already set in the context section, but up to date.
- Perform basic VM life cycle operations. After a task is done, the VM can request OpenNebula to shutdown, suspend the VM...
Associated revisions
Feature #2054: CONTEXT/TOKEN = yes creates a token.txt file in the context cdrom
Feature #2054: Add CONTEXT/ONEGATE_URL variable to VMs
feature #2054: Add new OneGate cloud auth
feature #2054: Add OneGate server
feature #2054: Add OneGate to install.sh
feature #2054: Add logger helper to CloudAuth.rb
feature #2054: Use vm owner instead of created_by
feature #2054: Fix ONEGATE_LOG constant in onegate-server.rb
Feature #2054: Make onegate-server executable
Feature #2054: Log token error in VM template
Feature #2054: Create onegate_auth file on bootstrap
Feature #2054: Add TOKEN_PASSWORD to all users
Feature #2054: Fix onegate url
feature #2054: Add "\n" when updating the template
feature #2054: Improve error messages
feature #2054: Add token checkbox to the Template creation form
Feature #2054: Migrator to 4.1.80
Feature #2054: Add Linux guest onegate script
feature #2054: Free encoded string in aes encryption. Move token path to history. Minor changes
History
#1
Updated by Simon Boulet about 8 years ago
I think #2 could be done using the metadata-server.
Concerning #3, Amazon uses shutdown behavior for this. When a "worker" VM is done doing its work, it can simply issue a shutdown.
I really am not a big fan of #1. Why not require the metrics to be set when the VM is initially deployed? Or use something independent from the VM template, perhaps using the file/document feature. Authenticating the VM securely is going to be real pain, requiring setting up SSL, enforcing certificate validation, etc. Whatever you decide to do please make sure this is optional and turned off by default.
#2
Updated by Carlos Martín about 8 years ago
Hi,
Simon Boulet wrote:
I think #2 could be done using the metadata-server.
We were thinking about a simple xml dump of the VM object. But while we are at it, I agree that it makes sense to try to make it ec2-compatible. The metadata server made by Ricardo Duarte should be a good starting point
https://bitbucket.org/ricardoduarte/opennebula-metadata
Concerning #3, Amazon uses shutdown behavior for this. When a "worker" VM is done doing its work, it can simply issue a shutdown.
I really am not a big fan of #1. Why not require the metrics to be set when the VM is initially deployed? Or use something independent from the VM template, perhaps using the file/document feature. Authenticating the VM securely is going to be real pain, requiring setting up SSL, enforcing certificate validation, etc. Whatever you decide to do please make sure this is optional and turned off by default.
This is related to #1852. The current monitorization can get information from the hypervisor, but we want to allow internal guest monitoring probes. This external server was the solution we came with, to allow any script to push attributes into the VM template.
#3
Updated by Simon Boulet about 8 years ago
Carlos Martín wrote:
This is related to #1852. The current monitorization can get information from the hypervisor, but we want to allow internal guest monitoring probes. This external server was the solution we came with, to allow any script to push attributes into the VM template.
OK, do we really need the VM to push the metrics? Can't we instead poll the VM for the metrics? Or somehow the host could know the VM has custom metrics (I'm thinking about the IM MONITOR polling). For monitoring I really like Ganglia. If you have the VM set up to push metrics to an upstream gmond (or perhaps a gmond running on the host) you could poll VM specific metrics there. If you use Host sFlow the VM metrics are labelled 1234.vmetric_name where 1234 is the VM ID. Could reuse that, and magically add all the vmetrics to the VM monitoring attributes in OpenNebula.
#4
Updated by Ricardo Duarte about 8 years ago
Did you had gave look to AWS CloudWatch and the AWS Auto Scaling features and APIs?
That could be a very good reference.
#5
Updated by Ruben S. Montero about 8 years ago
- Status changed from New to Assigned
- Assignee set to Carlos Martín
#6
Updated by Carlos Martín almost 8 years ago
- Status changed from Assigned to Closed
- Resolution set to fixed
Done! OneGate documentation:
http://opennebula.org/documentation:rel4.2:onegate_configure
http://opennebula.org/documentation:rel4.2:onegate_usage