F21 Beta release announcement
by Jaroslav Reznik
Hi marketing team/WGs,
me again - we're getting closer to Beta release. The readiness
meeting is just one week away from now, it would be great to have
at least draft prepared.
I see, Joe already created Beta announcement page.
https://fedoraproject.org/wiki/F21_Beta_release_announcement
Btw. it was excellent work on Alpha, with WGs and everyone else
being involved! I expect we don't need much updates from Alpha,
just a bit extend it with more features, more details.
Thanks
Jaroslav
9 years, 6 months
Re: "Package sets" release criterion: what to do with it?
by Adam Williamson
On Fri, 2014-10-03 at 14:29 -0400, Paul W. Frields wrote:
> On Mon, Sep 29, 2014 at 06:25:46PM -0700, Adam Williamson wrote:
> > Hi, folks. I'm checking the release criteria again for Fedora.next
> > compatibility, and there's an Alpha criterion with obvious issues:
> >
> > "Package sets
> >
> > When doing a graphical install using the dedicated installer images, the
> > installer must be able to install each of the release blocking desktops,
> > as well as the minimal package set. "
> >
> > This was obviously written to the world where we had generic installer
> > images - the DVD, and intentionally-generic netinsts. We do not have
> > those things any more.
> >
> > Do we want to dump this criterion entirely, or is there any of it we
> > would like to keep? For instance, would we consider it 'release
> > blocking' functionality for you to be able to do some/any of the above
> > from the Server and/or Workstation network install images *after
> > configuring the repos manually*? Particularly, the minimal installation?
> > I'm not sure F21 as currently conceived would offer an avenue for doing
> > an interactive minimal installation.
> >
> > Basically, it comes down to: do we want to have a blessed method for
> > doing a network install of KDE and/or minimal? If so, do we want to
> > block releases on it?
>
> Correct me if I'm wrong, but doesn't the WS-specific netinst.iso allow
> you to install the standard Workstation product, among other things?
> I think I booted it the other day while redoing an installation, and
> saw multiple products available. I don't recall seeing Minimal but I
> didn't look specifically for it.
Sorry for the belated reply, but it's a good opportunity to try and
re-start this question.
At the time you wrote the mail, and indeed currently, the WS and Server
netinsts in fact act as 'universal' network install images - but this is
not per design, it's a bug.
Insofar as there was a design, it was to 'Product'-ize the network
install images - have them offer only the environment group that matches
the Product, and its option groups, by default. No-one really did the
work ahead of time to find out if that was actually feasible, though,
and what we found out at Alpha time is that it is rather difficult to
achieve with our current image generation process and anaconda
behaviour.
The bug tracking this is
https://bugzilla.redhat.com/show_bug.cgi?id=1134524 .
As things stand, if no-one does anything, the Product network install
images for 21 Beta will also be 'universal'. No-one, AFAICT, has even
taken a swing at solving the issues that prevent them being Product-ized
yet.
Funnily enough, so long as the network install images continue to act as
'universal' images, we can continue to use the existing release
criterion, I guess. Not sure whether it's appropriate, but it is at
least valid.
Before anyone asks, it is also not trivial to just ship a single
'universal' network install image. Traditional install media are built
out of product trees. Pre-F21, the netinst.iso image was built in the
'Fedora' tree -
https://dl.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/ , for
e.g. . That tree was populated with all the bits necessary to build the
'Fedora DVD' - the bits specified in fedora-install-fedora.ks . The
packages in that tree are all the packages on the DVD. The netinst.iso
was simply the DVD ISO without all the packages.
In a Product-y world, we don't have a Fedora/ tree any more. We don't
have anywhere logical to build a single 'officially universal' network
install image. We have these trees:
https://dl.fedoraproject.org/pub/fedora/linux/releases/test/21-Alpha/
with installer images built in Server/ and Workstation/ . It gets messy
if we try and yank the network install image out of one of those trees
after creation and stick it somewhere else. (And of course the Product-y
network install images are *branded* with their Product name, even
though there's really nothing very Product-y about them at all).
One option if we just wanted to go with a single 'universal' netinst
image is to build it out of Everything/ , but then (AIUI - dgilmore may
correct me) the downside would be it'd make the compose process even
longer.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 6 months
Server WG Meeting (2014-10-07)?
by Stephen Gallagher
I forgot to send out a request for agenda. Do we have anything urgent
that we need to discuss, or shall we all keep working on hitting the
Beta deadline?
9 years, 6 months
Server GUI Use Case
by John Unland
Here is some use cases I came up with that Stephen G. wanted.
Case 1: Migration of servers.
Ex: Server A is a old model so were going to migrate the configuration
to the new Server A. (You really have to be there physically there to
mess with hardware / networking)
Case 2: Install / Remove Hardware.
Ex: Faulty RAM / CPU / Hard drive (That is not hotswapable) you want a
quick way to identify the server and turn it off from a KVM inside the
rack. (Not all company's will have a dedicated machine to SSH or go
into a web-browser to configure these things. They may still have
KVM's inside there cabinets.)
Case 3: Installation of server software (Open Source AND Proprietary).
Ex: Bitnami + your appliance, a appliance software stack where you can
install it in a VM or locally inside a desktop. However you need to
have a GUI to configure / start/stop / view logs to install locally.
(They still have there own web interface in a browser but you still
need a GUI to install it.)
Sidenote: Case 3 ~ When you install Bitnami + your appliance locally
it uses the Container feature like Docker so it does not interfere
with other configurations in the same server.
When I was doing my research at my University, I opted to give the
user to use either the Ajenti, because it was a quick overview of your
server / services that you were running. AND I wanted to have a
configuration / overview control panel locally (That I was going to
build in-house) so that you could have more advanced outlook on your
server as well as local documentation, Hardware Install / Uninstall
Wizard, and some other helpful stuff for the person. Because I figured
that a small business didn't have a IT staff so it had to depend on
ques from the software logs / messages and the documentation. But you
could pretty much run the server from either both or one of them just
fine...
I know for the beta and I think the full release you want just the
base + essential server roles, and then later down the road your going
to define more. How about you leave the essential roles for now that
way you will have somewhat have a base to go off of other servers
(ownCloud, Round Cube, HPC roles, etc.), BUT create a template so that
members of the community can create there own roles and add it to a
repo list. Kinda like having the Play Store on Android but for
servers. I know you are still in Alpha phase but this is just
something to consider, but I digress.
So those are my cases, hope this was some of help to the SIG.
9 years, 6 months
Proposed Server release criteria for F21 Beta and Final
by Adam Williamson
Hi, folks. So, I drew up a rough draft of the Server release criteria
for Beta and Final as I suggest they might be. We could kick it around
at tomorrow's meeting if desired. Here we go:
BETA
=== Remote logging ===
It must be possible to forward system logs to a remote system using
Server packages.
=== Firewall configuration ===
Release-blocking roles must be able to report their status in regard to
the system firewall as described in the
[[Server/Technical_Specification#Firewall|technical specification]].
=== Roles ===
Release-blocking roles and the supported role configuration interfaces
must meet the core functional
[[Server/Technical_Specification#Role_Definition_Requirements|Role
Definition Requirements]] to the extent that supported roles can be
successfully started, stopped, and queried.
=== Cockpit ===
??????
FINAL
=== Roles ===
Release-blocking roles and the supported role configuration interfaces
must fully meet the
[[Server/Technical_Specification#Role_Definition_Requirements|Role
Definition Requirements]].
=== Cockpit ===
??????
You will note first of all the big ?????? for Cockpit. Cockpit's role
really isn't terribly well defined in the tech spec or PRD, so it is
hard to draft requirements. Is it primarily supposed to be an interface
for controlling roles? If so, can we treat it that way in the criteria,
and require things from it as regards its job in configuring roles?
I think the Role criteria described above would be okay, and at least
unambitious enough not to cause huge problems, for F21, but I'm really
not that happy with them for the long term.
It's obviously not practical to start hardcoding specific requirements
for specific roles into the criteria. What I would like instead is to
have a little more process on the Product side for Roles. I'd suggest
that Roles themselves should have definitions of their expected
functionality baked in at the point of creation / approval.
These could be split into sections to be required at Alpha, Beta and
Final. You could, for instance, expect roles to basically start up and
not explode at Alpha, expect them to be broadly 'feature complete' and
testable at Beta, and expect them to fully meet their listed functional
requirements at Final, just as a quick cut. Here's a very rough mock-up
for the "Domain Controller" role as a guide:
Alpha
-----
The Role must start and stop successfully. When the role is running, a
client system must be able to enrol into the FreeIPA domain.
Beta
----
When the Role is running, it must be able to enrol and unenrol multiple
clients. Client systems must be able to authenticate user accounts via
Kerberos. The FreeIPA configuration web UI must be available and allow
at least basic configuration of user accounts and permissions.
Final
-----
Oh, I don't know, I'm running out of ideas, I don't do that much more
with my FreeIPA system than is described in Beta. You know better than
me! That's why you should be writing this! :)
Well, I sort of ran out of steam at the end there, but you kinda get the
idea, right?
We can set things up appropriately so the release criteria can sensibly
call out to them. I'd expect the criteria would just say something like
'Release-blocking roles must meet the functional requirements listed in
their definition pages for the Beta milestone' or whatever, with a link
to a sensible target from which you could easily find the Role
definition pages.
I'd be very grateful for feedback on both the proposed criteria for F21,
and the idea above. We do need to get the Beta criteria in place ASAP,
Beta TC1 is due tomorrow (yes, I know, no rest for the wicked :/) I'll
start drafting up test cases ASAP.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 6 months
