[JBoss JIRA] (JBIDE-26893) Create universal template and label that would accommodate different rhel needed by interop testing team
by Ondrej Dockal (Jira)
[ https://issues.jboss.org/browse/JBIDE-26893?page=com.atlassian.jira.plugi... ]
Ondrej Dockal updated JBIDE-26893:
----------------------------------
Description:
We would like to use universal label that would cover different rhel versions that are required by interop testing. The idea is that we will keep one/two label for interop testing slave: rhel-interop (and possibly for both stream, so rhel-interop-7 and rhel-interop-8), which would have used image: rhel-interop-7(8)-snapshot that would have actually needed rhel version to test. During provisioning we will replace snapshot with proper rhel. This way we can keep these two labels and do not need to change interop test job label all the time via PR in cci-config repo.
Reqs:
* UMB trigger for interop rhel to run provision job with
* job will be parametrized based on rhel version given by umb message
* jenkins provisioning job build description needs to be updated to have available info about rhel version
Pros:
* do not need to change code via PR every time there is new bits to test
* probably can be fully automated
Cons:
* only one version to test at a time
* complex and possibly unstable?
was:
We would like to use universal label that would cover different rhel versions that are required by interop testing. The idea is that we will keep one label for interop testing slave: rhel-interop, which would have used image: rhel-interop-snapshot that would have actually needed rhel version to test. During provisioning we will replace snapshot with proper rhel. This way we can keep one label and do not need to change interop test job label all the time via PR in cci-config repo.
Reqs:
* build description needs to be updated to have available info about rhel version
* UMB trigger for interop rhel to run provision job with
Pros:
* do not need to change code via PR every time there is new bits to test
* probably can be fully automated
Cons:
* only one version to test at a time
* complex and possibly unstable?
> Create universal template and label that would accommodate different rhel needed by interop testing team
> --------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-26893
> URL: https://issues.jboss.org/browse/JBIDE-26893
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: integration-tests, qa
> Affects Versions: 4.13.0.Final
> Reporter: Ondrej Dockal
> Assignee: Ondrej Dockal
> Priority: Major
> Labels: jenkins
> Fix For: 4.14.x
>
>
> We would like to use universal label that would cover different rhel versions that are required by interop testing. The idea is that we will keep one/two label for interop testing slave: rhel-interop (and possibly for both stream, so rhel-interop-7 and rhel-interop-8), which would have used image: rhel-interop-7(8)-snapshot that would have actually needed rhel version to test. During provisioning we will replace snapshot with proper rhel. This way we can keep these two labels and do not need to change interop test job label all the time via PR in cci-config repo.
> Reqs:
> * UMB trigger for interop rhel to run provision job with
> * job will be parametrized based on rhel version given by umb message
> * jenkins provisioning job build description needs to be updated to have available info about rhel version
>
> Pros:
> * do not need to change code via PR every time there is new bits to test
> * probably can be fully automated
> Cons:
> * only one version to test at a time
> * complex and possibly unstable?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JBIDE-26919) OC binary: should warn if 3.x is used for an OpenShift 4 cluster (and vice versa)
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26919?page=com.atlassian.jira.plugi... ]
André Dietisheim updated JBIDE-26919:
-------------------------------------
Description:
OC 4.x does not fully work with an OpenShift 3.x cluster. The opposite is also true:
In a mail on the mailing list on the 17th of October (*[openshift-sme] 4.x oc client is not compatible with OCP 3.11.*)
{quote}
The open shift 4.1 CLI can't get SecurityContextConstraints from 3.11 openshift. Is this expected? or we need to fix this?
$ oc get SecurityContextConstraints restricted -o name
error: attempt to print an ungroupified object: /v1, Kind=SecurityContextConstraints
oc version
Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.18-201909201915+53a7fbd-dirty", GitCommit:"53a7fbd", GitTreeState:"dirty", BuildDate:"2019-09-21T03:15:55Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-09-12T23:41:09Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
{quote}
answered by saying that one should use the oc binary that matches the cluster in terms of version:
{quote}
API's change per each OpenShift version. You should always be sure to match the version of the CLI to the target cluster version (at least to the minor version) and have experienced errors similar to what you are receiving in the past.
{quote}
was:
OC 4.x does not fully work with an OpenShift 3.x cluster. The opposite is also true:
In a mail on the mailing list on the 17th of October (*[openshift-sme] 4.x oc client is not compatible with OCP 3.11.*)
{quote}
The open shift 4.1 CLI can't get SecurityContextConstraints from 3.11 openshift. Is this expected? or we need to fix this?
# oc get SecurityContextConstraints restricted -o name
error: attempt to print an ungroupified object: /v1, Kind=SecurityContextConstraints
oc version
Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.18-201909201915+53a7fbd-dirty", GitCommit:"53a7fbd", GitTreeState:"dirty", BuildDate:"2019-09-21T03:15:55Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-09-12T23:41:09Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
{quote}
answered by saying that one should use the oc binary that matches the cluster in terms of version:
{quote}
API's change per each OpenShift version. You should always be sure to match the version of the CLI to the target cluster version (at least to the minor version) and have experienced errors similar to what you are receiving in the past.
{quote}
> OC binary: should warn if 3.x is used for an OpenShift 4 cluster (and vice versa)
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-26919
> URL: https://issues.jboss.org/browse/JBIDE-26919
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.12.0.Final
> Reporter: André Dietisheim
> Priority: Major
> Labels: oc_binary
> Fix For: 4.14.x
>
>
> OC 4.x does not fully work with an OpenShift 3.x cluster. The opposite is also true:
> In a mail on the mailing list on the 17th of October (*[openshift-sme] 4.x oc client is not compatible with OCP 3.11.*)
> {quote}
> The open shift 4.1 CLI can't get SecurityContextConstraints from 3.11 openshift. Is this expected? or we need to fix this?
> $ oc get SecurityContextConstraints restricted -o name
> error: attempt to print an ungroupified object: /v1, Kind=SecurityContextConstraints
> oc version
> Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.18-201909201915+53a7fbd-dirty", GitCommit:"53a7fbd", GitTreeState:"dirty", BuildDate:"2019-09-21T03:15:55Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"darwin/amd64"}
> Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-09-12T23:41:09Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
> {quote}
> answered by saying that one should use the oc binary that matches the cluster in terms of version:
> {quote}
> API's change per each OpenShift version. You should always be sure to match the version of the CLI to the target cluster version (at least to the minor version) and have experienced errors similar to what you are receiving in the past.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JBIDE-26919) OC binary: should warn if 3.x is used for an OpenShift 4 cluster (and vice versa)
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26919?page=com.atlassian.jira.plugi... ]
André Dietisheim updated JBIDE-26919:
-------------------------------------
Description:
OC 4.x does not fully work with an OpenShift 3.x cluster. The opposite is also true:
In a mail on the mailing list on the 17th of October (*[openshift-sme] 4.x oc client is not compatible with OCP 3.11.*)
{quote}
The open shift 4.1 CLI can't get SecurityContextConstraints from 3.11 openshift. Is this expected? or we need to fix this?
$ oc get SecurityContextConstraints restricted -o name
error: attempt to print an ungroupified object: /v1, Kind=SecurityContextConstraints
$ oc version
Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.18-201909201915+53a7fbd-dirty", GitCommit:"53a7fbd", GitTreeState:"dirty", BuildDate:"2019-09-21T03:15:55Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-09-12T23:41:09Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
{quote}
answered by saying that one should use the oc binary that matches the cluster in terms of version:
{quote}
API's change per each OpenShift version. You should always be sure to match the version of the CLI to the target cluster version (at least to the minor version) and have experienced errors similar to what you are receiving in the past.
{quote}
was:
OC 4.x does not fully work with an OpenShift 3.x cluster. The opposite is also true:
In a mail on the mailing list on the 17th of October (*[openshift-sme] 4.x oc client is not compatible with OCP 3.11.*)
{quote}
The open shift 4.1 CLI can't get SecurityContextConstraints from 3.11 openshift. Is this expected? or we need to fix this?
$ oc get SecurityContextConstraints restricted -o name
error: attempt to print an ungroupified object: /v1, Kind=SecurityContextConstraints
oc version
Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.18-201909201915+53a7fbd-dirty", GitCommit:"53a7fbd", GitTreeState:"dirty", BuildDate:"2019-09-21T03:15:55Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-09-12T23:41:09Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
{quote}
answered by saying that one should use the oc binary that matches the cluster in terms of version:
{quote}
API's change per each OpenShift version. You should always be sure to match the version of the CLI to the target cluster version (at least to the minor version) and have experienced errors similar to what you are receiving in the past.
{quote}
> OC binary: should warn if 3.x is used for an OpenShift 4 cluster (and vice versa)
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-26919
> URL: https://issues.jboss.org/browse/JBIDE-26919
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.12.0.Final
> Reporter: André Dietisheim
> Priority: Major
> Labels: oc_binary
> Fix For: 4.14.x
>
>
> OC 4.x does not fully work with an OpenShift 3.x cluster. The opposite is also true:
> In a mail on the mailing list on the 17th of October (*[openshift-sme] 4.x oc client is not compatible with OCP 3.11.*)
> {quote}
> The open shift 4.1 CLI can't get SecurityContextConstraints from 3.11 openshift. Is this expected? or we need to fix this?
> $ oc get SecurityContextConstraints restricted -o name
> error: attempt to print an ungroupified object: /v1, Kind=SecurityContextConstraints
> $ oc version
> Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.18-201909201915+53a7fbd-dirty", GitCommit:"53a7fbd", GitTreeState:"dirty", BuildDate:"2019-09-21T03:15:55Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"darwin/amd64"}
> Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-09-12T23:41:09Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
> {quote}
> answered by saying that one should use the oc binary that matches the cluster in terms of version:
> {quote}
> API's change per each OpenShift version. You should always be sure to match the version of the CLI to the target cluster version (at least to the minor version) and have experienced errors similar to what you are receiving in the past.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JBIDE-26919) OC binary: should warn if 3.x is used for an OpenShift 4 cluster (and vice versa)
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26919?page=com.atlassian.jira.plugi... ]
André Dietisheim updated JBIDE-26919:
-------------------------------------
Labels: oc_binary (was: )
> OC binary: should warn if 3.x is used for an OpenShift 4 cluster (and vice versa)
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-26919
> URL: https://issues.jboss.org/browse/JBIDE-26919
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.12.0.Final
> Reporter: André Dietisheim
> Priority: Major
> Labels: oc_binary
> Fix For: 4.14.x
>
>
> OC 4.x does not fully work with an OpenShift 3.x cluster. The opposite is also true:
> In a mail on the mailing list on the 17th of October (*[openshift-sme] 4.x oc client is not compatible with OCP 3.11.*)
> {quote}
> The open shift 4.1 CLI can't get SecurityContextConstraints from 3.11 openshift. Is this expected? or we need to fix this?
> $ oc get SecurityContextConstraints restricted -o name
> error: attempt to print an ungroupified object: /v1, Kind=SecurityContextConstraints
> $ oc version
> Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.18-201909201915+53a7fbd-dirty", GitCommit:"53a7fbd", GitTreeState:"dirty", BuildDate:"2019-09-21T03:15:55Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"darwin/amd64"}
> Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-09-12T23:41:09Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
> {quote}
> answered by saying that one should use the oc binary that matches the cluster in terms of version:
> {quote}
> API's change per each OpenShift version. You should always be sure to match the version of the CLI to the target cluster version (at least to the minor version) and have experienced errors similar to what you are receiving in the past.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JBIDE-26919) OC binary: should warn if 3.x is used for an OpenShift 4 cluster (and vice versa)
by André Dietisheim (Jira)
André Dietisheim created JBIDE-26919:
----------------------------------------
Summary: OC binary: should warn if 3.x is used for an OpenShift 4 cluster (and vice versa)
Key: JBIDE-26919
URL: https://issues.jboss.org/browse/JBIDE-26919
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.12.0.Final
Reporter: André Dietisheim
OC 4.x does not fully work with an OpenShift 3.x cluster. The opposite is also true:
In a mail on the mailing list on the 17th of October (*[openshift-sme] 4.x oc client is not compatible with OCP 3.11.*)
{quote}
The open shift 4.1 CLI can't get SecurityContextConstraints from 3.11 openshift. Is this expected? or we need to fix this?
# oc get SecurityContextConstraints restricted -o name
error: attempt to print an ungroupified object: /v1, Kind=SecurityContextConstraints
oc version
Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.18-201909201915+53a7fbd-dirty", GitCommit:"53a7fbd", GitTreeState:"dirty", BuildDate:"2019-09-21T03:15:55Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-09-12T23:41:09Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
{quote}
answered by saying that one should use the oc binary that matches the cluster in terms of version:
{quote}
API's change per each OpenShift version. You should always be sure to match the version of the CLI to the target cluster version (at least to the minor version) and have experienced errors similar to what you are receiving in the past.
{quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JBIDE-26919) OC binary: should warn if 3.x is used for an OpenShift 4 cluster (and vice versa)
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26919?page=com.atlassian.jira.plugi... ]
André Dietisheim updated JBIDE-26919:
-------------------------------------
Fix Version/s: 4.14.x
> OC binary: should warn if 3.x is used for an OpenShift 4 cluster (and vice versa)
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-26919
> URL: https://issues.jboss.org/browse/JBIDE-26919
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.12.0.Final
> Reporter: André Dietisheim
> Priority: Major
> Fix For: 4.14.x
>
>
> OC 4.x does not fully work with an OpenShift 3.x cluster. The opposite is also true:
> In a mail on the mailing list on the 17th of October (*[openshift-sme] 4.x oc client is not compatible with OCP 3.11.*)
> {quote}
> The open shift 4.1 CLI can't get SecurityContextConstraints from 3.11 openshift. Is this expected? or we need to fix this?
> # oc get SecurityContextConstraints restricted -o name
> error: attempt to print an ungroupified object: /v1, Kind=SecurityContextConstraints
> oc version
> Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.18-201909201915+53a7fbd-dirty", GitCommit:"53a7fbd", GitTreeState:"dirty", BuildDate:"2019-09-21T03:15:55Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"darwin/amd64"}
> Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-09-12T23:41:09Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
> {quote}
> answered by saying that one should use the oc binary that matches the cluster in terms of version:
> {quote}
> API's change per each OpenShift version. You should always be sure to match the version of the CLI to the target cluster version (at least to the minor version) and have experienced errors similar to what you are receiving in the past.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months