Split up separate components into seperate Images

[MaxRink]

Currently everything is bundled into one image, this is usually not good practice as its brings quite a few problems with it, like longer pull times, not being able to do granular updates and such. It also adds complexity to the image build.
I would see a few components that should probably be their own images:

• MariaDB: unsure if not just using official images is the better option here ( or bitnami charts if running on k8s)
• webserver
• ironic
• dns/dhcp

Please correct me if im wrong with my assumption

[dtantsur]

I full agree with this. I know that @elfosardo was going to look in the same direction, please sync with him before taking any drastic actions. Some comments:

MariaDB: unsure if not just using official images is the better option here

I'd like to use official images if possible. Maybe not straight away. If we need to start with our images - let's do it.

dns/dhcp

A small correction: it's TFTP+DHCP (no DNS, even though we use dnsmasq as the implementation).

webserver

This one is going to be quite tricky. We run ironic/inspector API as WSGI applications behind httpd. We could of course split all these, but I don't feel well running 3 (?) httpd instances just for Metal3.

[MaxRink]

This one is going to be quite tricky. We run ironic/inspector API as WSGI applications behind httpd. We could of course split all these, but I don't feel well running 3 (?) httpd instances just for Metal3.

We currently handle that by having ironic in cluster and tying everything together using nginx Ingress, but doing that statically in an docker environment should also be possible. You would still need a seperate instance for wsgi tho, but with less config

[dtantsur]

How exactly does it look? I see these possibilities:

1. nginx (TLS termination) -> (uwsgi protocol) -> uwsgi (with ironic) -> ... (JSON RPC)
2. nginx/httpd (TLS termination) -> (http) -> uwsgi/gunicorn (with ironic)/ironic-api -> ...

Do you mean option 2?

[MaxRink]

yes, we currently run option 2

[dtantsur]

@elfosardo I suspect it may cause issues for us downstream because we have neither uwsgi nor gunicorn?

[elfosardo]

I just have started scratching the surface to finally split the different services in their own images, MariaDB would definitely be a good start point, the others are a bit tricky, especially the httpd service.
As @dtantsur pointed out we may have some issues downstream with actually either approaches.

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[elfosardo]

we're currently in the process of separating mariadb #339

[elfosardo]

/remove-lifecycle stale

[Rozzii]

/kind design
/kind feature
/triage accepted

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[Rozzii]

/remove-lifecycle stale

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[Rozzii]

/lifecycle frozen

[matthewei]

what progerss about this PR?

[Rozzii]

@matthewei this was discussed a few times, the situation is more complicated it will be affected by both what @mboukhalfa is doing in relation to metal3-io/baremetal-operator#1739 and related to the work that is being done related to the ironic-standalone-operator. So for now the AFAIK separating these images is not a priority until the way(s) of Ironic deployment are not finalized.

[matthewei]

@Rozzii Many thanks! I see.