search

anuket-project / anuket-specifications

Anuket specifications
https://docs.anuket.io
123 stars 116 forks source link

[TSC] OpenSack base release for RA-1, RI-1. #964

Closed rabi-abdel closed 4 years ago

rabi-abdel commented 4 years ago

As discussed in Prague, we need to decide on the base OpnStack version for RA-1 and RI-1.

rabi-abdel commented 4 years ago

Discussed in TSC:

  1. We need a policy to:

    • Specify when to move to a different OpenStack version. (what its he criteria)
    • What would be our backward compatibility policy.
    • @rabi-abdel to create one in the tech overall document.

  2. Base (Major) Version

    • do we need to specify a base version: YES.
    • @pgoyal01 to clarify in RA-1 the policy of supporting backward compatibility.

  3. which Version:

    • @bfcohen to sync with Ildiko about the most used active version of opstack across operators.
    • Survey to ask operators (@rabi-abdel to talk to Atul about creating one)
jbeltranatl commented 4 years ago

Re: Poll

Example areas of questions to operators...What version on today? Next target version? What is strategy used to identify the next target release?

[MikeF] The strategy should include the drivers, questions, or qualifiers, to assess why the next release is needed (e.g. current release has many errors, new release has needed features to match marketing plan and roadmap, etc)

pgoyal01 commented 4 years ago

Backward compatibility: in general OpenStack is backward compatible: "In general there is a requirement that release N will keep backward compatibility with release N-1 and in a deployment N’s and N-1’s services can safely coexist." However, if new functions introduced in version N are used then they will not work in version N-1.

For exposed services, API compatibility is of critical importance. There are guidelines on ensuring API Interoperability between OpenStack releases and the RPC APIs (between OpenStack Services).

But for every rule there are exceptions. Exceptions occur primarily for new services as they are not stable and continue to undergo changes including architectural changes. For example, Cybrg in the Stein release (API v2) is very different from the Pike release (API v1); there are new APIs and also a number of APIs from v1 have been deprecated. Fortunately, Cyborg is not exposed as is utilised by Nova.

rabi-abdel commented 4 years ago

[Ildiko]:

I would highlight two concepts. One is API versions and the other is the releases of the different services.

Many of the core services adopted to use microversions for their APIs to provide better structure and visibility into changes and help with backward compatibility. There is some information about the concept for Nova described here: https://docs.openstack.org/api-guide/compute/microversions.html

In general the APIs are always compatible, though you may have to use a newer microversion to get new functionality.

On the deployment side config options should be deprecated before they are removed meaning N+1 upgrade works without modifying configs but N+2 may not (note that is per option so can have different references for N). There is some upgrade testing with using the tool called Grenade: https://opendev.org/openstack/grenade/src/branch/master

The OpenStack community is using multiple release models depending on whether you’re releasing a service, a library, client, etc. The most often used release model is called “cycle-with-rc” that describes projects that produce a single release at the end of the cycle, with one or more release candidates (RC) close to the end of the cycle and optional development milestone betas published on a per-project need.

You can find information about the releases and release models here: https://docs.openstack.org/contributors/common/releases.html And information about prior releases in addition is here: https://releases.openstack.org

rabi-abdel commented 4 years ago

[Ildiko said]: Hi,

Sorry that I missed today’s meeting.

Following up on the item below, we are running a user survey that provides some data around deployments. Based on the past two years the most deployments are using one of the five releases between Mitaka and Queens. There are some deployments on both older and newer versions as well. Based on data that we have I can’t really name one particular release.

In general I also think we shouldn’t pin things to an older release just because it’s currently the most deployed. As we are looking into evolution paths both on the side of technologies like containers and new deployment concepts like edge it doesn’t make sense to constrain OpenStack services to an older version when they are providing infrastructure management services for both of these examples.

We are currently working on to identify basic functionality that we need. Based on that we can do a feature-support-matrix to see if all the basics are supported and have the optional and wishlist items tracked and do testing accordingly, at least as a starting point.

What do you think?

Thanks, Ildikó

ASawwaf commented 4 years ago

CNTT ( RA-1 ) almost will depend on the core project of Openstack ( Nova, Neutron , Cinder , Swift , Keystone , Heat , Galance , Horizon and Ironic )

and if we monitor the updates/changes in these project from release to release we will find that there is no major changes expect updates on certain exposed API

to follow every release it will be to touch and not make sense

On practical, as an operator, to make this upgrades it required a very long time and effort to recertify and validate the VNF on the new release ( within certain setup for each operator)

and I can give a practical example during our next call

So my recommedation , to go to any release when :

So let define a major release that we can target (Redhat approach )

what did you think @rabi-abdel @pgoyal01

rabi-abdel commented 4 years ago

@bfcohen said: Hi Ildiko - Sorry you missed the meeting. There are several components to the discussion. We were looking for the most common deployment for Telecom's more as a stake in the sand for the determining the bottom level for a supported RA. We also need to determine the right cadence for matching CNTT to the OpenStack releases. which are still at every six months, but now mapping to minor and major releases. Since for the most part newer versions of OS are now backwards compatible and are adding new features, we might be able to update the RA when a new feature that needs to be incorporated is available. I think that we can word the documents so that we call out the minimum supported release, and then not name releases going forward, but just say that new releases will be automatically supported on some x time line. I did find out that Red Hat is typically 6 months to a year behind the "official" current release. That means that they take 6 months to a year to do their own certification and validation into their version of the OpenStack that they are selling to the telecom operators.

Other options might be to not map it to a release, but a set of features that are needed to support the RA. As we need new features, we can add them. I am open to suggestions.

rabi-abdel commented 4 years ago

I kind of like @bfcohen proposal of specifying the minimum supported release (based on the features we specify in RA) and we need to make sure that we clarify that x releases in future will be supported in accordance to OpenStack combability policy.

rabi-abdel commented 4 years ago

CNTT ( RA-1 ) almost will depend on the core project of Openstack ( Nova, Neutron , Cinder , Swift , Keystone , Heat , Galance , Horizon and Ironic )

and if we monitor the updates/changes in these project from release to release we will find that there is no major changes expect updates on certain exposed API

to follow every release it will be to touch and not make sense

On practical, as an operator, to make this upgrades it required a very long time and effort to recertify and validate the VNF on the new release ( within certain setup for each operator)

and I can give a practical example during our next call

So my recommedation , to go to any release when :

  • Complete change in archiecture as convert Openstack control plan from VM to Container based ( which it is achived right now )
  • New project that we are planning to adept like cybrog , Kuryu , Kata ,...

So let define a major release that we can target (Redhat approach )

what did you think @rabi-abdel @pgoyal01

will specifying a minimum release of OpenStack will work (since we understand OpenStack combinability policy). we then update our minimum release if we find features that we would like to include in RA in future OpenSack releases and so on? what do you think @ASawwaf ?

ASawwaf commented 4 years ago

CNTT ( RA-1 ) almost will depend on the core project of Openstack ( Nova, Neutron , Cinder , Swift , Keystone , Heat , Galance , Horizon and Ironic ) and if we monitor the updates/changes in these project from release to release we will find that there is no major changes expect updates on certain exposed API to follow every release it will be to touch and not make sense On practical, as an operator, to make this upgrades it required a very long time and effort to recertify and validate the VNF on the new release ( within certain setup for each operator) and I can give a practical example during our next call So my recommedation , to go to any release when :

  • Complete change in archiecture as convert Openstack control plan from VM to Container based ( which it is achived right now )
  • New project that we are planning to adept like cybrog , Kuryu , Kata ,...

So let define a major release that we can target (Redhat approach ) what did you think @rabi-abdel @pgoyal01

will specifying a minimum release of OpenStack will work (since we understand OpenStack combinability policy). we then update our minimum release if we find features that we would like to include in RA in future OpenSack releases and so on? what do you think @ASawwaf ?

agreed, but we need to define the criteria for an upgrade , is it Just new feature ? or or,...

pgoyal01 commented 4 years ago

@ASawwaf Thanks. We can add to the criteria for selecting a new release that you already specified:

Regarding targeting an OSTK release the various OSTK vendors follow different approaches at least as it concerns their extended support versions (see below). In Paris, we chose Pike for various reasons including stability, but also because many of the API calls and responses were standardised (use of UUIDs consistently, etc.)

To fully support hardware accelerators though, we need at least Stein as the architecture of Cyborg and the APIs have changed significantly; Cyborg now also interacts with Glance.

Red Hat, Canonical and Mirantis OSTK policies

Red Hat provides Extended Life Cycle Support (ELS) for every third release: Red Hat Open Stack Platform (RHOSP) 10 (Newton), 13 (Queens), and the next will be RHOSP16 (Train). RH doesn't distinguish between OSTK major and minor releases.

Canonical provides Long Term Support for the first OSTK release of an even year (LTS every 2 years) -- 2016 Mitaka, 2018 Queens, 2020 Ussuri (next).

Hence, some of the Operators are going to tie themselves to upgrading to an ELS or LTS version - not necessarily consecutive. For RH, upgrade from Newton to Train, or for Canonical Mitaka to Ussuri.

Mirantis MCP program supports practically all OSTK releases (rare exceptions).

karinesevilla commented 4 years ago

To move from an OpenStack release to another, the need to add new feature considered mandatory by CNTT to support workloads must be a driver. It must be added to criteria mentioned above security fix and API deprecation) As mentioned by @pgoyal01, it may happen with Hardware acceleration and Cyborg

pgoyal01 commented 4 years ago

Here is the list so far including items suggested by @ASawwaf and @karinesevilla:

The new OpenStack release must be a major release

rabi-abdel commented 4 years ago

@collivier said: Hi,

As mentioned during the meeting, I would consider it's also about the versions still maintained by the communities involved (OpenStack, OPNFV, etc.). It's not so simple because the capabilities to backport changes could differ between the different services and the related tests (a few of them manages their own releases too).

I strongly think RA1 Chapter5 and the related testing in RC are already in a good shape (the major versions, the minimal micro versions, the mandatory capabilities) and reach the starting point mentioned. Yes it's an open question if we do set new mandatory capabilities which was added in Rocky, Stein or Train.

I will evaluate the needs of upper micro version bounds by checking the last OpenStack releases. It should be very difficult and I think Cinder doesn't manage so well the microversions (e.g. the multi-attach support dropped in Cinder Train without new microversions). https://review.opendev.org/#/c/681167/ Cédric

rabi-abdel commented 4 years ago

we need 2 things:

ASawwaf commented 4 years ago

@rabi-abdel For the 2nd point, it covered up, we can take the above as a baseline after that we can capitalize on it

the ask here, when can we accommodate it