----- Original Message -----
From: "Kai Qiang Wu" wkqwu@cn.ibm.com To: "Steve Gordon" sgordon@redhat.com Cc: "Ton Ngo" ton@us.ibm.com Sent: Saturday, March 12, 2016 5:07:17 AM Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
Hi Steve, I think what you did is rpm version, here is my finding:
[minion@k8-pdvmggl3ys-0-cdruybssooyh-kube-master-vtartl7oubyc ~]$ rpm -qa | grep kubernetes kubernetes-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-node-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-client-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-master-1.1.0-0.17.git388061f.fc23.x86_64 [minion@k8-pdvmggl3ys-0-cdruybssooyh-kube-master-vtartl7oubyc ~]$ kubectl version Client Version: version.Info{Major:"1", Minor:"0", GitVersion:"v1.0.6", GitCommit:"388061f00f0d9e4d641f9ed4971c775e1654579d GitTreeState:"clean"} Server Version: version.Info{Major:"1", Minor:"0", GitVersion:"v1.0.6", GitCommit:"388061f00f0d9e4d641f9ed4971c775e1654579d GitTreeState:"clean"}
It seems we should trust kubectl version, it is final version, it said v1.0.6.
Adding cloud@lists.fedoraproject.org. Folks, can you explain the reason for the discrepancy between the packages that appear to have been used to build the image and the tools themselves? Specifically looking at Fedora-Cloud-Atomic-23-20160308.x86_64.qcow2
Thanks,
Steve
Thanks
Best Wishes,
Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing
E-mail: wkqwu@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193
Follow your heart. You are miracle!
Steve Gordon ---12/03/2016 12:46:50 am-------- Original Message ----- > From: "Kai Qiang Wu" wkqwu@cn.ibm.com
From: Steve Gordon sgordon@redhat.com To: Kai Qiang Wu/China/IBM@IBMCN Cc: Ton Ngo ton@us.ibm.com Date: 12/03/2016 12:46 am Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
----- Original Message -----
From: "Kai Qiang Wu" wkqwu@cn.ibm.com To: "Steve Gordon" sgordon@redhat.com Cc: "Ton Ngo" ton@us.ibm.com Sent: Friday, March 11, 2016 3:58:04 AM Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
Hi Steve,
I tried the link you gave me https://getfedora.org/en/cloud/download/atomic.html and download the atomic 23 image,
And deploy with Magnum, and login in server, and found it is still GitVersion: V1.0.6
Could you confirm is it v1.1.0 ? From my test, I did not find it such case.
I am simply loading the image up in virt-manager:
$ sudo qemu-img create -f qcow2 -o preallocation=metadata /var/lib/libvirt/images/Test-Fedora-Cloud-Atomic-23-20160308.x86_64.qcow2 50G $ sudo virt-resize --expand /dev/vda1 /home/sgordon/Downloads/Fedora-Cloud-Atomic-23-20160308.x86_64.qcow2 /var/lib/libvirt/images/Test-Fedora-Cloud-Atomic-23-20160308.x86_64.qcow2
...create new VM from disk image in virt-manager and attach init.iso CD-ROM with metadata, ssh in...
$ cat /etc/redhat-release Fedora release 23 (Twenty Three) $ rpm -qa | grep kubernetes kubernetes-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-node-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-client-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-master-1.1.0-0.17.git388061f.fc23.x86_64
Are you sure Magnum isn't modifying it?
-Steve
Thanks
Best Wishes,
Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing
E-mail: wkqwu@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193
Follow your heart. You are miracle!
Steve Gordon ---11/03/2016 10:46:06 am-------- Original Message ----- > From: "Kai Qiang Wu" wkqwu@cn.ibm.com
From: Steve Gordon sgordon@redhat.com To: Kai Qiang Wu/China/IBM@IBMCN Cc: Ton Ngo ton@us.ibm.com Date: 11/03/2016 10:46 am Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
----- Original Message -----
From: "Kai Qiang Wu" wkqwu@cn.ibm.com To: "Steve Gordon" sgordon@redhat.com Cc: "Ton Ngo" ton@us.ibm.com Sent: Thursday, March 10, 2016 9:00:09 PM Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
Hi Steve,
Glad to know above information, It seems clearer to me now.
Fedora atomic is updated more frequent, (as you said maybe two-weekly) Each update is well tested and ready for production, each new image just include some new version (kubernetes and docker). Is it ?
Yes, though major rebases/updates may still have to wait for e.g. Fedora Atomic 24. The easiest way to track when new updates are released is to join the cloud@lists.fedoraproject.org list.
-Steve
I asked before, because I thought those image was only used for internal test. Which can be a gap for customer use. As customer would only want to use official release image. (which means community fully supported)
Thanks
Best Wishes,
Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing
E-mail: wkqwu@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193
Follow your heart. You are miracle!
Steve Gordon ---11/03/2016 09:49:36 am-------- Original Message ----- > From: "Kai Qiang Wu" wkqwu@cn.ibm.com
From: Steve Gordon sgordon@redhat.com To: Kai Qiang Wu/China/IBM@IBMCN Cc: Ton Ngo ton@us.ibm.com Date: 11/03/2016 09:49 am Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
----- Original Message -----
From: "Kai Qiang Wu" wkqwu@cn.ibm.com To: "Steve Gordon" sgordon@redhat.com
Hi Steve,
What's the difference between those images ? Is that daily build test image ? Not GA official release image ?(Like Redhat linux 7.0)
No, that is the Fedora Atomic 23 image - which is updated ("GA" if you will) on a regular basis.
I did not expect user have many images which could waste test effort in our side. I expect it would be one official release image.
RHEL/CentOS Atomic are updated less regularly but of course this also means using slightly older versions of included components.
If we have, could you give a link what's the official atomic 23 image ?
The link to the official atomic 23 image is the one I already gave you:
There is a new official Fedora Atomic 23 image on a regular basis. The above link will always contain the latest Fedora Atomic release. It seems to me you are complaining that the original Fedora Atomic 23 did not have kubernetes-1.1.0 (which was released shortly *after* Fedora 23 was released) but also complaining that the image is re-spun often enough to pick up such changes? Similarly the Magnum community at large's most frequent complaint (and justification for building special/custom images) is that Fedora Atomic does not update *frequently enough* or does not have new enough versions of the key components. It is not clear to me what your desired/expected outcome is?
-Steve
Thanks
Best Wishes,
Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing
E-mail: wkqwu@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193
Follow your heart. You are miracle!
From: Steve Gordon sgordon@redhat.com To: Kai Qiang Wu/China/IBM@IBMCN Date: 10/03/2016 11:13 pm Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
----- Original Message -----
From: "Kai Qiang Wu" wkqwu@cn.ibm.com To: "Steve Gordon" sgordon@redhat.com
Yes, I noticed that,
But from our guys test result, atomic 23 was integrated with kubernetes 1.0.6, not 1.1.0.
Which I think it is not good for some features (like cinder volume plugin support).
As I said, it is updated two-weekly. The versions in the earlier email are present in the latest F23 Atomic images. Specifically:
Fedora-Cloud-Atomic-23-20160223.x86_64.qcow2:
docker-1.9.1 flannel-0.5.4 kubernetes-1.1.0 etcd-2.2.1
I loaded the image myself and confirmed this.
-Steve
Thanks
Best Wishes,
Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing
E-mail: wkqwu@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193
Follow your heart. You are miracle!
From: Steve Gordon sgordon@redhat.com To: Kai Qiang Wu/China/IBM@IBMCN Date: 10/03/2016 09:59 pm Subject: Re: [openstack-dev] [magnum] Discussion of
supporting
single/multiple OS distro
----- Original Message -----
From: "Kai Qiang Wu" wkqwu@cn.ibm.com To: sgordon@redhat.com Sent: Wednesday, March 9, 2016 9:15:05 PM Subject: Re: [openstack-dev] [magnum] Discussion
of
supporting single/multiple
OS distro
Hi Steve,
Where can I get integrated software versions in Atomic 23 ? (As you mentioned it include kubernetes v1.10 and docker 1.9.1 etc)
Do we have any official link for that as refer ?
Hi Kai,
I was pulling the latest image from this location:
https://getfedora.org/en/cloud/download/atomic.html
These images are updated every 2 weeks or so, although major rebases
(e.g.
moving to docker 1.10) will still likely only occur in rawhide
development
for F24. Note that there are some changes required to use an F23 based Atomic:
https://review.openstack.org/#/c/276232/
Thanks,
Steve
Thanks
Best Wishes,
Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing
E-mail: wkqwu@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing
P.R.China
100193
Follow your heart. You are miracle!
From: Steve Gordon sgordon@redhat.com To: "OpenStack Development Mailing List (not
for usage questions)"
openstack-dev@lists.openstack.org Cc: Josh Berkus jberkus@redhat.com Date: 01/03/2016 10:30 pm Subject: Re: [openstack-dev] [magnum]
Discussion of
supporting
single/multiple OS distro
----- Original Message ----- > From: "Kai Qiang Wu" wkqwu@cn.ibm.com > To: "OpenStack Development Mailing List (not for usage > questions)" openstack-dev@lists.openstack.org > Cc: "Josh Berkus" jberkus@redhat.com > > We found some issue about atomic host run some docker volume > plugin, while > atomic and docker volume plugin both not sure what's the root > cause
of
> that. > > here is the link > https://github.com/docker/docker/issues/18005#issuecomment-190215862
Thanks for highlighting this PR, I'll add it to my list.
> Also I did not find atomic image update quickly, ( but k8s and > docker both > release quickly, which can lacks of new feature applied in our > development), I think atomic have a gap for that.
This is definitely likely to continue to be a real issue particularly w.r.t. docker itself - containerization of k8s, flannel, and etcd will alleviate at least some of the pain though as does the fact that
updates
are now in fact being pushed out every couple of weeks. As it stands
the
official Fedora Atomic images appear to actually contain equivalent or newer components than the custom builds at https://fedorapeople.org/groups/magnum/ (?), e.g.:
Fedora-Cloud-Atomic-23-20160223.x86_64.qcow2:
docker-1.9.1 flannel-0.5.4 kubernetes-1.1.0 etcd-2.2.1
fedora-21-7.qcow2:
docker-1.9.1 flannel-0.5.0 kubernetes-1.1.0 etcd-2.0.13
I digress though, as I said in the follow up either way it doesn't seem
to
me like only having support for one image would be a win for users
it does make sense though to expect more of the work to support each image
to
come from the folks interested in maintaining that support though than being spread across the entire magnum team.
Thanks,
Steve
>
> Kai Qiang Wu (吴开强 Kennan) > IBM China System and Technology Lab, Beijing > > E-mail: wkqwu@cn.ibm.com > Tel: 86-10-82451647 > Address: Building 28(Ring Building), ZhongGuanCun Software Park, > No.8 Dong Bei Wang West Road, Haidian District Beijing
P.R.China
> 100193 >
> Follow your heart. You are miracle! > > > > From: Steve Gordon
> To: Guz Egor
guz_egor@yahoo.com, "OpenStack
Development Mailing
> List (not for usage questions)" > openstack-dev@lists.openstack.org > Cc: Josh Berkus
> Date: 01/03/2016 08:19
pm
> Subject: Re:
[openstack-dev] [magnum]
Discussion of
supporting > single/multiple
OS distro
> > > > ----- Original Message ----- > > From: "Guz Egor" guz_egor@yahoo.com > > To: "OpenStack Development Mailing List (not for usage > > questions)" > openstack-dev@lists.openstack.org > > > > Adrian, > > I disagree, host OS is very important for operators because of > integration > > with all internal tools/repos/etc. > > I think it make sense to limit OS support in Magnum main > > source.
But
not > sure > > that Fedora Atomic is right choice,first of all there is no documentation > > about it and I don't think it's used/tested a lot by
Docker/Kub/Mesos
> > community. > > Project Atomic documentation for the most part lives here: > > http://www.projectatomic.io/docs/ > > To help us improve it, it would be useful to know what you think > is > missing. E.g. I saw recently in the IRC channel it was discussed > that there > is no documentation on (re)building the image but this is the > first
hit
in > a Google search for same and it seems to largely match what has > been copied > into Magnum's docs for same: > > >
http://www.projectatomic.io/blog/2014/08/build-your-own-atomic-centos-or-fed...
> > > I have no doubt that there are areas where the documentation is
lacking,
> but it's difficult to resolve a claim that there is no > documentation
at
> all. I recently kicked off a thread over on the atomic list to > try
and
> relay some of the concerns that were raised on this list and in > the
IRC
> channel recently, it would be great if Magnum folks could chime > in
with
> more specifics: > > >
https://lists.projectatomic.io/projectatomic-archives/atomic/2016-February/t...
> > > Separately I had asked about containerization of
kubernetes/etcd/flannel
> which remains outstanding: > > >
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/...
> > > Fedora Atomic builds do seem to be hitting their planned two > weekly update > cadence now though which may alleviate this concern at least > somewhat
in
> the interim: > > >
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/...
> > https://fedorahosted.org/cloud/ticket/139 > > Thanks, > > Steve > > > It make sense to go with Ubuntu (I believe it's still most > > adopted > > platform in all three COEs and OpenStack deployments) and
CoreOS
(is > > highly adopted/tested in Kub community and Mesosphere DCOS uses > > it
as
> well). > > We can implement CoreOS support as driver and users can use it > > as > reference > > implementation. > > > > --- Egor > > From: Adrian Otto adrian.otto@rackspace.com > > To: OpenStack Development Mailing List (not for usage > > questions) > > openstack-dev@lists.openstack.org > > Sent: Monday, February 29, 2016 10:36 AM > > Subject: Re: [openstack-dev] [magnum] Discussion of supporting > > single/multiple OS distro > > > > Consider this: Which OS runs on the bay nodes is not important > > to
end
> users. > > What matters to users is the environments their containers > > execute
in,
> which > > has only one thing in common with the bay node OS: the kernel. > > The linux > > syscall interface is stable enough that the various linux
distributions
> can > > all run concurrently in neighboring containers sharing same > > kernel. There > is > > really no material reason why the bay OS choice must match what
distro
> the > > container is based on. Although I’m persuaded by Hongbin’s > > concern
to
> > mitigate risk of future changes WRT whatever OS distro is the prevailing > one > > for bay nodes, there are a few items of concern about duality > > I’d
like
to > > zero in on: > > 1) Participation from Magnum contributors to support the CoreOS specific > > template features has been weak in recent months. By > > comparison, > > participation relating to Fedora/Atomic have been much > > stronger. > > 2) Properly testing multiple bay node OS distros (would)
significantly
> > increase the run time and complexity of our functional tests. > > 3) Having support for multiple bay node OS choices requires > > more > extensive > > documentation, and more comprehensive troubleshooting details. > > If we proceed with just one supported disto for bay nodes, and
offer
> > extensibility points to allow alternates to be used in place of > > it,
we
> > should be able to address the risk concern of the chosen distro > > by > selecting > > an alternate when that change is needed, by using those
extensibility
> > points. These include the ability to specify your own bay > > image,
and
the > > ability to use your own associated Heat template. > > I see value in risk mitigation, it may make sense to simplify > > in
the
> short > > term and address that need when it becomes necessary. My point > > of
view
> might > > be different if we had contributors willing and ready to > > address
the
> variety > > of drawbacks that accompany the strategy of supporting multiple > > bay node > OS > > choices. In absence of such a community interest, my preference > > is
to
> > simplify to increase our velocity. This seems to me to be a
relatively
> easy > > way to reduce complexity around heat template versioning. What > > do
you
> think? > > Thanks, > > Adrian > > > > On Feb 29, 2016, at 8:40 AM, Hongbin Lu hongbin.lu@huawei.com
wrote:
> > Hi team, This is a continued discussion from a review [1]. > > Corey O'Brien > > suggested to have Magnum support a single OS distro (Atomic). I > disagreed. I > > think we should bring the discussion to here to get broader set > > of > inputs. > > Corey O'Brien From the midcycle, we decided we weren't going to > continue > > to support 2 different versions of the k8s template. Instead, > > we
were
> going > > to maintain the Fedora Atomic version of k8s and remove the > > coreos > templates > > from the tree. I don't think we should continue to develop > > features
for
> > coreos k8s if that is true. In addition, I don't think we > > should
break
> the > > coreos template by adding the trust token as a heat parameter.
Hongbin
> Lu I > > was on the midcycle and I don't remember any decision to remove
CoreOS
> > support. Why you want to remove CoreOS templates from the tree.
Please
> note > > that this is a very big decision and please discuss it with the
team
> > thoughtfully and make sure everyone agree. Corey O'Brien > > Removing
the
> > coreos templates was a part of the COE drivers decision. Since > > each
COE
> > driver will only support 1 distro+version+coe we discussed > > which
ones
to > > support in tree. The decision was that instead of trying to > > support every > > distro and every version for every coe, the magnum tree would > > only
have
> > support for 1 version of 1 distro for each of the 3 COEs > > (swarm/docker/mesos). Since we already are going to support > > Atomic
for
> > swarm, removing coreos and keeping Atomic for kubernetes was > > the favored > > choice. Hongbin Lu Strongly disagree. It is a huge risk to > > support
a
> single > > distro. The selected distro could die in the future. Who knows. > > Why make > > Magnum take this huge risk? Again, the decision of supporting
single
> distro > > is a very big decision. Please bring it up to the team and have > > it > discuss > > thoughtfully before making any decision. Also, Magnum doesn't > > have
to
> > support every distro and every version for every coe, but > > should support > > *more than one* popular distro for some COEs (especially for > > the popular > > COEs). Corey O'Brien The discussion at the midcycle started > > from
the
> idea > > of adding support for RHEL and CentOS. We all discussed and > > decided that > we > > wouldn't try to support everything in tree. Magnum would > > provide support > > in-tree for 1 per COE and the COE driver interface would allow
others
to > add > > support for their preferred distro out of tree. Hongbin Lu I
agreed
the > > part that "we wouldn't try to support everything in tree". That
doesn't
> > imply the decision to support single distro. Again, support > > single distro > is > > a huge risk. Why make Magnum take this huge risk? [1] > > https://review.openstack.org/#/c/277284/ Best regards, Hongbin
On 03/13/2016 03:04 PM, Steve Gordon wrote:
----- Original Message -----
From: "Kai Qiang Wu" wkqwu@cn.ibm.com To: "Steve Gordon" sgordon@redhat.com Cc: "Ton Ngo" ton@us.ibm.com Sent: Saturday, March 12, 2016 5:07:17 AM Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
Hi Steve, I think what you did is rpm version, here is my finding:
[minion@k8-pdvmggl3ys-0-cdruybssooyh-kube-master-vtartl7oubyc ~]$ rpm -qa | grep kubernetes kubernetes-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-node-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-client-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-master-1.1.0-0.17.git388061f.fc23.x86_64 [minion@k8-pdvmggl3ys-0-cdruybssooyh-kube-master-vtartl7oubyc ~]$ kubectl version Client Version: version.Info{Major:"1", Minor:"0", GitVersion:"v1.0.6", GitCommit:"388061f00f0d9e4d641f9ed4971c775e1654579d GitTreeState:"clean"} Server Version: version.Info{Major:"1", Minor:"0", GitVersion:"v1.0.6", GitCommit:"388061f00f0d9e4d641f9ed4971c775e1654579d GitTreeState:"clean"}
It seems we should trust kubectl version, it is final version, it said v1.0.6.
Adding cloud@lists.fedoraproject.org. Folks, can you explain the reason for the discrepancy between the packages that appear to have been used to build the image and the tools themselves? Specifically looking at Fedora-Cloud-Atomic-23-20160308.x86_64.qcow2
There is some history behind that. There is a bug report for it here:
https://bugzilla.redhat.com/show_bug.cgi?id=1291860
The good news is that if you test out the kube 1.2 that is in updates testing and give it some karma we might be able to release close to the same time that kubernetes upstream releases 1.2:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-a89f5ce5f4
- Dusty
----- Original Message -----
From: "Dusty Mabe" dusty@dustymabe.com To: cloud@lists.fedoraproject.org
On 03/13/2016 03:04 PM, Steve Gordon wrote:
----- Original Message -----
From: "Kai Qiang Wu" wkqwu@cn.ibm.com To: "Steve Gordon" sgordon@redhat.com Cc: "Ton Ngo" ton@us.ibm.com Sent: Saturday, March 12, 2016 5:07:17 AM Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
Hi Steve, I think what you did is rpm version, here is my finding:
[minion@k8-pdvmggl3ys-0-cdruybssooyh-kube-master-vtartl7oubyc ~]$ rpm -qa | grep kubernetes kubernetes-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-node-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-client-1.1.0-0.17.git388061f.fc23.x86_64 kubernetes-master-1.1.0-0.17.git388061f.fc23.x86_64 [minion@k8-pdvmggl3ys-0-cdruybssooyh-kube-master-vtartl7oubyc ~]$ kubectl version Client Version: version.Info{Major:"1", Minor:"0", GitVersion:"v1.0.6", GitCommit:"388061f00f0d9e4d641f9ed4971c775e1654579d GitTreeState:"clean"} Server Version: version.Info{Major:"1", Minor:"0", GitVersion:"v1.0.6", GitCommit:"388061f00f0d9e4d641f9ed4971c775e1654579d GitTreeState:"clean"}
It seems we should trust kubectl version, it is final version, it said v1.0.6.
Adding cloud@lists.fedoraproject.org. Folks, can you explain the reason for the discrepancy between the packages that appear to have been used to build the image and the tools themselves? Specifically looking at Fedora-Cloud-Atomic-23-20160308.x86_64.qcow2
There is some history behind that. There is a bug report for it here:
Well sort of, it explains where the source for the package is coming from but it doesn't really help me understand whether I should trust the package versioning (1.1.0) or the versioning the packaged code reports (1.0.6) in the current image? The blog post linked in the bug also just glosses over this by reporting the package versions:
http://www.projectatomic.io/blog/2015/12/fedora-atomic-host-two-week-release...
From this one would make the same assumption I did - that it's 1.1.0, but is it actually?
The good news is that if you test out the kube 1.2 that is in updates testing and give it some karma we might be able to release close to the same time that kubernetes upstream releases 1.2:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-a89f5ce5f4
This does at least appear to report correctly as 1.2.0:
$ kubectl version Client Version: version.Info{Major:"1", Minor:"2", GitVersion:"v1.2.0", GitCommit:"cffae0523cfa80ddf917aba69f08508b91f603d5", GitTreeState:"clean"} Server Version: version.Info{Major:"1", Minor:"2", GitVersion:"v1.2.0", GitCommit:"cffae0523cfa80ddf917aba69f08508b91f603d5", GitTreeState:"clean"}
Which still leaves me wondering what is to be trusted when it comes to the version in the current image?
-Steve
There is some history behind that. There is a bug report for it here:
Well sort of, it explains where the source for the package is coming from but it doesn't really help me understand whether I should trust the package versioning (1.1.0) or the versioning the packaged code reports (1.0.6) in
It's really 1.0.6, and yes, it's really confusing.
Jason