On 12/3/18 10:34 AM, Bogdan Dobrelya wrote:
Hi Kevin.
Puppet not only creates config files but also executes a service
dependent steps, like db sync, so neither '[base] -> [puppet]' nor
'[base] -> [service]' would not be enough on its own. That requires some
services specific code to be
Hi Kevin.
Puppet not only creates config files but also executes a service
dependent steps, like db sync, so neither '[base] -> [puppet]' nor
'[base] -> [service]' would not be enough on its own. That requires some
services specific code to be included into *config* images as well.
PS. There
Still confused by:
[base] -> [service] -> [+ puppet]
not:
[base] -> [puppet]
and
[base] -> [service]
?
Thanks,
Kevin
From: Bogdan Dobrelya [bdobr...@redhat.com]
Sent: Friday, November 30, 2018 5:31 AM
To: Dan Prince; openstack-dev@lists.openstack.org;
On 11/30/18 1:52 PM, Dan Prince wrote:
On Fri, 2018-11-30 at 10:31 +0100, Bogdan Dobrelya wrote:
On 11/29/18 6:42 PM, Jiří Stránský wrote:
On 28. 11. 18 18:29, Bogdan Dobrelya wrote:
On 11/28/18 6:02 PM, Jiří Stránský wrote:
Reiterating again on previous points:
-I'd be fine removing
On Fri, 2018-11-30 at 10:31 +0100, Bogdan Dobrelya wrote:
> On 11/29/18 6:42 PM, Jiří Stránský wrote:
> > On 28. 11. 18 18:29, Bogdan Dobrelya wrote:
> > > On 11/28/18 6:02 PM, Jiří Stránský wrote:
> > > >
> > > >
> > > > > Reiterating again on previous points:
> > > > >
> > > > > -I'd be fine
On 11/29/18 6:42 PM, Jiří Stránský wrote:
On 28. 11. 18 18:29, Bogdan Dobrelya wrote:
On 11/28/18 6:02 PM, Jiří Stránský wrote:
Reiterating again on previous points:
-I'd be fine removing systemd. But lets do it properly and not via 'rpm
-ev --nodeps'.
-Puppet and Ruby *are* required for
On 29. 11. 18 20:20, Fox, Kevin M wrote:
If the base layers are shared, you won't pay extra for the separate puppet
container
Yes, and that's the state we're in right now.
unless you have another container also installing ruby in an upper layer.
Not just Ruby but also Puppet and Systemd.
Oh, rereading the conversation again, the concern is having shared deps move up
layers? so more systemd related then ruby?
The conversation about --nodeps makes it sound like its not actually used. Just
an artifact of how the rpms are built... What about creating a dummy package
that
If the base layers are shared, you won't pay extra for the separate puppet
container unless you have another container also installing ruby in an upper
layer. With OpenStack, thats unlikely.
the apparent size of a container is not equal to its actual size.
Thanks,
Kevin
On 28. 11. 18 18:29, Bogdan Dobrelya wrote:
On 11/28/18 6:02 PM, Jiří Stránský wrote:
Reiterating again on previous points:
-I'd be fine removing systemd. But lets do it properly and not via 'rpm
-ev --nodeps'.
-Puppet and Ruby *are* required for configuration. We can certainly put
them in
On 11/28/18 8:55 PM, Doug Hellmann wrote:
I thought the preferred solution for more complex settings was config maps. Did
that approach not work out?
Regardless, now that the driver work is done if someone wants to take another
stab at etcd integration it’ll be more straightforward today.
On Wed, 2018-11-28 at 13:28 -0500, James Slagle wrote:
> On Wed, Nov 28, 2018 at 12:31 PM Bogdan Dobrelya > wrote:
> > Long story short, we cannot shoot both rabbits with a single shot,
> > not
> > with puppet :) May be we could with ansible replacing puppet
> > fully...
> > So splitting config
On Wed, Nov 28, 2018 at 12:31 PM Bogdan Dobrelya wrote:
> Long story short, we cannot shoot both rabbits with a single shot, not
> with puppet :) May be we could with ansible replacing puppet fully...
> So splitting config and runtime images is the only choice yet to address
> the raised security
On 11/28/18 6:02 PM, Jiří Stránský wrote:
Reiterating again on previous points:
-I'd be fine removing systemd. But lets do it properly and not via 'rpm
-ev --nodeps'.
-Puppet and Ruby *are* required for configuration. We can certainly put
them in a separate container outside of the runtime
Reiterating again on previous points:
-I'd be fine removing systemd. But lets do it properly and not via 'rpm
-ev --nodeps'.
-Puppet and Ruby *are* required for configuration. We can certainly put
them in a separate container outside of the runtime service containers
but doing so would
Ok, so you have the workflow in place, but it sounds like the containers are
not laid out to best use that workflow. Puppet is in the base layer. That means
whenever puppet gets updated, all the other containers must be too. And other
such update coupling issues.
I'm with you, that binaries
Hi,
On Tue, Nov 27, 2018 at 7:13 PM Dan Prince wrote:
> On Tue, 2018-11-27 at 16:24 +0100, Bogdan Dobrelya wrote:
> > Changing the topic to follow the subject.
> >
> > [tl;dr] it's time to rearchitect container images to stop incluiding
> > config-time only (puppet et al) bits, which are not
On Wed, 2018-11-28 at 15:12 +0100, Bogdan Dobrelya wrote:
> On 11/28/18 2:58 PM, Dan Prince wrote:
> > On Wed, 2018-11-28 at 12:45 +0100, Bogdan Dobrelya wrote:
> > > To follow up and explain the patches for code review:
> > >
> > > The "header" patch https://review.openstack.org/620310 ->
> > >
On 11/28/18 2:58 PM, Dan Prince wrote:
On Wed, 2018-11-28 at 12:45 +0100, Bogdan Dobrelya wrote:
To follow up and explain the patches for code review:
The "header" patch https://review.openstack.org/620310 -> (requires)
https://review.rdoproject.org/r/#/c/17534/, and also
On Wed, 2018-11-28 at 12:45 +0100, Bogdan Dobrelya wrote:
> To follow up and explain the patches for code review:
>
> The "header" patch https://review.openstack.org/620310 -> (requires)
> https://review.rdoproject.org/r/#/c/17534/, and also
> https://review.openstack.org/620061 -> (which in
On Wed, 2018-11-28 at 00:31 +, Fox, Kevin M wrote:
> The pod concept allows you to have one tool per container do one
> thing and do it well.
>
> You can have a container for generating config, and another container
> for consuming it.
>
> In a Kubernetes pod, if you still wanted to do
To follow up and explain the patches for code review:
The "header" patch https://review.openstack.org/620310 -> (requires)
https://review.rdoproject.org/r/#/c/17534/, and also
https://review.openstack.org/620061 -> (which in turn requires)
https://review.openstack.org/619744 -> (Kolla change,
The pod concept allows you to have one tool per container do one thing and do
it well.
You can have a container for generating config, and another container for
consuming it.
In a Kubernetes pod, if you still wanted to do puppet,
you could have a pod that:
1. had an init container that ran
On Tue, 2018-11-27 at 16:24 +0100, Bogdan Dobrelya wrote:
> Changing the topic to follow the subject.
>
> [tl;dr] it's time to rearchitect container images to stop incluiding
> config-time only (puppet et al) bits, which are not needed runtime
> and
> pose security issues, like CVEs, to
Changing the topic to follow the subject.
[tl;dr] it's time to rearchitect container images to stop incluiding
config-time only (puppet et al) bits, which are not needed runtime and
pose security issues, like CVEs, to maintain daily.
Background:
1) For the Distributed Compute Node edge case,
25 matches
Mail list logo
