.0.8 latest can't pull the docker image #387
Comments
|
You probably already figured it out but you need to provide It probably should've hold the latest nightly build tag but we still don't have such since 0.8.0 release. |
|
Nope, had no clue I needed that. Thanks. |
|
Hmm, I trried this for the master branch and got this error. Warning Failed 10s (x2 over 31s) kubelet, realdev-kube-worker-2 Failed to pull image "docker.io/istio/proxyv2:latest": rpc error: code = Unknown desc = Error response from daemon: manifest for istio/proxyv2:latest not found helm template install/kubernetes/helm/istio --set global.tag=latest --name istio --namespace istio-system --set tracing.enabled=true | kubectl create -f - |
|
Didn't work. I can't remember how I installed htis originally. But when trying to use the github repo I can't install from master or 0.8 now. helm template install/kubernetes/helm/istio --set global.tag=latest --name istio --namespace istio-system --set tracing.enabled=true | kubectl create -f - Warning Failed 11s kubelet, realdev-kube-worker-2 Failed to pull image "docker.io/istio/proxyv2:latest": rpc error: code = Unknown desc = Error response from daemon: manifest for istio/proxyv2:latest not found |
|
Ok, got it. Did I miss something somewhere in the docs that indicated I had to set this global.tag option? helm template install/kubernetes/helm/istio --set global.tag=0.8.0 --name istio --namespace istio-system | kubectl create -f - |
|
Sorry, right, The docs are referring to the released packages. |
|
The released packages (0.8.0) need to be labeled with 0.8.latest as well.
Unfortunately the release scripts don't do this yet - someone needs to
manually label the packages until scripts are updated.
The default install from each branch should be able to pick the latest
images - the published release is pinned to a version (and may by old/out
of date).
Master should point to the automatically nightly builds.
…On Sun, Jun 10, 2018 at 10:40 PM Yossi Mesika ***@***.***> wrote:
Sorry, right, 0.8.0 tag.
The docs are referring to the released packages
<https://github.com/istio/istio/releases>.
I believe that there the global.tag is set correctly. Isn't it?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#387 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAFI6jK-Iu4P3WgED3F09cTKjCdAgg4Eks5t7gLngaJpZM4UhKzq>
.
|
|
@costinm I think it's the images in the docker hub that needs to be tagged with |
|
Yes, someone in rel team needs to do it ( or write a script so this is done
automatically for releases )
…On Mon, Jun 11, 2018 at 9:25 AM Yossi Mesika ***@***.***> wrote:
@costinm <https://github.com/costinm> I think it's the images in the
docker hub that needs to be tagged with 0.8.latest.
I would do it but I don't think I have permissions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#387 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAFI6qmZxwIErVNUV87LoYoFGNt72UtDks5t7pn8gaJpZM4UhKzq>
.
|
|
cc @hklai |
|
I doubt anyone had given much thought about installing from a release branch instead of using the release artifacts. It is unclear to me if 0.8.latest is latest cutting edge build or latest stable build. If former, we currently do not even push to docker hub. Similarly, we do not label "latest" in the daily release on master either. |
|
We do label latest in nightly builds in circleci - and we did put quite a
bit of thought into this. And for master
using the helm has worked for quite a while, based on the nightly label
from circleci.
The 'release artifacts' will probably not include helm charts - the plan
for 1.0 is to have the helm charts in the helm repositories,
so helm users can install Istio without having to download a release, with
just "helm install", as any other helm application.
Users who use 'helm template' or 'istioctl gen-deploy' may still need to
download the release, so will users who manually
inject.
…On Tue, Jun 12, 2018 at 7:07 PM Andy Lai ***@***.***> wrote:
I doubt anyone had given much thought about installing from a release
branch instead of using the release artifacts.
It is unclear to me if 0.8.latest is latest cutting edge build or latest
stable build. If former, we currently do not even push to docker hub.
Similarly, we do not label "latest" in the daily release on master either.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#387 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAFI6jbBZ5-yFbqtO3DtRbeZKHNJ_BXSks5t8HPdgaJpZM4UhKzq>
.
|
|
Sorry - helm charts will be included in release artifacts for helm tempate
users only - users of tiller (full helm) will not require
the templates from the release.
…On Tue, Jun 12, 2018 at 11:25 PM Costin Manolache ***@***.***> wrote:
We do label latest in nightly builds in circleci - and we did put quite a
bit of thought into this. And for master
using the helm has worked for quite a while, based on the nightly label
from circleci.
The 'release artifacts' will probably not include helm charts - the plan
for 1.0 is to have the helm charts in the helm repositories,
so helm users can install Istio without having to download a release, with
just "helm install", as any other helm application.
Users who use 'helm template' or 'istioctl gen-deploy' may still need to
download the release, so will users who manually
inject.
On Tue, Jun 12, 2018 at 7:07 PM Andy Lai ***@***.***> wrote:
> I doubt anyone had given much thought about installing from a release
> branch instead of using the release artifacts.
>
> It is unclear to me if 0.8.latest is latest cutting edge build or latest
> stable build. If former, we currently do not even push to docker hub.
>
> Similarly, we do not label "latest" in the daily release on master either.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#387 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AAFI6jbBZ5-yFbqtO3DtRbeZKHNJ_BXSks5t8HPdgaJpZM4UhKzq>
> .
>
|
|
I can't say it is well thought of when something depends on circle nightly builds that is different from the regular daily releases maintained by the release team. If we continue that approach circle should probably build nightly from release-0.8 (and other release branches) and label 0.8.latest (and newer releases later). Otherwise we should kill circle nightly and make sure daily releases label accordingly as well. And with Tiller, I suppose it can just take the release label (i.e. 0.8.0) without requiring the templates from the release, right? |
Related to: * istio#1533 * istio/old_issues_repo#387 * istio/istio#6348
|
Either the build or the doc needs to be fixed. Related: |
|
On Wed, Jun 13, 2018 at 9:29 AM Andy Lai ***@***.***> wrote:
I can't say it is well thought of when something depends on circle nightly
builds that is different from the regular daily releases maintained by the
release team.
If it is maintained by developers and uses circle - it doesn't mean it is
not 'well thought'.
If we continue that approach circle should probably build nightly from
release-0.8 (and other release branches) and label 0.8.latest (and newer
releases later).
We should certainly label 0.8.latest. It can be done manually - but it
needs dockerhub permissions.
I believe circle is building nightly from release-0.8 - but it doesn't have
permissions to 'istio' repo (and probably not a good idea to give it that
permission).
Circle is using istionightly dockerhub, and should label last build.
Otherwise we should kill circle nightly and make sure daily releases label
accordingly as well.
Why kill circle nightly ??? It is the one that works with lastest.
Kill the daily releases if you want to kill something, or fix them.
And with Tiller, I suppose it can just take the release label (i.e. 0.8.0)
without requiring the templates from the release, right?
That would require for each build to update helm templates, which will be
in a different repo.
And for master - the templates will still be harder to use if we moved back
to daily builds and SHAs.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#387 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAFI6l2s6GLh8CMLCB8T6tyVgGXvyH7gks5t8T4CgaJpZM4UhKzq>
.
|
|
Note that the tags are a bit different now that circle builds from release,
the helm templates in the branches and master will need to use
the new tags. This can be extended to development/shared branches as well,
to make it easy to test the latest nightly build
https://hub.docker.com/r/istionightly/pilot/tags/
This also works with tools like 'keel' which can update automatically.
…On Mon, Jun 18, 2018 at 12:47 AM Costin Manolache ***@***.***> wrote:
On Wed, Jun 13, 2018 at 9:29 AM Andy Lai ***@***.***> wrote:
> I can't say it is well thought of when something depends on circle
> nightly builds that is different from the regular daily releases maintained
> by the release team.
>
If it is maintained by developers and uses circle - it doesn't mean it is
not 'well thought'.
> If we continue that approach circle should probably build nightly from
> release-0.8 (and other release branches) and label 0.8.latest (and newer
> releases later).
>
We should certainly label 0.8.latest. It can be done manually - but it
needs dockerhub permissions.
I believe circle is building nightly from release-0.8 - but it doesn't
have permissions to 'istio' repo (and probably not a good idea to give it
that permission).
Circle is using istionightly dockerhub, and should label last build.
> Otherwise we should kill circle nightly and make sure daily releases
> label accordingly as well.
>
Why kill circle nightly ??? It is the one that works with lastest.
Kill the daily releases if you want to kill something, or fix them.
> And with Tiller, I suppose it can just take the release label (i.e.
> 0.8.0) without requiring the templates from the release, right?
>
That would require for each build to update helm templates, which will be
in a different repo.
And for master - the templates will still be harder to use if we moved
back to daily builds and SHAs.
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#387 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AAFI6l2s6GLh8CMLCB8T6tyVgGXvyH7gks5t8T4CgaJpZM4UhKzq>
> .
>
|
|
@stonefury typically the model for running master containers is to build them yourself. I guess some folks are using the nightly builds, and it sounds like some folks are using the circleci builds, but if you really want the manifest implementation to match the code in the container implementation, self-building is required. |
|
Some people like to build istio. Others just want to run or test latest
build from a branch.
The default value in helm can't be the self build - since it's changing all
the time. And it shouldn't be something old or invalid. So the only option
for the default is a label - not sure what is controversial about it. Is
there any other option for the default value?
…On Mon, Jun 18, 2018, 20:29 Steven Dake ***@***.***> wrote:
@stonefury <https://github.com/stonefury> typically the model for running
master containers is to build them yourself. I guess some folks are using
the nightly builds, and it sounds like some folks are using the circleci
builds, but if you really want the manifest implementation to match the
code in the container implementation, self-building is required.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#387 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAFI6t7-VBTI0Biu-lUKKhqGG9cc1bqSks5t9_GmgaJpZM4UhKzq>
.
|
|
@costin I find nothing all that controversial about it. I was simply pointing out the status quo. Agree that the default shouldn't be self-build. Without a constantly trailing functional container implementation, the container implementation and manifest implementation become de-synchronized (and assume developers are running on the latest master). With appropriate caveats about using daily builds, even if tested, I don't see a problem. |
The official daily release (the one that we document in github/wiki/etc) also builds with latest on different branches. And we have a plan to have it push images to dockerhub with appropriate tags as well. Having two systems is an overhead, even if you sign up to maintain/fix the circle nightly. (To be clear my point is that we should have one system making daily/nightly releases. It can be prow, circle or anything else, but at the moment circle not the one supported by the release team.) |
Related to: * istio#1533 * istio/old_issues_repo#387 * istio/istio#6348
I'm sorry if I'm just missing something here but I pulled the 0.8.0 branch and trying to install with helm and getting.
Failed to pull image "docker.io/istio/proxyv2:0.8.latest": rpc error: code = Unknown desc = Error response from daemon: manifest for istio/proxyv2:0.8.latest not found
The text was updated successfully, but these errors were encountered: