Ubuntu Wiki

   1 [20:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/24/%23ubuntu-classroom.html following the conclusion of the session.
   2 [20:01] <obino> thanks Edulix
   3 [20:01] <obino> very nice presentation
   4 [20:02] <obino> I am graziano obertelli and I work at eucalyptus systems
   5 [20:02] <obino> feel free to ask questions at any time
   6 [20:02] <obino> if they are about eucalyptus I may be able to answer them :)
   7 [20:03] <obino> Eucalyptus powers the UEC
   8 [20:04] <obino> Ubuntu added a nice themes to Eucalyptus, the image store and very nifty way to autoregister the components
   9 [20:04] <obino> which makes it a breeze to install UEC on Ubuntu clusters
  10 [20:05] <obino> at http://open.eucalyptus.com/learn/what-is-eucalyptus you can quickly check what is eucalyptus
  11 [20:05] <obino> with it you can have your own private cloud
  12 [20:05] <obino> currently Eucalyptus supports AWS EC2 and S3 API
  13 [20:06] <obino> thus a lot of clients tools written for EC2 should work with Eucalyptus
  14 [20:06] <obino> minus minor changes like the endpoint URL
  15 [20:07] <obino> Eucalyptus has a modular architecture: there are 5 main components
  16 [20:07] <obino> the cloud controller (CLC)
  17 [20:07] <obino> walrus (W)
  18 [20:07] <obino> the cluster controller (CC)
  19 [20:08] <obino> the storage controller (SC)
  20 [20:08] <obino> and the node controller (NC)
  21 [20:08] <obino> the CLC and W are the user facing components
  22 [20:08] <obino> they are the endpoints for the client tools
  23 [20:08] <obino> respectively for the EC2 API and for the S3 API
  24 [20:09] <obino> there has to be 1 CLC and 1 W per installed cloud
  25 [20:09] <obino> and they need to be publicly accessible
  26 [20:09] <obino> the CC is the middle man
  27 [20:10] <obino> it controls a set of NCs
  28 [20:10] <obino> and reports them to the CLC
  29 [20:10] <obino> it controls the network for the instances running on its NCs
  30 [20:11] <obino> there can be multiple CCs in a cloud
  31 [20:11] <obino> the SC usually sits with the CC
  32 [20:11] <obino> there has to be one SC per CC
  33 [20:11] <obino> otherwise EBS won't be available for that cluster
  34 [20:12] <obino> SC and CC needs to be able to reach (talk to) the CLC and W
  35 [20:12] <obino> the NC is the real worker
  36 [20:12] <obino> instances runs on the machine hosting the NC
  37 [20:13] <obino> the previous tutorials explained a great deal of the user interaction, so I'll talk a bit of the behind the scene
  38 [20:14] <obino> for example what happened when an instance is launched
  39 [20:14] <obino> the CLC receive the requests
  40 [20:15] <obino> depending on the 'zone' the request asks, it will select the correspondent CC
  41 [20:15] <obino> after of course having checked that there is enough capacity left in that zone
  42 [20:15] <obino> with it is sends information about the network to set up for the instance
  43 [20:16] <obino> since every instance belongs to a security group and each security group has its own private network
  44 [20:17] <obino> the CC will then decide which NC will run the instance
  45 [20:17] <obino> based on the selected scheduler
  46 [20:17] <obino> and it will setup the network for the security group
  47 [20:18] <obino> this step is dependent on how Eucalyptus is configured, since there are 4 different Networking Modes
  48 [20:18] <obino> once the NC receives the requests it will need to emi file (the root fs of the future instance)
  49 [20:19] <obino> the NC keeps a local cache for the previous emi it saw before
  50 [20:19] <obino> it's a LRU cache so the least used image will be evicted if the cache grows too big
  51 [20:19] <obino> so the NC will check first to see if the emi is in the cache
  52 [20:20] <obino> if not it will have to contact W to get it
  53 [20:20] <obino> this is why W needs to be accessible by the NCs
  54 [20:20] <obino> of course it's not only the emi that the NC downloads but the eki and the eri too
  55 [20:21] <obino> once the image is transferred. it is copied into the cache first
  56 [20:22] <obino> after that the emi, eki and eri are assembled for the specific hypervisor the NC has access to
  57 [20:22] <obino> so, in the case of KVM, a single disk is created
  58 [20:22] <obino> the size of which depends on the configuration the cloud administrator gave to the instances
  59 [20:23] <obino> and the emi is copied into the first partition
  60 [20:23] <obino> the 3rd partition is populated with the swap
  61 [20:23] <obino> and the second one will be ephemeral
  62 [20:24] <obino> libvirt is finally instructed to start the instance
  63 [20:25] <obino> and of course the NC will take all the steps to setup the network  for the instance
  64 [20:25] <obino> from this quick run down, you will see why the first time an instance is booted on one NC takes longer
  65 [20:26] <obino> there is an extra network transfer (from W) and an extra disk copy (to populate the cache) that takes place
  66 [20:27] <ClassBot> smoser asked: is Eucalyptus expecting to have EBS-root and accompaning API calls (StartInstances StopInstances ...) ?
  67 [20:27] <obino> boot from EBS is expected to be in the next release
  68 [20:28] <obino> at least that's what they told me :)
  69 [20:28] <obino> I'm not sure about the start and stop instances call
  70 [20:29] <obino> the above instance life cycle that I went through should be helpful to understand how to debug the most frequent problem on a Eucalyptus installation
  71 [20:29] <obino> the instance won't reach running state
  72 === smspillaz is now known as smspillaz|zzz
  73 [20:30] <obino> from the above is easy to see that starting backward may be helpful
  74 [20:30] <obino> so starting from the NC logs to see if the instance started correctly (or at least libvirt tried to start it)
  75 [20:30] <obino> and if nothing is there, check the CC logs
  76 [20:30] <obino> to finish with the CLC logs
  77 [20:32] <obino> despite the complexity, eucalyptus is fairly easy to install
  78 [20:32] <obino> and the UEC has taken this step even further
  79 [20:32] <obino> so if you want to play with Eucalyptus or the UEC, you just need 2 machines available
  80 [20:33] <obino> if instead you want to play with Eucalyptus before installing to see what is can do and how good is the EC2/S3 APIs
  81 [20:33] <obino> then you can try our community cloud http://open.eucalyptus.com/CommunityCloud
  82 [20:33] <obino> called ECC
  83 [20:34] <obino> the ECC is available to everybody
  84 [20:34] <obino> the SLA are designed to avoid abuses
  85 [20:35] <obino> so your instance(s) will be terminated after 6 hours of running time
  86 [20:35] <obino> you can of course re-run instances at will, but no more than 4 at any point in time
  87 [20:35] <obino> same idea for the bucket, volumes and snapshots
  88 [20:36] <obino> the ECC runs the latest stable version of Eucalyptus, currently 2.0.2
  89 [20:37] <obino> if you are a developers and you are more insterested in the code and architecture, we have assembled few pages at http://open.eucalyptus.com/participate/contribute
  90 [20:37] <obino> which may be useful
  91 [20:38] <obino> starting from our launchpad home, and the API version we support
  92 [20:39] <obino> we have 2 launchpad branches, for stable version and for the development of the next version
  93 [20:39] <obino> both are accessible of course
  94 [20:39] <obino> we provide also some 'nightly builds'
  95 [20:40] <obino> they are actually produced on a weekly basis, but they kept the name
  96 [20:40] <obino> finally we give some information on how to contribute back to eucalyptus
  97 [20:41] <obino> and the final page is an assortment of various tips which may be of use to developers
  98 [20:41] <obino> like debugging tricks, or using eclipse or partial compile/deploy
  99 [20:41] <obino> we are hoping to expand this area sooon
 100 [20:42] <obino> finally under http://open.eucalyptus.com/participate you will see various ways to interact with us and Eucalyptus
 101 [20:42] <obino> in particular the forum is quite active and it is quite a resource to solve issues
 102 [20:43] <obino> as well as the community wiki
 103 [20:43] <obino> is there anything in particular that you want to hear about eucalyptus?
 104 [20:44] <obino> of questions?
 105 [20:44] <obino> *or*
 106 [20:44] <obino> well then, it looks like I managed to put everyone to sleep! :)
 107 [20:45] <obino> this http://open.eucalyptus.com/contact contains all the different ways to reach us in case you have questions
 108 [20:46] <obino> and of course there is the UEC page https://help.ubuntu.com/community/UEC
 109 [20:47] <obino> which contains very good information about Eucalyptus/UEC
 110 [20:48] <ClassBot> tonyflint1 asked: are there any plans for addition tools/utilities/documentation for creating custom images?
 111 [20:49] <obino> we currently have few pages under our community wiki under the tab images http://open.eucalyptus.com/wiki/images
 112 [20:49] <obino> which could be a chore at times
 113 [20:50] <obino> but they are useful to understand how things works
 114 [20:50] <obino> most of the EC2 images should work with UEC/Eucalyptus
 115 [20:50] <obino> so any way you have to generate images should work
 116 [20:51] <obino> the kernel/initrd combination depends of course from the hypervisor the instances will use
 117 [20:51] <ClassBot> There are 10 minutes remaining in the current session.
 118 [20:52] <obino> in short we don't have short term plan to generate new tools but we are working with the current tools to make sure they are compatibles with eucalyptus
 119 [20:52] <obino> if you have a favorite tool to generate images, let us know :)
 120 [20:52] <obino> tonyflint1: does it answer your question?
 121 [20:55] <ClassBot> gholms|work asked: Boxgrinder seems to be a decent tool for building images.  Any idea if that works with Ubuntu?
 122 [20:55] <obino> good question
 123 [20:55] <obino> we are in contact with a developer (marek) of boxgrinder, who has been very helpful so we are hoping to have an official eucalyptus plugin soon
 124 [20:56] <obino> as for the question itself it could be interpreted in 2 ways: will boxgrinder create ubuntu images? or will boxgrinder be packaged for ubuntu?
 125 [20:56] <ClassBot> There are 5 minutes remaining in the current session.
 126 [20:57] <obino> both are probably better answer by the boxgrinder developers
 127 [20:57] <obino> I would hope yes
 128 [20:57] <obino> boxgrinder should be fairly portable
 129 [20:58] <obino> and it has a nice plugin structure
 130 [21:00]  * kim0 claps 
 131 [21:00] <kim0> Thanks a lot for this wonderful session
 132 [21:00]  * obino bows
 133 [21:01] <kim0> Alright everyone .. Thank you for attending Ubuntu Cloud Days
 134 [21:01] <kim0> I hope it was fun and useful
 135 [21:01] <kim0> You can find us at #ubuntu-cloud
 136 [21:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/24/%23ubuntu-classroom.html
 137 [21:01] <kim0> and feel free to ping me personally later
 138 [21:01] <kim0> Thanks .. best regards .. till next time