Hi all,
Recently, the workflows squad has been reorganized and people from the
squad are joining different squads. I would like to discuss how we are
going to adjust to this situation to make sure that tripleo-common
development is not going to be blocked in terms of feature work and reviews.
On Wed, Nov 28, 2018 at 5:13 AM Jiri Tomasek wrote:
[...]
> As a possible solution, I would like to propose Adriano as a core reviewer
> to tripleo-common and adding tripleo-ui cores right to +2 tripleo-common
> patches.
>
[...]
Not a member of the squad but +2 to the idea
Thanks for
On Wed, Nov 28, 2018 at 4:33 PM Natal Ngétal wrote:
> On Tue, Nov 27, 2018 at 4:50 PM Marios Andreou wrote:
> > as just mentioned in the tripleo weekly irc meeting [1] some of us are
> trying to make small weekly improvements to the tripleo docs [2]. We are
> using this bug [3] for tracking
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, Nov 28, 2018 at 5:13 AM Jiri Tomasek wrote:
> Hi all,
>
> Recently, the workflows squad has been reorganized and people from the
> squad are joining different squads. I would like to discuss how we are
> going to adjust to this situation to make sure that tripleo-common
> development is
On Wed, Nov 28, 2018 at 4:19 PM Marios Andreou wrote:
> great you are very welcome !
Thanks.
> not really, I mean "anything goes" as long as it's an improvement ( and the
> usual review process will determine if it is or not :) ). Could be as small
> as typos or broken links/images, through
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
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 ->
> > >
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,
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
On Tue, Nov 27, 2018 at 4:50 PM Marios Andreou wrote:
> as just mentioned in the tripleo weekly irc meeting [1] some of us are trying
> to make small weekly improvements to the tripleo docs [2]. We are using this
> bug [3] for tracking and this effort is a result of some feedback during the
>
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
Added Kolla tag as we all together might want to do something to that
systemd included in containers via *multiple* package dependencies, like
[0]. Ideally, that might be properly packaging all/some (like those
names listed in [1]) of the places having it as a dependency, to stop
doing that as
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
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
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
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 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
18 matches
Mail list logo
