15:00:48 <pknirsch> #startmeeting Fedora Base Design Working Group (2014-04-25)
15:00:48 <zodbot> Meeting started Fri Apr 25 15:00:48 2014 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:56 <pknirsch> #meetingname  Fedora Base Design Working Group
15:00:56 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:01:08 <pknirsch> Alright, good morning and good afternoon folks
15:02:02 <jwb> hi
15:02:05 <pknirsch> I hope everyone had a great last weekend (and for those enjoying holidays over Easter an extended weekend :)
15:02:11 <jreznik_q10> Hi guys
15:02:32 <pknirsch> I didn't have a lot for today's agenda, mainly a checkup on the things we discussed 2 weeks ago
15:02:39 <jreznik_q10> weekend is here and it starts raining ;-)
15:02:49 <pknirsch> thanks jwb for already sending the FESCO vote about the securetty feature
15:02:56 <pknirsch> jreznik_q10: same here :)
15:02:56 <jwb> np
15:03:29 <pknirsch> so we can leave that off. so the only official topic for today is the merge reviews.
15:03:35 <pknirsch> #topic Status merge reviews
15:03:52 <pknirsch> jreznik_q10, dgilmore: i think you two wanted to look into that, right? Any news there?
15:03:58 * notting is here
15:04:03 <pknirsch> heya notting :)
15:04:14 <jreznik_q10> for merge reviews FAD, Dennis is going to prepare invitation mails
15:04:20 <pknirsch> #chair jwb jreznik_q10 notting
15:04:20 <zodbot> Current chairs: jreznik_q10 jwb notting pknirsch
15:04:45 <jreznik_q10> we talked about it yesterday
15:06:31 <pknirsch> Alright. Lets keep it on a quick update status then for next weeks, jreznik_q10 ?
15:07:01 <jreznik_q10> Yep, let's try not to forget ;)
15:07:16 <pknirsch> oki, good
15:07:33 <pknirsch> #info Keep reviews in topic section for next meetings.
15:07:40 <pknirsch> #topic Open Floor
15:07:44 <pknirsch> moving to open floor then
15:07:52 <pknirsch> I have one thing that i just remembered today:
15:08:03 <pknirsch> I'll be on PTO next Friday and away for the extended weekend.
15:08:17 <jreznik_q10> Do you want cover?
15:08:26 <pknirsch> So if someone would run the meeting next week that would be awesome
15:08:32 <pknirsch> yes jreznik_q10 :)
15:08:35 <jreznik_q10> I can
15:08:43 * pknirsch think jreznik_q10 is typing faster than himself :(
15:08:46 <pknirsch> thanks!
15:09:03 <pknirsch> #info pknirsch on PTO next Friday, jreznik going to run the meeting.
15:09:06 <jreznik_q10> smartphone with hw keyboard in a tram ;-)
15:09:22 <pknirsch> heh
15:09:48 <jreznik_q10> Btw. one question - we're still behind that decision of no deliverables for Base WG, right?
15:10:26 <jreznik_q10> or are there any requests for releng? And as releng belongs to Base WG
15:10:47 <jreznik_q10> We should review it I'd say
15:10:52 * pknirsch nods
15:11:02 <jreznik_q10> See my email to devel and releng ticket
15:11:23 <pknirsch> Right, just wanted to say, i haven't seen anything there yet
15:11:31 <jwb> i was thinking of something along those lines earlier this morning
15:11:45 <jwb> it seems both Server and Workstation need a basic install tree for fedup to work
15:11:55 <pknirsch> mhm
15:12:04 <jwb> i don't immediately see why they would be different, nor why it couldn't be a Base repo
15:12:19 <jwb> since we have previously talked about doing a minimal boot.iso/netboot thing
15:12:25 <pknirsch> Aye
15:12:26 <jreznik_q10> I was thinking about the same
15:12:49 <jwb> seems like it would be better to do that than to duplicate an install tree for all the products.  maybe i'm missing something though
15:12:55 <pknirsch> Does Cloud need/use the same one as well? or does mattdm's group have different requirements there?
15:13:00 <jwb> was hoping dgilmore would be around
15:13:02 <pknirsch> Or do they need that at all?
15:13:12 <jwb> pknirsch, not sure on Cloud.  i don't think fedup is really a thing they do?
15:13:18 <jwb> but yeah, could talk to them
15:13:23 <pknirsch> yea, thats why i'm wondering.
15:13:54 <pknirsch> I they "only" do image deployments without major release upgrades inside the images, i don't think fedup is something we need to worry about there then
15:14:11 <jreznik_q10> well, there's no requirement they have to use it, still sharing over the rest products could be nice to have
15:14:13 <notting> jwb: what do you mean by install tree? the stage2?
15:14:57 <jwb> notting, that's part of the problem.  i'm not sure what dgilmore is talking about when he says install tree.  nirik and i were chatting and thought it was the equivalent of the stuff fedup needs from the existing 'Fedora' repo
15:15:05 <jwb> which is what the Fedora DVD is composed from
15:15:13 <jwb> the repo could still exist, just in a smaller form
15:16:04 <notting> fedup, afaik, needs an upgrade fedup image to boot into, and access to the full repo of packages so it can get everything to upgrade
15:16:44 * dgilmore is here
15:16:45 <jwb> the upgrade fedup image seems like it could be the common part.  the repo would point to a product specific repo
15:16:48 <pknirsch> but couldn't that fedup image be the same for everyone?
15:17:07 <pknirsch> and dgilmore already stated we'll have a Everything repo as well
15:17:26 <dgilmore> pknirsch: yes but thats never been installable and its not planned to be so now
15:18:02 <dgilmore> pknirsch: the fedup image may need to be different per product
15:18:05 <pknirsch> sure, but the fedup image could reference to that repo, or? or is there a reason why it couldn't?
15:18:08 <pknirsch> ah
15:18:10 <pknirsch> ok
15:18:11 <jreznik_q10> next tram stop is mine but I'll let yasic running...
15:18:35 <jwb> "may need to be" is the question.  i'm not seeing a reason why it would be different
15:19:20 <dgilmore> jwb: if the products diverge in setup etc it may need to be handled in each product having different dracut modules in the upgrader
15:19:48 <dgilmore> that could be passed on via the cli
15:19:51 <dgilmore> or other means
15:20:04 <jwb> dgilmore, or you could create a generic one that has all the modules.
15:20:31 <dgilmore> jwb: depends on implementation
15:20:38 <jwb> which is what we're talking about
15:20:58 <dgilmore> jwb: either way all procucts need an install tree to be able to make images going forward
15:21:32 <dgilmore> and pxe install of all products should be done
15:21:56 <jwb> yes, you've said that.  i believe you even without fully understanding why.  what i'm driving at is if that install tree can be common and could possibly be the thing we use for Base boot/net iso
15:22:07 <dgilmore> personally I prefer to pxe install, I don't use a livecd other than to test they work
15:22:56 <dgilmore> jwb: that would require anaconda work not scoped
15:23:21 <jwb> ...
15:23:22 <jwb> why?
15:23:25 <dgilmore> jwb: anaconda expects the package set to be part of the install tree where stage2 is found
15:23:55 <dgilmore> pottentially the product trees could be added as second repos
15:24:02 <dgilmore> potentiallhy
15:24:04 <notting> dgilmore: an override can be passed on the commandline, if i'm remembering right, so it's doable.
15:24:07 <dgilmore> gahh i cant spell
15:24:33 <dgilmore> notting: yeah, but ugly and would need all the documentation to change
15:24:54 <dgilmore> doable but harder
15:25:08 <jwb> so instead of changing documentation, we're going to duplicate repos across 3 products unnecessarily?
15:25:58 <dgilmore> jwb: not really
15:26:30 <notting> dgilmore: what i mean to say is that if you can already override the main repo on the commandline or via kickstart, i'm not sure that it's much extra anaconda work to expose it more/better. but probably a question for the anaconda team
15:26:39 <jreznik_q10> we can talk to docs guys
15:27:03 <dgilmore> if products end up offering different anaconda experiences then they ill need to have different contents in the installer/upgrade trees
15:27:22 <jwb> that's not likely for f21
15:27:27 <jwb> given fesco said to not do that
15:27:43 <jreznik_q10> it it ever happens
15:27:44 <dgilmore> jwb: right, but it seems wise to assume it is going to happen
15:27:53 <dgilmore> at some point
15:28:24 <dgilmore> I think some of the answers will be clearer when we do our first test compose
15:28:36 <jwb> why aren't we doing that now?
15:28:50 <jwb> or rather, what is missing that's preventing us from doing that now
15:30:12 <dgilmore> its on myt list to work out next week
15:30:36 <jwb> ok.  so we can revisit this in next week's Base meeting i guess
15:30:42 <notting> jwb: believe we're also waiting on the WGs to have alpha-ish kickstarts for their products (rather than just copying over the cloud & desktop ones)
15:30:44 <dgilmore> at some point i want to make the nightly composes be a full compose not partial as we do today
15:30:56 <dgilmore> that too
15:31:23 <jwb> notting, sure.  i'm working on WS today.  but using the existing desktop ks isn't really a bad start
15:31:32 <jwb> (though apparently it doesn't fit in 4G anymore)
15:31:40 <dgilmore> we need to start with something
15:31:57 <dgilmore> jwb: there is a workstation kickstart for the install tree that will need work also
15:32:27 <jwb> dgilmore, ... that's exactly what i've been driving at above.  i don't understand why we need a separate install tree for all 3 products.
15:32:32 <dgilmore> at least today thats how we make the tree that has the workstation package set
15:32:41 <jwb> it seems we could find the superset and create one install tree
15:32:58 <dgilmore> jwb: then we have todays Fedora tree
15:33:05 <jwb> why is that a problem?
15:33:12 <notting> jwb: *nod*. afaik, server doesn't have anything, though
15:33:49 <dgilmore> jwb: the installer would offer the packages in worlkstation, server and cloud
15:34:05 <dgilmore> if so whats the point in doing fedora.next
15:34:16 <dgilmore> as nothing is really changing
15:34:45 <jwb> what do you mean "would offer"?
15:34:55 <nirik> uh... I was operating under the idea that we would use kickstarts for that?
15:34:56 <jwb> anaconda doesn't do on-the-fly package selection anymore
15:35:05 <jwb> nirik, right
15:35:53 <dgilmore> jwb: then every install would be exactly the same.
15:36:27 <dgilmore> jwb: having a seperate install tree Workstation installs without a kickstart would be different to server installs without a kickstart
15:36:35 <nirik> anaconda doesn't let you choose specific packages, but you can choose groups/comps things, no?
15:36:44 <dgilmore> nirik: afaik yes
15:37:32 <jwb> i'm still not seeing a problem
15:38:02 <nirik> if you do a install against the tree with no kickstart, yeah, you would get the superset?
15:39:11 <jwb> discounting that live installs are done from the image, which is created from a KS?
15:39:18 <nirik> so, I guess for server thats not super ideal... since workstation would show up there...
15:39:24 <dgilmore> jwb: since we would hardlink the trees together having seperate trees per product doesnt cost much disk wise
15:39:44 <nirik> dgilmore: does that mean fedup would diverge? which images would we use?
15:39:54 <jwb> nirik, right.  i'm more concerned about fedup
15:40:12 <nirik> 3*testing also seems very bad
15:40:31 <nirik> (if we can avoid it)
15:40:35 <dgilmore> nirik: it could diverge
15:41:05 <dgilmore> there is many unanswered questions still
15:41:19 <jwb> so maybe we should ask and get answers
15:41:31 <nirik> so, the only advantage to seperate so far I see is the available groups could be product specific only?
15:41:47 <dgilmore> jwb: i think many answers will come when we have a compose
15:42:02 <dgilmore> as we can then examine and test
15:42:07 <dgilmore> and see whats what
15:42:07 * nirik really thinks we should strive to avoid duplication if there's not really really good reasons for it
15:42:46 <jwb> ok, i guess we can revist next week then
15:43:03 <dgilmore> nirik: available groups would be product specific, and over time there is room for product specific divergance
15:43:03 <pknirsch> sounds good
15:43:48 <nirik> dgilmore: multiplying our qa load by 3 for 'the future' seems bad to me... if there's good reasons for/need for divergence right now, sure... but I am having trouble seeing it.
15:44:55 <dgilmore> nirik: well it also gives each product something to push and advertise
15:45:20 <nirik> well, they have their own images for that... but ok.
15:45:26 <dgilmore> nirik: server doest
15:45:29 <dgilmore> doesnt
15:45:42 <dgilmore> Servers product is an install tree
15:45:42 <nirik> it will.
15:46:06 <nirik> https://fedoraproject.org/wiki/Server/Technical_Specification#Supported_Architectures_and_Install_Media
15:46:16 <nirik> and a local install media.
15:46:54 <dgilmore> nirik: yeah thats a install dvd which is the product of creating an install tree
15:47:15 <nirik> well, I would not call the install tree the product. ;)
15:47:25 <nirik> but sure.
15:47:26 <dgilmore> to make that we have to make a product specific install tree
15:47:34 <nirik> why product specific?
15:47:55 <nirik> we can take this off line too if we are de-railing the meeting....
15:48:05 <dgilmore> nirik: because how pungi works it includes the packages and comps in the install tree on the dvd
15:48:18 <dgilmore> thats how it works
15:48:39 <mjg59> More or less work to fix pungi than to duplicate trees?
15:49:00 <dgilmore> mjg59: much more work
15:49:11 <dgilmore> as its not really pungi but mkisofs
15:49:49 <dgilmore> we would need to have some way to modify comps and tell mkisofs to exclude some contents in the tree
15:49:49 <nirik> humf. ok.
15:50:41 <dgilmore> and as we will hardlink the product trees the cost is low
15:50:43 <jwb> i'm lost.  why is mkisofs involved
15:50:52 <dgilmore> jwb: thats what makes the install iso
15:50:54 <nirik> dgilmore: the disk space cost.
15:51:00 <dgilmore> pungi calls it
15:51:03 <dgilmore> nirik: true
15:51:15 <nirik> I think adamw might not like multiplying all the fedup and netinstall test plans X 3
15:52:07 <nirik> jwb: if we make a dvd image (for server) we don't want workstation stuff on it... (no idea on specifically why mkisofs is involved)
15:52:33 <jwb> nirik, that seems solvable with code.
15:52:34 <dgilmore> nirik: mkisofs is involved as its the tool pungi calls to make the dvd iso
15:52:45 <dgilmore> jwb: not simply
15:52:54 <nirik> dgilmore: but pungi feeds it content?
15:52:57 <jwb> why would anyone think this would all be simple?
15:53:09 <nirik> :)
15:53:12 <dgilmore> nirik: pungi lays out the tree and says here make it
15:53:31 <jwb> there's engineering work to be done..  i'm not sure why we'd plan on just reusing existing tools as-is at the cost of duplicating effort for everyone else
15:55:08 <nirik> sure, lets work on solutions. ;)
15:55:15 <dgilmore> there is plans for much work
15:56:02 <dgilmore> anyway lets more on and re-visit when we have a test compose to look at
15:56:16 <dgilmore> move on
15:56:47 <pknirsch> oki, sounds good.
15:56:54 <pknirsch> i had one last short item:
15:59:17 <pknirsch> I've had a quick talk with Florian Weimer today and he was talking to me about automated checks and things we could look at hardening, especially for the Base packages. I've asked him to compile a list of things and we can then see what we can do with them. Probably run it past FESCO and talk with QE and FPC how that could then be implemented/automated.
15:59:37 <pknirsch> but no concrete info yet. I'll also ask him to write up the summary for fedora-devel ofc
15:59:44 <jwb> ok
15:59:45 <pknirsch> so we can disucss this there first as well
15:59:51 <dgilmore> pknirsch: sounds like something for task-o-tron
15:59:56 <pknirsch> aye
16:00:09 <pknirsch> dgilmore: had the same idea there, too
16:01:21 <dgilmore> sounds like a worthwhile task though
16:01:24 <pknirsch> jup
16:01:29 <pknirsch> especially if it can be automated
16:01:32 <pknirsch> which it should be
16:01:43 <dgilmore> indeed
16:02:19 <pknirsch> Oki thats all from me though
16:02:22 <pknirsch> anything else?
16:02:50 <dgilmore> I have nothing
16:03:18 <pknirsch> ok, thanks guys! good discussion today.
16:03:32 <pknirsch> have a great weekend!
16:03:37 <pknirsch> #endmeeting