21:01:02 <gholms> #startmeeting Cloud SIG (30 Sep 2010)
21:01:02 <zodbot> Meeting started Thu Sep 30 21:01:02 2010 UTC.  The chair is gholms. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:01:07 <gholms> #meetingname cloud
21:01:07 <zodbot> The meeting name has been set to 'cloud'
21:01:13 <gholms> #chair rbergeron
21:01:13 <zodbot> Current chairs: gholms rbergeron
21:01:25 <rbergeron> #topic Roll Call!
21:01:30 * jsmith is here, but will be in/out
21:01:42 * jgreguske present
21:01:42 <gholms> bacon
21:01:46 * jforbes is here
21:01:54 * rbergeron loooooves bacon
21:02:07 <rbergeron> hey, jgreguske :)
21:02:12 * rbergeron waves hai to jforbes
21:02:20 <jgreguske> hey there
21:02:20 * obino is here at least for a little bit
21:02:25 <jforbes> heya
21:02:32 <rbergeron> heya obino
21:02:39 <rbergeron> #topic EC2 status update
21:02:40 <obino> hi!
21:02:51 <rbergeron> jforbes: take it away, sir :) any updates or fun stuff to talk about?
21:02:57 <rbergeron> #chair jforbes
21:02:57 <zodbot> Current chairs: gholms jforbes rbergeron
21:02:58 <gholms> mmcgrath and mdomsch are also here to provide input on mirror-related stuff.
21:03:16 <brianlamere> reading
21:03:20 <mmcgrath> yo yo
21:03:30 <rbergeron> oooh, we're a full house today :)
21:03:33 <rbergeron> excellent
21:03:54 <eric-smith> I have a comment on the mirror proposal. Should I wait, or do you want it now?
21:04:06 <rbergeron> gholms: thoughts?
21:04:15 <gholms> Let's see what jforbes has to say, first.
21:04:19 * mmcgrath is multitasking but here.
21:04:23 * rbergeron was going to see if jforbes had any immediate feedback on ec2 stuff
21:04:25 * skvidal is listening
21:04:25 <gholms> (My topics tend to run rather long)
21:04:25 <jforbes> Right, so we have released beta, which means we have to get beta images pushed ASAP.  The ks file required a few changes, but the images are building now.  Basically I want F14 beta images up by tuesday
21:04:34 <rbergeron> nice!
21:05:01 <jgreguske> jforbes: this can be taken off-meeting, but I'm interested in how you're building them
21:05:04 <rbergeron> #info We've released beta, which means we need to get beta images pushed asap. the ks file required a few changes, but images are building now. jforbes wants f14 beta images up by tuesday
21:05:08 <jforbes> Slightly limited by my upstream, we should have images up tonight
21:05:24 <jforbes> jgreguske: appliance-tools for actual build
21:05:38 <jforbes> then euca2ools for the ec2-api-tools pieces
21:05:53 <jgreguske> jforbes: cool. You may be interested to know that recent versions of koji can build appliances with appliance-tools
21:06:05 <gholms> O.o
21:06:22 <jforbes> jgreguske: that is interesting indeed
21:06:27 <jforbes> any docs on that?
21:06:32 <skvidal> jgreguske: intersting - that can build appliances can koji build IN the applicance?
21:06:35 <jgreguske> jforbes: with the right permissions and tag set up you can use the spin-appliance directive
21:06:59 <jgreguske> jforbes: no docs right now on appliances, but there are some for koji building livecds
21:07:06 <jgreguske> it's basically the same idea
21:07:09 <dgilmore> jgreguske: its not enablked and tested in fedora yet
21:07:18 <dgilmore> jgreguske: but its on my todo list
21:07:28 <jgreguske> dgilmore: I know, I'm trying to light that fire :P
21:07:34 <dgilmore> :)
21:07:37 * rbergeron cues up the doors
21:07:54 <jgreguske> the approach is mock chroot, install whatever-tools into it, and run that in the chroot
21:07:54 * dgilmore has a bunch of koji changes to do soon
21:08:09 <jgreguske> koji will track what RPMs where added to the image
21:08:17 <gholms> #info koji has a spin-appliance directive that constructs inside mock chroots, though it is untested with Fedora
21:08:18 <jgreguske> as well as keep the ks file around next to the image
21:08:56 <jgreguske> dgilmore: I should have more cycles to help with that testing should you need me
21:09:04 <jforbes> That is very nice indeed, would make life much easier
21:09:05 <dgilmore> jgreguske: excellente
21:09:34 <gholms> #action dgilmore and jgreguske to test koji spin-appliance
21:09:35 <jgreguske> if you folks want I can take an action item to propose it more formally
21:09:43 <gholms> jgreguske: :)
21:09:46 <rbergeron> jforbes: anything you need help with as far as getting the beta up?
21:09:53 <rbergeron> jgreguske: that would be awesome.
21:09:55 <jgreguske> instead of dropping a surprise bomb in a meeting and expecting Stuff to happen :)
21:10:11 <jforbes> rbergeron: more bandwidth?  That is the limiting factor ATM
21:10:38 <jforbes> rbergeron: but once images are up I wil post for a couple of people to test before we make the more broad announcement
21:11:06 <brianlamere> ok, made a comment on the discussion page
21:11:13 <dgilmore> jgreguske: submit it as a feature for F-15
21:11:23 <gholms> Is that really a feature?
21:11:27 * rbergeron sends jforbes a magical time-development machine
21:11:42 <dgilmore> gholms: its lets us track it and make sure its done in a visable way
21:11:46 <gholms> True
21:11:55 <dgilmore> gholms: there are other benefits to it beinga  feature
21:12:13 <brianlamere> jforbes:  if you could include me in the list of testers that would be spiffy :)
21:12:35 <jforbes> Actually, I will try to give it a spin tomorrow morning, since it would make for a cleaner handoff to releng
21:13:18 <gholms> Before I forget:
21:13:26 <gholms> #info Boxgrinder people are looking into using euca2ools instead of ec2-api-tools
21:13:28 <gholms> #link https://jira.jboss.org/browse/BGBUILD-55
21:13:34 <jforbes> brianlamere: I will put the test request to the cloud list, that was what I meant by more limited and a fedora planet and testers/devel list announcement
21:13:47 <brianlamere> ah, ok
21:14:20 <brianlamere> gholms:  did you see my comment on the discussion side of your proposal link?
21:14:22 <jforbes> err more limited than a testers/devel list announcememnt I mean
21:14:24 <gholms> brianlamere: Yes
21:15:07 <brianlamere> the "fedora-(region name)" is the pattern already in place by others, and what Ben@AWS suggested we attempt to use as well
21:15:54 <brianlamere> I have all the current and predicable future names there already
21:16:30 <jgreguske> dgilmore: I'll propose it as an F15 feature, update the koji wiki to include it
21:16:34 <brianlamere> ie - there's a eu-west-1 now, so I presumed there would be a eu-east-1 eventually...and where there was a 1, I added a 2 and 3 as well ;)
21:16:45 <gholms> What are the numbers for?
21:17:05 <brianlamere> that's the region name.  it's not just us-west, its us-west-1
21:17:10 <gholms> Oh
21:17:40 <brianlamere> the zones then become a letter after the region name; us-west-1[abcd]
21:17:50 <gholms> Should Fedora's AMIs be uploaded to buckets like "fedora-images-us-west-1", then?  Where are they currently going?
21:17:50 * mmcgrath wonders if those could be used for country codes.
21:18:52 <brianlamere> I grabbed fedora-ami, fedorahosted, fedora-cloud, etc etc as options for things like AMIs.  But yeah, they could just go in a region bucket, too
21:19:00 <brianlamere> er, instead
21:19:08 <eric-smith> Could the repo URI's be something under fedoraproject.org that only resolves to an internal EC2 address? Then you wouldn't have to worry about external access.
21:19:35 <eric-smith> or cross-zone access.
21:19:38 <brianlamere> mccgrath:  unfortunately no; "ap" is "asia pacific" which doesn't really fit to any standard.  That's the 3rd meta area with regions
21:19:43 <brianlamere> US, EU, and AP
21:19:57 <gholms> Aren't AMIs restricted to one region?
21:20:12 <brianlamere> yes, but the buckets they are in aren't
21:20:50 <gholms> So we would not need to publish one per region?
21:20:56 <eric-smith> sorry, I have to run. I'll check the transcript later.
21:20:57 <gholms> I'm trying to figure out why Ubuntu does.
21:21:03 <gholms> eric-smith: Sorry  :(
21:21:17 <gholms> http://uec-images.ubuntu.com/maverick/current/
21:22:00 <brianlamere> I think they eat costs for a bit of user experience improvement.  But, I don't think using a region name instead of a single bucket is really that confusing
21:22:38 <brianlamere> especially since Ben@aws et. al are so interested in getting an AMI from us to put up on the top as a generic install option
21:22:40 <gholms> What I'm saying is that they *do* publish one AMI per region.  So we need to do so as well.
21:22:49 <gholms> ...right?
21:23:05 <jgreguske> for RHEL the buckets have the region in the name and put the region specific AMIs in the appropriate bucket
21:23:11 <brianlamere> sec, lemme double check - I thought I had seen their bucket names be the same regardless of region (for AMI, that is)
21:23:13 <jforbes> Sure, it is easy enoug h to copy an image
21:23:14 <jgreguske> it's just clearer
21:24:22 <gholms> Yeah
21:24:30 <gholms> brianlamere: Their list is here:  http://uec-images.ubuntu.com/maverick/current/
21:25:40 <gholms> Oh, those aren't bucket names.
21:25:43 * gholms needs sleep
21:26:24 <jforbes> bucket names shouldnt really matter to users
21:26:40 <gholms> Either way it seems reasonable to me to put images in buckets with region-specific names.
21:27:24 <Oxf13> wait, are we talking about copying image file names?
21:27:29 <jforbes> I am not really arguing against it, just rather apathetic to it
21:27:40 <Oxf13> wouldn't that necessitate modifying and re-signing any signed CHECKSUM files?
21:27:54 <jgreguske> Oxf13: talking about the names of the buckets, not the images
21:27:55 <gholms> Oxf13: AMIs, not ISOs.
21:28:06 * Oxf13 goes back into his hole
21:28:13 <gholms> ;)
21:28:37 <gholms> https://wiki.ubuntu.com/UEC/Images/NamingConvention
21:29:04 <brianlamere> yes- so if you look at the "source" for those, they're all "099720109477/ebs" - where 099720109477 is their bucket name
21:29:12 <brianlamere> icky
21:29:34 <gholms> How about "fedora-images-us-west-1" and so forth?
21:29:39 <brianlamere> I agree though that people won't be confused by bucket names
21:29:49 <jgreguske> brianlamere: actually that is an account number
21:30:09 <gholms> All I really care about is that we have an "official" spot to push images to.
21:30:11 <brianlamere> yeah, it's an account number - but that's because they opted to do that instead of putting it in a bucket ;)
21:30:21 <brianlamere> a named bucket, that is
21:30:28 <jgreguske> I think EBS-backed AMIs always get that
21:30:31 <brianlamere> amazon reserves your account number as a bucket name
21:30:44 <jgreguske> ah I see, I wasn't aware it was a "bucket" per se
21:31:17 <brianlamere> hmm...maybe you're partially right - the ephemeral-backed one is sourced at "ubuntu-images-testing-us/ubuntu"
21:31:27 <brianlamere> but it's not specific to a region then, either
21:31:35 <gholms> What about https://wiki.ubuntu.com/UEC/Images/NamingConvention
21:31:36 <gholms> ?
21:32:10 <brianlamere> yup, keeping to that would make sense
21:32:49 <gholms> Proposal:  Upload Fedora AMIs to buckets like "fedora-images-us-west-1" and so forth.
21:32:54 <brianlamere> are you going to see if those names are avail and grab them, or do you want me to do it quick so that no one spoils the party by grabbing just one before we're ready?
21:32:56 <gholms> Anyone +1/-1 on that?
21:33:09 <jgreguske> brianlamere: can EBS-backed AMIs ever be in a bucket that is not an account #?
21:33:43 <jgreguske> gholms: seems reasonable to me, fwiw
21:33:59 * jgreguske not sure where he stands as a new-comer here
21:34:06 <brianlamere> jgreguske:  I thought I had done that myself, but I can't really be certain
21:34:20 <gholms> brianlamere: Are you fine with that naming scheme?  If so, you probably should.  They're easy to claim/release.
21:34:26 <brianlamere> I'm a newcomer too, just been here a couple months
21:34:35 <brianlamere> er, few months?  not long, either way ;)
21:34:42 <gholms> jforbes: Still around?  Does that naming scheme work for you?
21:34:43 <brianlamere> ok - will just take a few seconds
21:34:47 <rbergeron> we embrace newcomers :) no worries :)
21:35:07 <brianlamere> will cost me all of maybe 3 cents to do, so if he doesn't like them I lost an entire 3 pennies
21:35:12 <brianlamere> probably less
21:35:39 <gholms> #agreed Fedora AMIs will be uploaded to buckets "fedora-images-us-west-1" and so forth.
21:35:50 <jforbes> gholms: Yeah, it seems to, I am just concerned about how we will manage some of this in relation to cost.  I need to have some conversations since the official fedora account right now is single tier and tied to my credit card :)
21:36:01 <gholms> #action brianlamere to reserve relevant bucket names
21:36:15 <rbergeron> can't we tie it to the fedora account somehow? mdomsch? ^^^
21:36:34 <jforbes> I have the fedora account right now
21:36:41 <gholms> jforbes: Yeah, we're going to have to come up with something more formal than that.  There's a little bit of that in the mirror proposal.
21:36:56 <rbergeron> and it's not tied to spevack's RH card?
21:37:07 <jforbes> gholms: Yup, just a matter of some conversations I need to have with spevack
21:37:18 <jforbes> rbergeron: no, that never happened, so it is tied to my personal card
21:37:41 <gholms> Is that something you can work with him on in the coming weeks?
21:38:06 <jforbes> yup
21:38:24 * rbergeron will gently remind max as well :)
21:38:55 <gholms> #action jforbes to work on getting funding for an "official" fedora AWS account set up
21:39:06 <gholms> Once we have something that works we can see what Amazon is willing to help us with.
21:39:39 <gholms> Anything else image-related, or shall we move on to mirroring?
21:40:01 <jgreguske> any work with PV-Grub AKIs?
21:40:10 <jforbes> Well, right now I ahve free S3 on that account for images, but I am sure we will have to negotiate for mirrors and such
21:40:32 <gholms> We don't have to build AKIs any more, do we?
21:40:39 <mdomsch> I have account info too; but not that's free
21:40:39 <jforbes> jgreguske: nothing to do, Amazon made their PV-Grub AKIs public and we use them
21:40:52 <jgreguske> jforbes: ok, that's what I wanted to know :)
21:41:24 <gholms> Moving right along...
21:41:31 <jgreguske> jforbes: so is Fedora 14 going to consist of S3 and EBS?
21:41:35 <jgreguske> or just one or the other
21:41:43 <jgreguske> gholms: sorry, slow typing that out :)
21:42:02 * obino needs to duck out
21:42:10 <gholms> Good point.  We should probably publish EBS and instance store images if possible
21:42:12 <jforbes> jgreguske: just S3 at the moment
21:42:20 <gholms> Is that a lot of work?
21:42:28 <brianlamere> I personally use EBS, not S3-backed.
21:42:37 <brianlamere> they're created slightly differently
21:42:39 <jforbes> not sure honestly
21:42:55 <jgreguske> jforbes: on the RHEL side I've written up some scripting to automate construction of them
21:42:58 <jforbes> I have never created an EBS backed image, need some infor on it
21:43:00 <brianlamere> er, uploaded slightly differently that is
21:43:08 <jforbes> jgreguske: Ooh, that would be nice if you could point me to it
21:43:11 <jgreguske> jforbes: I can work with you on that and see what you think
21:43:16 <gholms> Does anything differ on the image itself?
21:43:36 <brianlamere> if anything, probably just grub.conf :)
21:43:38 <jgreguske> gholms: yes, fstab is slightly different
21:43:43 <jgreguske> and grub.conf, potentially
21:43:50 <jgreguske> otherwise no, it's the same
21:43:58 * gholms wonders if cloud-init can deal with that
21:44:11 <brianlamere> that and the ebs patch is much more important with an ebs-backed image
21:44:21 <gholms> Eh, it's something to look into.
21:44:21 <brianlamere> did the ebs patch get included in your image?
21:45:09 <jgreguske> brianlamere: if you're asking me, no
21:45:16 <jforbes> brianlamere: I have yet to see that patch
21:45:34 <jforbes> brianlamere: I got an email saying that one exists, with no patch attached or link to one
21:45:48 <jgreguske> hang on there is a bz for it
21:45:56 <jgreguske> not sure if it is public though
21:46:22 <jgreguske> https://bugzilla.redhat.com/show_bug.cgi?id=637308
21:46:22 <jforbes> jgreguske: doesnt matter, just point me to it on my rh email
21:46:23 <gholms> <aside>Why on earth would such a bug be private?</aside>
21:46:43 <jgreguske> can you guys see that?
21:46:47 <gholms> Yeah
21:46:49 <jgreguske> good
21:46:58 <brianlamere> ah, I thought it was in the email.  The wording seemed to suggest he wanted us to have it, probably just an oversight
21:47:11 <gholms> Should it be cloned against Fedora?
21:47:14 <gholms> s/it/the bug/
21:47:19 <jforbes> brianlamere: Yeah, I replied asking for it, and for the upstream status, and got nothing
21:47:46 <jforbes> gholms: depends, let me look at the patch.  It might be possible, might not
21:49:03 <gholms> Anything else image-related?
21:49:45 <gholms> Okee dokee
21:49:53 <gholms> #topic EC2 mirror proposal
21:49:57 <gholms> #link https://fedoraproject.org/wiki/User:Gholms/EC2_Mirror_Proposal
21:50:03 <gholms> Thoughts?
21:50:32 <brianlamere> jforbes:  my bad, I didn't include original attachment when I CC'd you on my response to him about it.  It was there - it's in your inbox now
21:50:34 * rbergeron thanks gholms for putting this out :)
21:50:58 <gholms> At the bottom are four questions we should try to answer soon so we know *what* to do.
21:51:17 <mmcgrath> Yeah
21:51:18 <mmcgrath> mdomsch: around?
21:51:24 <jforbes> gholms: seems sane to me, though again I have concerns with getting te accounts set up/funded backed by someone elses money :)
21:51:38 <gholms> Indeed.
21:51:55 <mmcgrath> gholms: you mentioned they might be able to have a special url?
21:52:05 <brianlamere> jforbes:  heh - I can imagine that ;)  thought the IAM stuff looks very promising.  I've already started using it here, it's making life way easier
21:52:32 <gholms> mmcgrath: They would look like "http://s3.amazonaws.com/fedora-mirror-us-west-1/fedora/linux/releases/...", so not really.
21:52:32 <mmcgrath> gholms: or were you hoping that there be NO changes to the yum configs at all?
21:52:55 <brianlamere> mmcgrath:  they already can (bucketname.s3.amazon.com, or something like that) but question is if there is an *internal* url that can be used
21:53:19 <mmcgrath> Ok, step back a second.
21:53:23 <mdomsch> mmcgrath: back now
21:53:23 <gholms> The idea is to have a yum plugin check what region an instance is in and send that off to mirrormanager as an additional parameter.  MM will then read that, do a lookup, and prepend the region-specific URI to the mirrorlist.
21:53:26 <mmcgrath> I've got an amazon guest.
21:53:42 <skvidal> gholms: how does it check the region?
21:53:45 <skvidal> is it just as stored value?
21:53:46 <mmcgrath> do I have the yum provided /etc/yum.repos.d/ configs?  or special ones?
21:53:53 <gholms> skvidal: You fetch it via curl.
21:53:55 <mdomsch> skvidal: that's my question too
21:54:06 <skvidal> gholms: fetch WHAT?
21:54:10 <skvidal> the region is fetched?
21:54:14 <gholms> The region name.
21:54:15 <brianlamere> gholms:  you can actually get to the buckets via "bucketname.s3.amazonaws.com" ( just verified the url)
21:54:15 <gholms> Yes
21:54:20 <skvidal> gholms: fetch it from where?
21:54:47 <gholms> brianlamere: ^
21:55:04 <gholms> There's a special IP address they can query to get meta-info about themselves.
21:55:07 <skvidal> okay
21:55:08 <brianlamere> S3 is basically just a html service; you say "wget fedora-imagest-testing-us.s3.amazonaws.com/myfilename"
21:55:14 <skvidal> is that info likely to change dynamically?
21:55:24 <gholms> Not once an image has started.
21:55:24 * rbergeron has to abandon ship slightly early, i leave this in gholms's always excellent hands to wrap things up when that time comes :)
21:55:26 <brianlamere> the region an instance is will never change
21:55:35 <skvidal> gholms: okay - then have the kickstart fetch it
21:55:49 <skvidal> and store the value in /etc/yum/vars/awsregion
21:56:01 <skvidal> then you can refer to it in your yum.conf and in all repos as $awsregion
21:56:29 <gholms> Then we end up munging repo configs.  It sounded like people in #fedora-admin weren't too keen on that.
21:56:38 <skvidal> munging them where?
21:56:44 <gholms> ...in the repo configs?
21:57:30 <gholms> The region name has to get into the yum config *somehow.*
21:58:27 <gholms> (Or am I talking nonsense here?)
21:58:44 <mdomsch> it'd be nice if we didn't have to touch the repo config files
21:58:51 <mdomsch> but adding a yum plugin at install time
21:58:54 <mdomsch> or editing a config file
21:59:00 <mdomsch> the config file change is easier
21:59:03 <skvidal> that's really your only option
21:59:11 <skvidal> plugin or config-change
21:59:12 <skvidal> hey I know
21:59:16 <skvidal> put $awsregion
21:59:20 <skvidal> and $othershithere
21:59:24 <skvidal> on ALL mm calls
21:59:29 <skvidal> if there's nothing for them - yum just leaves them
21:59:30 <skvidal> :)
21:59:48 <gholms> Interesting...
22:00:23 <gholms> brianlamere: Can you boot a AMI stored in one region inside of a different region?
22:00:30 <jgreguske> no
22:00:44 <gholms> Then that's a viable option.  mdomsch?
22:00:58 * mmcgrath bbiab, has to get dinner ready sorry :-/
22:00:59 <gholms> Oh, wait:
22:01:15 <mdomsch> fine by me; you still have to have kickstart fetch the info
22:01:18 <skvidal> gholms: well - the trick is you need to get all the repos modified now
22:01:20 <mdomsch> and if you're going to do that much
22:01:32 <mdomsch> in kickstart
22:01:36 <mdomsch> might as well edit the repo files too
22:01:43 <mdomsch> and not mess with the plugin
22:01:50 <gholms> I see one problem with this, though:  people can re-bundle their images and copy them to different regions.  Then these people hit mirrors from the wrong region and we start getting charged money.
22:01:59 <mdomsch> we?
22:02:02 <mdomsch> they presumably
22:02:07 <gholms> Whoever pays for it...
22:02:34 <gholms> mdomsch: skvidal is proposing changing the stock fedora-release package so we don't have to edit configs at all - just generate a file.
22:02:55 <jforbes> We raly only want 1 image generated, and copy it across regions in my opinion
22:02:57 <skvidal> mdomsch: I'm saying it could be done - I'm not saying it WILL be done
22:03:06 <gholms> Then bare-metal Fedora hosts just pass &prepend= with nothing afterwards.
22:03:15 <skvidal> jforbes: then have a startup script fetch the region info and store it
22:03:23 <jforbes> skvidal: yup
22:03:27 <gholms> worksforme
22:03:35 <skvidal> gholms: no - the baremetal ones will pass &prepend=$foo$bar$baz
22:03:45 <skvidal> if there is no variable named that - yum LEAVES IT ALONE
22:03:47 <brianlamere> gholms:  sorry, was looking at something else.  I do not think that can be done, no
22:03:48 <skvidal> see the difference?
22:04:06 <gholms> Oh, it leaves the whole thing there.
22:04:09 <skvidal> right
22:04:12 <skvidal> it's not a big deal
22:04:15 <skvidal> just means $foo == nothing
22:04:19 <skvidal> to mirrormanager
22:04:31 <skvidal> and I doubt there would be a region named $AWSREGION
22:04:32 <gholms> As long as mirrormanager is all right with that then that should work.  Right?
22:04:33 <skvidal> or whatnot :)
22:04:45 <mdomsch> MM ignores options it doesn't know about
22:05:01 <gholms> Here it would know about the option, but be passed a bad *value.*
22:05:03 <skvidal> mdomsch: always nice
22:05:12 <mdomsch> that makes for an uglier URL for users to look at
22:05:20 <mdomsch> if they cat /etc/yum.repos.d/*
22:05:28 <gholms> e.g., prepend=$AWS_REGION instead of prepend=us-west-1
22:05:48 <skvidal> mdomsch: true
22:05:55 <mdomsch> if folks can run an image in a different region, then the lookup needs to be dynamic, hence the plug-in
22:06:15 <gholms> If we check it every time the system starts that should be sufficient.
22:06:17 * jsmith likes the plug-in option better
22:06:35 <mdomsch> skvidal: I presume a plug-in can append things to the URL fetched to get the mirrorlist?
22:06:41 <gholms> The plug-in idea, on the other hand, makes for slightly cleaner configs.
22:06:43 <skvidal> mdomsch: yes a config plugin can do it
22:07:18 <mdomsch> so plugin to get dynamic action, and clean config file.  I like.
22:07:42 <gholms> skvidal: Have a preference?
22:07:57 <skvidal> mdomsch: except it means code-maintenance - for ever
22:07:58 <skvidal> on that plugin
22:08:19 <gholms> The alternative is code maintenance on an init script.
22:09:05 * jforbes has to run, but couldn't the cloud-init bits be useful here?
22:09:18 <gholms> jforbes: For the init script part, sure.
22:09:20 <jforbes> I will read the log from this when I get back
22:09:39 <skvidal> I'm gonna go walk the pooch
22:09:48 <gholms> So, what do we go with?
22:09:52 <skvidal> lemme know what you need
22:09:56 <skvidal> and I'll do what I can to help
22:11:03 <brianlamere> jforbes:  yes, but remember - it's really simple
22:11:18 <gholms> How about this:
22:11:20 <gholms> Proposal 1:  yum plugin
22:11:25 <gholms> Proposal 2:  init script + variable in stock repo configs
22:11:28 <brianlamere> jforbes:  a simple "curl http://169.254.169.254/latest/meta-data/placement/availability-zone" will return a string similar to "us-west-1a" which, at that point, you know the region
22:11:35 <gholms> Who prefers what?
22:12:18 <brianlamere> gholms:  with the evolving nature of the world of IT, option 2 seems to have more forward-thinking possibilities
22:12:22 <jgreguske> for reference, RHEL figures it out at boot time using what brianlamere just described
22:12:43 <skvidal> jgreguske: to be fair - rhel has its own plugin for all the repos and stuff
22:12:45 <gholms> jgreguske: And writes it to /etc/yum/vars/blah, or...?
22:13:02 <skvidal> gholms: some of them are, now. but /etc/yum/vars didn't exist pre-rhel6 :)
22:13:30 <gholms> RHEL on EC2 works differently.  It doesn't hit RHN directly.
22:13:47 <jgreguske> right but it still needs to dynamically figure out where to go
22:13:51 <gholms> Yeah
22:13:57 <jgreguske> figured that datum would be useful to the discussion
22:14:32 <gholms> Would the community at large be okay with an extra bit added onto stock repo configs?
22:15:09 <gholms> If we want to go with proposal 2 we have to file a bug against fedora-release *now.*
22:15:23 <skvidal> okay
22:15:26 <skvidal> option2
22:15:40 <skvidal> add a bit onto the stock repo configs which is just
22:15:45 <skvidal> $extrastuff
22:15:49 <skvidal> or
22:15:59 <skvidal> $extra_mirrorlist_stuff
22:16:09 <skvidal> that way it can be used generically
22:16:52 <jgreguske> for RHEL (not saying this is the right way to do it, just suggesting) cloud images have an extra set of packages that handle the configuration
22:16:54 <gholms> mdomsch and I discussed sending "&prepend=foo" to the mirrorlist URI.  Maybe something equally generic?
22:17:05 <jgreguske> and only the cloud images have them
22:17:11 <jgreguske> is a similar model feasible here?
22:18:06 <gholms> Then we can just create /etc/yum/vars/prepend only on EC2 images.
22:18:33 <brianlamere> it's not just something useful to the "cloud" though - it's useful to anyone who is not able to do the "normal" thing on the internet
22:19:07 <gholms> That's why we came up with a non-cloudy name.
22:19:17 <jgreguske> ok, ignore me then
22:19:28 <gholms> i.e., prepend=aws-ec2-us-west-1
22:19:36 <brianlamere> I mentioned as an example I'll re-use here, servers that are on the NIPR/SIPR; they can't just reach over and do whatever, they have to go through special places.  Allowing a generic way to affect the mirrorlist would, I think, be the better idea
22:20:15 <gholms> Then MM admins can set up those mappings as necessary.
22:20:28 <brianlamere> the question we have to figure out then is there a compute.internal address for the s3 buckets, as a complement to their external public urls :)
22:21:22 <gholms> What does s3.amazonaws.com resolve to inside EC2?
22:21:43 <gholms> Oof, mdomsch left.
22:22:10 <gholms> It sounds like people prefer the /etc/yum/vars/prepend (or whatever) idea.
22:22:52 <brianlamere> it resolves to a public IP, unfortunately
22:23:57 <gholms> skvidal: Do you suppose something like this should also go to a list?
22:25:31 <gholms> Does anyone else here have an opinion?  I feel like I'm talking to myself here.
22:26:07 <skvidal> gholms: gonna have to talk to releng definitely
22:26:08 <skvidal> get their okay
22:26:15 <skvidal> Oxf13 and notting
22:26:40 <brianlamere> ha - sorry gholms ;)  I'm trying to figure out the private URLs of the s3 buckets ;)
22:27:20 <gholms> Maybe I should file a releng ticket to get their thoughts/approval/disapproval.
22:28:40 <gholms> I'll do that.  We can revisit the rest next week when more people are here.
22:28:52 <jgreguske> gholms: need to bail as it's getting late at the office :)
22:29:04 <gholms> ^ My point exactly.  :)
22:29:11 <jgreguske> gholms: I'll check up the log and be in touch with others this week
22:29:19 <gholms> Sounds good
22:30:16 <gholms> #action gholms to file a releng ticket to gather opinions/approvals/disapprovals of a way to direct EC2 instances to the right mirrors
22:30:39 <gholms> #topic Open floor
22:30:55 <gholms> Anyone have anything else to add?  We're late as usual, so if nothing pops up I will close in 1 minute.
22:31:23 <brianlamere> not here; will see if I can get that private s3 bucket info to you
22:31:50 <gholms> Thanks for coming, everyone!
22:31:56 <gholms> #endmeeting