Hi
On 6 Oct 2014, at 17:41, Clint Byrum cl...@fewbar.com wrote:
We have to be _extremely_ careful in how we manage this. I actually think
it has potential to really blow up in our faces.
Yes, anything we do here has the potential to be extremely ruinous for
operators, but the reality is that
Excerpts from Chris Jones's message of 2014-10-07 04:35:33 -0700:
Hi
On 6 Oct 2014, at 17:41, Clint Byrum cl...@fewbar.com wrote:
We have to be _extremely_ careful in how we manage this. I actually think
it has potential to really blow up in our faces.
Yes, anything we do here has the
On 8 October 2014 06:49, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Chris Jones's message of 2014-10-07 04:35:33 -0700:
AFAICS, the only risk left at that point, is elements that other people are
maintaining. If we consider that to be a sufficient risk, we can still build
the
Hi
On 7 Oct 2014, at 18:49, Clint Byrum cl...@fewbar.com wrote:
* Create an element which imports /etc/passwd and /etc/group from local
disk into image. This will have an element-provides of uid-gid-map
I don't think it should import those files wholesale, IMO that's making way too
many
Excerpts from Chris Jones's message of 2014-10-07 12:23:20 -0700:
Hi
On 7 Oct 2014, at 18:49, Clint Byrum cl...@fewbar.com wrote:
* Create an element which imports /etc/passwd and /etc/group from local
disk into image. This will have an element-provides of uid-gid-map
I don't think it
Hi
On 7 Oct 2014, at 20:47, Clint Byrum cl...@fewbar.com wrote:
I don't think it should import those files wholesale, IMO that's making way
too many assumptions about the similarity of the two builds.
Disagree on the grounds that the point of this is to deal with people
who already have
Excerpts from Chris Jones's message of 2014-10-07 13:27:07 -0700:
Hi
On 7 Oct 2014, at 20:47, Clint Byrum cl...@fewbar.com wrote:
I don't think it should import those files wholesale, IMO that's making
way too many assumptions about the similarity of the two builds.
Disagree on the
Excerpts from Clint Byrum's message of 2014-10-02 14:15:30 +:
Excerpts from Gregory Haynes's message of 2014-10-01 19:09:38 -0700:
If we really want to go with this type of aproach we could also just
copy the existing /etc/passwd into the image thats being built. Then
when users are
Excerpts from Gregory Haynes's message of 2014-10-06 07:06:02 -0700:
Excerpts from Clint Byrum's message of 2014-10-02 14:15:30 +:
Excerpts from Gregory Haynes's message of 2014-10-01 19:09:38 -0700:
If we really want to go with this type of aproach we could also just
copy the
Excerpts from James Polley's message of 2014-10-02 05:37:25 +:
All three of the options presented here seem to assume that UIDs will always
be allocated at image-build time. I think that's because most of these UIDs
will be used to write files into the chroot at image-create time - if I
-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: 02 October 2014 02:51
To: openstack-dev
Subject: [openstack-dev] [TripleO] a need to assert user ownership in
preserved state
Recently we've been testing image based updates using TripleO, and we've
run into an
Excerpts from Gregory Haynes's message of 2014-10-01 19:09:38 -0700:
Excerpts from Clint Byrum's message of 2014-10-02 01:50:33 +:
Recently we've been testing image based updates using TripleO, and we've
run into an interesting conundrum.
Currently, our image build scripts create a
Excerpts from James Polley's message of 2014-10-01 22:37:25 -0700:
All three of the options presented here seem to assume that UIDs will always
be allocated at image-build time. I think that's because most of these UIDs
will be used to write files into the chroot at image-create time - if I
-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: 02 October 2014 15:16
To: openstack-dev
Subject: Re: [openstack-dev] [TripleO] a need to assert user ownership
in preserved state
Excerpts from Gregory Haynes's message of 2014-10-01 19:09:38 -0700:
Excerpts
Excerpts from Sullivan, Jon Paul's message of 2014-10-02 02:08:26 -0700:
-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: 02 October 2014 02:51
To: openstack-dev
Subject: [openstack-dev] [TripleO] a need to assert user ownership in
preserved state
On 3 Oct 2014, at 00:25, Clint Byrum cl...@fewbar.com wrote:
Excerpts from James Polley's message of 2014-10-01 22:37:25 -0700:
All three of the options presented here seem to assume that UIDs will always
be allocated at image-build time. I think that's because most of these UIDs
will
On 3 Oct 2014, at 02:57, James Polley j...@jamezpolley.com wrote:
On 3 Oct 2014, at 00:25, Clint Byrum cl...@fewbar.com wrote:
Excerpts from James Polley's message of 2014-10-01 22:37:25 -0700:
All three of the options presented here seem to assume that UIDs will
always be
Excerpts from Clint Byrum's message of 2014-10-02 01:50:33 +:
Recently we've been testing image based updates using TripleO, and we've
run into an interesting conundrum.
Currently, our image build scripts create a user per service for the
image. We don't, at this time, assert a UID, so
Clint Byrum cl...@fewbar.com wrote on 10/01/2014 09:50:33 PM:
Recently we've been testing image based updates using TripleO, and we've
run into an interesting conundrum.
Currently, our image build scripts create a user per service for the
image. We don't, at this time, assert a UID, so it
On 02/10/14 12:26, Mike Spreitzer wrote:
I do not understand the problem statement. Unfortunately, I am not
familiar with image based updates using TripleO. What is updating what?
If the UIDs are not asserted, what UIDs shift by one? Is this because
some files keep owner UID while the some
All three of the options presented here seem to assume that UIDs will always be
allocated at image-build time. I think that's because most of these UIDs will
be used to write files into the chroot at image-create time - if I could think
of some way around that, I think we could avoid this
21 matches
Mail list logo
