Regrets not to attend today meeting
by Truong Anh Tuan
Hi everyone,
I will have a trip tommorow morning so I can not attend today meeting.
I will read the logs.
Kind regards,
Tuan
10 years, 5 months
Installation Roles vs. Post-installation Role Assignment (or pets vs. livestock)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
One topic that keeps coming up on other threads that I think we need
to address first is when and where roles are assigned and whether they
can be modified after installation. There are two general trains of
thought here (maybe more; please chime in if you see other approaches).
First, for those of you who haven't heard the "pets vs. livestock"
metaphor, it goes something like this: Traditional datacenters are
like pets. You have a few beefy machines dedicated to one or more
tasks each. You maintain them, care for them and nurse them back to
health if they get into trouble, much the same way that a pet owner
would take care of their dog, cat, ferret, etc.
On the other side of the fence, you have the DevOps/Rapid
Deployment/Rapid Recovery folks who treat their environments more like
cattle. They have lots of redundant, scale-out VMs that serve a single
purpose and if they begin to have issues (memory pressure, intrusion,
chaos theory progression), they are cut down and replaced with a new,
pristine copy. This is analogous to livestock, where if one cow stops
producing milk, it's usually served as hamburgers shortly thereafter
and the farmer goes and buys another cow.
So I think we need to take a look at which of these two approaches we
want to be addressing. Or if we intend to try to handle both. It's my
understanding that the Fedora Cloud Working Group is *very* heavily
focused on addressing the "livestock" side of this argument, so we may
want to keep that in mind (and I've CCed Matthew Miller to represent
that group in this discussion).
If we choose to address the "pets" scenario (aka the traditional
infrastructure scenario), we probably need to be looking at role
assignment as an API (as suggested by Miloslav). Essentially, we
should build an interface into the system that allows us to configure
a role on demand - providing it the necessary configuration
information - and have it produce a system that corresponds to our
vision of an integrated solution. This API should be invokable either
at Kickstart time or remotely via a console such as Cockpit or
Satellite after installation and should have the same exact effect in
either case.
However, if we're looking more at addressing the "livestock" scenario,
then we probably DO only care about the initial deployment being
correct, which may be done via Kickstart or simply having a set of
pre-generated VM/Container images that can be booted with an API to
assign the configuration the first time it comes up.
These are *very* different deployment strategies, and we need to
determine which that we as the Fedora Server want to be pursuing
before we go any further, in my opinion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKGIxIACgkQeiVVYja6o6MFjgCfTrcFEQJXyZwwLeaiayiTEgPx
h9gAn18zpkv7gUOAJgTCY0XbVF/PllnH
=pv+C
-----END PGP SIGNATURE-----
10 years, 5 months
Agenda for Server Working Group Meeting (2013-11-18)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I sent out a call for agenda items on Friday, so here is the planned
agenda for tomorrow's meeting at 1600 UTC in #fedora-meeting-1
* Goals for Server Role Installation (group)
* Personas (mizmo)
* Server Lifecycle Proposal (sgallagh)
* Updates and Testing Proposal (nirik)
* Server Role List Proposal (Viking-Ice)
* Installation Roles vs. Post-installation Role Assignment (sgallagh)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKKOVQACgkQeiVVYja6o6MrTgCePJ6BajciaCGOH/00aLWTUQY6
rVYAoIij7HXW+zru3ane17cYVzO1OlD7
=A9GA
-----END PGP SIGNATURE-----
10 years, 5 months
Fedora.next Product Branding
by Ryan Lerch
With the creation of 3 products for Fedora, the Fedora Design Team
anticipates many new questions around Fedora's brand. As the main
caretakers of the Fedora brand, we are going to have to figure these
things out within the next few months. For example, the Design Team is
starting to think about how to answer these types of questions:
• Should each product have its own logo? or
• Can you add our product to the Fedora website? or
• Can you make our product its own website? (How should we represent
these products on the website? Should we allow products to have their
own separate websites?)
To start off the rebranding discussion, the Fedora Design Teamhas4 basic
questions for each of the 3 product-focused working groups to answer:
(1) What problem does your product solve, in one sentence?
(2) Who is the target audience for your product, in one sentence?
(3) List at least 5 products that successfully target the same target
audience you are after.
(4) List at least 5 products that try to solve the same problem.
We are reaching out to each group individually to ask that you discuss
these questions and come back to us with answers by Wednesday, December
4th2013.
cheers,
ryanlerch
-------------------------
Fedora Design Team
10 years, 5 months
Call for Agenda (2013-11-19)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Let's try to set an agenda for this week's Server WG meeting. Please
respond to this thread and I'll send out the formal agenda on Monday.
Agenda items suggested from last week's IRC meeting:
* Goals for Server Role Installation (group)
* Personas (mizmo)
* Server Lifecycle Proposal (sgallagh)
* Updates and Testing Proposal (nirik)
* Server Role List Proposal (Viking-Ice)
I'd also like to add the discussion from the "Installation Roles vs.
Post-installation Role Assignment" I started today as a stretch agenda
item, if we have time and enough people have had a chance to weigh in
on the mailing list.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKGS2EACgkQeiVVYja6o6PRCgCePWwyC19ETLnQOv9D/GXUCdbm
FqkAoJRxcBU9v167hKe/Sm9xfMoQq+MB
=XzBl
-----END PGP SIGNATURE-----
10 years, 5 months
Call for Agenda (2013-11-19)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Let's try to set an agenda for this week's Server WG meeting. Please
respond to this thread and I'll send out the formal agenda on Monday.
Agenda items suggested from last week's IRC meeting:
* Goals for Server Role Installation (group)
* Personas (mizmo)
* Server Lifecycle Proposal (sgallagh)
* Updates and Testing Proposal (nirik)
* Server Role List Proposal (Viking-Ice)
I'd also like to add the discussion from the "Installation Roles vs.
Post-installation Role Assignment" I started today as a stretch agenda
item, if we have time and enough people have had a chance to weigh in
on the mailing list.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKGS2EACgkQeiVVYja6o6PRCgCeMndmgix7lhQEBlg6VSsLlcsl
AWMAn0OqOsD4MB90JTzPbKNDMg00m5oO
=7S/0
-----END PGP SIGNATURE-----
10 years, 5 months
Call for Agenda (2013-11-19)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Let's try to set an agenda for this week's Server WG meeting. Please
respond to this thread and I'll send out the formal agenda on Monday.
Agenda items suggested from last week's IRC meeting:
* Goals for Server Role Installation (group)
* Personas (mizmo)
* Server Lifecycle Proposal (sgallagh)
* Updates and Testing Proposal (nirik)
* Server Role List Proposal (Viking-Ice)
I'd also like to add the discussion from the "Installation Roles vs.
Post-installation Role Assignment" I started today as a stretch agenda
item, if we have time and enough people have had a chance to weigh in
on the mailing list.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKGS2QACgkQeiVVYja6o6PvwQCgqMHpirXKUtLdap+ilsShohfG
9wUAn0QbSu/Z5xst6BEnkvk1qkC6TMCE
=OBfJ
-----END PGP SIGNATURE-----
10 years, 5 months
Meeting Summary / November 12, 2013
by Máirín Duffy
Hi folks!
Below find a summary of yesterday's meeting. You can also read it in
blog format at http://fedoraserver-wgblog.rhcloud.com/?p=16 .
Below the summary, you'll find the meetbot links if you'd like to read
the raw logs.
Meeting Minutes
===============
Here’s a run-down of today’s Server Working Group meeting:
Agenda
======
* Can a single server have multiple roles?
* Installation of base + roles
Can a single server have multiple roles?
========================================
This topic discussion covered the following points:
* We agreed that a single server should be able to serve multiple roles.
* Testing combinations of roles on the same server will be tricky. There
are some known combinations that will not work (for example, FreeIPA
isn’t compatible with mod_nss.)
* We’ll start with basic, single server roles, and over time we will
adde tested combinations. (All agreed.)
“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,” said sgallagh.
I pointed out there were some concerns about that approach last week.
sgallagh responded, “There was concern about being able to test such
things.”
“Yeah, testing can be a big pain if we have 10 featured things and you
can install any one or any combo of them,” said nirik. “But we could
also just say ‘we test each of these things alone, let us know if they
interact poorly.’”
mitr asked sgallagh, “We aren’t ordinarily concerned about testing a
system that has both Firefox and Devhelp installed; isn’t this the same
thing?”
“At first glance I agree with you,” replied sgallagh. “but with server
applications they can sometimes interact with each other in odd ways.
Such as requiring mod_nss vs. mod_ssl in apache (to pluck a known
example out of the air.)”
“Server can have one or more roles,” added Viking-Ice. “There is no
doubt about that.”
“But we need to be clear what we test in that world,” said nirik.
“Yes,” agreed mitr.
sgallagh added, “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.”
“We chose a role and we test cover that role,” said Viking-Ice.
“Alternatively, when/if we get automated tests,” said mitr, “doing a
‘full install’ and running all the tests on it should be reasonable –
but let’s not commit do doing manual work twice.”
Evolution asked, “Do we document roles that obviously conflict?”
“I would say not,” answered Viking-Ice.
“Well in some cases you can in some others you cannot,” simo answered.
“In freeipa we use mod_nss… so you won’t be able to use it with another
program that depends on mod_ssl. That may change in time to avoid
issues, and fedora server contribution may actually help smooth those
issues in some cases.”
sgallagh also answered, “That would still require testing all of them
together to learn whether they conflict.”
“We can only guarantee what we test,” said simo. “So perhaps we should
start just with bare roles, and in time add explicitly tested combinations.”
mizmo brought simo’s proposal to the table and it was supported by everyone:
*** Regarding multiple roles on one server, we will start with just bare
roles, and in time add explicitly tested combinations. ***
Installation of base + roles
============================
mizmo brought up, “It looks like another concern from last week’s
minutes, about multiple roles per server, was how to install the server
that way.”
“You install the base server ( which I call FOSSP, )” replied
Viking-Ice, “then install one or more roles.”
“Yeh, that makes sense to me,” replied mizmo. “The anaconda UI actually
makes this pretty easy… you can set various roles to be compatible /
incompatible and let users select.”
sgallagh asked, “By way of comps groups?”
“Yep,” mizmo replied.
“That’s the way to go in my opinion too,” said nirik.
mizmo added, “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.”
“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.”
“Way too many decisions in one sentence,” said mitr.
nirik responded, “-1 on kickstarts.”
“I think kickstart is too implementation-specific, although it’s
obviously going to come into play,” added mizmo.
“Kickstarts should be supported but not required,” simo added.
sgallagh asked nirik, “Can you expand on that?”
“Kickstarts only work at install/create time. You can’t for example
install foo and then decide to add role bar later,” said nirik.
“Kickstarts contain too many site-specific items.”
mizmo responded, “If the role was a comps group, you could though,”
pointing out how a role could be added on later.
“Yes, which is why I think it’s a better solution,” said 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?” sgallagh asked nirik.
“Yes,” nirik replied.
“Nirik,” said Viking-Ice, “We install either the base server or base
server + 1 ( and later as has been decide ) or more roles. We test this
as is as it comes from us.”
“I’d like to see it in anaconda/yum groups personally,” said Evolution.
“Kickstart recipes would be good, but as a community thing maybe outside
what we’re doing here.”
mizmo added, “I don’t think we have a good GUI way to install groups
post-install, though.”
“That ‘needs to change,’” said mitr. “Mind, it’s not a matter of adding
a comps group only; installing a server role should also allow easily
invoking a GUI to set up that role as a group.”
“That’s one thing actually I want to talk using Cockpit for, when that
project finds its feet a bit,” sgallagh pointed out.
“Which brings up for me how we still need to discuss personas :) ” said
mizmo.
Viking-Ice replied, “I think we can drop personas and target and just do
the prd’s for roles.”
mizmo questioned Viking-Ice, “Then how do you know how to make the
decisions if you dont know who the product is for?”
“Well, roles should be targeted at personas,” sgallagh said. “Where the
persona may simply be “Admin that needs to run a mail server. Or more
likely “Admin that needs to be able to manage a groupware suite.”
“Right,” said Viking-Ice. “Our audience are administrators, and we do
not care at which level or how experienced they are.”
“I think we should actually be aiming to target a more junior admin than
we traditionally have,” responded sgallagh.
“I think it would be good to be clear about our targets,” added nirik.
“What kind of personas do you have in mind?” asked simo. “Unix-savvy
admin vs clueless admin? Are there any other?”
mizmo replied, “Let’s pick that up after the install base + roles topic.”
sgallagh said, “For post-install, I was personally envisioning doing
something like canned ansible recipes (formulas?)”
“Again, tho, the problem is that they are very site specific,” responded
nirik.
“BTW you can add an role later ( After install via yum or dnf foo )”
said Viking-Ice.
nirik replied, “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.”
“Can we agree on goals instead of technology first?” asked mitr. mizmo,
sgallagh, and simo agreed to this.
Viking-Ice continued, “We provide vm’s and best out of the box
experience ( which can be read as few steps to get it going.)”
“I think we need to decide only if we want to make it easy to install a
‘role’ and when. Only at anaconda time or at any time?” said simo.
mitr proposed a couple of goals:
* “Goal 1: automated (“mass”) install within a larger Linux
infrastructure (e.g. PXE is an option, may have LDAP/IPA.)”
* “Goal 2: manual install without a supporting infrastructure (e.g. the
very first Linux server).”
After that we ended up hopping on an etherpad (via piratepad.net) and
working through some goals. We got a good set of initial goals and
deferred some goals for later discussion, then promoted the document to
the wiki, here:
https://fedoraproject.org/wiki/Server/Proposals/Server_Roles/Installation...
We ran out of time and decided not to continue past the original
allotted time this week. Further discussion about server role
installation goals will take place in this thread on the mailing list.
Meetbot Minutes:
===============
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeti...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeti...
Log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeti...
10 years, 5 months
