19:02:04 <jeblair> #startmeeting infra
19:02:04 <openstack> Meeting started Tue Sep 23 19:02:04 2014 UTC and is due to finish in 60 minutes.  The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:04 <krtaylor> o/
19:02:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:07 <openstack> The meeting name has been set to 'infra'
19:02:09 <jeblair> #link agenda https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
19:02:09 <pleia2> o/
19:02:16 <jhesketh> Morning
19:02:18 <jeblair> #link last meeting http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-09-16-19.01.html
19:02:21 <VijayTripathi> Hi all
19:02:28 <jeblair> #topic  Actions from last meeting
19:02:31 <mordred> o/
19:02:31 <jeblair> jhesketh rework 109485 to impact only infra jobs
19:02:39 <krtaylor> hey everybody
19:02:56 <jeblair> oh let's just jump to swift logs
19:02:59 <jeblair> #topic swift logs
19:03:23 <jeblair> jhesketh: still working on 109485?
19:03:50 <jeblair> #link https://review.openstack.org/#/c/109485/
19:03:53 <jhesketh> I put it up as a new review, let me dig up the link sorry
19:03:56 <jeblair> #link https://etherpad.openstack.org/p/swift_logs_next_steps
19:04:01 <clarkb> jhesketh: 122154?
19:04:55 <jhesketh> clarkb: yep, that's it
19:05:01 <jeblair> #link reworked 109485 is 122154 https://review.openstack.org/#/c/122154
19:05:21 <jeblair> updated etherpad
19:05:49 <jeblair> okay, so that's something we should review soon to unblock this
19:06:24 <clarkb> looks straighforward too. I will review post meeting
19:06:42 * SergeyLukjanov lurking
19:06:54 <jeblair> anything else on swift-logs?
19:07:28 <jhesketh> 122159 is also related but not blocking
19:07:50 <jeblair> #link https://review.openstack.org/#/c/122159
19:07:57 <anteaya> jhesketh: can you add that to the etherpad too?
19:08:00 <jhesketh> Otherwise I think we just want to review how switching over infra logs goes
19:08:20 <jeblair> sounds good
19:08:39 <jhesketh> anteaya: yep, I will later :-)
19:08:43 <anteaya> jhesketh: thanks
19:08:59 <jeblair> #topic  Config repo split
19:09:08 <jeblair> so first part of this is this spec: http://specs.openstack.org/openstack-infra/infra-specs/specs/puppet-modules.html
19:09:18 <jeblair> nibalizer: did you start a storyboard story for that?
19:09:38 <pleia2> he's puppetconfing today, not sure if he's here (I found corner to do meeting :))
19:09:48 <jeblair> i don't see one
19:10:05 <jeblair> this is pretty much blocked on someone filing a story, and a task for each project so that people can actually get started on it
19:10:10 <jeblair> any volunteers to do that?
19:10:23 <nibalizer> i didn't do that, sorry
19:10:42 <nibalizer> ill do it now
19:11:06 <jeblair> #action nibalizer file a story with a task for each project for http://specs.openstack.org/openstack-infra/infra-specs/specs/puppet-modules.html
19:11:22 <jeblair> the second part of this is http://specs.openstack.org/openstack-infra/infra-specs/specs/config-repo-split.html
19:11:41 <jeblair> i believe we are actually ready to go on that
19:11:48 <jeblair> i have a series of puppet changes up
19:12:01 <jeblair> and anteaya has prepared a strawman project-config repo
19:12:05 <anteaya> I think I have the repos in the two stages they need to be in
19:12:24 <jeblair> #link https://review.openstack.org/#/q/topic:project-config,n,z
19:12:30 <anteaya> one after the git filter branch and one after the filter branched has been reorganized
19:12:35 <fungi> assuming changes look good to everyone, do we want to pick a day this week to freeze and do it?
19:12:38 <clarkb> so that is just needing review?
19:12:39 <jeblair> #link https://github.com/anteaya/project-config
19:12:47 <jeblair> #link https://github.com/anteaya/reorganized-project-config-02
19:12:49 <anteaya> clarkb: I believe yes
19:13:04 <mordred> jeblair: so sequence is land new anteaya repo, then land config changes, then land change to config to remove stuff?
19:13:12 <anteaya> and please review the two git repos as well, so I can fix anything that is incorrect
19:13:23 <clarkb> mordred: with a freeze in the middle
19:13:25 <mordred> yah
19:13:41 <fungi> freeze as step #0 i think
19:13:41 <mordred> wrap that whole thing in "obtain write-lock"
19:13:43 <jeblair> i think anteaya is anticipating that we would do the reorganization after the project-config import
19:14:00 <anteaya> that is what I have planned
19:14:09 <anteaya> since the reorg commit will be big
19:14:17 <anteaya> and would prefer to have it done via gerrit
19:14:21 <anteaya> rather than locally
19:14:22 <mordred> gotcha
19:14:25 <anteaya> open to opinons
19:14:34 <jeblair> mordred: so that's: land anteaya new repo, land project-config reorg, land puppet changes, land change to config to remove stuff
19:14:56 <jeblair> i think that will work fine
19:15:00 <jeblair> anteaya: ^
19:15:04 <fungi> wfm
19:15:07 <anteaya> I haven't done the config change to remove stuff, but I can
19:15:20 <anteaya> and that is also a config rename at the same time, is it not?
19:15:44 <anteaya> config -> system-config
19:15:46 <jeblair> we need to create the gate jobs for the project-config repo; that's not done yet,
19:15:52 <anteaya> ah
19:16:00 <clarkb> that plan sounds good to me
19:16:00 <fungi> anteaya: depending on your preferences, you may just want to script up the steps to do the delete-stuff change. otherwise it's going to conflict heavily between now and when we freeze
19:16:14 <jeblair> though it might be easier to add the jobs after the repo exists
19:16:24 <anteaya> I can work on the commands to do the delete stuff change
19:16:30 <fungi> repo first, then jobs, i think
19:16:35 <anteaya> and put up a repo for review on github
19:16:43 <jeblair> anteaya: we do want to do a config -> system-config rename, but it doesn't have to happen at the same time;  we probably need a few more puppet changes for that.
19:16:43 <anteaya> then offer the patch in the freeze
19:17:00 <jeblair> so, as far as scheduling goes...
19:17:06 <anteaya> okay I can do a config delete stuff patch then
19:17:14 <jeblair> i'm going to be away for 1.5 weeks starting saturday
19:17:21 <fungi> yeah, i think we're better off planning for a breather between the split and the rename just to shake out oddness
19:17:41 <anteaya> kk
19:17:53 <anteaya> how about I do up an etherpad of steps
19:18:03 <anteaya> based on what we have identified
19:18:09 <anteaya> and then we can go from there
19:18:10 <jeblair> which means we (a) rush it in this week; (b) you do it without me; (c) we do it after i get back (> oct 8)
19:18:23 <anteaya> which do you prefer?
19:18:33 <anteaya> I don't feel rushed if we do it this week
19:18:40 <anteaya> just wednesday is bad for me
19:18:43 <fungi> this week seems reasonable to get the split knocked out, and as long as everyone else isn't also taking vacation i expect we can handle issues which crop up once the split bakes in production while jeblair enjoys a much-deserved vacation
19:19:02 <anteaya> I concur with fungi
19:19:03 <mordred> I'm booked today and tomorrow, but should be available to be helpful thursday and friday
19:19:14 <mordred> as well as next week
19:19:17 <clarkb> fungi: ya
19:19:18 <anteaya> thursday or friday is good for me too
19:19:19 <fungi> thursday seems like a good day
19:19:30 <clarkb> why don't we try for thursday then?
19:19:35 <pleia2> I'm out thursday for a holiday, but you can probably do without me :)
19:19:40 <fungi> i'm open every day this week, and around for the forseeable future until the summit
19:19:45 <anteaya> it will take me about 45 minutes after the freeze to do the filter branch
19:19:52 <mordred> kk
19:20:02 <anteaya> so the freeze should be at least 2 hours
19:20:03 <fungi> pleia2: thursday's a holiday?
19:20:07 <mordred> I think we can be frozen for the whole day if need be
19:20:14 <anteaya> rosh hashana
19:20:17 <anteaya> eating and temple
19:20:17 <pleia2> fungi: rosh hashanah
19:20:26 <fungi> aha! yes, i totally forgot that was this week
19:20:53 <anteaya> so 1900 utc on thursday?
19:21:03 * jhesketh will be around to help where he can
19:21:04 <jeblair> how about we freeze starting at 00:01 utc thursday
19:21:11 <anteaya> and I will have an etherpad to track set up
19:21:11 <jeblair> (which is wed evening for most of us)
19:21:18 <anteaya> jeblair: oh I'm fine with that
19:21:19 <fungi> sounds fine by me
19:21:29 <clarkb> jeblair: sounds good
19:21:32 <fungi> a day-long freeze for config changes should be bearable to the project
19:21:42 <mordred> if it's not, the project can learn patience
19:21:42 <clarkb> then we start the work when people wake up the next "day"
19:21:47 <fungi> heh
19:21:48 <jeblair> clarkb: yep
19:22:42 <fungi> i guess we'll remind jhesketh, SergeyLukjanov and me not to approve any config changes starting at 0 hours thursday utc
19:23:04 <clarkb> should remind all of us :)
19:23:05 <jhesketh> Noted
19:23:26 <fungi> indeed
19:23:36 <jeblair> when should we target unfreezing?
19:23:45 <fungi> "when it's done?"
19:23:52 <jeblair> heh, works for me :)
19:23:53 <anteaya> I'm for that
19:24:09 <fungi> done and reasonably seeming to be not-broken
19:24:22 <anteaya> yes to the non-brokenness
19:24:31 <jeblair> #agreed freeze project config changes 00:01 utc thursday sept 25
19:24:31 <krtaylor> ++
19:24:46 <fungi> party goes until question marks
19:24:51 <jeblair> #agreed cutover to project-config repo thursday morning us-time
19:24:54 <fungi> all invited to attend
19:25:16 <jeblair> anteaya: that means you can do your work wed night or thurs morning, whichever works better
19:25:42 <anteaya> I was just thinking I can have the new repo and repo regorg done my wed night
19:25:54 <jeblair> #action jeblair send project-config announcement to -dev list
19:26:03 <anteaya> then if jhesketh wants some fun he can do the jobs patches during the night, his day
19:26:20 <anteaya> and the great merging can happen thursday daytime north america time
19:26:25 <anteaya> jhesketh: does that work for you?
19:26:52 <jhesketh> anteaya: yep, I can help review if you remind me :-)
19:26:59 <anteaya> jhesketh: thanks
19:27:12 <AJaeger_> do you want to merge in some config changes before Thursday?
19:27:14 <jeblair> anything else on this one?
19:27:32 <jeblair> AJaeger_: good point, we should try to clear out as much of those as possible today and tomorrow
19:27:33 <AJaeger_> I mean: Should we clean the queue as much as possible - or not?
19:28:19 <fungi> we probably should, yes
19:28:19 <AJaeger_> and perhaps ask in your announcement mail to not submit new changes...
19:28:40 <pleia2> or "don't expect them to be merged until..."
19:28:51 <anteaya> fungi: can you be around wednesday night to merge the repo with manage projects? then we can offer patches to it like the reorg patch
19:28:54 <fungi> eh, just warn that new changes proposed may need reworking or abandoning and reproposing to a different project after the split
19:29:01 <pleia2> fungi: yeah
19:29:31 <jeblair> anteaya, fungi: i think we can do that thurs morning
19:29:32 <anteaya> since folks won't read it anyway and it will give us something to point to when we tell them that afterward
19:29:35 <anteaya> jeblair: okay
19:29:54 <AJaeger_> ;)
19:29:54 <fungi> anteaya: jeblair: yeah i think we do that with the other changes in sequence. no need to split them up overnight
19:30:01 <anteaya> fungi: kk
19:30:10 <jeblair> in fact, you doing the prop wed night; and fungi merging it thurs morning may work out really well timing wise
19:30:16 <jeblair> s/prop/prep/
19:30:20 <anteaya> okay
19:30:23 <fungi> if we're impatient, there are ways to speed up the patch taking effect when we're working on it
19:30:28 <jeblair> ya
19:30:35 <anteaya> no, just wanting to be efficient is all
19:30:39 <anteaya> not impatient
19:31:03 <jeblair> #topic  Nodepool DIB
19:31:09 <mordred> yay!
19:31:16 <fungi> i meant if we get impatient because it's blocking us merging other changes depending on that existing
19:31:19 <jeblair> so this is sorta happening :)
19:31:27 <clarkb> wip
19:31:29 <mordred> jeblair++
19:31:33 <anteaya> fungi: ah yes
19:31:46 <clarkb> I am hoping that by this afternoon we will have restarted nodepool and have our first image built
19:31:47 <jeblair> we ran into an error in production, fixed it and some other things after local testing, and i think we're about ready to try in prod again
19:32:14 <jeblair> i still haven't built an image locally, and i'm not sure why; i suspect it may be a disk space issue, but the error output is not helpful :(
19:32:30 <fungi> i can help/do a nodepool restart after this meeting, since i'll mostly just be lurking the tc/project meetings at that point
19:32:33 <jeblair> at any rate; i don't think it's going to kill production
19:32:42 <mordred> jeblair: I'd love to learn more about what broke for you
19:32:48 <jeblair> me too
19:33:02 <clarkb> fungi: ya me too. watiing on the logging change to merge though
19:33:23 <jeblair> 2014-09-23 18:31:51,010 INFO nodepool.image.build.devstack-trusty-dib: umount2: Invalid argument
19:33:23 <jeblair> 2014-09-23 18:31:51,093 INFO nodepool.image.build.devstack-trusty-dib: umount: /tmp/image.lyVl2cy4: not mounted
19:33:32 <jeblair> mordred: that's the end of the dib log for me.  :/
19:33:45 <ianw> jeblair: that looks like the exit cleanup, real issue will be before that
19:34:02 <ianw> (seen that a fair bit :)
19:34:51 <jeblair> ianw: ok; i don't see anything error-like immediately before it
19:35:06 <mordred> yah - it's like devstack - the errors at the end are not the real errors
19:35:15 <jeblair> last thing it does is 2014-09-23 18:31:45,092 INFO nodepool.image.build.devstack-trusty-dib: Caching cirros-0.3.0-x86_64-disk.vhd.tgz file from https://github.com/downloads/citrix-openstack/warehouse/cirros-0.3.0-x86_64-disk.vhd.tgz in /home/nodepool/.cache/image-create/source-repositories/cirros_0_3_0_x86_64_disk_vhd_tgz_c610756fad56eab78721f8601c631e88396b6a31
19:35:26 <jeblair> it doesn't say it errored, but it doesn't say it completed either
19:35:32 <fungi> or at least they weren't real errors until someone added errorexit
19:35:54 <fungi> so maybe dib needs to run under errorexit like devstack does ;)
19:35:55 <jeblair> best hypothesis: it ran out of space on that but didn't happen to mention it.  :/
19:36:06 <ianw> jeblair: i've found important stuff is sometimes missing, have a change out to enable better tracing : https://review.openstack.org/119023 ... getting it merged is a pain though
19:36:42 <jeblair> oh no gertty crashed!
19:36:54 * jeblair files bug
19:37:02 <mordred> SpamapS, lifeless: ^^
19:37:05 <jeblair> anyway, i guess we'll try it in production soon
19:37:10 <clarkb> ++
19:37:21 <clarkb> if it is a disk issue we should be fine on the current nodepool server
19:37:25 <zaro> o/
19:37:27 <clarkb> if it isn't then we keep debugging
19:37:36 <SpamapS> dib should be set -e
19:37:45 <SpamapS> Like, thats a bug, I'd happily triage that as High priority
19:38:19 <jeblair> #topic  Jobs on trusty
19:38:33 <jeblair> er, do we have any current work going on with this?
19:38:42 <clarkb> jeblair: pypy switched
19:38:46 <fungi> yeah, it's slowed a bit but progressing
19:38:56 <fungi> we did move all the pypy jobs to trusty last week, yes
19:39:01 <clarkb> py34 is still in progress. the upstream bug for the py34 gc bug has an assignee now
19:39:18 <jeblair> any reviews need attention?
19:39:21 <fungi> the main blocker bug for 3.4 is now picked up by barry so presumably new package coming to trusty soon
19:39:30 <jeblair> cool
19:39:37 <clarkb> #link https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1367907
19:39:38 <uvirtbot> Launchpad bug 1367907 in python3.4 "Segfault in gc with cyclic trash" [High,In progress]
19:39:43 <fungi> all of the outstanding reviews at this point are in non-infra projects
19:40:03 <fungi> #link https://etherpad.openstack.org/p/py34-transition
19:40:05 <fungi> is up to date
19:40:24 <jeblair> #topic StoryBoard Migration (krotscheck)
19:41:05 <jeblair> krotscheck: is the migration script ready for use?
19:41:52 <jeblair> let's assume so.  :)
19:42:06 <jeblair> do we want to move all the infra projects at once?
19:42:17 <clarkb> I think so
19:42:19 <mordred> yah
19:42:19 <jeblair> i lean toward yes
19:42:28 <clarkb> if we are going to deal with the pain might as well jump into the deep end
19:42:39 <clarkb> more opportunities to get through issues too
19:42:43 <fungi> i will go mad switching back and forth constantly otherwise
19:42:43 <mordred> jeblair: I believe krotscheck said that it quite successfully loads his local instance with tons of data
19:42:43 <jeblair> and we close all the bug-trackers on launchpad except for openstack-ci, which we will leave open for e-r tracking only
19:43:02 <mordred> jeblair: we could make an elastic-recheck tracker
19:43:08 <mordred> and close openstack-ci
19:43:22 <jeblair> i'm guessing we move existing openstack-ci bugs to openstack-infra/config (soon to be system-config)
19:43:29 <mordred> ++
19:43:36 <fungi> i agree
19:43:46 <jeblair> mordred: it's not for bugs in elastic-recheck, it's for "infra bugs" that elastic-recheck sees
19:43:46 <krotscheck> Sorry
19:43:51 <krotscheck> Was talking with zaneb
19:43:52 <krotscheck> zaro
19:44:06 <krotscheck> SO the migration script landed with https://review.openstack.org/#/c/122047/
19:44:17 <krotscheck> I’ve been able to load zuul and storyboard with it.
19:44:39 <jeblair> isn't storyboard already in storyborad?
19:44:51 <krotscheck> There’s a couple of misfiled bugs on launchpad.
19:44:54 <jeblair> (ooh, there he is again -- that story borat)
19:45:06 <mordred> jeblair: AAH. gotcha
19:45:09 <fungi> does the migration script preserve bug number to identical story number or is there some indirect mapping?
19:45:10 <jeblair> krotscheck: oh, what project are they filed against?
19:45:26 <krotscheck> jeblair: openstack-infra/storyboard
19:45:36 <jeblair> krotscheck: on launchpad
19:46:01 <krotscheck> fungi: It does not maintain numbers, but it does keep track of an internal cache so duplicates aren’t imported on a failure.
19:46:09 <mordred> so - two thoughts ...
19:46:21 <jeblair> krotscheck: (i'm confused because i think you said you moved storyboard bugs over, but i don't think there should be storyboard bugs in launchpad)
19:46:27 <mordred> a) maintaining numbers would be nice ... however b) if we do that, we'll need to manage auto-increment-index
19:46:38 <fungi> just curious how we look up the new story for a known lp bug number
19:46:43 <jeblair> mordred: i kind of think maintaining numbers is critical for openstack
19:46:43 <ttx> storyborat - I see an April's fools in the making
19:46:51 <jeblair> maybe not
19:46:55 <mordred> jeblair: I do too
19:47:05 <mordred> because there are going to be a ton of patches up that reference the old number
19:47:05 <jeblair> okay, so what's the story there?
19:47:14 <krotscheck> jeblair: Lemme go find those
19:47:15 <jeblair> and feel free to just rtfm me to where this is doc'd
19:47:17 <mordred> I have a thought in my head of how we can do it
19:47:24 <mordred> that I can write up and propose
19:47:33 <zaro> maybe use a field to map storyboard # to launchpad #?
19:47:35 <fungi> foreign keys! foreign keys!
19:47:42 <jeblair> mordred: okay, maybe we should make sure we know what the whole story is there before we actually import infra
19:47:44 <clarkb> does an autoincrementing index not jump values already present?
19:47:57 <jeblair> because we're maybe about to do something irreversible
19:48:05 <mordred> clarkb: it does - we'll just need to alter the table and set the next value for auto-increment after we do the import
19:48:15 <jeblair> there's the additional complication of two imports
19:48:31 <zaro> i think i already have patches that reference storyboard #s
19:48:39 <mordred> because we don't want to autoincrement in a space that has numbers we're going to pull
19:48:41 <jeblair> we don't want storyboard's new very-high autoincrement (because of the infra import) to start using story numbers that exist in lp and might even be an openstack bug later
19:48:48 <mordred> right
19:48:50 <reed> do we have a bot that stores quotes? "<jeblair> because we're maybe about to do something irreversible" deserves to be passed to history
19:48:50 <jeblair> mordred: ++
19:48:54 <mordred> which is why we set the index
19:49:02 <krotscheck> mordred: That… worries me, because if we import one project whose last bug is ##, and autoincrement to ##+1, but that’s owned by a different project which is imported later(tm)....
19:49:02 <mordred> reed: we should have one
19:49:07 <mordred> right
19:49:11 <clarkb> mordred: gotcha
19:49:12 <mordred> this is the thing I keep saying
19:49:18 <mordred> we need to set the autoincrement index
19:49:22 <mordred> for all of the above reasons
19:49:32 <mordred> we can do this in one of two ways ...
19:50:05 <krotscheck> I remember this discussion in Brussles being ‘well, by the time our normal storyboard autoindex hits the first bug filed for openstack, we’ll be old men.
19:50:12 <reed> have the imported bugs keep numbers and manage new bugs with letter-number combo? :)
19:50:13 <mordred> we can set it back to what it was before the import - or we can just bump it up to well above the current max
19:50:25 <krotscheck> s/(men)/wo\/($1)
19:50:27 <mordred> I think I would vote for setting it low
19:50:34 <jeblair> mordred: yeah, that sounds like it will work
19:50:43 <mordred> I'd liek to write this up in a sane way and send it out
19:50:44 <jeblair> (i've never done that, but i take your word it can be done in mysql)
19:50:47 <mordred> and not try to explain it all here
19:50:52 <jeblair> mordred: sounds good
19:51:04 <krotscheck> Righto
19:51:11 <krotscheck> I think I know what you mean.
19:51:20 <jeblair> #action mordred to write up autoincrement plan for infra bug import
19:51:52 <jeblair> anything else on this?
19:52:06 <krotscheck> Which project do you want to move first? I want to do test runs on a local instance.
19:52:22 <jeblair> krotscheck: i think we want to move them all at (approximately) the same time
19:52:24 <mordred> krotscheck: I'd try test runs on openstack-ci - since that's got the most stuf
19:52:30 <jeblair> we should probably rustle up a list of what "all" means :)
19:52:35 <mordred> jeblair: ++
19:52:50 <krotscheck> indeed.
19:53:09 <jeblair> anyone want to take a stab at that?
19:53:15 <krotscheck> I can handle that.
19:53:34 <jeblair> #action krotscheck make list of infra projects in launchpad for krotscheck to use in testing
19:53:44 <jeblair> i don't think it's actually that many
19:53:56 <krotscheck> Right, I’ll ping in the infra channel to get people’s opinions
19:54:02 <jeblair> ++ thanks
19:54:19 <jeblair> end of topic?
19:54:26 <krotscheck> it is for me.
19:54:29 <jeblair> #topic  Publish devstack.org content under infra (anteaya)
19:54:57 <jeblair> anteaya: ?
19:55:00 <anteaya> so at the beginning of Juno we had a meeting agenda item about this and agreed this was something we wanted to do
19:55:18 <anteaya> then we got bogged down in the devstack.org > foundation domain name change
19:55:21 <jeblair> oh hey the foundation owns the domain now :)
19:55:28 <anteaya> which jbryce has confirmed has happend
19:55:31 <anteaya> yes they do
19:55:34 <anteaya> so we are off again
19:55:40 <anteaya> what do we want to do?
19:55:53 <jeblair> did we decide on a home for the content to live?
19:56:00 <anteaya> if memory serves, we wer at the point of figuring out servers and redirects
19:56:07 <anteaya> we did not that I recall
19:56:10 <jeblair> if not, we should ask dtroyer where it should go
19:56:11 <anteaya> but we wanted to
19:56:19 <jeblair> eg, in devstack itself, or in a new "devstack-org" repo
19:56:28 <anteaya> oh the code is in devstac
19:56:48 <jeblair> anteaya: yeah, in the gh-pages branch
19:56:53 <anteaya> dtroyer made the source code change in the spring, it lives in devstack/docs
19:56:58 <jeblair> oh ok
19:56:59 <jeblair> cool
19:57:10 <anteaya> now where do we want to serve it up?
19:57:32 <jeblair> then yeah, we just need some jobs to publish it to, probably at this point, a vhost on static.o.o ?
19:57:44 <anteaya> #link http://git.openstack.org/cgit/openstack-dev/devstack/tree/docs/source
19:57:54 <jeblair> (eventually, probably a vhost on publish.o.o, but that's part of the docs publishing spec and work hasn't started on that yet)
19:58:33 <anteaya> and fungi I told jbryce you would let him know when we are ready for a domain name record change
19:58:55 <jeblair> is it not managed in the usual way?  if so, we should be able to change it.  if not, i'm not interested in doing this.  :)
19:59:15 <fungi> anteaya: yeah, he'll presumably need to repoint the authoritative dns to rackspace's nameservers once we set up a zone for it
19:59:16 <jeblair> oh
19:59:27 <anteaya> jeblair: ah sorry, I don't know
19:59:29 <jeblair> it's still pointed at different authoritative servers
19:59:33 <fungi> assuming it isn't there already
19:59:53 <anteaya> I don't know what the usual way is
20:00:01 <anteaya> and jbryce may or may not either
20:00:08 <jeblair> so yeah, let's say the first step is getting it attached to the openstack account in rackspace cloud so we can manage dns for it
20:00:11 <fungi> yeah, it's being served by not-rackspace dns servers at the moment
20:00:21 <anteaya> fungi: can you do that then?
20:00:23 <clarkb> jeblair: sounds good
20:00:38 <fungi> sure, #action me bob
20:00:49 <anteaya> ha ha ha
20:00:50 <jeblair> #action fungi get devstack.org served by openstack rackspace dns account
20:00:55 <fungi> i'l need to figure out what sequence rackspace wants it to happen in
20:01:01 <jeblair> thanks everyone, we're at time!
20:01:04 <jeblair> #endmeeting