[JBoss JIRA] (JBIDE-22626) Updating deployed docker image on OpenShift does not work
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22626?page=com.atlassian.jira.plugi... ]
Jeff Cantrill commented on JBIDE-22626:
---------------------------------------
First comment is that you can not change from 'refresh' to 'updateResource' unless you are in fact 'updating'. Without looking at the code more in depth, I presume the path that is 'refresh'ing would return the latest version of the resource to later be updated.
DC's with configchange triggers will basically over-write the value in the container block based on what the trigger says; the container.image field is essentially ignored. I think you should be updating this: https://gist.github.com/bdshadow/49acf54196091bb772f2a368fd57348b#file-re...
I'm curious how you got a second container in the spec which essentially is a duplicate. This could be an issue in the rest-client we need to address.
If any of these changes are difficult because of the restclient, that means we need to update the restclient.
> Updating deployed docker image on OpenShift does not work
> ---------------------------------------------------------
>
> Key: JBIDE-22626
> URL: https://issues.jboss.org/browse/JBIDE-22626
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Final
> Reporter: Marián Labuda
> Assignee: Dmitrii Bocharov
> Priority: Critical
> Labels: docker, openshift_v3
> Fix For: 4.4.1.Final
>
>
> In JBIDE-22515 was fixed use case when user have an image with specific tag. That works now ok.
> But if user deploys image with tag e.g. :0.8 to OpenShift, resources are created for this specific tag. When I am trying to Deploy to OS image with tag :0.9 afterwards, everything finish without an error. No new resources are created, but no existing resources are modified to contain this new image. Deployment config still contains tag :0.8 and thus new deployment is not done.
> Basically we need to modify deployment config in such cases to contains newer tag and let OpenShift do all magic and redeploy it.
> In order to add this version tag after semicolon, right-click on the image -> Add tag -> Re-type namespace/imagename + add ":0.8" e.g.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22626) Updating deployed docker image on OpenShift does not work
by Dmitrii Bocharov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22626?page=com.atlassian.jira.plugi... ]
Dmitrii Bocharov commented on JBIDE-22626:
------------------------------------------
[~adietish], [~xcoulon], [~jcantrill] need your help with the task, as i'm not quite confident in this Deployment stuff and what is happening.
I saw in [Jeff's fix|https://github.com/jbosstools/jbosstools-openshift/pull/1148] that he firstly tries to get ImageStream from connection and then if there is no one, create it.
I've implemented the same logic for other resources: SERVICE, ROUTE and DEPLOYMENT_CONFIG, e.g.:
{code:java}
private IService stubService(IResourceFactory factory, String name, String selectorKey, String selectorValue) {
IService service = findServiceFor(parameters.getProject().getName());
if (service == null) {
service = factory.stub(ResourceKind.SERVICE, name, parameters.getProject().getName());
}
service.setPorts(parameters.getServicePorts());
service.setSelector(selectorKey, selectorValue);
return service;
}
{code}
Also i changed [here|https://github.com/jbosstools/jbosstools-openshift/blob/d4565ac20d6e...] from just retrieving\refreshing resource to _connection.updateResource(resource)_;
If there is no any of the resources - [i create it|https://github.com/jbosstools/jbosstools-openshift/blob/cf442398a36631...].
However, i have problem with updating DeploymentConfig.
Here is the DC i have before update: https://gist.github.com/bdshadow/271754b11a9f5945de1a107390bcc5ec
Here is my request for update: https://gist.github.com/bdshadow/49acf54196091bb772f2a368fd57348b
request: Request{method=PUT, url=https://10.1.2.2:8443/oapi/v1/namespaces/sample-project/deploymentconfigs/aloha, tag=null}
But i get:
{code:json}
!MESSAGE Error creating resource: {
"kind" : "Status",
"apiVersion" : "v1",
"metadata" : {},
"status" : "Failure",
"message" : "DeploymentConfig \"aloha\" is invalid: spec.template.spec.containers[1].name: Duplicate value: \"aloha\"",
"reason" : "Invalid",
"details" : {
"name" : "aloha",
"kind" : "DeploymentConfig",
"causes" : [{
"reason" : "FieldValueDuplicate",
"message" : "Duplicate value: \"aloha\"",
"field" : "spec.template.spec.containers[1].name"
}]
},
"code" : 422
}
{code}
I don't have such an error for ROUTE or IMAGE_STREAM. I can even see in Web Console that a new tag appeared for the Image Stream.
I understand the message of the error. But how can i then update the DeploymentConfig to point at image with new tag? What should request look like? Is DafaultClient update suitable for this?
We also figured out with [~jeffmaury] that we can update the lines:
{code:java}
containers:
-
name: aloha
image: 'foo/aloha:1'
ports:
{code}
to have 'foo/aloha:2' just simply through Web Console or even through CLI without any problem, but only when image isn't pushed to registry. When it is, the DC looks like:
{code:java}
-
name: aloha
image: '172.30.189.18:5000/sample-project/aloha@sha256:5d4937328d7801654118efc25500a78a0901b161267e3e08c54e7...'
ports:
{code}
and you can't change this link with sha to another image. Web Console lets you do this, but if you press Edit YAML again after - you'll see the same line.
Finally, if you still read =) How can i update the DeploymentConfig and what am i doing wrong? Is it possible at all to update it from client and using our openshift-restclient?
I'll be very grateful for any help, as i'm really confused about this JIRA
> Updating deployed docker image on OpenShift does not work
> ---------------------------------------------------------
>
> Key: JBIDE-22626
> URL: https://issues.jboss.org/browse/JBIDE-22626
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Final
> Reporter: Marián Labuda
> Assignee: Dmitrii Bocharov
> Priority: Critical
> Labels: docker, openshift_v3
> Fix For: 4.4.1.Final
>
>
> In JBIDE-22515 was fixed use case when user have an image with specific tag. That works now ok.
> But if user deploys image with tag e.g. :0.8 to OpenShift, resources are created for this specific tag. When I am trying to Deploy to OS image with tag :0.9 afterwards, everything finish without an error. No new resources are created, but no existing resources are modified to contain this new image. Deployment config still contains tag :0.8 and thus new deployment is not done.
> Basically we need to modify deployment config in such cases to contains newer tag and let OpenShift do all magic and redeploy it.
> In order to add this version tag after semicolon, right-click on the image -> Add tag -> Re-type namespace/imagename + add ":0.8" e.g.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBDS-3627) Installer needs to help move past lack of t/c signing
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3627?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3627:
--------------------------------
Sprint: devex #120 September 2016
> Installer needs to help move past lack of t/c signing
> -----------------------------------------------------
>
> Key: JBDS-3627
> URL: https://issues.jboss.org/browse/JBDS-3627
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Enhancement
> Components: platform-installer
> Reporter: Joshua Wilson
> Assignee: Denis Golovin
> Labels: havoc
> Fix For: 10.2.0.AM1
>
> Attachments: Installer-not-signed-tc.PNG
>
>
> DevSuite installer uses "REST services in JBoss Download Manager" explained here https://mojo.redhat.com/docs/DOC-940689.
> DevSuite Intsaller follows the explanation for tc-accepted entry point [code is here|https://github.com/redhat-developer-tooling/developer-platform-insta...]. It uses file from previous CDK release (published in cdn and available through download manager) to do verification:
> 1. that provided credentials are valid;
> 2. that required T&C's are signed.
> There are two major use cases for developers installing DevSuite using Installer:
> 1. Direct download - when developer sign in to developers.redhat.com and download installer himeslf;
> 2. Shared installer - when someone share installer with developers without account.
> There two kind of users involved in those scenarios above:
> 1. New users that must go through registration process;
> 2. Registered users.
> *Direct download*
> For new ones registration process is really simple now. After creating RHD account and downloading installer there is no additional steps to get through installation.
> For already registered users there could be problems related to T&C's and authentication reported here https://issues.jboss.org/browse/RHDENG-579.
> So far there are two kind of problems:
> 1. Users can login and download DevSuite installer, but cannot use the same credentials to install;
> 2. Users that can login in to developers.redhat.com and get request to sign additional T&C's but credentials for the same user in DevSuite Installer reported as invalid when REST tc-accepted entry point is used
> *Shared Download*
> In this scenario new users without account can press Register link, then go through registration process in browser return back to installer and use new account credentials for installation.
> Registered users could need to sign additional T&C's if missing and would be good to show external link to do so. Current entry point tc-accepted does not provide any hints where missing T&C's could be signed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months