Following up from here:
http://groups.google.com/group/jclouds-dev/browse_thread/thread/ed85fbf9c00fe0a1/71b6495dd864a834?lnk=gst&q=bastion#
Seems we didn't solve this last year. Seems easiest to add a member
to nodeMetadata that is a set of URIs which expose the connections
available to this vm.
Ex.
node.adminEndpoints =
vnc://privateip
ssh://privateip
ssh://bastion:6101
or..
node.adminEndpoints =
rdp://privateip etc..
Not sure this is the best way, but it seems the most straightforward
means to move the ball forward. WDYT?
-Adrian
-Adrian
--
You received this message because you are subscribed to the Google Groups "jclouds-dev" group.
To post to this group, send email to jclou...@googlegroups.com.
To unsubscribe from this group, send email to jclouds-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jclouds-dev?hl=en.
If I understand this proposal correctly it's about storing, in metadata,
a list of ways to get *to* this machine. That way, once the connection
methods have been set up, you can easily query a machine to figure out
(alternative) ways of connecting to it.
Looking at the referenced thread, it would seem that that also refers to
ways to get jclouds to help actually *set up* the connections in
questions, rather than just storing the connection information for easy
retrieval later.
Has that changed or did I misread the original thread?
Also, if Chris Dean (the last poster to the thread) is still around
would it be worthwhile reaching out there to see if this addresses their
use case..?
ap
On Fri, Mar 2, 2012 at 12:03 AM, Andrew Phillips <aphi...@qrmedia.com> wrote:
>> Following up from here:
>>
>> http://groups.google.com/group/jclouds-dev/browse_thread/thread/ed85fbf9c00fe0a1/71b6495dd864a834?lnk=gst&q=bastion#
>>
>> Seems we didn't solve this last year. Seems easiest to add a member
>> to nodeMetadata that is a set of URIs which expose the connections
>> available to this vm.
>>
>> Ex.
>> node.adminEndpoints =
>> vnc://privateip
>> ssh://privateip
>> ssh://bastion:6101
>
>
> If I understand this proposal correctly it's about storing, in metadata, a
> list of ways to get *to* this machine. That way, once the connection methods
> have been set up, you can easily query a machine to figure out (alternative)
> ways of connecting to it.
yep, querying the known and available
>
> Looking at the referenced thread, it would seem that that also refers to
> ways to get jclouds to help actually *set up* the connections in questions,
> rather than just storing the connection information for easy retrieval
> later.
not quite yet. similar to our volume support, which is read-only,
only trying to specify a portable means to display them at the moment.
This is in response to things going stale, yet folks still being
without means to connect to things. I'd like to solve the whole
shebang simultaneously, but there doesn't seem harm in doing
read-only, then later an option for portable setup. That's the idea
anyway.
>
> Has that changed or did I misread the original thread?
>
> Also, if Chris Dean (the last poster to the thread) is still around would it
> be worthwhile reaching out there to see if this addresses their use case..?
>
> ap
>
>
If I understand this proposal correctly it's about storing, in metadata, a list of ways to get *to* this machine. That way, once the connection methods have been set up, you can easily query a machine to figure out (alternative) ways of connecting to it.node.adminEndpoints =
vnc://privateip
ssh://privateip
ssh://bastion:6101