On 10/30/2015 08:30 AM, Peter Robinson wrote:
On Fri, Oct 30, 2015 at 12:40 AM, Dusty Mabe <dusty@xxxxxxxxxxxxx> 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?
Maybe, but the fedora cloud base image doesn't include docker so you
have to grab it from the repo, so dnf grabs whatever is newest. If
updates-testing is enabled then you get it from there.
For the atomic image you are right, unfortunately we haven't tested this
one as much because it isn't release blocking so some of us have
concentrated more on the cloud image for that.
We are trying to improve.
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?
We didn't just rely on automated tests because they are brand new. We
tested quite a bit manually as well, we just haven't been doing as much
of that recently (as of the RCs) and I apologize for that. Apparently
the TCs were built against the wrong repos (at least for atomic ostree
stuff). So RC* was something completely different and we didn't know
that would happen.
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 thanked Dennis quite a bit for his efforts the other night. In the
case of this email we haven't asked anyone to do anything. I sent this
to the cloud list to raise awareness within the group so that we can
improve for next time.
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.
Yes, karma should have been applied, but like I said most of us (well I
can really on speak for myself) didn't realize the stuff wasn't in
stable. You can choose to believe that or not. I'll let others speak for
themselves.
Just for the record I have been personally using the Fedora 23 cloud
image for my $dayjob for over a month. No issues because everything was
pulled from updates-testing. I have learned my lesson and I think I'll
propose that the cloud images disable this in the future when going
through testing stages.
Dusty
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
