[08:51] <flaccid> erichammond: i have that image going RightScale managed in a deploy atm
[10:11] <erichammond> flaccid: I'm having trouble parsing that sentence.  Is it possible to rephrase?
[10:11] <flaccid> i have your latest ubuntu image running under rightscale and its script management
[10:12] <erichammond> Are you using the lightweight bootstrap init script or a full RightScale software install?
[10:13] <flaccid> im using basically what i ported from http://support.rightscale.com/06-FAQs/FAQ_0103_-_How_do_I_make_any_Amazon_Machine_Image_(AMI)_capable_of_running_RightScripts%3f which essentially a colleage in services here did a while ago
[10:15] <erichammond> I can't use that approach on the images I build because it significantly increases the image size (and startup time) just to support a service which most of the users aren't going to be using.
[10:16] <erichammond> If RightScale support can be added as a lightweight, optional feature which is only triggered when run inside the RightScale environment, then I'm happy to add it.  This seems to be the intent of the init script Martin provided.
[10:16] <flaccid> that was part of the reason why i was taking them upstream. i was unaware of this lightweight thing
[10:17] <erichammond> In both cases, I'd also be interested to know if there are any limitations in the RightScale support.  For example, I know that they enable RightScripts, but do the images also work with the monitoring, rebundling, and other integration features?
[10:18] <erichammond> Plus, I've heard that some of the more advanced RightScripts may have needed some polishing to work smoothly with Ubuntu, so it would be nice to hear if this has been done.
[10:19] <erichammond> At this point, it's all rumor and hearsay as I'm not actively testing RightScale beyond seeing that a simple RightScale startup script is run.
[10:19] <flaccid> as for the monitoring, the sys monitoring install script would need to be run and that would need to be compatible
[10:19] <flaccid> in terms of RightScripts in general, a lot are being updated, but there is still some that are not independent of distro etc.
[10:21] <flaccid> well eric, i am new, but i am there. personally i use debian in the cloude, not ubuntu or centos, so you can be assured i'll be following all this up. i had not rcvd any word on any new script that conditionally tested for debian lsb ..
[10:22] <erichammond> If you ever run into Uri, tell him I said hi.
[10:22] <flaccid> ah i'll ping him, i saw him last week; we were in the same motel
[10:23] <flaccid> he is very transient in terms of travel
[10:28] <erichammond> Also, if you are aware of a super-responsible, super-technical person/organization who cares deeply about Debian on EC2 and who might be interested in the thankless job of building, maintenance, and support of public Debian AMIs, I'd be interested in phasing out of this in the coming year.
[10:28] <flaccid> erichammond: oh and your note on start up time, i didn't do that as a boot script. i bundled it.
[10:28] <flaccid> erichammond: isn't that where I come in ?
[10:31] <erichammond> Time will tell :)
[10:31] <flaccid> sure..
[10:32] <flaccid> id like ec2 to upgrade xen so i can run freebsd
[10:32] <flaccid> so i settle for debian
[10:32] <erichammond> I'm not doing anything official, so anybody can really put forth a better (or as good) product and folks can migrate over.
[10:32] <erichammond> I'm willing to provide mentoring and guidance to anybody who is interested in tackling the project.
[10:33] <flaccid> i just see it as an ec2 ami and rs enabled branch
[10:33] <erichammond> My first point of guidance is: You have no idea what you're getting into.  You really don't want to do this.
[10:33] <flaccid> why is that
[10:33] <erichammond> If they're misguided enough to continue, then they've passed the first test.
[10:34] <flaccid> i'm sure i've tackled greater obstacles
[10:38] <erichammond> Building the first public AMI is the easy part.  It's the months and months of upgrading, testing, support, feedback, etc. where the initial glamor starts to wear off.
[10:38] <erichammond> There is also a lot of pressure to make sure that the AMIs are kept available as companies are depending on them for their business to stay afloat and for their individual livelihoods.
[10:39] <erichammond> Once you create a public AMI that folks are depending on, you can pretty much never delete it.
[10:39]  * Debolaz saves "Building the first public AMI.." line in his quote file for later lols.
[10:50] <erichammond> I'm going on two years in December and, though it's been personally rewarding in a number of ways, I am hoping my contributions to the community in another year will be taking on a different form.
[10:54] <flaccid> thanks for the info. i like to make the build process as automated as possible. i respect your AMIs and use them so its just a matter of where you want to go
=== erichammond1 is now known as erichammond
[21:00] <smoser> erichammond, just fyi, i talked with martin earlier regarding bug 434181 and he is thinking they'd like to go that way
[21:00] <uvirtbot> Launchpad bug 434181 in ec2-init "rightscale init script" [Low,Confirmed] https://launchpad.net/bugs/434181
[21:00] <smoser> it means they dont ever have to block on us as long as we keep a compatible run-user-data
[21:02] <erichammond> smoser: Good to know.  Seems like they'll have to solve a couple tough problems: How to determine if an AMI supports user-data scripts (not possible to do in the general sense); How to make user-data look the same to users who are passing in user-data within RightScale (though I suppose if users are using the RightScale API to access user-data it could be done).
[21:04] <smoser> well the first problem is easier than getting some arbitrary script included in everyone's images, and maintaining them there.
[21:04] <smoser> the second, yeah, i dont know whow they let users get at user data, this would result in them putting more there then they are currently.
[21:05] <smoser> they currently *do* put some stuff in user data though. something like:
[21:05] <smoser> RS_rn_id=427443, RS_rn_url=amqp://f946b5de28e3b64393e2e46d6e48f83311d2031d:fd729575f5b152823869ec22828c18358addd877@m..., RS_api_url=https://my.rightscale.com/api/inst/ec2_instances/3c5b532b9b035589cf6b3414c4be2f8817ab14d6,
[21:07] <erichammond> smoser: Right, I was aware of the first line which triggers the startup hooks, but their web interface also lets the user specify "user-data" which I thought was sent as the contents of user-data after that line.
[21:07] <smoser> i dont know. martinr mentioned to me "cross cloud"ness
[21:07] <erichammond> smoser: I haven't looked at this part in a couple years and they might implement the "user-data" outside of user-data.
[21:08] <smoser> and the inability to rely on user-data outside of ec2
[21:08] <erichammond> smoser: In any case, as long as they are willing to do the work, I'm thrilled.
[21:08] <smoser> so if they want to be at all cross-cloud for their users, giving raw access to user data meta service isn't probably good anyway
[21:09] <erichammond> smoser: Yep, it makes sense with all the expansion they've done beyond just EC2.
[21:10] <smoser> since your here...
[21:10] <smoser> if you want to try to put together suggested changes for "run at S99" bug, go ahead.
[21:11] <smoser> the thing i am dreading is that i'm going to get questioned on 2 init scripts being installed by that package .. as in bug 434693
[21:11] <uvirtbot> Launchpad bug 434693 in ec2-init "[MIR] ec2-init" [High,Incomplete] https://launchpad.net/bugs/434693
[21:12] <erichammond> smoser: I didn't notice an objection to multiple init scripts in that bug.
[21:13] <erichammond> Is this really the first package which had to do things at different rc priorities?
[21:13] <smoser> no. but objections to lots of things. and them not being proper init scripts anyway... i dont know. your'e right though nothing explicit against it.  but the lsb headers and such is a pita.
[21:16] <erichammond> smoser: So do you think the existing ec2-init script is going to have a lot of changes soon?  Should I wait for those before splitting it?
[21:17] <smoser> i dont think so.
[21:17] <smoser> oh. well, other than using echo versus lsb_functions
[21:17] <erichammond> smoser: ok, simple 'nuff
[21:18] <Debolaz> Hmm... I'm going to set up a secondary nameserver on EC2. I'm pondering how to push out the configuration file (named.conf) for it. Is this something I should be storing on S3, or is it better to just download it from our (non-ec2-)website?
[21:18] <erichammond> smoser: bzr+ssh://bazaar.launchpad.net/~ubuntu-on-ec2/ec2-init/trunk/ seems to have disappeared.
[21:18] <erichammond> What branch should I use as the base for the proposed changes?
[21:19] <erichammond> I have a note about bzr+ssh://bazaar.launchpad.net/~soren/ec2-init/0.5/ at some point in the recent past
[21:21] <smoser> yeah, thats what i have as trunk
[21:21] <smoser> soren is sick today, but i'd ask him what he wants. i'm not even really privy to publish a build
[21:21] <smoser> but i doubt its significantly different
[21:22] <smoser> erichammond, dont bother. ill try to do this tonight.
[21:22] <smoser> err.. wait. can't tonight.
[21:22] <smoser> but i'll get to it.
[21:57] <erichammond> smoser: ok, thanks
=== erichammond1 is now known as erichammond