EucalyptusRemoteAutoRegistration

Revision 1 as of 2009-11-26 08:19:13

Clear message

Summary

This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

Rationale

This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.

User stories

Assumptions

Design

You can have subsections that better describe specific parts of the issue.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

  • data migration, if any
  • redirects from old URLs to new ones, if any
  • how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

UDS discussion notes

9.10

  • Automated registration runs at boot when services are up and running
  • Should this be run one time only?
  • All registration occurs on the "CLC + CC + SC + Walrus" system, so its easy to ensure components are running

10.04

  • Expectation: minimize manual steps
  • Assumption: only one CLC is installed on the local avahi broadcast network (because otherwise they'll all hear advertisements and act on them)
  • upstart registration job: Switch to do it until it has successfully registered

Dependencies

  • CC registration: CLC running, CC sshd running, eucalyptus-cc installed on CC
  • SC registration: CLC running, SC sshd running, CC registered on CLC
  • Walrus registration: CLC running, Walrus sshd running
  • NC registration: CC running, CC registered, NC sshd running, eucalyptus-nc installed on NC

Sequence of events

(Advertisements may be asynchronous (e.g. Avahi) or synchronous (e.g. an RPC method call to the next thing up) but in either case there is an explicit sync point before going beyond registration.)

  • CLC installed (via UEC installer) and brought up
  • CLC advertises "I am the CLC"
  • CC installed (via UEC installer)
    • Look for CLC Avahi advertisement
    • If unsuccessful, fall back to prompting for CLC hostname/IP
  • CC boots, starts sshd
  • Attempt Avahi auto-registration
    • CC advertises "I am ready to be registered as foo"
    • CC waits until it has been registered, by polling for key presence
    • Meanwhile, CLC hears advertisement, registers CC (ensuring this is done only once)
  • If unsuccessful, fall back to registration service
    • CC connects to CLC and requests registration synchronously
  • CC notices it has been registered
  • CC advertises "cluster foo is registered"
  • Walrus installed (via UEC installer)
    • Look for CLC Avahi advertisement
    • If unsuccessful, fall back to prompting for CLC hostname/IP
  • Walrus boots, starts sshd
  • Attempt Avahi auto-registration
    • Walrus advertises "I am ready to be registered as foo"
    • Walrus waits until it has been registered, by polling for key presence
    • Meanwhile, CLC hears advertisement, registers Walrus (ensuring this is done only once)
  • If unsuccessful, fall back to registration service
    • Walrus connects to CLC and requests registration synchronously
  • SC installed (via UEC installer)
    • Look for CLC Avahi advertisement
    • If unsuccessful, fall back to prompting for CLC hostname/IP
  • SC looks for clusters on the local network, offers the user a choice of which one this SC "belongs" in
  • SC boots, starts sshd
  • Attempt Avahi auto-registration
    • SC advertises "I am ready to be registered as foo"
    • SC waits until it has been registered, by polling for key presence
  • If unsuccessful, fall back to registration service
    • SC connects to CLC and requests registration synchronously
  • Meanwhile:
    • CLC hears SC advertisement
    • CLC queries to check that cluster foo is registered
    • CLC registers SC with cluster foo
  • NC installed (via UEC installer)
    • NC looks for clusters on the local network, offers the user a choice of which one this NC "belongs" in
    • Fall back to prompting for CC hostname/IP
  • NC boots, starts sshd
  • Avahi auto-registration
    • NC advertises "I am ready to be registered with cluster foo"
    • CC hears NC advertisement
    • CC checks that the cluster name matches its name
  • CC waits until it has been registered itself
  • CC registers NC (ensuring this is done only once)

Alternative

Single registration service on CLC/CC with three modes:

  • Autoregister local network things (CC, CLC)
  • Autoregister anything (CLC only)
  • Disable autoregister (CC, CLC)

Advertisements

"Upward" unicast messages
  • CC to CLC "I am ready to be registered as foo"
  • SC to CLC "I am ready to be registered with cluster foo"
  • NC to CC "I am ready to be registered with cluster foo"
  • Walrus to CLC "I am ready to be registered" (also "I am the walrus")

"Downward" broadcast messages
  • CLC to CC, SC, Walrus "I am the CLC"
  • CC to NC "I am registered as foo"
  • CC to SC "I am registered as foo"

Implementation

Advertisement technology

  • Avahi
    • Pros: simple, no polling required
    • Cons: only works within a broadcast domain, or with a reflector proxy
  • Registration service running on the CLC (for Walrus, CC, SC) and CC (for NC)
    • e.g. CGI script accessible over HTTP
    • can store information rather than acting on it immediately, in the case that the CC is not yet registered but receives messages from SC/NC
    • requires explicit trust action by admin, since this constitutes the ability for anyone to register a cluster non-interactively

Need to be able to:

  • Install new cloud (CLC, Walrus, CC, SC, NC)
  • Add new cluster (CC, SC, NC...) to existing cloud
    • on a different broadcast domain from the CLC?
  • Add Node(s) to a cluster

Some advertisements are critical (for the registration), some other are informative (for discovery in the installer)

  • Listening daemon on CLC / CC waiting on advertisements?

Security concerns: autoregistration trusts any Walrus/CC/SC/NC that comes up

  • Use a shared secret?
  • Use "install mode"

Package installation

  • could the public keys be published via avahi to be used (with fingerprint confirmation) for configuration?

To do

  • State diagram for registration process
  • Decision on whether/how much to trust the network

CategorySpec