[00:16] <SpamapS> argh!  WARNING: Invalid keys at [https://launchpad.net/~clint-fewbar/+sshkeys]
[00:18] <flaccid> lol
[00:18] <flaccid> all the above seems about the usual standard for ubuntu
[00:19] <flaccid> oh you are a canonical/ubuntu guy?
[00:49] <jair> hello everyone
[00:51] <jair> it is a requirement to download the server version 10.10 of ubuntu to use landscape and set up the private cloud? or it is the same kernel I have the alternate version 64bit 10.10 should that work?
[00:56] <jair> basically what I am asking do I need to download the version 10.10 server of ubuntu or in reality the version 10.10 desktop 64bit will have the same packages and capabilities?
[01:15] <flaccid> 3mins, uber patient :)
[09:27] <superxgl> hi all, i have running an instance : euca-run-instances $AMI_IMAGE  -k $KEY_NAME --addressing private -n 1 -g $CLUSTER_MASTER  -f "$bin"/$USER_DATA_FILE -t $INSTANCE_TYPE $KERNEL_ARG --ramdisk eri-A535178D
[09:27] <superxgl> and i have installed cloud-init package
[09:27] <superxgl> but i don't why "-f "$bin"/$USER_DATA_FILE" do not execute
[09:28] <superxgl> is there something wrong ?
[09:29] <superxgl> the file "$bin"/$USER_DATA_FILE" did *NOT* be executed
[09:36] <flaccid> you might wanna show the stdeer and exit code
[09:37] <TeTeT> yeah, is $USER_DATA_FILE a regular shellscript? Can you get it from the instance via wget?
[09:42] <superxgl> this is the shell script :   http://pastebin.com/mijcWEmc
[09:45] <flaccid> captcha, lame
[09:46] <flaccid> ok so where is the output?
[09:47] <superxgl> this shell script starts the hadoop daemon, no output
[09:49] <flaccid> you might wanna run it under -ex so you can see what is occurring with the commands.
[09:51] <superxgl> i have copy this file to my instance , and it can run correclty
[09:52] <superxgl> sorry, what do u mean run it under -ex  ?
[09:52] <flaccid> they are bash parameters
[09:52] <flaccid> going to dinner; bye
[09:53] <superxgl> flaccid : ok ,tkx.bye
[10:02] <superxgl> hmm...because it can running in the instance correclty, so i think the shell script is ok
[10:02] <superxgl> so i think maybe the cloud-init has problems
[10:03] <superxgl> http://pastebin.com/VTneuzuE
[10:13] <superxgl> TeTeT: how can i get it from the instance via wget ?
[10:14] <superxgl> wget from the instance meta-data ?
[10:18] <TeTeT> superxgl: hmm, don't know from the top of my head, something like wget http://169.254.169.254/current/userdata
[10:19] <TeTeT> superxgl: http://docs.amazonwebservices.com/AmazonEC2/dg/2007-01-03/AESDG-chapter-instancedata.html
[12:26] <superxgl> TeTeT: thnx. i will have a try
[12:27] <superxgl> TeTeT:  http://pastebin.com/5vRdxGy1
[12:28] <michael__> Is there a good opensource project for providing a layer ontop of ec2 or uec for scalable websites or webapps?
[12:28] <michael__> something like scalr.net
[12:28] <soren> scalr is open source.
[12:29] <TeTeT> superxgl: sorry, out of ideas then
[12:30] <superxgl> TeTeT: tkx. i will try finding it out
[12:31] <michael__> soren: yeah but it isn't perfect ;) I just wanted to ask for alternatives :D
[12:33] <soren> michael__: If you want better answers, ask better questions.
[12:33] <soren> michael__: Like, say, explain how scalr isn't meeting your needs.
[12:34] <michael__> scalr isn't stable yet, the current version has a lot of bugs
[12:34] <michael__> no automatic caching (no needed, but would be a great feature)
[12:35] <michael__> a Paas layer would be really cool. something like google app engine for uec
[12:36] <nwl> Cloud Foundry perhaps? :)
[12:41] <superxgl> where is the cloud-init's message output ?
[12:43] <TeTeT> superxgl: on the console, via euca-get-console-output <instance id>
[12:45] <superxgl> [root@CLC bin]# euca-get-console-output i-464C07BC
[12:45] <superxgl> i-464C07BC
[12:45] <superxgl> 2011-04-13T11:59:22.263Z
[12:45] <superxgl> NOT SUPPORTED
[12:46] <superxgl> hmm...eucalyptus not supported
[12:46] <superxgl> i found /var/log/cloud-init.log  ,but the file is blank
[12:53] <kim0> maybe /var/log/syslog
[13:00] <superxgl> kim0: i find all the file under /var/log, could not find.
[13:02] <kim0> superxgl: cd /var/log ; grep -r cloud-init * ?
[13:04] <superxgl> hereis the cloud-init file :   http://pastebin.com/LYyrxxJP
[13:05] <superxgl> -bash-3.2# cd /var/log ; grep -r cloud-init *
[13:05] <superxgl> rpmpkgs:cloud-init-0.5.14-23.amzn1.noarch.rpm
[13:08] <superxgl> maybe the cloud-init is not running ?
[13:14] <kim0> maybe the grepping is just not right too
[13:14] <kim0> that's an amazon linux instance right .. never used that before
[13:16] <superxgl> no, it's not an amazon linux instance, it's an eucalyptus instance
[13:16] <superxgl> but the cloud-init package is downloaded from the amazon linux instance
[13:17] <superxgl> maybe that's the problem ?
[13:17] <superxgl> maybe i have to change something ?
[13:18] <kim0> just use an ubuntu instance ? :)
[13:19] <superxgl> emm..but now i need to use centos instance
[13:21] <kim0> you'd have to dig deep then how the package starts with the system? rpm -ql cloud-init
[13:22] <kim0> is there a service, is it started, open the script, check where it logs ..etc
[13:24] <superxgl> kim0 :　oh, tkx. it is a really useful command.  http://pastebin.com/rfUS8Zjv
[14:37] <superxgl> http://open.eucalyptus.com/forum/mysql-server-eucalyptus-image-how      "This only works currently with Ubuntu guests and CentOS AMI guests."
[14:37] <superxgl> maybe not CentOS EMI guests
[14:39] <TREllis> smoser: I'm checking the latest cloud-init in natty... I want to use it on a baremetal install, I see the preseed values but I'm missing how I specify meta-data/user-data urls? can I do that as a kernel option?
[14:40] <smoser> yes...
[14:40] <TREllis> ie. If I seed it to 'NoCloud', How'd I seed /var/lib/cloud/seed...?
[14:40] <smoser> let me look.
[14:40] <smoser> theres kind of two ways i think
[14:40] <TREllis> I'm just poking around the code, but I thought asking you might be quicker :)
[14:41] <smoser> i would really like your help on getting this documented...
[14:41] <smoser> i think the 2 ways are something like:
[14:42] <smoser> a.) drop files ('user-data' and 'meta-data') in /var/lib/cloud/seed/nocloud-net
[14:42] <TREllis> Sure, I'm kinda documenting this as I go anyway but for a different project, should be easy to pull out the relevant bits
[14:43] <smoser> user-data can be empty, meta-data should have a value 'seedfrom: http://tinyurl.com/sm-'
[14:43] <TREllis> ah-ha :)
[14:43] <smoser> what will then heppen is it will pull from http://tinyurl.com/sm-meta-data and http://tinyurl.com/sm-user-data
[14:44] <smoser> the second way you can do this is via kernel command line. you can put cloud-config values in
[14:44] <TREllis> ok, so I'm thinking in a late_command I'll pull the meta-data and user-data files down then... or earlier in the boot grokking /proc/cmdline for urls
[14:44] <TREllis> ah so there is that already
[14:45] <superxgl>  curl http://202.115.132.66:8773/latest/user-data
[14:45] <superxgl> i can get the user-data
[14:46] <TREllis> superxgl: try doing that if you aren't actually on a cloud :-)
[14:46] <TREllis> ie. on baremetal
[14:49] <superxgl> TREllis:  sorry, i could not follow u. what do u mean " on baremetal" ?
[14:50] <smoser> TREllis, right. that will work.
[14:50] <smoser> or should
[14:51] <TREllis> smoser: but you say 2nd way, via kernel command line, what's the option 'user-data=url.to/user-data' ? ;-)
[14:51] <smoser> TREllis, ./doc/examples/kernel-cmdline.txt has info on how you feed the kernel command line
[14:52] <smoser> you can just set cloud-config values. and one of those values (i think) you can set is 'meta-data'
[14:52] <TREllis> superxgl: ie, you are installing a bunch of physical systems and you have zero meta-data service on your network
[14:52] <smoser> err... 'seed-from'
[14:53] <TREllis> smoser: ah-ha, found that file thanks, I'll write up a small post on it.
[14:55] <smoser> TREllis, please let me know what you find. i really apologize for not having done this myself.
[14:55] <smoser> but i would like to get the doc into cloud-init
[14:55] <TREllis> smoser: no worries, it's bleeding edge new stuff :)
[14:55] <smoser> and fix anything that doesnt work.
[14:56] <superxgl> TREllis ： sorry for my poor englist. so what should i do to get the cloud-init running ? i am still a little confused..
[14:57] <TREllis> on a related note, I notice that cobbler doesn't respect --kopts-post for ubuntu
[14:57] <TREllis> superxgl: sorry, I don't follow you, I was talking about a different topic
[14:58] <superxgl> TREllis : hmm...seems that you were talking about cloud-init , but i could not follow ;-)
[14:59] <TREllis> superxgl: we were discussing ways you can provide the same meta-data and user-data like ec2/eucalyptus for cloud-init but without using ec2 or eucalyptus
[15:01] <superxgl> TREllis : oic...it's exciting..
[15:04] <smoser> TREllis, bummer regading cobbler
[15:11] <TREllis> smoser: actually... it might just be me. I notice it only uses them in a post snippit which I'm not using, so as long as our grub2 works with 'grubby' it should be ok
[15:16] <superxgl> maybe i can use this way on my instances
[15:16] <superxgl> i will put the scripts on my instances
[15:17] <superxgl> and once the instance start , make the scripts running
[15:34] <superxgl> -bash-3.2# python /usr/bin/cloud-init
[15:34] <superxgl>   File "/usr/bin/cloud-init", line 48
[15:34] <superxgl>     except IOError as e:
[15:34] <superxgl>                     ^
[15:34] <superxgl> SyntaxError: invalid syntax
[15:34] <superxgl> looks like the script has some syntax errors ?
[15:46] <superxgl> ? looks like cloud-init uses python 2.6
[15:52] <superxgl> i have installed python 2.6, but my default version still is python 2.4
[15:54] <superxgl> but not this problem
[15:57] <superxgl> -bash-3.2# python /usr/bin/cloud-init
[15:57] <superxgl> Traceback (most recent call last):
[15:57] <superxgl>   File "/usr/bin/cloud-init", line 23, in ?
[15:57] <superxgl>     import cloudinit
[15:57] <superxgl> ImportError: No module named cloudinit
[16:27] <smoser> well, superxgl, i wonder how you installed, but you're not here.
[17:19] <TeTeT> smoser: from what I've seen it seems he copied the scripts to whatever os and hoped it would run
[18:20] <michael__> nwl yeah cloud foundry looks cool missing the php support :D
[18:21] <michael__> any other opensource layer for using uec as a scalable iaas or as a paas (like scalr.net or google app engine) thanks for suggestions
[18:21] <nwl> michael__: none that are very good or mature
[18:22] <michael__> yeah that'S my problem atm
[18:22] <michael__> scalr isn'T bad so
[18:22] <michael__> but paas would be awesome, but it should support php node.js at least
[18:30] <michael__> nwl openfoundry looks great they will add php support, but when :D
[19:01] <kim0> Hi everyone
[19:01] <kim0> Ensemble community weekly meeting starting
[19:02] <kim0> basically this meeting should help keep community members aware of ensemble development
[19:02] <kim0> I'll be directing any interested people to attend
[19:02] <kim0> also summaries of this meeting will be posted to planet ubuntu ..etc
[19:02] <hazmat> This week and last week in ensemble.. we've had a few things go in and a few things in progress. the overall status board for this milestone development (ends at UDS-O) is at http://people.canonical.com/~niemeyer/budapest.html
[19:03] <kim0> ideally, any future community contributions would be discussed as well
[19:03] <kim0> Since this is the very first time
[19:03] <kim0> I think it might be appropriate
[19:03] <niemeyer> We'll soon be moving that to https://ensemble.canonical.com, btw.. we're just getting the web site organized.
[19:03] <niemeyer> Well, s/organized/setup
[19:04] <kim0> to introduce what works "today" in ensemble .. and what is being worked on
[19:04] <kim0> niemeyer: Great
[19:04] <hazmat> Last week the ensemble-team landed some changes to formula authorship, specifically the relation-changed-hook was broken out into three separate hooks the relation-joined, relation-changed, relation-depart.
[19:05] <kim0>  hazmat care to explain why that split was needed
[19:05] <hazmat> Currently the team is working on a way for the admin to configure services, formula upgrades and fixes to recipes for the the hook change and bashifying our examples.
[19:06] <hazmat> kim0, in the course of three formula authors writing hooks, it became clear that none of them where getting the sequencing write on the exchange between services. Ensemble was calling the relation-changed hook with one three events join, changed, depart.
[19:06] <kim0> I think it makes sense to touch a bit deep on what each change would mean to a user or formula developer
[19:07] <jimbaker> it should be noted that the example recipes for wordpress and mysql have been updated to the new hook semantics seen with -relation-joined, -relation-changed, and -relation-departed
[19:07] <hazmat> join denotes that a unit of the related service came online
[19:07] <hazmat> change denotes the unit of a related service changed its settings
[19:07] <hazmat> depart  denotes the unit of a related service went offline
[19:07] <kim0> hazmat: perfect
[19:08] <kim0> hazmat: can you comment on the stuff you're doing for next week as well
[19:08] <hazmat> There are additional descriptions of what a service/service unit/ and relation in our online docs. http://j.mp/ensemble-docs
[19:08] <kim0> Thanks for noting that
[19:09] <kim0> hazmat: How is formula upgrades planned to work
[19:10] <hazmat> The problem was that formula authors where coding things to relation-change, but that created a subtle timing issue for the sequence, in a distributed system, the change may have already happened by the time the join event was recieved, such that there would be no changed.. The change event is generated/observed against the last time the unit saw the remote unit settings.
[19:11] <hazmat> Since it was clear this was a common and subtle issue, we decided to change the hook invocation, such that 1. the hooks where split out into relation-joined, relation-changed, and relation-broken
[19:11] <hazmat> 2. That relation-changed would always be invoked after relation-joined
[19:11] <kim0> Yeah makes sense
[19:11] <DigitalFlux> I think that makes sense from a configuration management point of view
[19:11] <hazmat> There's still some work to be do to upgrade the principia repository with these latest semantics
[19:12] <hazmat> So moving on to formula upgrades
[19:12] <kim0> Great way for anyone wanting to wet hands with ensemble .. would be fixing principia to the new hook semantics :)
[19:12] <jimbaker> (based on my experience, the upgrade to these new hook semantics is quite painless)
[19:12] <kim0> jimbaker: is there some pattern ?
[19:13] <jimbaker> kim0, basically what you see is that the handshaking becomes explicit
[19:13] <jimbaker> prior to the hook semantic changes, formula authors, including myself, were using the accidental ordering of hooks to do the handshaking
[19:14] <kim0> setup -> joined , tear-down -> departed right
[19:14] <jimbaker> now what you do in your script is you get your relation settings if you need to consume them. if not there, wait until they become available
[19:14] <hazmat> The scope of upgrades is pretty large when talking about an arbitrary services, for now to we're tackling an initial step of upgrading just the formula itself, after some back and forth, we'll be restricting formula upgrades to only those service units that are currently running, if its a broken state, it won't be upgraded. We're separately adding a notion of resolving workflow errors, with optional hook retry.
[19:14] <jimbaker> in your script it is as simple as doing an immediate exit 0 at the point of getting the setting
[19:15] <kim0> jimbaker: thanks for exaplining that .. guess reading the built-in examples is also a great way to read an example
[19:15] <jimbaker> (end of story on painless changes for new hook semantics, it's that simple)
[19:15] <hazmat> cool
[19:16] <hazmat> so back to upgrades, end result there will be two new ensemble subcommands, ensemble upgrade-formula --repository=examples mydbservice  to upgrade a service formula.
[19:16] <hazmat> and ensemble resolved [--retry] unit_name
[19:16] <kim0> hazmat: why isn't upgrading a formula as simple as departing an old service unit .. joining a new one .. or is it ?
[19:16] <hazmat> kim0, so we're doing formula upgrades, not service upgrades here
[19:17] <hazmat> ideally the semantic allows for seamless transition without bringing down units
[19:17] <kim0> hazmat: assuming our perfect example of a wordpres SU running, with a backend mysql SU running
[19:17] <hazmat> ie. no events are lost, all queued hook executions and observed changes would continue with the new formula
[19:17] <kim0> could you explain the steps for an upgrade please
[19:18] <kim0> how it's planned to work rather
[19:18] <hazmat> so say we've got three units of a wordpress service called myblog running
[19:18]  * kim0 nods
[19:18] <hazmat> i've got a new formula which enables some cool plugin in wordpress
[19:19] <hazmat> to upgrade the service, i'd run ensemble upgrade-formula --repository=$REPO_DIR myblog
[19:19] <hazmat> That will look into the repo directory for a formula matching the formula of myblog, verify its a newer revision, upload and it mark the units for upgrade.
[19:20] <hazmat> On the unit side, they'll detect they need upgrades, download the formula, ... and most importantly, execute the upgrade-hook from the new formula before any other hooks from the new formula are executed.
[19:21] <hazmat> As an additional restriction, to ease authorship of a upgrade hooks, we'll only be upgrading service units that are currently running.
[19:21] <kim0> aha .. a new  hook
[19:21] <hazmat> so if the service unit had failed to install or start correctly, it won't be upgradeable
[19:22] <hazmat> otherwise it becomes a very open-ended question of what the upgrade hook needs to consider
[19:22] <hazmat> if they can't make any assumptions about the environment their running in
[19:22] <kim0> Question: Is there some "good-bye" hook for the old version of the formula?
[19:23] <kim0> Question: Also, does "upgrade-hook" know which version it is upgrading from ? For instance some wordpress upgrades can have (or not) DB schema changes based on the version you're coming from
[19:23] <hazmat> kim0, there are two good-bye hooks depending on context, in the relation context, if a service is related to other services, if a service unit  goes away, those units will get a -relation-depart hook execution, if the service is removed or the relation between services is removed, they'll get a -relation-broken  hook execution.
[19:24] <hazmat> in the context of a service unit, if the unit is removed or shutdown (including if the service is removed), the 'stop' hook will be executed.
[19:24] <kim0> hazmat: yes but do any of depart or broken get fired in case of upgrade
[19:25] <hazmat> kim0, no.. they don't, the to mysql it looks like the service stays online the whole time
[19:25] <kim0> cool
[19:25] <kim0> wrt question2 .. what version the upgrade is starting from
[19:26] <kim0> is that known to upgrade hook
[19:26] <hazmat> the mysql units don't see any changes to the state of the wordpress unit... optionally we're looking in the future of allowing  an upgrade hook to iterate and  modify the relations of the unit, if a hook uses that api, then the remote side would see changes
[19:26] <hazmat> kim0, not yet, but that sounds like a good idea :-)
[19:26] <kim0> hehe cool
[19:27] <kim0> Ironically for "Wordpress" what version you're coming from matters a lot
[19:27] <kim0> Should I file a bug :)
[19:27] <hazmat> kim0, i'll add it the formula upgrade bug 750483
[19:27] <kim0> awesome
[19:28] <kim0> that sounds well covered
[19:28] <kim0> Any other points
[19:29] <kim0> hazmat: anything else ?
[19:30] <hazmat> nothing else comes to mind for me that's landing this week, bcsaller is doing service-config work which is very cool, but is going to be another week, jim's doing some work on exposing/securing services using ec2 security groups.
[19:30] <kim0> jimbaker: Wanna talk about anything
[19:30] <DigitalFlux> I hope i'm not interrupting, but As far as i remember, i did read somewhere that ensemble can depend on shell scripts or puppet to apply the configuration ..
[19:31] <jimbaker> currently ensemble deploys machines such that the firewall is open
[19:31] <hazmat> DigitalFlux, all hook are is effectively just an executable, those executable can be in any language and use any tools they'd like
[19:31] <kim0> DigitalFlux: Yeah it's a high level orchestration tool .. the "hooks" can be written in any language
[19:31] <DigitalFlux> I don't think that's in the docs, right ? http://people.canonical.com/~niemeyer/ensemble/index.html
[19:31] <kim0> DigitalFlux: two answers for the price of one ;)
[19:31] <kim0> Docs are very basic right now
[19:32] <kim0> DigitalFlux: Help make it better :) bzr branch lp:ensemble
[19:32] <jimbaker> we will be addressing such that the firewall is configurable by the ensemble user (ensemble expose, ensemble unexpose), with corresponding hooks (exposed, unexposed), and hook commands  (open-port, close-port)
[19:32] <niemeyer> kim0, DigitalFlux: Well, even suggesting improvements would already be welcome, if you don't have the time to push the changes yourself
[19:32] <kim0> jimbaker: wow that's cool stuff
[19:33] <jimbaker> DigitalFlux, it's described to a certain extent in the docs. i actually copy edited some text in the formulas that make it more explicit
[19:33] <jimbaker> formulas *section*
[19:33] <niemeyer> kim0: It is indeed!  Effectively an Ensemble user can just do "ensemble expose myblog" and that works
[19:33] <hazmat> niemeyer, do the draft/specs get published on the doc site?
[19:33] <niemeyer> hazmat: Yeah
[19:33] <hazmat> ah. there it is
[19:33] <kim0> What is open-port close-port ? why are those needed
[19:33] <hazmat> the expose work is described in further detail at http://people.canonical.com/~niemeyer/ensemble/drafts/expose-services.html
[19:34]  * kim0 clicks
[19:34] <jimbaker> kim0, we need to tell ensemble what ports a service needs opened
[19:34] <hazmat> and http://people.canonical.com/~niemeyer/ensemble/drafts/expose-services.html#service-exposing-for-formula-authors
[19:34] <jimbaker> there was some debate on whether to describe this in the metadata, but we decided that it was too restrictive to make it static
[19:34] <DigitalFlux> That's great !, i wil just have to read more about the hooks then ..
[19:34] <jimbaker> also, a service can open and close ports for a given service unit when that unit is in fact ready
[19:35] <hazmat> kim0, there's a notion that a service isn't nesc. running on a fixed port, that over time we'll need to do some negotiation for service ports, so that we can do multi-tenant on a machine
[19:35] <kim0> ah that's cool as well
[19:36] <hazmat> ie. run three units of different wordpress services on a single machine, each connected to a load balancer for the service.. even with lxc network namespace isolation, we'll be doing a nat against the host machine interface to the container network device.
[19:36] <kim0> does {open,close}-port operate on top of ec2 security groups ?
[19:36] <jimbaker> DigitalFlux, this copy editing is in a branch right now, see lp:~jimbaker/ensemble/new-hook-semantics-5-docs
[19:36] <hazmat> kim0, the mechanism is generic, in future we'll be utilizing machine level firewalls, but for now it will use ec2 security groups
[19:36] <hazmat> but such a change won't effect the formula-author or user workflow
[19:37]  * DigitalFlux pulling ..
[19:37] <jimbaker> this was another important reason - we wanted it provider independent
[19:37] <kim0> hazmat: so different backends .. i.e. in the future things like cisco firewall APIs would be useable right
[19:37] <kim0> without even formulas needing change! freaking awesome :)
[19:37] <niemeyer> alonswartz: How does it feel so far.. looks reasonable?  Anything we can help with?
[19:38] <niemeyer> kim0: Exactly!
[19:38] <kim0> jimbaker: Great stuff, anything else you want to comment on
[19:38] <DigitalFlux> Overwhelming :)
[19:38] <kim0> Indeed it is
[19:38] <hazmat> to be fair the implementation change won't effect them, but the introduction of port-negotiation/allocation might.
[19:38] <kim0> Only because it's the first time I suppose :)
[19:39] <hazmat> indeed
[19:39] <jimbaker> kim0, i think that pretty much covers it for me. i have some other work to smooth out rough edges and inconsistencies, as might be expected :)
[19:39] <kim0> Any special handling to RPC style services .. a la NFS
[19:39] <kim0> I guess it's a corner case
[19:40] <kim0> but why not bring that up :)
[19:40] <jimbaker> kim0, we have only considered a very simple mode of port opening, but potentially we could extend it
[19:40] <kim0> definitely makes sense
[19:40] <kim0> Great stuff indeed
[19:40] <jimbaker> we do cover tcp and udp, but not how it would interact with stateful firewalls for example
[19:40] <kim0> jimbaker: guess ec2 security groups cover those too as well
[19:41] <jimbaker> kim0, indeed, it was an easy mapping for now :)
[19:41] <kim0> um .. icmp ? ipsec ? future versions right
[19:41] <kim0> those not having a notion of port .. might be a bit problematic
[19:41] <jimbaker> i do believe the mechanism we have in place should readily support other protocols in the future, it's not restrictive on what open-port means for example
[19:42] <kim0> yeah let's leave it till then
[19:42] <kim0> cool
[19:42] <alonswartz> niemeyer: sorry, I had to handle a quick emergency...
[19:42] <niemeyer> alonswartz: Oh, no problem
[19:42] <kim0> alonswartz: hey
[19:42] <alonswartz> Hey kim0 :)
[19:42] <niemeyer> alonswartz: Was just wondering if we could help with anything you might be pondering about, since you already had some background on the project previously
[19:42] <kim0> o/
[19:42] <alonswartz> I didn't get to follow the whole conversation, but I do have a question
[19:43] <alonswartz> Is the project ready for outside collaboration yet?
[19:43] <kim0> It is!
[19:43]  * kim0 looks around
[19:44] <kim0> bzr branch lp:ensemble
[19:44] <niemeyer> alonswartz: Absolutely
[19:44] <niemeyer> alonswartz: The whole development happens in the open
[19:44] <kim0> alonswartz: https://lists.ubuntu.com/mailman/listinfo/Ensemble
[19:44] <niemeyer> alonswartz: Open IRC channel, mailing list, source code, etc
[19:44] <alonswartz> I have to admit I haven't looked into ensemble since my brush with it at UDS-M
[19:45] <niemeyer> alonswartz: We've come a long way.. it actually works now :-)
[19:45] <kim0> hehe
[19:45] <alonswartz> but it seems you have made great head way
[19:45] <alonswartz> I'll read up the docs, take it for a spin, and then I'll be more clued up as to the design, and hopefully have ideas on how I can help
[19:46] <kim0> bcsaller: o/
[19:46] <bcsaller> hmm?
[19:47] <alonswartz> OT, I saw you chose to use txaws. out of curiosity, why not boto? does ensemble use async?
[19:47] <kim0> It's the first time
[19:47] <kim0> bcsaller: So you're free to comment on anything you like :)
[19:47] <bcsaller> I think I'll have more new stuff to show next week
[19:47] <jimbaker> alonswartz, we use twisted completely
[19:48] <jimbaker> (this works better with the underlying zookeeper implementation)
[19:48] <kim0> bcsaller: sure thing .. we're not limited to last week though for this time ..
[19:48] <alonswartz> before I ask stupid questions that are answered in the docs, I'll read them first...
[19:49] <kim0> Alrighty
[19:49] <hazmat> we debated a while ago about twisted vs. eventlet/gevent.. but its done at this point.
[19:49] <alonswartz> but I can't help myself, does/will (or how does) ensemble handle scaling ?
[19:49] <jimbaker> short answer: yes!
[19:49] <kim0> as in add service units in runtime
[19:49] <hazmat> alonswartz, at the moment, you can scale via adding removing units to any service in the environment
[19:49] <kim0> I think it already does huh
[19:50] <alonswartz> so the user needs to do it manually, right? there isn't a master ensemble server that handles it transparently...
[19:50] <jimbaker> alonswartz, again i'd refer you to our docs, many of the hooks deal with scaling up and down
[19:50] <hazmat> there isn't any autoscaling exposed at the moment, just the ensemble command line to do it.
[19:51] <hazmat> alonswartz, but its a bit more automated than manual.. if i have mediawiki connected to mysql, memcached, and haproxy.. adding a unit of mediawiki, auto configures it with all those other services.
[19:51] <alonswartz> fair enough, i'll read the docs and come back with better questions :)
[19:52] <kim0> Open topic .. any comments, questions
[19:52] <niemeyer> Thanks all!
[19:52] <jimbaker> the one thing we don't do that's part of the autoscaling is automatically determine how many service units you need. that would seem to depend on your specific stack needs
[19:52] <kim0> Can't believe we almost consumed the full hour
[19:52] <kim0> this was a blast
[19:52] <niemeyer> jimbaker: That's up for debate
[19:53] <jimbaker> but we do handle the orchestration, and that's a differentiating factor compared to say puppet
[19:53] <niemeyer> jimbaker: We haven't covered that topic yet, so let's not provide the impression we're not doing it when in fact we really have to think through the use cases.
[19:53] <kim0> I would want to hook auto-scaling to some performance-measuring-hook
[19:53] <jimbaker> niemeyer, agreed
[19:53] <niemeyer> kim0: Exactly
[19:53] <kim0> lovely
[19:53]  * kim0 hugs Ensemble
[19:54] <alonswartz> Thanks folks!
[19:54] <kim0> Thanks niemeyer jimbaker bcsaller hazmat alonswartz DigitalFlux
[19:54] <kim0> Meeting end
[19:54] <jimbaker> kim0, thanks for organizing this
[19:54] <bcsaller> kim0: thanks
[19:54] <kim0> Thank you folks .. This is really exciting stuff
[19:55] <DigitalFlux> Yeah, Thanks kim0
[19:55] <kim0> Lovely Ubuntu communities hehe :)
[19:56] <DigitalFlux> autoscaling with upper limits for the resources would be AWESOME !
[19:56] <kim0> ec2 limits you to 20 instances any way :P
[19:56] <DigitalFlux> kim0: Oh, didn't know that
[19:57] <kim0> you have to explictly ask them to raise that limit
[19:57] <DigitalFlux> But still, if that can be done based on some metrics that i specify, and machines will scale up and down ..
[19:57] <DigitalFlux> Well, i will have to quit my job then :-)
[19:58] <kim0> DigitalFlux: ec2 has some form of that
[19:58] <kim0> they can monitor load average and auto-scale up/down
[19:58] <kim0> TEH cloud :)
[19:58] <kim0> BUT
[19:58] <DigitalFlux> So what form of orchestration do you point to here ?
[19:58] <alonswartz> kim0: ec2 has a 20 instance limit?
[19:58] <kim0> ec2 would "scale" by launching you an instance and you're on your own
[19:58] <DigitalFlux> jimbaker: So what form of orchestration do you point to here ?
[19:59] <DigitalFlux> kim0: ofc
[19:59] <kim0> alonswartz: yeah afaik .. you can raise it
[19:59] <kim0> you'd just have to contact them
[19:59] <kim0> or use a different account ..
[20:00] <kim0> DigitalFlux: with ensemble .. you're not on your own
[20:00] <kim0> an instance is fired, hooks are triggered to configure it and join it to neighbour instances
[20:00] <alonswartz> kim0: good to know. I didn't know they had a limit.
[20:00] <DigitalFlux> kim0: That's the new slogan for the project ? :-)
[20:00] <kim0> alonswartz: you probably wanna check that too :)
[20:01] <kim0> dont depend on my leaky memory .. but I found traces of that on google .. so I'm probably not making it up
[20:01] <alonswartz> i was planning on spinning up a 100 instance cluster (for a batch job), so I'll need to look into that
[20:01] <kim0> hehe perfect timing
[20:02] <alonswartz> i'll report back :)
[20:02]  * kim0 is interested what would need 100 instances
[20:03] <alonswartz> kim0: batch build of all turnkey appliances, all target formats, all amazon regions, all...
[20:04] <alonswartz> the list goes on and on ..
[20:04] <kim0> a ha .. got it
[20:04] <kim0> one thing I disliked about ec2 .. is their biggest instance is 64G ram
[20:04] <alonswartz> add 64bit to the equation and it spirals out of control...
[20:05] <kim0> a friend of mine doing scientific numerical analysis needs a bigger rig .. any suggestions
[20:22] <jimbaker> DigitalFlux, sorry was in another meeting
[20:23] <DigitalFlux> jimbaker: no probs, i'm in another one right now :)
[20:23] <jimbaker> ensemble ensures that all hooks are fired on all service units, in the correct order
[20:24] <DigitalFlux> jimbaker: you mentioned orchestration
[20:24] <jimbaker> so this is what i would describe as orchestration
[20:24] <DigitalFlux> hmm, and puppet doesn't do something similar ?
[20:24] <jimbaker> a given service unit only needs to take care of itself, responding as its hooks fire
[20:25] <jimbaker> puppet/chef is very different. it's top down. and because there's a need to worry about the layout, it's hard to write generic recipes
[20:26] <DigitalFlux> yeah, there have been some efforts done to enhance this, but i guess the model is still different than ensemble
[20:26] <DigitalFlux> I need to work on how can i get both of the worlds i guess
[20:26]  * DigitalFlux needs to do some lab
[20:27] <jimbaker> DigitalFlux, it's definitely a different model. one thing i was challenged on is that puppet better accommodates a model of sysadmins actually logging into a machine and messing around
[20:28] <jimbaker> this is defended on the basis that critical fixes must be done and now ;)
[20:28] <jimbaker> i think the cloud model where we don't care about specific machines is inherently better for this
[20:29] <DigitalFlux> hmm, considering puppet+mcollective, wouldn't that be already solved using this combination ?
[20:29] <jimbaker> as i recall mcollective, we still have a better foundation in zookeeper, which gives us total ordered events and a consistent, durable view of the world
[20:30] <kim0> jimbaker: I would love to capture that in plain English in a faq page :)
[20:30] <jimbaker> but i can really talk best about ensemble
[20:30] <kim0> did niemeyer check mcollective as well
[20:30] <kim0> and how ensemble would compare
[20:31] <jimbaker> kim0, it really comes straight from a zookeeper faq, but there are some ensemble considerations that need to be mixed in
[20:32] <kim0> jimbaker: I'm adding a faq page tomorrow .. so would love if you could explain a bit more how ensemble is different from puppet+mcollective
[20:32] <jimbaker> i'm probably not the best person on the team, but i'm sure we can help there
[20:33] <niemeyer> kim0: There's absolutely nothing like Ensemble out there
[20:33] <kim0> niemeyer: I'm writing a faq page tomorrow
[20:33] <kim0> some nice explanations are most welcome :)
[20:33] <niemeyer> kim0: Not even close.. the perspective taken is completely different
[20:33] <niemeyer> kim0: https://j.mp/ensemble-docs  should help
[20:34] <kim0> I guess I should read more about mcollective :)
[20:34] <niemeyer> kim0: I think this is the wrong perspective..
[20:35] <niemeyer> kim0: Documentation on Ensemble should be produced to demonstrate its merits, and why we're developing it
[20:35] <niemeyer> kim0: There's no point in *starting* with something like a competition shootdown
[20:35] <kim0> niemeyer: yeah but how is ensemble different from puppet/chef and how it relates to augeas, mcollective...etc is FAQ I think
[20:36] <kim0> Not that I'd talk down other tools .. each has a purpose in life
[20:36] <niemeyer> kim0: Show why we're developing Ensemble, why it rocks, why we love what we're doing
[20:36] <niemeyer> kim0: Let people figure by themselves how it compares
[20:36] <jimbaker> kim0, fwiw, we recommend using augeas w/ ensemble
[20:36] <kim0> jimbaker: awesome
[20:37] <jimbaker> it's a nice tool that's perfectly matches w/ what ensemble does
[20:37] <jimbaker> vs say using puppet templates, which could be done, but just brings in more unnecessary stuff
[20:38] <jimbaker> principia currently demonstrates the use of augtool, and the bashified examples i've been working on will add it in a future branch
[20:41] <kim0> jimbaker: does ensemble discourage templates ..
[20:42] <jimbaker> kim0, not at all. they can be the only way to accomplish certain things. but augtool is more robust
[20:43] <jimbaker> assuming the lens exist (writing them is more complicated however)
[20:44] <jimbaker> however, one can readily write templates in nearly any language. the bashified examples for example demonstrate that with bash here docs
[20:44] <jimbaker> everything the template needs can simply be obtained from the necessary settings
[20:46] <jimbaker> the local scope that a hook runs in - it only has to work on changing its service unit and coordinating through settings - makes it unnecessary to do more complicated things in the templates
[20:46] <jimbaker> ensemble really has this wonderful simplicity about it. i think that is what excites us a team
[20:46] <jimbaker> as a team
[20:46] <kim0> always a sign you're doing things the right way :)
[20:47] <jimbaker> kim0, indeed. that's why the apt for the cloud is so appropriate as a way of conceptualizing what we are trying to do
[20:48] <jimbaker> even if we are working just on the dpkg part right now
[20:48] <kim0> hehe indeed!
[20:59] <Heartsbane> so I am curious with the example listed at https://help.ubuntu.com/community/UEC/BundlingImages
[21:00] <kirkland> Heartsbane: hi, trouble bundling?  what's your error?
[21:00] <Heartsbane> I keep getting Invalid certfailed to upload kernel
[21:01] <Heartsbane> failed to bundle kernel lucid-server-uec-amd64-vmlinuz-virtual
[21:01] <Heartsbane> failed: euca-bundle-image --destination /tmp/uec-publish-image.ljX0Sp --arch x86_64 --image /tmp/uec-publish-image.ljX0Sp/.rename.ulD5ZK/lucid-server-uec-amd64-vmlinuz-virtual --kernel true
[21:01] <Heartsbane> x86_64
[21:01] <Heartsbane> I am trying to understand what is happening there
[21:02] <Heartsbane> I am assuming there is more reading that someone can suggest or refer me too
[21:36]  * Heartsbane kicks himself over and over and over and over.
[21:37] <Heartsbane> sorry I figured it out ... time for more caffeine
[21:40] <Heartsbane> it was such a little thing :(
[21:41]  * Heartsbane is a ashamed.
[21:47] <michael__> any suggestions for a good layer on top of uec? in the way of scalr.net or google app engine? should be opensource.
[22:23] <SpamapS> interesting presentation about 'Xeround' at the MySQL UC
[22:23] <SpamapS> michael__: just pick your favorite language/framework
[22:26] <michael__> SpamapS: and how to make it scalable in the uec ?
[22:26] <michael__> I would like to run a few projects in a scalable way with a bit of failover resistance sorta