[placement][ptg] Containers/dockerfiles
From etherpad [1]:
* Some talk in the past of moving https://github.com/cdent/placedock into placement but not sure * Another option is [to] trigger container build with each merge I wrote this one, so I guess I should expand on it a bit. Basically, placedock is a Dockerfile for placement that strives to be small but configurable. The same repo also contains instructions (and YAML) for using the container in kubernetes, and provides a helm chart that uses the generated image. Each of those three things is done in a way where many of the choices are made for you in favor of being light and simple. In things like Kolla, openstack-helm, and other containerizing setups some of those choices are left as options, making the build and run infrastructure more complex. The result with placedock is a tiny service that scales horizontally really well. In the past there's been talk of including some of that stuff in the placement repo itself as a sort of "hey look, here's one way to do it". If we did that, which stuff? Another suggestion has been to use a web-hook or similar from zuul to trigger an image build (either at docker hub or some other registry) post-merge. Or we can let things go as they are (I manually build new images every now and again, which triggers automatic placecat [2] testing). The reason this comes back up is because I'm somewhat concerned that the "seriously, this is really simple" aspect of Placement gets lost and there's probably plenty of useful info in this kind of stuff. If we make it owned by more than just me, that might help spread the learning. Thoughts?k [1] https://etherpad.openstack.org/p/placement-ptg-train [2] https://github.com/cdent/placecat -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On 4/9/19 12:13 PM, Chris Dent wrote:
From etherpad [1]:
* Some talk in the past of moving https://github.com/cdent/placedock into placement but not sure * Another option is [to] trigger container build with each merge
I wrote this one, so I guess I should expand on it a bit. Basically, placedock is a Dockerfile for placement that strives to be small but configurable. The same repo also contains instructions (and YAML) for using the container in kubernetes, and provides a helm chart that uses the generated image.
Each of those three things is done in a way where many of the choices are made for you in favor of being light and simple. In things like Kolla, openstack-helm, and other containerizing setups some of those choices are left as options, making the build and run infrastructure more complex. The result with placedock is a tiny service that scales horizontally really well.
In the past there's been talk of including some of that stuff in the placement repo itself as a sort of "hey look, here's one way to do it". If we did that, which stuff?
Another suggestion has been to use a web-hook or similar from zuul to trigger an image build (either at docker hub or some other registry) post-merge.
We actually have some pretty awesome new container building jobs in Zuul now - I'd recommend using them. One of the things they can do is build your container image to be used in a gate job, and then when the patch for the gate job merges, publish and tag the actual container image used in the gate. This also works with depends-on, so if you have container images that consume layers from other container images or are built on top of them, all the right things happen. I'd be happy to help you get that set up in placement.
Or we can let things go as they are (I manually build new images every now and again, which triggers automatic placecat [2] testing).
One of the neat things with depends-on and containers is that it's done via registry config, so jobs _consuming_ images don't have to know that they're consuming speculative future images. This means you could have your placecat job run in the placement container build gate job against the speculative container state and things shoud Just Work.
The reason this comes back up is because I'm somewhat concerned that the "seriously, this is really simple" aspect of Placement gets lost and there's probably plenty of useful info in this kind of stuff. If we make it owned by more than just me, that might help spread the learning.
Thoughts?k
On Tue, 9 Apr 2019, Monty Taylor wrote:
I'd be happy to help you get that set up in placement.
Thanks, if we decide to follow through on this that would be awesome. And thanks for all the info which I will integrate back into the summaries when the time comes. Part of the question surrounding this is whether we want to take on the responsibility of "owning" container concepts within placement itself. Unless we wrap it in a bunch of "example" and "there's more than one way to do it" warnings people have demonstrated a tendency to take things as gospel (look at the damage some of the ways devstack managed web services spread around the OpenStack world). While I'm fairly confident that my little container works well for me, I'm hoping we can reach some consensus on whether we, the placement team, want to own such a thing. I'm tending towards thinking that we should because the potential educational value outweighs the vague concerns I'm not really able to enumerate (but the last paragraph below captures, a bit). As a mostly greenfield development, Placement doesn't have a lot of legacy weight so it tends to be able to demo: * good microversion handling * good http dispatch * good WSGI app hosting techniques * minimal config * good mini-container hygiene and probably some other things too. There are probably some useful techniques to pick up there. On the other hand, there was probably a time when Nova thought it has some good techniques to pick up and then everyone copied them and now there is regret. So it might be better that people look for examples outside of OpenStack, not within, where things tend to move slowly. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
As long as its marked under /examples or something, I think the benefits outweigh the drawbacks. It allows folks that have never been exposed to some of the containerized way of thinking to bump into it and see it in action. Your concern that examples that come from outside rather then inside is legit, but can be dealt with differently I think. You can have the example in tree, but ask folks outside OpenStack to help validate that its following best practices. Then you get the best of both worlds? Thanks, Kevin ________________________________________ From: Chris Dent [cdent+os@anticdent.org] Sent: Wednesday, April 10, 2019 3:23 AM To: openstack-discuss@lists.openstack.org Subject: Re: [placement][ptg] Containers/dockerfiles On Tue, 9 Apr 2019, Monty Taylor wrote:
I'd be happy to help you get that set up in placement.
Thanks, if we decide to follow through on this that would be awesome. And thanks for all the info which I will integrate back into the summaries when the time comes. Part of the question surrounding this is whether we want to take on the responsibility of "owning" container concepts within placement itself. Unless we wrap it in a bunch of "example" and "there's more than one way to do it" warnings people have demonstrated a tendency to take things as gospel (look at the damage some of the ways devstack managed web services spread around the OpenStack world). While I'm fairly confident that my little container works well for me, I'm hoping we can reach some consensus on whether we, the placement team, want to own such a thing. I'm tending towards thinking that we should because the potential educational value outweighs the vague concerns I'm not really able to enumerate (but the last paragraph below captures, a bit). As a mostly greenfield development, Placement doesn't have a lot of legacy weight so it tends to be able to demo: * good microversion handling * good http dispatch * good WSGI app hosting techniques * minimal config * good mini-container hygiene and probably some other things too. There are probably some useful techniques to pick up there. On the other hand, there was probably a time when Nova thought it has some good techniques to pick up and then everyone copied them and now there is regret. So it might be better that people look for examples outside of OpenStack, not within, where things tend to move slowly. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On Apr 9, 2019, at 2:37 PM, Monty Taylor <mordred@inaugust.com> wrote:
Another suggestion has been to use a web-hook or similar from zuul to trigger an image build (either at docker hub or some other registry) post-merge.
We actually have some pretty awesome new container building jobs in Zuul now - I'd recommend using them. One of the things they can do is build your container image to be used in a gate job, and then when the patch for the gate job merges, publish and tag the actual container image used in the gate.
My concern is the one-offness of placedock, not that it wouldn't work. But if Zuul can support this container building step, and we ensure that placedock follows the pattern that Zuul uses, we should be good. -- Ed Leafe
On 04/10/2019 12:46 PM, Ed Leafe wrote:
On Apr 9, 2019, at 2:37 PM, Monty Taylor <mordred@inaugust.com> wrote:
Another suggestion has been to use a web-hook or similar from zuul to trigger an image build (either at docker hub or some other registry) post-merge.
We actually have some pretty awesome new container building jobs in Zuul now - I'd recommend using them. One of the things they can do is build your container image to be used in a gate job, and then when the patch for the gate job merges, publish and tag the actual container image used in the gate.
My concern is the one-offness of placedock, not that it wouldn't work. But if Zuul can support this container building step, and we ensure that placedock follows the pattern that Zuul uses, we should be good.
Yeah, this was my thought as well. If we can (as the placement team) can take and own the "recipe" for constructing the container image using the Zuul container-image-building playbooks, then I'm 100% on board. Best, -jay
On Wed, 10 Apr 2019, Jay Pipes wrote:
On 04/10/2019 12:46 PM, Ed Leafe wrote:
On Apr 9, 2019, at 2:37 PM, Monty Taylor <mordred@inaugust.com> wrote:
We actually have some pretty awesome new container building jobs in Zuul now - I'd recommend using them. One of the things they can do is build your container image to be used in a gate job, and then when the patch for the gate job merges, publish and tag the actual container image used in the gate.
My concern is the one-offness of placedock, not that it wouldn't work. But if Zuul can support this container building step, and we ensure that placedock follows the pattern that Zuul uses, we should be good.
Yeah, this was my thought as well. If we can (as the placement team) can take and own the "recipe" for constructing the container image using the Zuul container-image-building playbooks, then I'm 100% on board.
Right, I'll make a proto-story for this and we can pick it back up post-PTG. Is there anyone itching to take the lead on this? Feel free to adapt the story and add more tasks and assign yourself if so. https://storyboard.openstack.org/#!/story/2005463 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
Sorry for the late answer here. As a deployer, I would prefer using the "official placement" build processes and artifacts. Therefore: 1) I like the idea of building images using openstack-infra zuul pipelines inside placement project scope. 2) I believe the helm charts should be discussed with the openstack-helm team, as they can probably share the best practices and/or can carry this for you (with your help). I would be happy to discuss this with you during PTG.
participants (6)
-
Chris Dent
-
Ed Leafe
-
Fox, Kevin M
-
Jay Pipes
-
Jean-Philippe Evrard
-
Monty Taylor