Change Proposals for Fedora 23

[Stephen Gallagher]

In addition to the PRD refresh that we are all looking at (*ahem*), we
also need to figure out what are the major efforts we're going to
engage in during the Fedora 23 cycle. Alpha Freeze for Fedora 23 will
be on July 28th[1], and that means we need to have at least a prototype
of what we want in Fedora 23 ready by that point.

I'll list some of the things that have been discussed on the mailing
list and in meetings recently and we can work from there. (I'll also
include my recommendations inline).

==============================
== File-sharing server role ==
==============================
=== Benefits ===

 * Simple, easy-to-use mechanism for producing a file-sharing host
using the CIFS and/or NFS protocols.
 * Clear gap in our offering today.

=== Requirements ===
 * Development of an API to manage the configuration.
 * Creation of a server role definition to provide the services.
 * Graphical interface for manipulating it (likely Cockpit, unless
another web-based tool can be adapted without sacrificing usability).
 

=== Issues/Risks ===

 * Cockpit developers have indicated they cannot spare the resources to
implement the GUI this cycle.

=== Recommendations ===
Ask for volunteers to work on the management API for Fedora 23 and
postpone cockpit and rolekit work until Fedora 24.


============================================
== Cockpit GUI for Domain Controller Role ==
============================================
=== Benefits ===
 * Easier setup of initial domain controller.
 * Demonstration of our commitment to converging capabilities into
Cockpit

=== Requirements ===
 * UI Design of role creation (started; thanks Andreas Nilsson!)
 * Resources familiar with JavaScript and D-BUS (acquired: we have a
GSoC student working on this)

=== Issues/Risks ===
 * Work is being done by a student as part of Google Summer of Code.
Student projects always carry some risk. GSoC schedule is a good fit
with the Fedora 23 schedule (recommended pencils-down date is before
Fedora 23 Beta)

=== Recommendations ===
Let's definitely move ahead with this one. I'm sure our student (Turner
England) will be motivated and excited to see his work featured
prominently as a deliverable. I will also be personally involved as one
of his two mentors (the other being Peter Volpe of the Cockpit team).


================================
== Containerized Server Roles ==
================================
=== Benefits ===
 * Server roles offered by containers will be unaffected by underlying
OS upgrades.
 * Containers written under the Nulecule specification will be possible
to migrate to the Fedora Atomic Platform (and possibly also OpenShift
v3) later.

=== Requirements ===
 * At least one proof-of-concept role (I am proposing memcached for
this, as it's very simple).
 * Ideally convert the Database Server role to a container format. Must
handle upgrades (or backup/restore) from F22 DB Role.
 * Docker package must be built for at least all primary arches (and
ideally the secondary arches as well).

=== Issues/Risks ===
 * More difficult to determine when upgrades are necessary and to apply
them.
 * Docker Hub only supports x86_64, so we will have to either provide a
hub of our own or build docker images in rolekit from Dockerfiles.

=== Recommendations ===
I will be working on at least the PoC role (memcached) at the direction
of my management at Red Hat, so we should probably treat this as a
given and go ahead with filing at least one Change Proposal.

I recommend for simplicity (and not adding to rel-eng's workload) that
we build the images in rolekit from Dockerfiles based on the latest
available RPMs in the standard Fedora package collection.

I also recommend that we defer attempting to completely solve the
docker image upgrade problem to Fedora 24 (there's some work going on
in the Atomic space that may be more mature by that point). I think for
a first attempt, it will be acceptable to just build the ability to
perform upgrades on demand and instead implement the notification of
upgrades at a later date.


==========================
== FreeIPA Replica Role ==
==========================

=== Benefits ===
 * Ability to set up a resilient domain
 * Fewer manual steps after the initial domain creation

=== Requirements ===
 * Mechanism to promote a domain client to a replica
 * Resources: This needs the heavy involvement of a FreeIPA developer
(simo?)

=== Issues/Risks ===
 * May require plumbing changes that cannot be completed in time.

=== Recommendations ===

Feedback needed from FreeIPA team before I can make any
recommendations.



[1] https://fedoraproject.org/wiki/Releases/23/Schedule

[Stephen Gallagher]

On Wed, 2015-06-03 at 08:43 -0400, Stephen Gallagher wrote:
>  In addition to the PRD refresh that we are all looking at (*ahem*), 
>  we
>  also need to figure out what are the major efforts we're going to
>  engage in during the Fedora 23 cycle. Alpha Freeze for Fedora 23 will
>  be on July 28th[1], and that means we need to have at least a 
>  prototype
>  of what we want in Fedora 23 ready by that point.
>  
>  I'll list some of the things that have been discussed on the mailing
>  list and in meetings recently and we can work from there. (I'll also
>  include my recommendations inline).
>  
>  ==============================
>  == File-sharing server role ==
>  ==============================
>  === Benefits ===
>  
>   * Simple, easy-to-use mechanism for producing a file-sharing host
>  using the CIFS and/or NFS protocols.
>   * Clear gap in our offering today.
>  
>  === Requirements ===
>   * Development of an API to manage the configuration.
>   * Creation of a server role definition to provide the services.
>   * Graphical interface for manipulating it (likely Cockpit, unless
>  another web-based tool can be adapted without sacrificing usability).
>   
>  
>  === Issues/Risks ===
>  
>   * Cockpit developers have indicated they cannot spare the resources 
>  to
>  implement the GUI this cycle.
>  
>  === Recommendations ===
>  Ask for volunteers to work on the management API for Fedora 23 and
>  postpone cockpit and rolekit work until Fedora 24.
>  
>  
>  ============================================
>  == Cockpit GUI for Domain Controller Role ==
>  ============================================
>  === Benefits ===
>   * Easier setup of initial domain controller.
>   * Demonstration of our commitment to converging capabilities into
>  Cockpit
>  
>  === Requirements ===
>   * UI Design of role creation (started; thanks Andreas Nilsson!)
>   * Resources familiar with JavaScript and D-BUS (acquired: we have a
>  GSoC student working on this)
>  
>  === Issues/Risks ===
>   * Work is being done by a student as part of Google Summer of Code.
>  Student projects always carry some risk. GSoC schedule is a good fit
>  with the Fedora 23 schedule (recommended pencils-down date is before
>  Fedora 23 Beta)
>  
>  === Recommendations ===
>  Let's definitely move ahead with this one. I'm sure our student 
>  (Turner
>  England) will be motivated and excited to see his work featured
>  prominently as a deliverable. I will also be personally involved as 
>  one
>  of his two mentors (the other being Peter Volpe of the Cockpit team).
>  
>  
>  ================================
>  == Containerized Server Roles ==
>  ================================
>  === Benefits ===
>   * Server roles offered by containers will be unaffected by 
>  underlying
>  OS upgrades.
>   * Containers written under the Nulecule specification will be 
>  possible
>  to migrate to the Fedora Atomic Platform (and possibly also OpenShift
>  v3) later.
>  
>  === Requirements ===
>   * At least one proof-of-concept role (I am proposing memcached for
>  this, as it's very simple).
>   * Ideally convert the Database Server role to a container format. 
>  Must
>  handle upgrades (or backup/restore) from F22 DB Role.
>   * Docker package must be built for at least all primary arches (and
>  ideally the secondary arches as well).
>  
>  === Issues/Risks ===
>   * More difficult to determine when upgrades are necessary and to 
>  apply
>  them.
>   * Docker Hub only supports x86_64, so we will have to either provide 
>  a
>  hub of our own or build docker images in rolekit from Dockerfiles.
>  
>  === Recommendations ===
>  I will be working on at least the PoC role (memcached) at the 
>  direction
>  of my management at Red Hat, so we should probably treat this as a
>  given and go ahead with filing at least one Change Proposal.
>  
>  I recommend for simplicity (and not adding to rel-eng's workload) 
>  that
>  we build the images in rolekit from Dockerfiles based on the latest
>  available RPMs in the standard Fedora package collection.
>  
>  I also recommend that we defer attempting to completely solve the
>  docker image upgrade problem to Fedora 24 (there's some work going on
>  in the Atomic space that may be more mature by that point). I think 
>  for
>  a first attempt, it will be acceptable to just build the ability to
>  perform upgrades on demand and instead implement the notification of
>  upgrades at a later date.
>  
>  
>  ==========================
>  == FreeIPA Replica Role ==
>  ==========================
>  
>  === Benefits ===
>   * Ability to set up a resilient domain
>   * Fewer manual steps after the initial domain creation
>  
>  === Requirements ===
>   * Mechanism to promote a domain client to a replica
>   * Resources: This needs the heavy involvement of a FreeIPA developer
>  (simo?)
>  
>  === Issues/Risks ===
>   * May require plumbing changes that cannot be completed in time.
>  
>  === Recommendations ===
>  
>  Feedback needed from FreeIPA team before I can make any
>  recommendations.
>  
>  
>  
>  [1] https://fedoraproject.org/wiki/Releases/23/Schedule
>   

Some items I forgot yesterday:

==============================
== Stable API Documentation ==
==============================

=== Benefits ===
Having a Fedora-provided repository of the specific set of API (and
ABI) that we guarantee stability or backwards-compatibility will go a
long way towards addressing the concerns around our lack of an LTS
release. Additionally, it will make life easier for our users to have a
single source to look for documentation, rather than the current
situation of having to search out each upstream for documentation.

=== Issues/Risks ===
 * Requires a large time commitment from someone on the Fedora Docs
team to collate the documentation and post it to the Fedora
Documentation site.
 * Requires developer effort to locate and identify the stable APIs
 * Almost certainly cannot all be done in a single release

=== Recommendations ===
 * Locate someone from Fedora Docs to do the collation
 * Start with a set of known-stable APIs (such as glibc and systemd)
and publish those for Fedora 23.



=========================
== API break detection ==
=========================

=== Benefits ===
Provide a taskotron process that will identify API and ABI breaks for
common languages when updates are submitted to Bodhi. If such are
detected, we should disable autopush-by-karma. This will allow us to be
able to better avoid incompatible updates in stable releases of Fedora.

=== Issues/Risks ===
 * Tooling needs to be implemented. (Some help may be available from
libabigail[1])
 * Someone needs to write a taskotron process that will run when
updates are created
 * Available tools for this are currently limited to C/C++ ELF
libraries

=== Recommendations ===
Search out someone to do this work. It is high value for comparatively
little work (since much of the hard work has been solved by
libabigail). Volunteers highly requested.

It would be worthwhile to start with C/C++ and see how things progress
from there.


[1] https://sourceware.org/libabigail/

[Stephen John Smoogen]

On 4 June 2015 at 06:21, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  On Wed, 2015-06-03 at 08:43 -0400, Stephen Gallagher wrote: 
>  ==============================
>  == Stable API Documentation ==
>  ==============================
>
>  === Benefits ===
>  Having a Fedora-provided repository of the specific set of API (and
>  ABI) that we guarantee stability or backwards-compatibility will go a
>  long way towards addressing the concerns around our lack of an LTS
>  release. Additionally, it will make life easier for our users to have a
>  single source to look for documentation, rather than the current
>  situation of having to search out each upstream for documentation.
>
>  === Issues/Risks ===
>   * Requires a large time commitment from someone on the Fedora Docs
>  team to collate the documentation and post it to the Fedora
>  Documentation site.
>   * Requires developer effort to locate and identify the stable APIs
>   * Almost certainly cannot all be done in a single release
>
>  === Recommendations ===
>   * Locate someone from Fedora Docs to do the collation
>   * Start with a set of known-stable APIs (such as glibc and systemd)
>  and publish those for Fedora 23.
>  
What guarentees does systemd have towards API's? They seem to be at
least adding new features all the time which would mean that the API
is getting larger over a release set. Which probably goes towards
having a definition of stable that we 'guarentee' as some see stable
as nothing be added and others see items not getting removed.

Also what level of API/ABI definitions are we looking as being
'published'. Getting a list of calls might be easy, but defining what
each call does would take time. [Past projects of standalone software
was on the order of 3-5 months depending on the level of detail
required.]

>  =========================
>  == API break detection ==
>  =========================
>
>  === Benefits ===
>  Provide a taskotron process that will identify API and ABI breaks for
>  common languages when updates are submitted to Bodhi. If such are
>  detected, we should disable autopush-by-karma. This will allow us to be
>  able to better avoid incompatible updates in stable releases of Fedora.
>
>  === Issues/Risks ===
>   * Tooling needs to be implemented. (Some help may be available from
>  libabigail[1])
>   * Someone needs to write a taskotron process that will run when
>  updates are created
>   * Available tools for this are currently limited to C/C++ ELF
>  libraries
>
>  === Recommendations ===
>  Search out someone to do this work. It is high value for comparatively
>  little work (since much of the hard work has been solved by
>  libabigail). Volunteers highly requested.
>
>  It would be worthwhile to start with C/C++ and see how things progress
>  from there.
>
>
>  [1] https://sourceware.org/libabigail/
>  _______________________________________________
>  server mailing list
>  server(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/server 


-- 
Stephen J Smoogen.

[Stephen Gallagher]

On Thu, 2015-06-04 at 07:27 -0600, Stephen John Smoogen wrote:
>  On 4 June 2015 at 06:21, Stephen Gallagher
> <sgallagh(a)redhat.com&gt; 
>  wrote:
>  > On Wed, 2015-06-03 at 08:43 -0400, Stephen Gallagher wrote:
>  
>  > ==============================
>  > == Stable API Documentation ==
>  > ==============================
>  > 
>  > === Benefits ===
>  > Having a Fedora-provided repository of the specific set of API (and
>  > ABI) that we guarantee stability or backwards-compatibility will go 
>  > a
>  > long way towards addressing the concerns around our lack of an LTS
>  > release. Additionally, it will make life easier for our users to 
>  > have a
>  > single source to look for documentation, rather than the current
>  > situation of having to search out each upstream for documentation.
>  > 
>  > === Issues/Risks ===
>  >  * Requires a large time commitment from someone on the Fedora Docs
>  > team to collate the documentation and post it to the Fedora
>  > Documentation site.
>  >  * Requires developer effort to locate and identify the stable APIs
>  >  * Almost certainly cannot all be done in a single release
>  > 
>  > === Recommendations ===
>  >  * Locate someone from Fedora Docs to do the collation
>  >  * Start with a set of known-stable APIs (such as glibc and 
>  > systemd)
>  > and publish those for Fedora 23.
>  > 
>  
>  What guarentees does systemd have towards API's? They seem to be at
>  least adding new features all the time which would mean that the API
>  is getting larger over a release set. Which probably goes towards
>  having a definition of stable that we 'guarentee' as some see stable
>  as nothing be added and others see items not getting removed.
>   
systemd has several D-BUS APIs that upstream guarantees will remain
compatible. Yes, new (and often non-guaranteed) APIs are released
regularly. We would be talking about supporting only the stable ones
formally.


>  Also what level of API/ABI definitions are we looking as being
>  'published'. Getting a list of calls might be easy, but defining what
>  each call does would take time. [Past projects of standalone software
>  was on the order of 3-5 months depending on the level of detail
>  required.]
>   
Ideally we'd be republishing upstream documentation, just gathering it
for easy access.



>  > 
>  > 
>  > =========================
>  > == API break detection ==
>  > =========================
>  > 
>  > === Benefits ===
>  > Provide a taskotron process that will identify API and ABI breaks 
>  > for
>  > common languages when updates are submitted to Bodhi. If such are
>  > detected, we should disable autopush-by-karma. This will allow us 
>  > to be
>  > able to better avoid incompatible updates in stable releases of 
>  > Fedora.
>  > 
>  > === Issues/Risks ===
>  >  * Tooling needs to be implemented. (Some help may be available 
>  > from
>  > libabigail[1])
>  >  * Someone needs to write a taskotron process that will run when
>  > updates are created
>  >  * Available tools for this are currently limited to C/C++ ELF
>  > libraries
>  > 
>  > === Recommendations ===
>  > Search out someone to do this work. It is high value for 
>  > comparatively
>  > little work (since much of the hard work has been solved by
>  > libabigail). Volunteers highly requested.
>  > 
>  > It would be worthwhile to start with C/C++ and see how things 
>  > progress
>  > from there.
>  > 
>  > 
>  > [1] https://sourceware.org/libabigail/
>  > _______________________________________________
>  > server mailing list
>  > server(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/server
>  
>  
>

[Dodji Seketeli]

Hello,

Stephen Gallagher <sgallagh(a)redhat.com&gt; a
écrit:

[...]

> > > =========================
> > > == API break detection ==
> > > =========================
> > > 
> > > === Benefits ===
> > > Provide a taskotron process that will identify API and ABI breaks 
> > > for
> > > common languages when updates are submitted to Bodhi. If such are
> > > detected, we should disable autopush-by-karma. This will allow us 
> > > to be
> > > able to better avoid incompatible updates in stable releases of 
> > > Fedora. 
[...]

We (the libabigail people) are working on this topic.  I am not sure we
can wrap it up for Fedora 23 (Sept, which is the data of the Beta
Freeze), but we certainly can shoot for it.

I sent a note to the devel list at
https://lists.fedoraproject.org/pipermail/devel/2015-June/211160.html so
I guess we can keep discussing about this topic there.

Cheers,

-- 
		Dodji

[Josh Boyer]

On Thu, Jun 4, 2015 at 8:21 AM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  Some items I forgot yesterday:
>
>  ==============================
>  == Stable API Documentation ==
>  ==============================
>
>  === Benefits ===
>  Having a Fedora-provided repository of the specific set of API (and
>  ABI) that we guarantee stability or backwards-compatibility will go a
>  long way towards addressing the concerns around our lack of an LTS
>  release. Additionally, it will make life easier for our users to have a
>  single source to look for documentation, rather than the current
>  situation of having to search out each upstream for documentation.
>
>  === Issues/Risks ===
>   * Requires a large time commitment from someone on the Fedora Docs
>  team to collate the documentation and post it to the Fedora
>  Documentation site.
>   * Requires developer effort to locate and identify the stable APIs
>   * Almost certainly cannot all be done in a single release
>
>  === Recommendations ===
>   * Locate someone from Fedora Docs to do the collation
>   * Start with a set of known-stable APIs (such as glibc and systemd)
>  and publish those for Fedora 23.
>
>
>
>  =========================
>  == API break detection ==
>  =========================
>
>  === Benefits ===
>  Provide a taskotron process that will identify API and ABI breaks for
>  common languages when updates are submitted to Bodhi. If such are
>  detected, we should disable autopush-by-karma. This will allow us to be
>  able to better avoid incompatible updates in stable releases of Fedora.
>
>  === Issues/Risks ===
>   * Tooling needs to be implemented. (Some help may be available from
>  libabigail[1])
>   * Someone needs to write a taskotron process that will run when
>  updates are created
>   * Available tools for this are currently limited to C/C++ ELF
>  libraries
>
>  === Recommendations ===
>  Search out someone to do this work. It is high value for comparatively
>  little work (since much of the hard work has been solved by
>  libabigail). Volunteers highly requested.
>
>  It would be worthwhile to start with C/C++ and see how things progress
>  from there. 
Wouldn't both of these be better served by the Base WG?  Particularly
for very low-level components like systemd and glibc.  I don't see why
Server would be the only Edition to have such documentation when it is
common across all of them.

josh

[Stephen Gallagher]

>  On Jun 4, 2015, at 12:21 PM, Josh Boyer
> <jwboyer(a)fedoraproject.org&gt; wrote:
>  
> > On Thu, Jun 4, 2015 at 8:21 AM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
> > 
> > 
> > Some items I forgot yesterday:
> > 
> > ==============================
> > == Stable API Documentation ==
> > ==============================
> > 
> > === Benefits ===
> > Having a Fedora-provided repository of the specific set of API (and
> > ABI) that we guarantee stability or backwards-compatibility will go a
> > long way towards addressing the concerns around our lack of an LTS
> > release. Additionally, it will make life easier for our users to have a
> > single source to look for documentation, rather than the current
> > situation of having to search out each upstream for documentation.
> > 
> > === Issues/Risks ===
> > * Requires a large time commitment from someone on the Fedora Docs
> > team to collate the documentation and post it to the Fedora
> > Documentation site.
> > * Requires developer effort to locate and identify the stable APIs
> > * Almost certainly cannot all be done in a single release
> > 
> > === Recommendations ===
> > * Locate someone from Fedora Docs to do the collation
> > * Start with a set of known-stable APIs (such as glibc and systemd)
> > and publish those for Fedora 23.
> > 
> > 
> > 
> > =========================
> > == API break detection ==
> > =========================
> > 
> > === Benefits ===
> > Provide a taskotron process that will identify API and ABI breaks for
> > common languages when updates are submitted to Bodhi. If such are
> > detected, we should disable autopush-by-karma. This will allow us to be
> > able to better avoid incompatible updates in stable releases of Fedora.
> > 
> > === Issues/Risks ===
> > * Tooling needs to be implemented. (Some help may be available from
> > libabigail[1])
> > * Someone needs to write a taskotron process that will run when
> > updates are created
> > * Available tools for this are currently limited to C/C++ ELF
> > libraries
> > 
> > === Recommendations ===
> > Search out someone to do this work. It is high value for comparatively
> > little work (since much of the hard work has been solved by
> > libabigail). Volunteers highly requested.
> > 
> > It would be worthwhile to start with C/C++ and see how things progress
> > from there.
>  
>  Wouldn't both of these be better served by the Base WG?  Particularly
>  for very low-level components like systemd and glibc.  I don't see why
>  Server would be the only Edition to have such documentation when it is
>  common across all of them.
>  
>  josh
>  _______________________________________________
>  server mailing list
>  server(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/server 

I suppose a better explanation would be hat the Server SIG has a strong interest and is
attempting to drive the effort. It certainly needs not be restricted to Server.

[Simo Sorce]

On Wed, 2015-06-03 at 08:43 -0400, Stephen Gallagher wrote:
>  ==========================
>  == FreeIPA Replica Role ==
>  ==========================
>  
>  === Benefits ===
>   * Ability to set up a resilient domain
>   * Fewer manual steps after the initial domain creation
>  
>  === Requirements ===
>   * Mechanism to promote a domain client to a replica
>   * Resources: This needs the heavy involvement of a FreeIPA developer
>  (simo?)
>  
>  === Issues/Risks ===
>   * May require plumbing changes that cannot be completed in time.
>  
>  === Recommendations ===
>  
>  Feedback needed from FreeIPA team before I can make any
>  recommendations. 
I am currently working on a key enabler for this upstream, it should be
possible to meet F23 deadlines, let's cross fingers.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York