16:02:02 #startmeeting Server Working Group Weekly Meeting (2013-11-12) 16:02:02 Meeting started Tue Nov 12 16:02:02 2013 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:07 #chair sgallagh mizmo nirik davidstrauss Evolution Viking-Ice simo tuanta mitr 16:02:07 Current chairs: Evolution Viking-Ice davidstrauss mitr mizmo nirik sgallagh simo tuanta 16:02:12 #topic roll call 16:02:34 .hellomynameis tuanta 16:02:35 tuanta: tuanta 'Truong Anh Tuan' 16:02:41 .hellomynamis sgallagh 16:02:51 .hellomynameis kevin 16:02:54 nirik: kevin 'Kevin Fenzi' 16:02:58 .hellomynameis sgallagh 16:03:00 sgallagh: sgallagh 'Stephen Gallagher' 16:03:04 ./hellomynameis kdetony 16:03:27 .hellomynameis pingou 16:03:28 pingou: pingou 'Pierre-YvesChibon' 16:03:32 Hello all 16:03:36 kde_tony: Drop the slash 16:03:43 .hellomynameis kdetony 16:03:44 kde_tony: kdetony 'Anthony Mogrovejo' 16:03:59 hello 16:04:10 have we started yet ? 16:04:18 simo: Doing roll-call 16:04:47 * simo rolls in 16:04:52 * Viking-Ice half in 16:06:11 * nirik is also watching beta release stuff, so will be somewhat distracted. 16:06:18 Understood 16:07:15 Evolution can't make it today. 16:07:22 davidstrauss, mizmo? 16:07:28 .fasinfo mizmo 16:07:31 mizmo: User "mizmo" doesn't exist 16:07:37 .fasinfo duffy 16:07:38 mizmo: User: duffy, Name: duffy, email: fedora@linuxgrrl.com, Creation: 2006-04-07, IRC Nick: mizmo, Timezone: US/Eastern, Locale: en, GPG key ID: 65E04EE2, Status: active 16:07:42 mizmo: Approved Groups: +sysadmin-nuancier gitbadges @gitfedora-magazine marketing gitanaconda fedorabugs cla_fedora @art cla_done gitspacewalk +gitspins @web cvsfedora packager @gitbluecurve @gitthemes gitpulp gitfedoracommunity gitmoksha sysadmin @designteam sysadmin-test gitfedora-zikula @gitfedora-insight-theme gitvirt_web gitfedora-web ambassadors @gitsparkleshare @gitpandix-logos cla_fpca @gitfedora-ux (1 more message) 16:07:42 * mizmo learns her own username 16:07:51 whoah damn sorry i didnt know it was that verbose 16:08:12 mizmo: (dot)hellomynameis is less so 16:08:14 * mizmo hides in the corner 16:08:16 my fasinfo pales in comparison with that one 16:08:17 thats why the 'hellomynameis' is nice for this. ;) 16:08:49 Ok, I think we have quorum to proceed 16:08:51 or just ".fas" 16:08:56 #topic agenda 16:09:11 So, I dropped the ball and forgot to send out an agenda request this week. 16:09:26 So I guess we'll pretty much go free-form? 16:09:34 tuanta: but fas is a wildcard search, so can get a ton of other stuff too. ;) 16:09:40 (We have plenty to discuss, just no formal agenda) 16:10:08 well i would suggest we discuss your proposal and nirik's proposal 16:10:16 lemme double check and see what the last meeting minutes left open too 16:10:28 So just a minor note: props to Viking-Ice for suggesting a governance formula that most of the other groups are copying verbatim 16:10:40 sgallagh, just the wise ones ;) 16:10:45 +1 ;) 16:10:47 :) yeah, cool. 16:10:49 * pknirsch lurks again 16:10:51 I think I got server roles nailed here https://fedoraproject.org/wiki/User:Johannbg/FOSSP#Server_Roles.2C_Technologies_and_Features_in_FedoraOS_Server_Platform_.28_FOSSP_.29 16:11:15 looks like we didn't resolve this from last time: "Each server could have multiple roles at the same time" 16:11:44 i thought we agreed not to have 500 PRDs last time 16:12:01 Viking-Ice: That's quite exhaustive. Let's take a look at that a little later (hopefully we can all scan through it in parallel) 16:12:11 mizmo: Not the same thing 16:12:29 Viking-Ice: could you send an e-mail to the list about the document, to make sure everyone gets a chance to review/think about it? 16:12:37 A server having multiple roles could be as simple as "In my cost-constrained office, I want my domain controller to also be my email server" 16:13:06 mitr, the is an draft for the FOS proposal 16:13:09 huh, yeah, thats a long set of stuff. 16:13:20 sgallagh, it seems like some folks were against that and some were for it, last meeting iiuc 16:13:24 mitr, but it covers most stuff we have talked about 16:13:34 mizmo: There was concern about being able to test such things. 16:13:38 * nirik opens a tab to read it at some point. 16:13:44 Which is certainly valid. 16:13:53 Viking-Ice: all the same, I can't really comment on that long document during the same hour I've first seen it 16:14:15 yeah, testing can be a big pain if we have 10 featured things and you can install any one or any combo of them. 16:14:16 I'd be inclined to propose that the mechanisms we settle on should *allow* it, but state that we recommend against it and don't test it. 16:14:19 sgallagh: We aren't ordinarily concerned about testing a system that has both Firefox and Devhelp installed; isn't this the same thing? 16:14:24 mitr, yeah I actually was going to send this out yesterday ( and now I was just talking about server roles spesific section there ) 16:14:37 but we could also just say 'we test each of these things alone, let us know if they interact poorly' 16:14:39 maybe let's focus on the drafts that have been out on the list for a week+ and make sure this new draft document is put on the queue to discuss on the list? 16:14:51 mitr, but I was up 02:00 thinking about the update/upgrade lifecycle stuf 16:14:52 are we diving into multiple roles at once topic now? 16:14:52 mizmo: +1 16:15:01 mitr: At first glance I agree with you, but with server applications they can sometimes interact with each other in odd ways. 16:15:20 mizmo: +1 16:15:23 Such as requiring mod_nss vs. mod_ssl in apache (to pluck a known example out of the air) 16:15:43 sgallagh, can you chair me? 16:15:46 server can have one or more roles 16:15:50 Can we pick one thing to discuss at a time and set the topic? 16:15:52 there is no doubt about that 16:15:53 #chair mizmo 16:15:53 Current chairs: Evolution Viking-Ice davidstrauss mitr mizmo nirik sgallagh simo tuanta 16:15:54 sgallagh: that's agood point 16:16:06 #topic Can a single server have multiple roles? 16:16:12 I say yes 16:16:18 very much yes. 16:16:19 it can have multiple roles 16:16:23 I think so too... 16:16:35 but we need to be clear what we test in that world. ;) 16:16:37 Yes 16:16:39 As I said above, I think it must be possible, but we can probably get away with stating that we only test each role in a vacuum 16:17:00 we chose a role and we test cover that role 16:17:15 Alternatively, when/if we get automated tests, doing a "full install" and running all the tests on it should be reasonable - but let's nto commit do doing manual work twice 16:17:22 do we document roles that obviously conflict? 16:17:28 well in some cases you can in some others you cannot 16:17:31 practical example 16:17:33 Evolution, I would say not 16:17:36 in freeipa we use mod_nss 16:17:51 so you won't be able to use it with another program that depends on mod_ssl 16:17:52 it looks like another concern from last week's minutes, about multiple roles per server, was how to install the server that way 16:18:09 Evolution: That would still require testing all of them together to learn whether they conflict. 16:18:10 that may change in time to avoid issues 16:18:16 you install the base server ( which I call FOSSP ) then install one or more roles 16:18:25 and fedora server contribution may actually help smooth those issues in soem cases 16:18:28 simo: I cited that exact example about twenty lines ago :) 16:18:30 it's a factorial problem. ;) 16:18:31 Viking-Ice, yeh that makes sense to me 16:18:32 but we can only guarantee what we test 16:18:40 so perhaps we should start just with bare roles 16:18:47 and the in time add explicitly tested combinations 16:18:52 simo +1 16:18:55 sgallagh: sorry 16:19:01 simo, sounds like a sane approach 16:19:03 simo: Not a problem. Just glad we agree :) 16:19:21 simo: +1 to that. Want to phrase it as a proposal we can ack? 16:19:29 right. just want to be clear we set expectations. 16:19:29 are we all agreed on simo's approach? "Start with just bare roles, and in time add explicitly tested combinations" 16:19:42 +1 16:19:45 mizmo: +1 16:19:46 +1 16:19:48 +1 16:19:59 +1 16:20:00 sure +1 16:20:01 +1 16:20:17 #agreed Regarding multiple roles on one server, we will start with just bare roles, and in time add explicitly tested combinations. 16:20:22 +1 16:20:34 #topic Installation of base + roles 16:20:46 This was starting a discussion a few lines ago, probably worth calling it out 16:20:54 the anaconda ui actually makes this pretty easy... 16:21:05 mizmo: By way of comps groups? 16:21:07 you can set various roles to be compatible / incompatible and let users select 16:21:09 sgallagh, yep 16:21:14 * nirik nods. 16:21:17 I think we can agree on this "FedoraOS Server Platform ( FOSSP ) is made available with or without an predefined server role,ready to use ks for traditional method of installation,directly into an isolated or OS container or as an whole-disk images to be used in private/public cloud as instance-store image or standalone server in the cloud itself. " 16:21:21 thats the way to go in my opinion too 16:21:22 if we have a better answer to comps groups or want to expand on them or fix them though it should be possible i think 16:21:40 Viking-Ice: -1 on kickstarts 16:21:57 i think ickstart is too implementation specific although it's obviously going to come into play 16:22:02 kickstart even lol 16:22:02 nirik: Can you expand on that? 16:22:04 kickstarts should be supported but not required 16:22:12 Viking-Ice: way too many decisions in one sentence 16:22:51 kickstarts only work at install/create time. You can't for example install foo and then decide to add role bar later. 16:23:06 kickstarts contain too many site specific items. 16:23:07 nirik, if the role was a comps group you could tho 16:23:12 * sgallagh wants a roll-bar on his high-performance server 16:23:21 mizmo: yes, which is why I think it's a better solution 16:23:50 nirik, i dont think we have a good gui way to do it though 16:24:02 do what? 16:24:07 install groups post-install 16:24:08 nirik: So you're just opposing pre-generated kickstart files we make available, rather than "don't use kickstart to set up servers", I assume? 16:24:09 I'd like to see it in anaconda/yum groups personally. kickstart recipes would be good, but as a community thing maybe outside what we're doing here. 16:24:15 mizmo: yum/dnf? 16:24:28 nirik, we install either the base server or base server + 1 ( and later as has been decide ) or more roles 16:24:29 mizmo: that "needs to change" - mind, it's not a matter of adding a comps group only; instaling a server role should also allow easily invoking a GUI to set up that role 16:24:31 sgallagh: yes 16:24:35 nirik, it's not a gui though, im just thinking if we're trying to target ms admin coming over 16:24:35 mizmo: That's one thing actually I want to talk using Cockpit for, when that project finds its feet a bit 16:24:37 nirik, we test this as is as it comes from us 16:24:52 which brings up for me how we still need to discuss personas :) 16:24:54 as an group 16:25:05 mizmo: is that a target for us? ;) 16:25:10 I think we can drop personas 16:25:20 and target and just do the prd's for roles 16:25:31 Well, roles should be targeted at personas 16:25:34 then how do you know how to make the decisions 16:25:38 if you dont know who the product is for 16:25:39 Where the persona may simply be "Admin that needs to run a mail server" 16:25:43 which is why i'm asking questions about GUIs 16:25:47 sgallagh, right 16:25:57 Or more likely "Admin that needs to be able to manage a groupware suite" 16:26:03 our audience are administrators 16:26:14 and we do not care at which level or how experienced they are 16:26:19 before we dive into this are there any dangling threads from base + roles installation? 16:26:22 I think it would be good to be clear about our targets. 16:26:31 sgallagh: mizmo: what kind of personas do you have in mind ? 16:26:39 mizmo: For post-install, I was personally envisioning doing something like canned ansible recipes (formulas?) 16:26:44 unix-savvy admin vs clueless admin ? 16:26:52 are there any other ? 16:26:55 simo, let's pick that up after the install base + roles topic 16:27:00 Viking-Ice: I think we should actually be aiming to target a more junior admin than we traditionally have 16:27:03 sgallagh: again tho the problem is that they are very site specific. 16:27:04 sorry just my brain today is slow and doesn;t see the light there 16:27:05 nirik, btw you can add an role later ( After install via yum or dnf foo ) 16:27:07 That's the way to increase our user base 16:27:26 sgallagh, let's not walk into defining administrator pandora box 16:27:31 Ok, deferring the persona discussion to later 16:27:35 Viking-Ice: if they are comps groups, sure... but if they are, why not use that in the installer to install whatever the person wants? or they can write their own kickstart. 16:27:49 sgallagh: so what is that we need to decide now ? 16:27:55 how to install a role ? 16:27:59 simo: Yes 16:28:01 or something else invovled here ? 16:28:05 Can we agree on goals instead of technology first? 16:28:12 +1 mitr 16:28:14 nirik, we provide vm's and best out of the box experience ( which can be read as few steps to get it going ) 16:28:14 mitr: Fair point 16:28:15 mitr: +1 16:28:33 goal 1: automated ("mass") install within a larger Linux infrastructure (e.g. PXE is an option, may have LDAP/IPA) 16:28:38 I think we need to decide only if we want to make it easy to install a 'role' 16:28:42 and when 16:28:47 goal 2: manual install without a supporting infrastructure (e.g. the very first Linux server) 16:28:48 only at anaconda time or at any time ? 16:28:49 mizmo: Two meetings ago, you were going to try to work up a vision and mission statement. Did you have a chance to come up with anything? 16:28:57 Do these make sense? Any other important goals? 16:29:21 mitr: install role at server install time, vs install role after base install 16:29:28 I think that was part of the discussion 16:29:35 simo: Yes 16:29:36 sgallagh, we came up with the mission statement last meeting, i put it on the wiki: "Fedora Server is a common base platform with 'featured application stacks' built on top of it. We commit to produce, test, and distribute these application stacks. " 16:29:40 and will be important once we start to support multiple roles at the same time 16:29:47 Oh I missed that (probably in the first hour?) 16:29:49 sgallagh, vision statement, i think we need a solid idea of the personas before i can touch that 16:29:52 sgallagh, could have been 16:30:09 simo: +1 to "during the installation/setup process" (not necessarily directly in anaconda, that's an implementation detail), and making it possible later makes sense to me (expecially in the single server / SMB case) 16:30:16 well I think we should just drop personas 16:30:29 mitr, what about a goal to repeat a server? 16:30:31 mizmo: For the record, +1 to the mission statement :) 16:30:39 each roles defines which admininistrators it's intended for 16:30:47 mitr, eg i need another one of this server here, can i redeploy it over there? 16:30:50 mizmo: I don't know. Is that usually done? 16:30:59 mitr, i dont know if it's usually done but i'd like to do it :) 16:31:13 mitr: That's something that's done a LOT in the cloud world 16:31:29 mitr, eg sometimes i have to set up one-off boxes for internal projects, so i take a few hours and poke around the configs and make it work. after the hours i have no clue what i did to make it work but i have to set up another one 16:31:31 * nirik notes anaconda spits out a ks from an install that you can reuse to get the same thing. 16:31:31 i.e. I'm low on capacity, I need another ten identical hypervisors 16:31:32 mizmo: I'd kind of assume that the workflow is to develop the "mass install" configuration in several iterations, and then just deploy that (and/or deploy more of this already ready configuration) 16:31:42 nirik, yeh but that doesn't include the magical post-install config 16:31:55 Viking-Ice: I think you miss a lot if you think a role defines the admin it is intended for 16:31:57 mizmo: true... 16:32:23 mitr, but that's a lot of work right? eg you have to write a playbook or puppet whatever. i just wanna copy/paste the server. maybe it's an imaging thing. maybe out of scope. but as a really stupid sysadmin this is something i've wanted to do 16:32:24 Viking-Ice: is a "file server" intended for an experienced admin or a junior admin ? 16:32:27 mizmo: the difficulty is that nobody really knows what all has changed in the machine by that time, it's more of an opaque disk image than a configuration. 16:32:52 mizmo: That level of control is probably too site-specific to really be in scope 16:32:54 simo, what do you mean 16:32:59 mizmo / mitr: well, with lvm snapshots and a way to move one to antoher install you might be able to do it. ;) 16:32:59 mizmo: Yes, it might be a lot of work - but the primary question is "is it wanted", we aren't really allocating manpower right now. (And I have no idea whether it is wanted) 16:33:01 exactly what I asked 16:33:04 Viking-Ice: ^ 16:33:06 mitr, there used to be a project that listened to config changes and stored them, i dont remember what its called 16:33:22 based on: each roles defines which admininistrators it's intended for 16:33:42 augeas - that's what it was called 16:34:03 * walters idly notes that in the ostree model, it's always possible to run "ostree admin config-diff" and get a diff from the default /etc ( this is possible because ostree demands /usr/etc contain the pristine defaults) 16:34:17 I'd like for us to agree that a high-level goal is "Server Roles should be installable by a junior administrator with little difficulty" 16:34:22 And yes, I realize how subjective that is 16:34:35 walters: What about (gem install my-something-not-in-rpm)? 16:34:38 mizmo: I think you may be more thinking of something like etckeeper ? 16:34:44 sgallagh: e.g. 'mizmo should be able to use this' hehe 16:35:06 simo, oh ive never heard of that but im reading up on it now and it sounds really good 16:35:16 mizmo: I was actually thinking "A Microsoft Admin should be able to figure it out so we can convert them to the light side", but sure. 16:35:24 simo, personally I dont want people that dont know rfc in a tent feet pole close to the internent 16:35:25 mizmo: it's useful for sure, saved my *ss a coupe of times :) 16:35:29 mitr: mmm...i have an answer for that that would not fit in the 180 characters or so allotted to me by this gtkentry in my irc client 16:35:32 nobody disagrees with this, right? "goal 1: automated ("mass") install within a larger Linux infrastructure (e.g. PXE is an option, may have LDAP/IPA)" 16:35:33 sgallagh: yes; I wouldn't probably insist on doing a mass / automated installation by a junior admin 16:35:52 simo, So I dont want us to target idiotic windows administrator that I have spent half an decate cleaning up after 16:35:59 Viking-Ice: ok can you keep a political agenda like that a bit farther from this group though ? I really thinnk that corsses the line 16:36:10 mitr: Well, maybe not the initial work, but redeploy and load-balancing additions should be junior-capable 16:36:21 * mizmo wants to set some of the goals we agree with to #agreed for easier minutes-reading 16:36:23 simo, you decided to walk this line and start defining administration to "junior" etc 16:36:24 sgallagh: sounds reasonable 16:36:38 Viking-Ice: junior doesn;t mean stupid 16:36:48 or illiterate, or whatever 16:36:59 everybody grows from junior to senior 16:37:08 nobody is born with knowledge and experience 16:37:17 Viking-Ice: How many RFCs do you really know by heart? I don't think that's a reasonable line to draw; "knows RFCs" typically ends up to "likes the non-Microsoft project, without knowing how well it conforms to RFCs" 16:37:19 When I say Junior Admin, I'm really saying "I want us to guide this person to become a senior admin that does things correctly instead of consistently :)" 16:37:30 sgallagh: +1 16:37:40 My point is we should not be defining administrators stage et all 16:37:42 sgallagh: what I said in other words :) 16:37:44 Ok, this is getting a bit off-topic, though. 16:37:55 sgallagh: it's the personas discussion 16:37:56 sgallagh: +1 16:37:56 just a meta-suggestion: should we maybe do an etherpad doc for listing out the goals here? 16:38:00 since they keep getting scrolled off hehe 16:38:02 we target administrator periods 16:38:13 topic is "Installation of base + roles" not "Personas" 16:38:15 mizmo: I'm not sure we have an etherpad instance to work with 16:38:16 Viking-Ice: no ? 16:38:20 sgallagh, piratepad :) 16:38:22 Viking-Ice: OK, let's not talk about stages, but about required knowledge: "reading 500-page Introduction to Linux Shell Scripting not required". Does that make more sense? 16:38:24 ah 16:38:25 and our purpose is to provide the best out of the box experience for them regardless if they are junior or advanced 16:38:34 * nirik notes there is a gobby tho if people want to use that 16:38:39 mizmo: If you could start one, I'll certainly sign in 16:38:50 http://piratepad.net/serverwg-install-goals 16:38:51 Viking-Ice: with this I can agree 16:38:57 Viking-Ice: Yes, that I agree with 16:39:04 however sometimes best *does* depend on the level of knowldege 16:39:10 it's not a black and white thing 16:39:29 In my mind, it's fine to offer hand-holding that the more senior admin can just opt to skip. 16:39:37 * mitr notes he'll probably have to leave in 21 minutes 16:39:44 sgallagh: exactly 16:40:13 simo, and that where the "Missing Infrastructure and or website Tool*" I mention there on the page comes in to guide newcomers to the right application or solution within the server role 16:40:47 Viking-Ice: ok let's finish the role thing than we can discuss about the personas thing 16:41:00 mizmo: do we have a vote on the installation of roles ? 16:41:16 Are we all roughly on the same page WRT junior admins? I.e. we're not targeting them exclusively but *should* target them? 16:41:18 simo, so i put the three proposed roles up on the piratepad http://piratepad.net/serverwg-install-goals 16:41:25 maybe the best way to proceed seeing as we have 20 minutes left 16:41:33 is i'll convert this to a doc on the wiki and we can hash it out on the list? 16:41:36 since we've got a good start? 16:41:42 * sgallagh nods 16:41:46 mizmo: I get an empty pad ? 16:41:51 * nirik waits for the priatepad to load 16:41:53 simo, weird 16:41:57 it's not loading here at all. 16:42:06 I think you will atleast need to rephrase goal 3 as you put 16:42:10 mizmo: ah as usual, javascript blocked, my faulkt 16:42:24 simo, sorrys :( gobby might have been better but i didnt know if everyone had the client installed 16:42:27 and I dont see why we need "installation roles to begin with" 16:42:28 Viking-Ice: Feel free to suggest a better phrasing 16:42:41 Viking-Ice: What do you mean? 16:42:50 I think this covers itFedoraOS Server Platform ( FOSSP ) is made available with or without an predefined server role,ready to use ks for traditional method of installation,directly into an isolated or OS container or as an whole-disk images to be used in private/public cloud as instance-store image or standalone server in the cloud itself. 16:42:58 mizmo: are the goal listed in order of importance ? or just an arbitrary ordefr ? 16:43:00 Viking-Ice: In my mind, it just means that you can write a kickstart that will include one or more roles. 16:43:15 As opposed to doing an installation of just the platform and adding a role later 16:43:23 sgallagh, we provide the ks file with predefined role 16:43:25 (to be clear, I think we must support both cases) 16:43:28 simo, order they were brought up in IRC :) 16:43:30 sgallagh, and test it 16:43:42 Viking-Ice: Implementation detail, but I think we're addressing the same need. 16:44:01 mizmo: ok I +1 on 1,2,3 -1 on 4 at least for now 16:44:11 Which is what we're trying to provide here. 16:44:12 mizmo: I don't think replication should be an initial goal. I think it might be something to figure out once we are running. 16:44:21 nirik, simo: fair 16:44:24 -1 on the entire concept of "installation roles" 16:44:24 mizmo: +1 on 1,2,3, 0 on 4 (I have no knowledge) 16:44:42 I know it is hard enough we do not want to have it as a goal for now 16:44:42 Viking-Ice: roles? goals. 16:44:47 mizmo: +1 on 1, 2 and 3. -1 on 4: it's too big a can of worms to have as a goal 16:44:51 (At this time) 16:45:00 Viking-Ice: the goal of this is to first decide what we want to support, _then_ we can sensibly talk about what technology is suitable. 16:45:06 so i'm +1 to 1-3 and -1 to 4 as well 16:45:20 Viking-Ice: It's just a terminology thing. It literally means: after the installer completes, this role is installed on the target system 16:45:28 I think we're talking past each other. 16:45:50 mitr, we need to support all of them ks ( mass install ) bare metal, vm containers 16:46:11 Viking-Ice: I agree, though not necessarily all in the first pass 16:46:15 mizmo: slighlty changed 3 16:46:15 regardless if they are juniors or not 16:46:20 do you agree we mean the same thing ? 16:46:29 simo, seems like a reasonable change to me 16:46:37 simo: +1 16:46:50 sgallagh, does that not make the inital goals to support all of thiese 16:46:52 mean these 16:47:14 Viking-Ice: Sorry, I didn't quite parse that. 16:47:39 What I mean is that I think we're discussing goals of the project, not necessarily of the first release. 16:47:44 note that we need to just make sure ti can be automated 16:47:53 we are not proposing to provide the automation right ? 16:47:55 sgallagh, I 'm not discussing the first release 16:48:03 (unless we make that a role as a server ) 16:48:04 So if we decide only to do kickstart and VM images in the first pass, we can still get the others later 16:48:08 could a goal be compatibility with deployment systems or do we not want to go there? 16:48:16 Viking-Ice: I was trying to clarify, not disagree :) 16:48:16 so these are goals for the 'server working group' ? or goals for installing the server roles? or ? 16:48:28 nirik, goals for installing the server roles 16:48:40 nirik, as an alternative to discussing specific technology 16:49:01 mizmo: I'd defer that for later - I can well imagine that we end up with a much better system that is incompatible with kicstarts but worth it 16:49:10 mizmo: goals for compatibility with deployment systems would be a great idea, though I'm not sure it fits into this specific discussion. 16:49:11 how about: existing servers and installed roles should be upgradable to new releases? 16:49:12 aren;t these the WG goals about what installations method we want to officially support ? 16:49:17 sgallagh, as I see it we need to support bare metal install ( single/plural ) we need to support vm's install ( single/plural ) we need to support container install whole OS or single application ( both single pluraal ) 16:49:30 nirik: yes please 16:49:37 sgallagh, well if, say im using (biased example) Satellite server to manage my unix deployment, i would like to be able to install roles from the admin console in Satellite 16:49:37 Viking-Ice: I agree. 16:49:51 nirik: I'd like that, but how to we live up to the goal if upstream does not ? 16:50:04 mizmo: yes, I follow you 16:50:05 mizmo: Modifying Satellite to do that should be an option as well 16:50:29 anyway +1 to 4, at least as a stretch goal 16:50:32 sgallagh, mitr: yeh. i don't know if satellite is the right target. whatever is most popular with our target admins should probably be a target. 16:50:34 simo: well, partly that depends on implementation... 16:50:38 simo: We modify, or, in the worst case, replace the upstream. (Is upgrading so valuable that it would be worth it? I think so but I don't know) 16:50:40 mizmo: can we add "where possile" ? 16:50:44 *possible 16:50:49 simo, to goal 4? 16:50:52 yes 16:50:54 sure 16:50:59 simo: I'd suggest we'd tend to select the projects we build roles around at least in part based on their past upgrade performance 16:51:00 we can't promise it for all roles 16:51:18 sgallagh: bind had very good performance up until they decided to go for 10 16:51:34 sgallagh: as in the financial services: past perf. are not indication fo future ...blahblahblah 16:51:35 :) 16:51:41 simo: Last I heard, bind9 was going to continue indefinitely 16:51:53 They're effectively separate projecrts 16:51:56 sgallagh: yeah but if you want to go bind10 there is no possible upgrade path 16:52:10 * sgallagh nods 16:52:12 there are going to be cases that are difficult. 16:52:23 do we want to squeeze another topic into the last ~10 minutes and push this one to the list, or keep going on this one? 16:52:28 Goals are not the same as mandates, either. 16:52:33 we could provide compat packages for some time to let people migrate, or docs, or tools to help, or whatever 16:52:34 We can do as much of this as is possible 16:52:56 sorry for going slightly technical but should we prompt in the install if we know we can't upgrade an installed role 16:53:07 and tell the admin we can't install unless he removes the role first ? 16:53:14 would it make sense ? 16:53:20 simo, "notify the user if not possible" is not so technical 16:53:24 I added a suffix to Goal 4; opinions? 16:53:32 mizmo: well not just notify, prevent upgrade 16:53:35 sgallagh +1 to edit 16:53:40 simo: "before modifying anything by the update process" 16:53:47 simo: I'm going to suggest that's an implemenation detail 16:53:51 sgallagh: ok 16:53:55 might not work with kickstarts, etc. 16:54:04 simo, are we letting the user know the thing isn't upgradeable before they install it, or let them know it's not upgradeable when they go to upgrade it later? 16:54:06 well that's why I would like to prevent 16:54:20 mizmo: we may not know at install time. 16:54:22 mizmo: When they go to upgrade it 16:54:30 nirik: sure we know 16:54:32 nirik: we should be able to know 16:54:37 oh? 16:54:45