Can't run a container with root bind mounted in F23 docker 1.7

[Peter Robinson]

>> On Fri, Oct 30, 2015 at 12:40 AM, Dusty Mabe <dusty at dustymabe.com> wrote:
>>>
>>> docker 1.7 is what is in the stable f23 repo. with that we can't run a
>>> container with root bind mounted into it:
>>>
>>> ```
>>> -bash-4.3# docker run -it --rm -v /:/host busybox
>>> Error response from daemon: Relabeling of / is not allowed
>>> -bash-4.3# rpm -q docker
>>> docker-1.7.0-22.gitdcff4e1.fc23.x86_64
>>> ```
>>>
>>> I guess we'll just have to go with it..
>>
>> Why is the cloud WG waiting until the last minute to be testing this?
>> I mean the NVR that your referring to has been there since the 28th
>> July. That's a lot of time to either fix it or move to a newer version
>> of docker to do so.
>
>
> So we had test days and we have been testing F23 cloud images along the way.
> The problem is that all the way up until the RC images came out we have had
> images that had the updates-testing repo enabled by default. docker-1.8.2 is
> in updates-testing so guess what? We have been testing that and not 1.7.1.

It's standard process to have it enabled by default during the
development cycle, but for at least the other images the generated
image while having updates testing enabled doesn't generate the image
with updates-testing enabled, you get it once it's running if you
update. Is that not the case here?

> Some of us, including myself, haven't been around fedora that long and this
> little detail is quite subtle and leads to many issues when you think you've
> tested something enough.
>
>>
>> Along with the previous thread of "the last time this was working was
>> TC11" that tells me the Cloud WG testing regime is sub par.
>>
>> Clearly there's some issues along the lines of:
>> 1) Incomplete test matrix
>> 2) Test matrix not being followed
>> 3) Use of automated test harnesses and people not checking the output
>
>
> Our automated tests are brand new, but are getting better all the time. The
> atomic image issues would have been caught by the test harness but that one
> test was disabled for the atomic images. It is now enabled for them.

How do you verify that the tests are effective and reflect the real
world? Or do you just assume if the test is green it's all good?

>> 4) gaps in what the auto test frame work is capable of and people not
>> doing manual testing to cover the difference until it's fixed
>> 5) a combination of all of the above
>>
>> Either way the above is a blatant disregard of other Working Groups,
>> teams and people in the project who have to spend a vast amount of
>> time when a respin is required producing the respin and the QAing it
>> even if nothing else has changed.
>
>
> Blatant disregard. Thanks. See earlier point about updates-testing repos.

Disrespect of other people's time and efforts?

>> I'm looking forward to the Cloud WG's postmortem once the release is
>> out covering how they're going to be the leading light in this regard
>> in F-24 because picking up issues that have been around for weeks and
>> months at RC9 clearly isn't good enough.
>
>
> See earlier point about updates-testing repos being enabled. Docker 1.8 has
> been in the updates-testing repos for months. When a user just does 'dnf
> install docker' a lot of times they don't check what repo it came from:
>
> https://bodhi.fedoraproject.org/updates/?packages=docker

Why when testing has since July when the above mentioned 1.7 release
was built has no one applies karma to get it to stable. This is a
fairly standard process that between July and final freeze [1] on 13th
of October it wouldn't have been hard to get enough karma to get a 1.8
release stable. Even then post freeze there's a process [2] to get
things to stable, it's even pretty much the same process for
Alpha/Beta/Final. Even with a bunch of newbies the process is well
known, people talk about it all the time and it's not hard to ask, and
I doubt everyone was new.

[1] https://fedoraproject.org/wiki/Releases/23/Schedule
[2] https://qa.fedoraproject.org/blockerbugs/milestone/23/final/buglist]