[JBoss JIRA] (JBIDE-22386) Server Editor: Select different service takes too long
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22386?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-22386:
-------------------------------------
Priority: Minor (was: Major)
> Server Editor: Select different service takes too long
> ------------------------------------------------------
>
> Key: JBIDE-22386
> URL: https://issues.jboss.org/browse/JBIDE-22386
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Reporter: Marián Labuda
> Priority: Minor
> Labels: openshift_v3, server_editor
> Fix For: 4.5.x
>
>
> Trying to select a different service for an OpenShift 3 Server Adapter in Server Editor takes too long. After click on the Select... button it takes ~2-3 seconds to open dialog to select a different service. It would be ok to take it that time if there would be some indication that something is happening, but there is no job while "something" is happening.
> Also clicking on the button multiple times (if it is not responsible, I clicked again and again and again), it takes a bit longer and open multiple dialogs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (JBIDE-22756) Connection: various weirdness in token/password implementations
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22756?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-22756:
-------------------------------------
Summary: Connection: various weirdness in token/password implementations (was: Connection: varioius weirdness in token/password )
> Connection: various weirdness in token/password implementations
> ---------------------------------------------------------------
>
> Key: JBIDE-22756
> URL: https://issues.jboss.org/browse/JBIDE-22756
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.4.1.AM2
> Reporter: Andre Dietisheim
> Labels: connection
> Fix For: 4.5.x
>
>
> The lifecycle of the token is rather weird and needs a consistent logic:
> When connecting via wizard the token is set in the connection wizard:
> {code:title=ConnectionWizardPageModel#connect}
> ...
> try {
> IConnection connection = createConnection(connectionFactory, connectionAuthenticationProvider);
> ...
> {code}
> {code:title=ConnectionWizardPageModel#createConnection}
> ...
> if (authProvider != null) {
> authProvider.update(connection); // sets the token
> }
> ...
> {code}
> {code:title=BearTokenAuthenticationProvider#update}
> ...
> connection.setAuthScheme(IAuthorizationContext.AUTHSCHEME_OAUTH);
> connection.setToken(tokenObservable.getValue());
> connection.setRememberToken(rememberTokenObservable.getValue());
> ...
> {code}
> {code:title=Connection#connect}
> if(authorize()) {
> ...
> {code}
> {code:title=Connection#authorized}
> ...
> if (context.isAuthorized()) {
> String username = context.getUser().getName();
> String token = context.getToken();
> updateAuthorized(username, token);
> } else {
> ...
> {code}
> The token is then fetched from client and set to the connection
> {code:title=Connection#updateAuthorized}
> setToken(token);
> ...
> {code}
> and the password is cleared
> {code:Connectoin#savePasswordOrToken}
> } else if (IAuthorizationContext.AUTHSCHEME_OAUTH.equals(getAuthScheme())){
> boolean success = saveOrClear(SECURE_STORAGE_TOKEN_KEY, this.token, isRememberToken());
> if(success) {
> //Avoid second secure storage prompt.
> //Token is stored, password should be cleared.
> clearPassword();
> {code}
> I suspect the aim here is to clear existing password in secure storage if the user is switching password->token based auth (and vice versa)
> The opposite is then not fully congruent. The token is only cleared in secure storage, not in Connection instance var
> {code:title=Connection#savePasswordOrToken}
> if (IAuthorizationContext.AUTHSCHEME_BASIC.equals(getAuthScheme())) {
> boolean success = saveOrClear(SECURE_STORAGE_PASSWORD_KEY, this.password, isRememberPassword());
> if (success) {
> //Avoid second secure storage prompt.
> // Password is stored, token should be cleared.
> clearToken();
> }
> {code:Connection#clearToken}
> // dont clear the token instance var: JBIDE-22594
> setRememberToken(false);
> saveOrClear(SECURE_STORAGE_TOKEN_KEY, null, false);
> {code}
> I suspect that we should only clear in secure storage, not in the Connection instance as we see in JBIDE-22594 (for the opposite case where we dont clear the token in the Connection instance). But then one has to keep in mind that all auth is token based. Even if you auth via password initially, the auth is then switched to token based once the authorization succeeded and we got a token:
> {code:title=Connection#updateAuthorized}
> setToken(token);
> if (IAuthorizationContext.AUTHSCHEME_OAUTH.equalsIgnoreCase(getAuthScheme())) {
> setUsername(username);
> }
> // force auth strategy to token if authorized
> TokenAuthorizationStrategy tokenStrategy = new TokenAuthorizationStrategy(token, username);
> client.setAuthorizationStrategy(tokenStrategy);
> {code}
> Another issue is that the connection and the auth schemeare both stored in different classes. The connection is stored via
> {code:title=ConnectionPersistency#persist}
> preferences.saveConnections(connections.keySet().toArray(new String[] {}));
> ...
> {code}
> while the auth scheme is stored in Connection#saveAuthSchemePreference:
> {code:title=Connection#connect}
> saveAuthSchemePreference();
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (JBIDE-21372) Server Adapter: automatically create a server for new apps
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21372?page=com.atlassian.jira.plugi... ]
Andre Dietisheim resolved JBIDE-21372.
--------------------------------------
Fix Version/s: 4.5.1.AM1
(was: 4.5.x)
Assignee: Andre Dietisheim
Resolution: Duplicate Issue
this was duplicated by JBIDE-24781
> Server Adapter: automatically create a server for new apps
> ----------------------------------------------------------
>
> Key: JBIDE-21372
> URL: https://issues.jboss.org/browse/JBIDE-21372
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift_v3, server_adapter
> Fix For: 4.5.1.AM1
>
>
> Currently one has to create the OpenShift 3 server adapter manually by using the menu File > New > Server > OpenShift 3 (or context menu in the Server view). We should now also create the server adapter when one successfully finishes the new/import application wizard. To achieve this we'll have to include a page in the new/import-application wizard for the required server settings.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (JBIDE-24781) New Application Wizard: Propose to create OpenShift server adapters automatically
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24781?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-24781:
-------------------------------------
Summary: New Application Wizard: Propose to create OpenShift server adapters automatically (was: Propose to create OpenShift server adapters automatically when creating application)
> New Application Wizard: Propose to create OpenShift server adapters automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-24781
> URL: https://issues.jboss.org/browse/JBIDE-24781
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.5.0.AM2
> Reporter: Mickael Istria
> Assignee: Dmitrii Bocharov
> Fix For: 4.5.1.AM2
>
>
> I'm trying to push an Eclipse project as an OpenShift application with Red Hat Developer Studio. When I create the application, the wizard asks me for an Eclipse project. I would expect that a server adapter would be created by default for this project, or that at least creating a server adapter would be proposed automatically (but remain cancellable).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (JBIDE-24439) Block PRs for merge untill the Jenkins build is successful (protected branches)
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24439?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-24439:
------------------------------------------
I'm willing to change my mind and support protected branches for the following reasons:
* PR checks seem to be far more stable lately
* I am quite annoyed with [formatting flaws|JBIDE-24797] in our source but it seems far less critical than broken builds bcs of unvetted merges. Especially since there seems not to be a viable alternative if discipline is lacking.
Still, I believe that we should be careful growing the hurdles for successful merges given how thin our team is stretched.
> Block PRs for merge untill the Jenkins build is successful (protected branches)
> -------------------------------------------------------------------------------
>
> Key: JBIDE-24439
> URL: https://issues.jboss.org/browse/JBIDE-24439
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.5.0.AM1
> Reporter: Nick Boldt
> Assignee: Jeff MAURY
> Fix For: LATER
>
>
> As discussed in this thread [1], we'd like to implement *Protected Branches* and
> *Required Status Checks* [2] for some jbosstools-* projects.
> [1] http://lists.jboss.org/pipermail/jbosstools-dev/2017-May/011948.html
> [2] https://help.github.com/articles/defining-the-mergeability-of-pull-requests/
> We will therefore need to document some requirements in jbosstools-devdoc about how to properly submit PRs when version-bumping is required:
> {quote}Make sure if your PR requires a version bump that the PR includes TWO commits. One for the change, and one for the version bump. That way the pair of commits can be built in the PR build and verify it works, AND when cherry picking the commit across branches, you can pick only the change and not the version-bump commit too.
> {quote}
> And we need to decide if we want to do what Fuse Tools does and require that PRs be reviewed before they can be merged, if we're ready to have that additional overhead on every PR.
> [~jeffmaury] as project lead can you state which project(s) you'd like to see changed in github, and which ones should be changed as such:
> * jbosstools-_____
> ** Protected Branch = master
> ** Required Status Check(s) = ....? (which checks do we want)
> ** PR reviews required = [true/false]
> From that list of projects / requirements, we can then create subtask JIRAs to track the workj & the changes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (JBIDE-24868) Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24868?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-24868 at 8/30/17 8:45 AM:
-------------------------------------------------------------------
* *Router timeout*:
according to the [docs|https://docs.openshift.org/latest/install_config/configuring_routing...] one can override the global timeout for a specific route by annotating it:
{code}
{
...
"kind": "Route",
"metadata": {
"annotations": {
"haproxy.router.openshift.io/timeout": "1h",
{code}
Using oc one has to do
{code}
# oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
{code}
As a non-admin user I can process this change and it seems effective. This is a change that we could apply to the route when debugging, removing it once we stop the debugging.
* *Debug connection timeout*:
Doing a keepalive-ping within the debug connection as arquilian does seems not to be possible for us since we're not in control of the sockets that are used for this sake.
* *lifeness probe":
this seems like an edge case, not critical. I ack though that with a lifeness probe in place debugging gets annoying since the user would have to manually remove it before and add it back in after debugging.
[~jeffmaury], [~rhuss], [~aurelien.pupier] Thoughts?
was (Author: adietish):
* Router timeout:
according to the [docs|https://docs.openshift.org/latest/install_config/configuring_routing...] one can override the global timeout for a specific route by annotating it:
{code}
{
...
"kind": "Route",
"metadata": {
"annotations": {
"haproxy.router.openshift.io/timeout": "1h",
{code}
Using oc one has to do
{code}
# oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
{code}
As a non-admin user I can process this change and it seems effective. This is a change that we could apply to the route when debugging, removing it once we stop the debugging.
* Debug connection timeout:
Doing a keepalive-ping within the debug connection as arquilian does seems not to be possible for us since we're not in control of the sockets that are used for this sake.
* lifenessprobe:
this seems like an edge case, not critical. I ack though that with a lifeness probe in place debugging gets annoying since the user would have to manually remove it before and add it back in after debugging.
[~jeffmaury], [~rhuss], [~aurelien.pupier] Thoughts?
> Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session
> ----------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-24868
> URL: https://issues.jboss.org/browse/JBIDE-24868
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.5.0.Final
> Reporter: Aurélien Pupier
> Assignee: Andre Dietisheim
> Labels: openshift_v3, server_adapter
> Fix For: 4.5.x
>
>
> it will avoid to have "debug connections always killed after 30s staying in a breakpoint"
> see https://twitter.com/ro14nd/status/895886024387067904 for source of suggestion
> k8 documentations on the matter are here: https://kubernetes.io/docs/tasks/configure-pod-container/configure-livene...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (JBIDE-24868) Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24868?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-24868 at 8/30/17 8:45 AM:
-------------------------------------------------------------------
* *Router timeout*:
according to the [docs|https://docs.openshift.org/latest/install_config/configuring_routing...] one can override the global timeout for a specific route by annotating it:
{code}
{
...
"kind": "Route",
"metadata": {
"annotations": {
"haproxy.router.openshift.io/timeout": "1h",
{code}
Using oc one has to do
{code}
# oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
{code}
As a non-admin user I can process this change and it seems effective. This is a change that we could apply to the route when debugging, removing it once we stop the debugging.
* *Debug connection timeout*:
Doing a keepalive-ping within the debug connection as arquilian does seems not to be possible for us since we're not in control of the sockets that are used for this sake.
* *lifeness probe*:
this seems like an edge case, not critical. I ack though that with a lifeness probe in place debugging gets annoying since the user would have to manually remove it before and add it back in after debugging.
[~jeffmaury], [~rhuss], [~aurelien.pupier] Thoughts?
was (Author: adietish):
* *Router timeout*:
according to the [docs|https://docs.openshift.org/latest/install_config/configuring_routing...] one can override the global timeout for a specific route by annotating it:
{code}
{
...
"kind": "Route",
"metadata": {
"annotations": {
"haproxy.router.openshift.io/timeout": "1h",
{code}
Using oc one has to do
{code}
# oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
{code}
As a non-admin user I can process this change and it seems effective. This is a change that we could apply to the route when debugging, removing it once we stop the debugging.
* *Debug connection timeout*:
Doing a keepalive-ping within the debug connection as arquilian does seems not to be possible for us since we're not in control of the sockets that are used for this sake.
* *lifeness probe":
this seems like an edge case, not critical. I ack though that with a lifeness probe in place debugging gets annoying since the user would have to manually remove it before and add it back in after debugging.
[~jeffmaury], [~rhuss], [~aurelien.pupier] Thoughts?
> Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session
> ----------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-24868
> URL: https://issues.jboss.org/browse/JBIDE-24868
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.5.0.Final
> Reporter: Aurélien Pupier
> Assignee: Andre Dietisheim
> Labels: openshift_v3, server_adapter
> Fix For: 4.5.x
>
>
> it will avoid to have "debug connections always killed after 30s staying in a breakpoint"
> see https://twitter.com/ro14nd/status/895886024387067904 for source of suggestion
> k8 documentations on the matter are here: https://kubernetes.io/docs/tasks/configure-pod-container/configure-livene...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (JBIDE-24868) Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24868?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-24868 at 8/30/17 8:45 AM:
-------------------------------------------------------------------
* *Router timeout*:
according to the [docs|https://docs.openshift.org/latest/install_config/configuring_routing...] one can override the global timeout for a specific route by annotating it:
{code}
{
...
"kind": "Route",
"metadata": {
"annotations": {
"haproxy.router.openshift.io/timeout": "1h",
{code}
Using oc one has to do
{code}
# oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
{code}
As a non-admin user I can process this change and it seems effective. This is a change that we could apply to the route when debugging, removing it once we stop the debugging.
* *Debug connection timeout*:
Doing a keepalive-ping within the debug connection as arquilian does seems not to be possible for us since we're not in control of the sockets that are used for this sake.
* *lifeness probe*:
this seems like an edge case, not critical. I ack though that with a lifeness probe in place debugging gets annoying since the user would have to manually remove it before and add it back in after debugging.
[~jeffmaury], [~rhuss], [~aurelien.pupier] Thoughts?
was (Author: adietish):
* *Router timeout*:
according to the [docs|https://docs.openshift.org/latest/install_config/configuring_routing...] one can override the global timeout for a specific route by annotating it:
{code}
{
...
"kind": "Route",
"metadata": {
"annotations": {
"haproxy.router.openshift.io/timeout": "1h",
{code}
Using oc one has to do
{code}
# oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
{code}
As a non-admin user I can process this change and it seems effective. This is a change that we could apply to the route when debugging, removing it once we stop the debugging.
* *Debug connection timeout*:
Doing a keepalive-ping within the debug connection as arquilian does seems not to be possible for us since we're not in control of the sockets that are used for this sake.
* *lifeness probe*:
this seems like an edge case, not critical. I ack though that with a lifeness probe in place debugging gets annoying since the user would have to manually remove it before and add it back in after debugging.
[~jeffmaury], [~rhuss], [~aurelien.pupier] Thoughts?
> Server adapter: Switch off pod livenessProbe.periodSecond property and router timeout during debug session
> ----------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-24868
> URL: https://issues.jboss.org/browse/JBIDE-24868
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.5.0.Final
> Reporter: Aurélien Pupier
> Assignee: Andre Dietisheim
> Labels: openshift_v3, server_adapter
> Fix For: 4.5.x
>
>
> it will avoid to have "debug connections always killed after 30s staying in a breakpoint"
> see https://twitter.com/ro14nd/status/895886024387067904 for source of suggestion
> k8 documentations on the matter are here: https://kubernetes.io/docs/tasks/configure-pod-container/configure-livene...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months