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
Severity...?
(In reply to Yaniv Kaul from comment #1) > Severity...? Changed to medium as bug 1501798
Now spent some time on this, and filed bug 1637809, and I suggest to close current as duplicate of it. Makes sense?
To clarify: this isn't enough for current bug. The rest should be handled by bug 1519194.
Not a blocker for 4.2.7, moving to 4.3.0
(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.
(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.
(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.
(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?
(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?
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).
(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.
(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 ***