Bug 1575979 - Provide solution for ovirt-imageio after IP/hostname change of engine host
Summary: Provide solution for ovirt-imageio after IP/hostname change of engine host
Keywords:
Status: CLOSED DUPLICATE of bug 1637809
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Tools.Rename
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
medium
medium vote
Target Milestone: ovirt-4.3.0
: ---
Assignee: Yedidyah Bar David
QA Contact: Jiri Belka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-08 13:21 UTC by Daniel Erez
Modified: 2018-10-10 10:00 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-10 10:00:58 UTC
oVirt Team: Integration
rule-engine: ovirt-4.3+


Attachments (Terms of Use)

Description Daniel Erez 2018-05-08 13:21:44 UTC
Description of problem:

ovirt-engine-rename does not take care about ovirt-imageio in 4.2.

The following key/certs should be regenerated:
/etc/pki/ovirt-engine/keys/imageio-proxy.p12
/etc/pki/ovirt-engine/keys/imageio-proxy.key.nopass
/etc/pki/ovirt-engine/certs/imageio-proxy.cer

Comment 1 Yaniv Kaul 2018-05-14 15:58:35 UTC
Severity...?

Comment 2 Daniel Erez 2018-05-14 16:03:51 UTC
(In reply to Yaniv Kaul from comment #1)
> Severity...?

Changed to medium as bug 1501798

Comment 3 Yedidyah Bar David 2018-10-10 07:04:50 UTC
Now spent some time on this, and filed bug 1637809, and I suggest to close current as duplicate of it. Makes sense?

Comment 4 Yedidyah Bar David 2018-10-10 07:07:04 UTC
To clarify: this isn't enough for current bug. The rest should be handled by bug 1519194.

Comment 5 Sandro Bonazzola 2018-10-10 07:15:22 UTC
Not a blocker for 4.2.7, moving to 4.3.0

Comment 6 Daniel Erez 2018-10-10 08:49:28 UTC
(In reply to Yedidyah Bar David from comment #3)
> Now spent some time on this, and filed bug 1637809, and I suggest to close
> current as duplicate of it. Makes sense?

I'm actually still not sure we can assume that the webadmin is the only client for imageio-proxy. We might want to use it in other projects (not oVirt necessarily) that aren't hosted on apache.

Comment 7 Yedidyah Bar David 2018-10-10 09:06:18 UTC
(In reply to Daniel Erez from comment #6)
> I'm actually still not sure we can assume that the webadmin is the only
> client for imageio-proxy. We might want to use it in other projects (not
> oVirt necessarily) that aren't hosted on apache.

Are there other existing clients?

E.g. is the imageio-daemon connecting to it? engine? vdsm? SDK?

Of course we can change the proxy, its configuration, setup, etc., in the future, as new needs arise.

Comment 8 Daniel Erez 2018-10-10 09:11:49 UTC
(In reply to Yedidyah Bar David from comment #7)
> (In reply to Daniel Erez from comment #6)
> > I'm actually still not sure we can assume that the webadmin is the only
> > client for imageio-proxy. We might want to use it in other projects (not
> > oVirt necessarily) that aren't hosted on apache.
> 
> Are there other existing clients?
> 
> E.g. is the imageio-daemon connecting to it? engine? vdsm? SDK?

We actually do support using the SDK for upload/download.
We have an example for it in python sdk:
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_disk.py

> 
> Of course we can change the proxy, its configuration, setup, etc., in the
> future, as new needs arise.

Comment 9 Yedidyah Bar David 2018-10-10 09:35:04 UTC
(In reply to Daniel Erez from comment #8)
> (In reply to Yedidyah Bar David from comment #7)
> > (In reply to Daniel Erez from comment #6)
> > > I'm actually still not sure we can assume that the webadmin is the only
> > > client for imageio-proxy. We might want to use it in other projects (not
> > > oVirt necessarily) that aren't hosted on apache.
> > 
> > Are there other existing clients?
> > 
> > E.g. is the imageio-daemon connecting to it? engine? vdsm? SDK?
> 
> We actually do support using the SDK for upload/download.
> We have an example for it in python sdk:
> https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/
> upload_disk.py

Thanks, this is exactly what I was looking for.

The SDK examples dir and README is a set of very loosly-coupled scripts, not a single application, so you can assume that any reasonable user will be able to adapt/configure/etc based on specific needs. However, as-is, above example is actually yet another reason to use apache's pki, not to have separate pki. As-is, the examples assume a single 'ca.pem' file for everything, and use it both to access the apache httpd proxying to the engine and the ovirt-imageio-proxy. So if the user changed httpd's cert to a 3rd-party-signed-one, connecting with it to imageio-proxy will fail, unless it is configured to use the 3rd-party CA.

So?

Comment 10 Daniel Erez 2018-10-10 09:41:32 UTC
(In reply to Yedidyah Bar David from comment #9)
> (In reply to Daniel Erez from comment #8)
> > (In reply to Yedidyah Bar David from comment #7)
> > > (In reply to Daniel Erez from comment #6)
> > > > I'm actually still not sure we can assume that the webadmin is the only
> > > > client for imageio-proxy. We might want to use it in other projects (not
> > > > oVirt necessarily) that aren't hosted on apache.
> > > 
> > > Are there other existing clients?
> > > 
> > > E.g. is the imageio-daemon connecting to it? engine? vdsm? SDK?
> > 
> > We actually do support using the SDK for upload/download.
> > We have an example for it in python sdk:
> > https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/
> > upload_disk.py
> 
> Thanks, this is exactly what I was looking for.
> 
> The SDK examples dir and README is a set of very loosly-coupled scripts, not
> a single application, so you can assume that any reasonable user will be
> able to adapt/configure/etc based on specific needs. However, as-is, above
> example is actually yet another reason to use apache's pki, not to have
> separate pki. As-is, the examples assume a single 'ca.pem' file for
> everything, and use it both to access the apache httpd proxying to the
> engine and the ovirt-imageio-proxy. So if the user changed httpd's cert to a
> 3rd-party-signed-one, connecting with it to imageio-proxy will fail, unless
> it is configured to use the 3rd-party CA.
> 
> So?

I'm not sure I understand the implications. Could we easily change it in the future if we want to use the proxy in other projects (e.g. kubevirt).
@Nir/Yaniv - what do you think?

Comment 11 Nir Soffer 2018-10-10 09:47:02 UTC
I don't see any reason to have proxy pki. On engine we should use apache pki, and on the hosts, vdsm pki.

This does not lomit usage in other projects. Providing and configuring pki is the only requirement to use the proxy or daemon (which will be the same process in the future).

Comment 12 Yedidyah Bar David 2018-10-10 09:49:42 UTC
(In reply to Daniel Erez from comment #10)
> I'm not sure I understand the implications. Could we easily change it in the
> future if we want to use the proxy in other projects (e.g. kubevirt).
> @Nir/Yaniv - what do you think?

If you want to make sure you keep the proxy itself independent and reusable, that's easy - refer as little as possible, or none at all, to oVirt-related stuff. You already do that, at least as far as https is concerned, by having a separate conf file and allowing setting pki stuff there (instead of e.g. directly writing the full path to the engine's ca cert right in the code).

The setup plugin of it, however, is a different story. It's very tightly-coupled to engine-setup. Making it run and properly configure the proxy on a separate machine, either to work with an existing oVirt engine or with some other unrelated project, will require more work.

Comment 13 Daniel Erez 2018-10-10 10:00:58 UTC
(In reply to Yedidyah Bar David from comment #12)
> (In reply to Daniel Erez from comment #10)
> > I'm not sure I understand the implications. Could we easily change it in the
> > future if we want to use the proxy in other projects (e.g. kubevirt).
> > @Nir/Yaniv - what do you think?
> 
> If you want to make sure you keep the proxy itself independent and reusable,
> that's easy - refer as little as possible, or none at all, to oVirt-related
> stuff. You already do that, at least as far as https is concerned, by having
> a separate conf file and allowing setting pki stuff there (instead of e.g.
> directly writing the full path to the engine's ca cert right in the code).
> 
> The setup plugin of it, however, is a different story. It's very
> tightly-coupled to engine-setup. Making it run and properly configure the
> proxy on a separate machine, either to work with an existing oVirt engine or
> with some other unrelated project, will require more work.

ok, makes sense. closing as duplicate of 1637809 then.
ovirt-engine-rename fix is covered by bug 1519194.

*** This bug has been marked as a duplicate of bug 1637809 ***


Note You need to log in before you can comment on or make changes to this bug.