============================================ #fedora-meeting: Infrastructure (2011-05-26) ============================================ Meeting started by nirik at 19:00:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-05-26/infrastructure.2011-05-26-19.00.log.html Meeting summary --------------- * Robot Roll Call (nirik, 19:00:01) * New folks introductions (nirik, 19:01:32) * ACTION: nirik will ping all fi-apprentice folks on the 1st. Inactive people will be removed the 7th. (nirik, 19:11:48) * Upcoming Tasks/Items (nirik, 19:11:56) * Quick Release retrospective (nirik, 19:55:45) * Open Floor (nirik, 19:58:34) Meeting ended at 20:00:23 UTC. Action Items ------------ * nirik will ping all fi-apprentice folks on the 1st. Inactive people will be removed the 7th. Action Items, by person ----------------------- * nirik * nirik will ping all fi-apprentice folks on the 1st. Inactive people will be removed the 7th. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * skvidal (146) * nirik (91) * ricky (49) * abadger1999 (37) * CodeBlock (16) * StylusEater (13) * janfrode (6) * zodbot (6) * goozbach (4) * mfurman (2) * Klainn (1) * jsmith (1) * smooge (0) * codeblock (0) -- 19:00:01 <nirik> #startmeeting Infrastructure (2011-05-26) 19:00:01 <zodbot> Meeting started Thu May 26 19:00:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:01 <nirik> #meetingname infrastructure 19:00:01 <nirik> #topic Robot Roll Call 19:00:01 <nirik> #chair goozbach smooge skvidal codeblock ricky nirik abadger1999 19:00:01 <zodbot> The meeting name has been set to 'infrastructure' 19:00:01 <zodbot> Current chairs: abadger1999 codeblock goozbach nirik ricky skvidal smooge 19:00:05 * ricky 19:00:11 * skvidal is here 19:00:13 * janfrode 19:00:15 * CodeBlock 19:00:39 * Klainn lurking 19:01:17 <nirik> ok, lets go ahead and dive in... 19:01:32 <nirik> #topic New folks introductions 19:01:38 <nirik> any new folks want to say hi? :) 19:01:51 <nirik> or apprentice folks like to chime with any questions or comments... 19:02:13 <nirik> janfrode: I saw your check on that one machine... meaning to reply there. ;) Sorry for the delay. 19:02:37 <janfrode> nirik: yes, was it something like that you wanted per machine ? 19:02:59 <nirik> yeah. I think we can fix some of the things on that one and it will help with others. 19:03:35 * nirik will try and look in more detail on that later today. 19:04:09 <nirik> any other new folks/apprentice issues? I did update the page a bit more: https://fedoraproject.org/wiki/Infrastructure_Apprentice 19:04:48 <nirik> I'll also try and find a few more easy tickets for apprentice folk to look into if they find them interesting... 19:05:03 <nirik> ok, moving on then in a minute... 19:05:11 * StylusEater is late, sorry 19:05:22 <mfurman> is late also, sorry 19:05:25 <nirik> no problem. 19:05:38 <nirik> you guys have any questions or comments on apprentice stuff? 19:05:47 <goozbach> here but not here 19:05:57 <skvidal> do we think it is working? 19:06:06 <nirik> I think it's too early to tell... 19:06:10 <skvidal> does being able to login and look around help? 19:06:16 <goozbach> does for me 19:06:17 <mfurman> nirik: not right off hand 19:06:18 <StylusEater> skvidal: can we run the puppet changes from that ticket? 19:06:30 <skvidal> from which ticket? 19:06:31 <nirik> StylusEater: which ticket? 19:06:32 <goozbach> well in understanding tuff 19:06:33 <StylusEater> skvidal: yes being able to login does help 19:06:34 <goozbach> stuff 19:06:43 <skvidal> goozbach: tuff stuff 19:07:00 <StylusEater> nirik: grabbing it 19:07:21 <StylusEater> .ticket 2777 19:07:22 <zodbot> StylusEater: #2777 (/etc/system_identification missing on some hosts?) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/2777 19:07:59 <StylusEater> skvidal: we were in freeze when the last meeting happened and you mentioned to put some changes in the ticket 19:08:04 <skvidal> ah 19:08:05 <skvidal> yes 19:08:09 <skvidal> thanks for reminding me 19:08:13 <skvidal> yah - I can check that in 19:08:13 <nirik> cool. 19:08:40 <StylusEater> skvidal: mcpita feedback too if you have time. 19:08:55 <StylusEater> .ticket 2747 19:08:56 <zodbot> StylusEater: #2747 (publictest minder script/db) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/2747 19:08:56 <skvidal> StylusEater: oh yes - I completely forgot about that... 19:09:06 <skvidal> StylusEater: again, thanks for the reminder 19:09:08 <nirik> excellent. We can handle those out of band? 19:09:13 <skvidal> yes 19:09:38 <nirik> ok, moving on in a minute unless something more on this topic comes up... 19:09:57 <CodeBlock> when is the apprentice cleanup? 19:10:25 <nirik> CodeBlock: good question. I had it as part of the per release housecleaning, but I think we should make it more often. ;) 19:10:37 <nirik> I was going to mail the group on the 1st and ask for feedback and how people were doing. 19:10:50 <nirik> people who don't reply by say the 7th, we could remove? 19:10:55 <CodeBlock> sounds good 19:10:58 <skvidal> +1 19:11:00 <nirik> we can always readd people who are away. 19:11:04 <CodeBlock> yep 19:11:20 <StylusEater> nirik: good idea 19:11:48 <nirik> #action nirik will ping all fi-apprentice folks on the 1st. Inactive people will be removed the 7th. 19:11:56 <nirik> #topic Upcoming Tasks/Items 19:12:18 <nirik> CodeBlock: when did you want to do the noc01 update? monday (which is a holiday), or ? 19:12:41 <CodeBlock> gah, yes Monday is a holiday ..and Tuesday is updates day 19:12:50 <nirik> 2011-05-31 18UTC UPDATES/reboots 19:13:07 <CodeBlock> Wednesday? 19:13:08 <nirik> also, Smooge wanted to do secondary cutover on the 31st (from 01 to 02) 19:13:15 <CodeBlock> (re nagios) 19:13:16 <nirik> sure. 19:14:04 <nirik> also, next week I am going to look at a new puppet and app01. 19:14:10 <nirik> (or later this week I guess) 19:14:20 <nirik> they are both on xen14, which is heading out of warentee. 19:14:39 <CodeBlock> so Wednesday the nagios stuff is definitely happening, it's been pushed back like 5 times now. 19:14:46 <nirik> yeah. 19:14:54 <nirik> it would be good to get it over. 19:14:57 <CodeBlock> yeah 19:15:07 <nirik> Other upcoming items: 19:15:14 <nirik> 2011-06-14 or so: post release housecleaning tasks. 19:15:14 <nirik> 2011-06-17 FPCA drop dead. 19:15:47 <nirik> I'm going to try and add more details to the post release housecleaning. 19:15:51 <abadger1999> Re: the fpca drop dead. I have a script to gather some fas/pkgdb metrics to run. 19:15:53 <nirik> will mail the list for more feedback 19:16:02 <nirik> abadger1999: cool. 19:16:34 <abadger1999> Will do that sometime this week. 19:16:43 <nirik> I think we are about 33% of people in cla_done+1 who have signed the fpca now. 19:16:58 <jsmith> nirik: That's great news! 19:17:38 <nirik> excuse me, 36% it seems. ;) 19:18:07 <nirik> ok, anyone have any other upcoming items they would like to discuss? 19:18:49 <nirik> ok, moving on then... 19:18:56 * skvidal had one 19:19:01 <nirik> go ahead: 19:19:07 <skvidal> merging of staging into master 19:19:09 * nirik can't type. go ahead. 19:19:10 <skvidal> and doing away with staging 19:19:28 <skvidal> 1. is anyone opposed to getting rid of 'staging' in our puppet git repo? 19:19:40 <nirik> I think stg the instances/machines has been useful. 19:19:57 <skvidal> nirik: the machines, sure 19:20:08 <skvidal> but I'm just talking about the staging 'branch' in our git repo 19:20:09 <nirik> you mean change how we deal with it, right? 19:20:13 <skvidal> yes 19:20:32 <skvidal> I've found that generally folks apply changes to master 19:20:37 <skvidal> and never merge them over to staging 19:20:42 <skvidal> for a while I thought it was just me 19:20:47 <skvidal> but then I discovered it was not 19:21:10 <skvidal> so in looking at what we have 19:21:16 <nirik> I think if we can come up with a better way that would be great. 19:21:28 <skvidal> well since the machines we use are just hostname.stg.blah 19:21:37 <skvidal> and we have to have that anyway for the nodename 19:21:51 <ricky> .stg modules? 19:21:57 <skvidal> is there any reason that we want to make something to test out - we couldn't do them the same 19:21:59 <ricky> That we delete when we're done? 19:22:03 <skvidal> or -staging class names 19:22:09 <skvidal> ricky: why not? 19:22:16 <skvidal> ricky: it's not like we're running out of disk space ;) 19:22:25 <nirik> or is there some way to #include the real one and just add our changes/staging changes above that? 19:22:54 <ricky> Puppet lets you do that, but then you can take those configs and paste them directly into the production configs 19:22:55 <skvidal> inheritance in puppet is sometimes...... challenging to follow out 19:23:05 <ricky> So it's probably easier to just copy entire modules or classes that you need to modify 19:23:09 <skvidal> nod 19:23:23 <abadger1999> There's things I like about the staging branch setup... but maybe it could be done differently. 19:23:41 <skvidal> abadger1999: what do you like about it? 19:23:47 <nirik> well, most of the time they will not be different from the real machine they are staging for except for a staging variable and /etc/hosts, right? 19:23:58 <abadger1999> Being able to merge master <=> staging is nice when you just have your changes -- debit is it's a pain when there's other peoples changes and you don't know what to do with it. 19:24:30 <janfrode> At work we run two git branches for puppet.. "master" on our lab/staging servers, and "production" on our production servers. We try to do all changes in "master", test them a few days on lab/staging before merging to "production". 19:24:42 <abadger1999> having the $environment variable so a template can be the same for staging and production but create a different file for .stg and prod is the other thing I like. 19:25:00 <ricky> Part of the trouble stems from the fact that our puppet configs is one giant repo, instead of being split out into separate bits that people care about. But I don't see that changing anytime soon 19:25:08 <nirik> janfrode: yeah, our prod is 'master' which is a bit backwards. ;( 19:25:24 <skvidal> abadger1999: see the $environment actually is one of the items that bothers me 19:25:34 <abadger1999> I dislike git branches in general, though, so if we can get something siilar without the git branches, I'd be more than happy. 19:25:36 <ricky> So you end up doing a merge, and having 10 other people's staging changes conflicting 19:25:47 <skvidal> ricky: yes 19:26:20 <skvidal> abadger1999: b/c you end up diverging so much and not being able to find the changes 19:26:22 <nirik> it would be nice whatever we end up with has a workflow that requires the changes in stg first... 19:26:25 <skvidal> but part of this is the way git does branches 19:26:32 <skvidal> nirik: except that doesn't work 19:26:38 <abadger1999> skvidal: I mean in a template: 19:26:43 <ricky> nirik: The problem with that right now is that our staging environment isn't complete :-/ 19:26:45 <skvidal> nirik: since our staging environment doesn't even remotely mimic our actual envir 19:26:46 <nirik> or automatically having them appear in stg when they land in prod 19:26:56 <nirik> yeah, there is that too. 19:27:01 <skvidal> nirik: automaticlaly just means anyone doing any real serious new work 19:27:05 <skvidal> in staging 19:27:12 <ricky> There was work to make koji01.stg actually work and be testable against two years back, but that never finished 19:27:18 <skvidal> is going to get tromped on when someone adds something in master 19:27:23 <ricky> I think staging has been mostly useful for web stuff, and that's about it 19:27:34 <skvidal> ricky: and then only with great effort 19:27:36 <ricky> *Maybe* testing updates, if people notice that they break 19:27:38 <abadger1999> skvidal: Things like this: http://fpaste.org/OYiM/ (from pkgdb.cfg) 19:28:03 <nirik> it was usefull for pkgs01 changes recently. 19:28:03 <skvidal> abadger1999: that exact same thing - in the postfix config - makes me want to hurt things 19:28:17 <skvidal> this is just what ricky and I were discussing 19:28:17 <abadger1999> skvidal: ah? So it's causing lots of divergence? 19:28:23 * abadger1999 looks at postfix config 19:28:31 <skvidal> in #fedora-noc 19:28:43 <skvidal> our modules are named after the app name 19:28:47 <skvidal> NOT after the service name 19:28:50 <skvidal> so we end up with 'httpd 19:28:51 <skvidal> module 19:28:54 <skvidal> which is useless 19:29:00 <skvidal> b/c everyyhing has an apache server on it 19:29:08 <skvidal> and we end up with entire world inside that module 19:29:26 <skvidal> we're much better off with service-instance names for our modules 19:29:28 <skvidal> so we have a module like 19:29:36 <skvidal> mailman-project 19:29:38 <skvidal> mailman-hosted 19:29:42 <skvidal> etc, etc 19:30:01 <skvidal> rather than having to do some horrible things to create 1 template file for fairly divergent configurations 19:30:13 * nirik nods. 19:30:21 <abadger1999> skvidal: I don't see any <% if environment ==.... in the postfix module. 19:30:23 <skvidal> I'm fine with configfile.cfg.hostname, too 19:30:32 <skvidal> abadger1999: in that case it's not the environment that's tripping it up 19:30:36 <abadger1999> skvidal: I think the service thing is different than the environment thing 19:30:38 <skvidal> abadger1999: in that case it is the 'is router' thing 19:30:44 * ricky isn't a huge fan of configfile.cfg.hostname 19:31:00 <skvidal> abadger1999: it is an it is not - it's all of the same problem in my head 19:31:07 <abadger1999> skvidal: Yeah -- I'd agree with you that using templates for doing different services from the same template is not something we really want to do. 19:31:23 <ricky> We end up having rsyncd.conf.download[1-5] and having to copy the same file back and forth - it'd be nice to have at the servertype level instead of at the node level 19:31:26 <skvidal> abadger1999: the issue is - we seem eager to conflate things to being 'one service' but it ends up costing us a lot of time when we have to make a big change 19:31:40 <abadger1999> I like it for environment as it means changes to the staging and prod environment are in sync.... don't have to update in two places. 19:31:52 <skvidal> ricky: well in that case a service-instance would be like: rsyncd-download 19:32:26 <skvidal> but I would not recommend a global 'rsyncd' module b/c it just means we cram a bunch of disparate junk into the rsyncd module dir 19:32:32 <ricky> Yes, I'd love to have that. And have most puppet things split by server type in a consistent way. 19:32:42 <skvidal> janfrode: you've said you use puppet in production 19:32:46 <skvidal> janfrode: how do y'all split up your modules? 19:33:17 <skvidal> abadger1999: how does it stay in sync? If you make a change to the template in master - you have to update it in staging, too - or at least merge it 19:33:26 <janfrode> skvidal: it's per app, not service.. 19:33:45 <skvidal> janfrode: so you have one big dir of 'httpd' that has a billion machines in it? 19:34:07 <abadger1999> skvidal: Yes, but if we had staging and master and one config file for the staging instance and one config file for the master instance, then we'd have four places to edit. 19:34:17 <janfrode> skvidal: not gotten there yet.. We don't have httpd configs in puppet yet. 19:34:25 <skvidal> abadger1999: I'm not sure I understand 19:34:34 <nirik> skvidal: I think the idea is that you make a change to stg, test, fix, come up with a final change that work, and then that exact change can be apply to master... 19:34:51 <StylusEater> nirik: that is my understanding too 19:34:55 <skvidal> nirik: which, again, fails b/c are staging env is only a handful of machines 19:35:00 * nirik wonders if bcfg is looking better (if only for a chance to reorg our existance:) 19:35:04 <ricky> One thing I wouldn't mind is to have a small httpd module that sets up basic stuff like logging, and then have anything more than that be configured per-service 19:35:05 <skvidal> people, for example, planet, most/all of koji 19:35:17 <abadger1999> skvidal: I'd love something like a template when included into a staging host it uses the staging $environment ; when included into a production host it uses the production $environment. 19:35:26 <janfrode> skvidal: but we do have things like an sudo module, and a separate "project" module that overrides the sudoers "content" setting. 19:35:32 <StylusEater> skvidal: so we're really trying to find a way to work around the assymetry of the environments 19:35:53 <abadger1999> skvidal: although.... I guess that we'd need some way to prevent the new version of the file going to production before we've tested in staging... so we always need at least two steps... hmm... 19:36:08 <skvidal> StylusEater: and the persistent assymetry - since I doubt seriously we're ever going to duplicate the whole thing 19:36:15 <StylusEater> skvidal: yes 19:36:31 <skvidal> nirik: so maybe that's a path to take 19:36:57 <StylusEater> so can we identify base configurations that will always stay the same...maybe pack those into modules, then per node make tweaks? I imagine that's what skvidal is saying but I don't want to put words in his mouth. 19:37:08 <ricky> Are we actually ever hoping to have a real staging environment, or will staging always only be useful for testing web app changes? 19:37:21 <nirik> skvidal: well, or I guess targeted pruning/cleanups... ie, pick one thing and fix it up, next... 19:37:21 <ricky> If we decide that, then maybe we can better design how staging vs. prod will actually work 19:37:25 <skvidal> ricky: I would not wager on ever having a real/complete staging env 19:37:53 <skvidal> nirik: so let's talk, briefly, about the places where staging is used 19:37:56 <skvidal> 1. web app dev 19:37:58 <skvidal> 2. nagios 19:38:08 <skvidal> those are the 2 I know of 19:38:10 <CodeBlock> hardly nagios... 19:38:22 <skvidal> CodeBlock: I was just going to mention that 19:38:36 <nirik> yeah, mostly/all web app stuff... 19:38:37 <CodeBlock> that was basicaly a testing ground for nag3... 19:38:38 <skvidal> there is no point in staging nagios - it doesn't conclict 19:38:41 <abadger1999> skvidal: I'd say the staging env works fairly well for testing some things -- the incompleteness doesn't mean we can't test read-only operation of bodhi, for instance, but we can't test that bodhi-koji-mash-createrepo all works. 19:38:47 <CodeBlock> *basically 19:39:02 <ricky> But that mostly falls under web, right? 19:39:12 <nirik> it's also used for pkgs/git/scm testing 19:39:24 <nirik> and possibly db stuff? 19:39:25 <skvidal> abadger1999: right - so we don't know that when we update rpm or somesuch that we'll break something in the mash stack 19:39:27 <abadger1999> simiarly, we can test pkgdb lets people change package ownership, but not whether pkgdb updates bugzilla bugs. 19:39:41 <skvidal> abadger1999: so help me out here 19:39:42 <abadger1999> skvidal: right. But that doesn't mean we have to give up on testing bodhi in staging. 19:39:46 <skvidal> no 19:39:49 <skvidal> I'm not saying we do 19:39:52 <abadger1999> <nod> 19:39:59 <ricky> I don't think anybody here wants to give up any staging functionality we have now 19:40:08 <skvidal> right now if you want to stage something out 19:40:09 <skvidal> you do 19:40:10 <ricky> Just want to find out which functionality we want/need from it 19:40:12 <skvidal> git checkout staging 19:40:13 <skvidal> modify 19:40:15 <skvidal> commit 19:40:16 <skvidal> push 19:40:21 <skvidal> blah blah 19:40:25 <skvidal> test changes 19:40:35 <skvidal> git merge your changes 19:40:40 <skvidal> see how much they conflict 19:40:41 <skvidal> manually fix 19:40:45 <skvidal> git push 19:40:53 <skvidal> all I'm really suggesting is this 19:41:00 <skvidal> instead of doing git checkout staging 19:41:10 <skvidal> for your modules you're acting on 19:41:19 <skvidal> just make -staging copies of them 19:41:20 <skvidal> modify 19:41:29 <skvidal> and merge them back to not-staging when you're ready 19:41:41 <abadger1999> skvidal: How do you merge them back when you're ready? 19:41:44 <skvidal> abadger1999: cp? 19:42:01 <abadger1999> Well, that doesn't work without the env var. 19:42:03 <skvidal> abadger1999: git diff/patch 19:42:06 <skvidal> abadger1999: huh? 19:42:09 <ricky> Conflicts can still happen unfortnuately :-/ 19:42:11 <skvidal> without the env var? 19:42:13 <skvidal> ricky: yes 19:42:21 <skvidal> ricky: but you don't have to dance between git branches 19:42:26 <skvidal> ricky: and occasionally have to start over :) 19:42:28 <abadger1999> skvidal: So if we can get the s/env var/puppet environment var/ working, that would be fine. 19:42:46 <skvidal> abadger1999: I'm really not understanding the issue 19:42:51 <abadger1999> skvidal: If you had pkgdb.cfg configured for staging... it has to take into account the incompleteness of staging. 19:42:52 <ricky> Hm. I happen to hate git less than most people here, so maybe it's just me 19:43:07 <ricky> But I prefer conflicts git knows about to conflicts git doens't know about 19:43:10 <abadger1999> for instance, we don't want to send email in staging for somethings, but we would in production. 19:43:11 <skvidal> ricky: I'm not alone in having to 'rm -f puppet' and git clone it all again 19:43:25 <ricky> But yeah, I can see the pain for people that don't like git :-) 19:43:38 <skvidal> abadger1999: so you just want to set an env var that cascades down? 19:43:51 <abadger1999> skvidal: So the staging config isn't going to be 100% like the production config... unless we can conditionalize those sections. 19:43:59 <ricky> We could keep the environments variable and just get rid of the branch. 19:43:59 <abadger1999> skvidal: I think that might work. 19:44:05 <nirik> skvidal: he wants to set that in stg when testing, but remove it before commiting/pushing to master/prod 19:44:07 <abadger1999> skvidal: Then we could cp the files 19:44:15 <ricky> Actually, we could even do this: 19:44:28 <ricky> For all staging changes, add an if $environment == "staging" { stuff } 19:44:34 <ricky> Then manually merge that in after you're done 19:44:58 <abadger1999> ricky: We could do that -- I like cp the file better though -- 19:44:58 <ricky> Then at least conflicts in the puppet manifests don't happen because there's only one copy of the file 19:45:07 <ricky> Unfortunately conflicts still happen in config files 19:45:19 <abadger1999> that keeps the conditionalized sections for things that are permanent differences between the environments. 19:46:35 <skvidal> okay - so it sounds like there is a fair amount of difference of how we do these things. 19:46:36 <nirik> so pkgs01.stg.whatever would be a hard link to pkgs01.whatever and when making stg changes, add them to the $env == "staging" 19:46:44 <ricky> I'm becoming crazy about the copy/rename classes/files because it increases the startup time for tiny changes that I typically do 19:46:49 <ricky> **becoming less crazy 19:46:55 <abadger1999> skvidal: So question about staging in branches -- do you think more/most of the issues are the sync from master=>stg not happening (rather than stg => master) ? 19:47:09 <skvidal> abadger1999: for me it has been both ways 19:47:13 <abadger1999> k 19:47:16 * nirik thinks we need to ponder on this morning perhaps. 19:47:19 <skvidal> abadger1999: and also it has been a fair bit of "where the hell is this" 19:47:20 <nirik> more. 19:47:23 <nirik> sheesh. 19:47:27 <abadger1999> skvidal: +1 to that last point. 19:47:34 <ricky> I think the problem is that stg => master doesn't happen enoguh, or doesn't happen cleanly (ie it has to be via a cherrypick) 19:47:35 <abadger1999> That drives me crazy too. 19:47:41 <skvidal> abadger1999: b/c I hate having that several minutes of "where is this in puppet" which I invariable have to do 19:47:45 <ricky> Which then cascades into making master => stg all broken 19:48:13 * nirik hugs git-grep 19:48:20 <ricky> git diff --stat staging master 19:48:21 <ricky> 665 files changed, 3846 insertions(+), 22484 deletions(-) 19:48:31 <skvidal> this is a situation where I would love to have a separate git repo for each of the major sections/modules 19:48:33 <skvidal> not a branch 19:48:36 <skvidal> a separate TREE 19:48:45 <skvidal> so when someone on the web team modifies a file 19:48:48 <skvidal> I don't have to care 19:48:50 <ricky> Yes, that's what I mentioned above with the "doesn't seem too likely to happen" :-/ 19:49:09 <ricky> It would mean that I can do merges on just the stuff that I care about 19:49:23 <nirik> can puppet deal with multiple repos like that? 19:49:23 <ricky> So somebody else's weird conflicts become not my problem :-) 19:49:32 <ricky> Yeah, puppet doens't care about the repos at all 19:49:36 <abadger1999> skvidal: Maybe we should break smolt off into a separate tree when we do that split and experiment? 19:49:39 <nirik> ie, if we split out say smolt into it's own thing 19:49:39 <ricky> It's just our git pull script would have to change 19:49:45 <nirik> abadger1999: jinx. 19:49:50 <abadger1999> :-) 19:49:50 <ricky> It's quite easy to do incrementally 19:49:55 <skvidal> nirik: all we do on puppet push 19:50:00 <skvidal> nirik: is copy the files over to a path 19:50:06 <skvidal> nirik: it's not rocket science-y :) 19:50:25 <CodeBlock> We could do that, or smolt could be our first bcfg module ;D 19:50:43 <nirik> anyhow, we have spent a while on this, shall we ponder more on it? or do we think we are going to come to a conclusion here? 19:50:53 <nirik> CodeBlock: :) 19:51:05 <skvidal> nirik: acutally 19:51:11 <skvidal> with what codeblock said, in mind 19:51:16 <ricky> I'd be very happy with splitting modules into separate repos, and I think it'd alleviate a ton of the merging pain 19:51:19 <skvidal> Iwas curious if you'd be willing to do something on the puppet1 upgrade 19:51:43 * nirik glanced at bcfg the other day. 19:52:01 <skvidal> nirik: how about naming the machine adminsrv or something like that 19:52:08 <skvidal> instead of the application-specific name of puppet 19:52:14 <skvidal> we can have as many cnames as we like :) 19:52:25 <nirik> sure, that seems like a good idea... 19:52:28 <skvidal> but in the event we do decide to move to something else..... 19:52:51 <ricky> Wouldn't we do a rebuild/rename when we move to something else anyway? 19:53:01 <skvidal> ricky: not necessarily 19:53:08 <skvidal> ricky: just standing up an app 19:53:09 <ricky> Not hugely against renaming now, but don't see how the trouble of doing it can't be bundled with the trouble of switching 19:53:15 <skvidal> ricky: is all that's actually required 19:53:26 <skvidal> and it keeps us from making confusing statements when testing like 19:53:26 <ricky> OK, I like rebuilding stuff, but fine then 19:53:44 <skvidal> "go edit bcfg2 in puppet" 19:53:47 <skvidal> "waha?" 19:53:58 <skvidal> etc 19:54:03 <nirik> I think we don't want a 'lets cut all over to this tuesday'... instead we might keep using puppet for a while and have say bcfg2 in a mode where it makes no changes, but reports, etc. 19:54:12 <skvidal> nirik: nod 19:54:17 <nirik> so, the same machine could well be running 2 of them at once. 19:54:32 <skvidal> nod 19:54:42 <CodeBlock> yeah 19:54:43 <skvidal> since in both cases they are both just a webserver/service 19:54:46 <skvidal> and a dir full of files 19:55:16 <nirik> so, summary here: we don't like the branch and merge pain, we want to figure out a plan to remove that pain, further discussion on list or in -admin? 19:55:34 <skvidal> sure 19:55:45 <nirik> #topic Quick Release retrospective 19:55:54 * CodeBlock might play around with setting up bcfg on a pt or three 19:55:58 * CodeBlock shuts up now 19:56:00 <nirik> Anyone have items from the release? what went well? what blew up? 19:56:39 <nirik> websites had a bunch of changes, but websites folks did great making them quickly... :) 19:56:52 <nirik> our mirror tiering system didn't work too well, and we need to fix it before next release. 19:57:01 <ricky> With the new spins creation process, the file name changes shouldn't bite websites as much next time. As in there shouldn't be any :-) 19:57:12 <nirik> that would be good. 19:57:21 <ricky> And we've now got a list of docs that we double check with docs in advance, which should mean less broken links next time 19:57:35 <ricky> **fewer 19:58:34 <nirik> #topic Open Floor 19:58:38 <nirik> anything for open floor? 20:00:12 * nirik listens to the crickets 20:00:19 <nirik> ok, thanks for coming everyone. 20:00:23 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
