[JBoss JIRA] (JBIDE-26869) CRC server adapter: OpenShift connection that is created is unusable at times
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26869?page=com.atlassian.jira.plugi... ]
André Dietisheim updated JBIDE-26869:
-------------------------------------
Attachment: start-crc-error-openshift-conn.mp4
> CRC server adapter: OpenShift connection that is created is unusable at times
> -----------------------------------------------------------------------------
>
> Key: JBIDE-26869
> URL: https://issues.jboss.org/browse/JBIDE-26869
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.13.0.AM1
> Reporter: André Dietisheim
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.13.0.Final
>
> Attachments: crc-connection-error.mp4, start-crc-error-openshift-conn.mp4
>
>
> *Steps* - not reproducibe at 100%, happens from time to time:
> # ASSERT: have ~/.crc folder killed
> # EXEC: create new CRC server adapter & Start it
> # ASSERT: OpenShift connection is created
> *Result:*
> Connection fails to authorize, reports that it cannot access resources using system:anonymous. Refreshing the connection doesn't help, so it's apparently not a timing issue (ex. creating the connection before the cluster is fully up and running)
> {code}
> com.openshift.restclient.authorization.ResourceForbiddenException: forbidden: User "system:anonymous" cannot get path "/oauth/authorize" forbidden: User "system:anonymous" cannot get path "/oauth/authorize"
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:111)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:66)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.tryAuth(OpenShiftAuthenticator.java:109)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.authenticate(OpenShiftAuthenticator.java:62)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.followUpRequest(RetryAndFollowUpInterceptor.kt:213)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:102)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:55)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.DefaultClient.request(DefaultClient.java:315)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:307)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:275)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:243)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:226)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:423)
> at com.openshift.internal.restclient.authorization.AuthorizationContext.isAuthorized(AuthorizationContext.java:63)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:237)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:226)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureOpenshift(ConfigureCRCFrameworksListener.java:102)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureFrameworks(ConfigureCRCFrameworksListener.java:73)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener$1.run(ConfigureCRCFrameworksListener.java:66)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JBIDE-26878) Improve validation of CRC Binary and Pull Secret File in CRC Server Wizard and Editor
by Ondrej Dockal (Jira)
[ https://issues.jboss.org/browse/JBIDE-26878?page=com.atlassian.jira.plugi... ]
Ondrej Dockal updated JBIDE-26878:
----------------------------------
Description:
I can image improved validation of Pull secret file that is available in CRC Server wizard and Server Editor.
Missing validation of CRC Binary:
* Please select a valid CRC Binary, which would check that file is really a crc binary - we used similar validation for minishift where (I f I recall it right) we checked in process the output from `minishift version` or `minishift status` command. Something similar I can imagine to be used for crc. Since `crc status` could return different outputs, version seems to be better option. I would agree to postpone this validation once the crc is GA. then please ignore this and create new jira issue. Thanks!
I can imagine all of those validation in action for pull secret path input:
* Path does not exist
* Is not a file
* Is not executable (user cannot read the file)
* Is not a valid Pull secret file (probably check for if file's content is a valid json and/or we can probably validate if json's first object is "auths"? This would be nice, but simple json validation seems fine)
I believe that last three points could be validated at once by reading the file's content and creating valid json object, or else showing the error that given path is no valid a secret file. It's up implementation, right?
was:
I can image improved validation of Pull secret file that is available in CRC Server wizard and Server Editor.
I can imagine all of those validation in action for pull secret path input:
* Path does not exist
* Is not a file
* Is not executable (user cannot read the file)
* Is not a valid Pull secret file (probably check for if file's content is a valid json and/or we can probably validate if json's first object is "auths"? This would be nice, but simple json validation seems fine)
I believe that last three points could be validated at once by reading the file's content and creating valid json object, or else showing the error that given path is no valid a secret file. It's up implementation, right?
> Improve validation of CRC Binary and Pull Secret File in CRC Server Wizard and Editor
> -------------------------------------------------------------------------------------
>
> Key: JBIDE-26878
> URL: https://issues.jboss.org/browse/JBIDE-26878
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: cdk
> Affects Versions: 4.13.0.Final
> Reporter: Ondrej Dockal
> Assignee: Rob Stryker
> Priority: Major
> Fix For: 4.13.0.Final
>
>
> I can image improved validation of Pull secret file that is available in CRC Server wizard and Server Editor.
> Missing validation of CRC Binary:
> * Please select a valid CRC Binary, which would check that file is really a crc binary - we used similar validation for minishift where (I f I recall it right) we checked in process the output from `minishift version` or `minishift status` command. Something similar I can imagine to be used for crc. Since `crc status` could return different outputs, version seems to be better option. I would agree to postpone this validation once the crc is GA. then please ignore this and create new jira issue. Thanks!
> I can imagine all of those validation in action for pull secret path input:
> * Path does not exist
> * Is not a file
> * Is not executable (user cannot read the file)
> * Is not a valid Pull secret file (probably check for if file's content is a valid json and/or we can probably validate if json's first object is "auths"? This would be nice, but simple json validation seems fine)
> I believe that last three points could be validated at once by reading the file's content and creating valid json object, or else showing the error that given path is no valid a secret file. It's up implementation, right?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JBIDE-26878) Improve validation of CRC Binary and Pull Secret File in CRC Server Wizard and Editor
by Ondrej Dockal (Jira)
[ https://issues.jboss.org/browse/JBIDE-26878?page=com.atlassian.jira.plugi... ]
Ondrej Dockal updated JBIDE-26878:
----------------------------------
Summary: Improve validation of CRC Binary and Pull Secret File in CRC Server Wizard and Editor (was: Improve validation of Pull Secret File in CRC Server Wizard and Editor)
> Improve validation of CRC Binary and Pull Secret File in CRC Server Wizard and Editor
> -------------------------------------------------------------------------------------
>
> Key: JBIDE-26878
> URL: https://issues.jboss.org/browse/JBIDE-26878
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: cdk
> Affects Versions: 4.13.0.Final
> Reporter: Ondrej Dockal
> Assignee: Rob Stryker
> Priority: Major
> Fix For: 4.13.0.Final
>
>
> I can image improved validation of Pull secret file that is available in CRC Server wizard and Server Editor.
> I can imagine all of those validation in action for pull secret path input:
> * Path does not exist
> * Is not a file
> * Is not executable (user cannot read the file)
> * Is not a valid Pull secret file (probably check for if file's content is a valid json and/or we can probably validate if json's first object is "auths"? This would be nice, but simple json validation seems fine)
> I believe that last three points could be validated at once by reading the file's content and creating valid json object, or else showing the error that given path is no valid a secret file. It's up implementation, right?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JBIDE-26878) Improve validation of Pull Secret File in CRC Server Wizard and Editor
by Ondrej Dockal (Jira)
Ondrej Dockal created JBIDE-26878:
-------------------------------------
Summary: Improve validation of Pull Secret File in CRC Server Wizard and Editor
Key: JBIDE-26878
URL: https://issues.jboss.org/browse/JBIDE-26878
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: cdk
Affects Versions: 4.13.0.Final
Reporter: Ondrej Dockal
Assignee: Rob Stryker
Fix For: 4.13.0.Final
I can image improved validation of Pull secret file that is available in CRC Server wizard and Server Editor.
I can imagine all of those validation in action for pull secret path input:
* Path does not exist
* Is not a file
* Is not executable (user cannot read the file)
* Is not a valid Pull secret file (probably check for if file's content is a valid json and/or we can probably validate if json's first object is "auths"? This would be nice, but simple json validation seems fine)
I believe that last three points could be validated at once by reading the file's content and creating valid json object, or else showing the error that given path is no valid a secret file. It's up implementation, right?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JBDS-4798) Warning: Illegal reflective access operation has occured
by Ondrej Dockal (Jira)
Ondrej Dockal created JBDS-4798:
-----------------------------------
Summary: Warning: Illegal reflective access operation has occured
Key: JBDS-4798
URL: https://issues.jboss.org/browse/JBDS-4798
Project: Red Hat CodeReady Studio (devstudio)
Issue Type: Bug
Components: installer
Affects Versions: 12.13.0.AM1
Reporter: Ondrej Dockal
Assignee: Jeff MAURY
Fix For: 12.x
When running the installer jar I got warning when on java 11.
{code}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.izforge.izpack.installer.InstallerFrame (file:/home/odockal/Downloads/codereadystudio-12.13.0.GA-v20190929-1916-B5040-installer-standalone.jar) to field sun.awt.X11.XToolkit.awtAppClassName
WARNING: Please consider reporting this to the maintainers of com.izforge.izpack.installer.InstallerFrame
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JBIDE-26868) Connection wizard: errors when login to https://api.openshift4-crs.crs.codereadyqe.com
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26868?page=com.atlassian.jira.plugi... ]
André Dietisheim commented on JBIDE-26868:
------------------------------------------
According to [~jkopriva] this is an issue of configuration in the cluster. There thus isn't anything that we can fix in Eclipse/openshift-restclient-java. Postponing to after 4.13.Final so that josef can fix those and test again.
> Connection wizard: errors when login to https://api.openshift4-crs.crs.codereadyqe.com
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-26868
> URL: https://issues.jboss.org/browse/JBIDE-26868
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: integration-tests, openshift
> Affects Versions: 4.13.0.AM1
> Environment: https://console-openshift-console.apps.openshift4-crs.crs.codereadyqe.com/
> (created with openshift installer on openstack)
> Reporter: André Dietisheim
> Assignee: Josef Kopriva
> Priority: Major
> Labels: connection_wizard
> Fix For: 4.14.x
>
>
> Steps:
> # EXEC: (VPN required) go to https://console-openshift-console.apps.openshift4-crs.crs.codereadyqe.com/ and login using: htpasswd > developer/developer
> # EXEC: once logged in, pick "Copy Login Command" from the menu in the top right corner - you'll have to log in again and hit "Display Token". You'll get a command displayed that you'll have to copy:
> {code}
> oc login --token=XXXXXX --server=https://api.openshift4-crs.crs.codereadyqe.com:6443
> {code}
> # EXEC: open connection wizard, hit "Paste Login Command" button & pick "Finish"
> Result:
> {code}
> com.openshift.restclient.authorization.ResourceForbiddenException: forbidden: User "system:anonymous" cannot get path "/apis" forbidden: User "system:anonymous" cannot get path "/apis"
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:111)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:66)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.ApiTypeMapper.request(ApiTypeMapper.java:265)
> at com.openshift.internal.restclient.ApiTypeMapper.readEndpoint(ApiTypeMapper.java:257)
> at com.openshift.internal.restclient.ApiTypeMapper.getApiGroups(ApiTypeMapper.java:220)
> at com.openshift.internal.restclient.ApiTypeMapper.init(ApiTypeMapper.java:155)
> at com.openshift.internal.restclient.ApiTypeMapper.isSupported(ApiTypeMapper.java:84)
> at com.openshift.internal.restclient.URLBuilder.buildWithNamespaceInPath(URLBuilder.java:148)
> at com.openshift.internal.restclient.URLBuilder.build(URLBuilder.java:135)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:301)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:275)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:243)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:226)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:423)
> at com.openshift.internal.restclient.authorization.AuthorizationContext.isAuthorized(AuthorizationContext.java:63)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:237)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:226)
> at org.jboss.tools.openshift.internal.common.ui.connection.ConnectionWizardPageModel.connect(ConnectionWizardPageModel.java:300)
> at org.jboss.tools.openshift.internal.common.ui.connection.ConnectionWizardPage$ConnectJob.doRun(ConnectionWizardPage.java:434)
> at org.jboss.tools.openshift.internal.common.core.job.AbstractDelegatingMonitorJob.run(AbstractDelegatingMonitorJob.java:37)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JBIDE-26876) Explorer: ctx menu "Show In" > "Web Console" for CRC fails with "unauthorized"
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26876?page=com.atlassian.jira.plugi... ]
André Dietisheim updated JBIDE-26876:
-------------------------------------
Summary: Explorer: ctx menu "Show In" > "Web Console" for CRC fails with "unauthorized" (was: Explorer: Show In > Web Console for CRC fails with "unauthorized")
> Explorer: ctx menu "Show In" > "Web Console" for CRC fails with "unauthorized"
> ------------------------------------------------------------------------------
>
> Key: JBIDE-26876
> URL: https://issues.jboss.org/browse/JBIDE-26876
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.13.0.AM1
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Major
> Fix For: 4.13.0.Final
>
>
> Steps:
> # ASSERT: have a connection to a running crc instance
> # EXEC: in Explorer: select the connection and pick *Show In > Web Console*
> Result:
> Browser is opened to https://api.crc.testing:6443/console. Browser then displays:
> {code}
> {
> "kind": "Status",
> "apiVersion": "v1",
> "metadata": {
>
> },
> "status": "Failure",
> "message": "forbidden: User \"system:anonymous\" cannot get path \"/console\"",
> "reason": "Forbidden",
> "details": {
>
> },
> "code": 403
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month