search

istio / old_issues_repo

Deprecated issue-tracking repo, please post new issues or feature requests to istio/istio instead.
37 stars 9 forks source link

.0.8 latest can't pull the docker image #387

Open bfleming-ciena opened 6 years ago

bfleming-ciena commented 6 years ago

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

ymesika commented 6 years ago

You probably already figured it out but you need to provide --set global.tag=latest to your helm install/template command.

It probably should've hold the latest nightly build tag but we still don't have such since 0.8.0 release.

bfleming-ciena commented 6 years ago

Nope, had no clue I needed that. Thanks.

bfleming-ciena commented 6 years ago

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 -

bfleming-ciena commented 6 years ago

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

bfleming-ciena commented 6 years ago

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 -

ymesika commented 6 years ago

Sorry, right, 0.8.0 tag.

The docs are referring to the released packages. I believe that there the global.tag is set correctly. Isn't it?

costinm commented 6 years ago

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 notifications@github.com 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 https://github.com/istio/issues/issues/387#issuecomment-396127836, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFI6jK-Iu4P3WgED3F09cTKjCdAgg4Eks5t7gLngaJpZM4UhKzq .

ymesika commented 6 years ago

@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.

costinm commented 6 years ago

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 notifications@github.com 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 https://github.com/istio/issues/issues/387#issuecomment-396302731, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFI6qmZxwIErVNUV87LoYoFGNt72UtDks5t7pn8gaJpZM4UhKzq .

sakshigoel12 commented 6 years ago

cc @hklai

hklai commented 6 years ago

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.

costinm commented 6 years ago

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 notifications@github.com 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 https://github.com/istio/issues/issues/387#issuecomment-396790444, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFI6jbBZ5-yFbqtO3DtRbeZKHNJ_BXSks5t8HPdgaJpZM4UhKzq .

costinm commented 6 years ago

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 costin@gmail.com 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 notifications@github.com 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 https://github.com/istio/issues/issues/387#issuecomment-396790444, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFI6jbBZ5-yFbqtO3DtRbeZKHNJ_BXSks5t8HPdgaJpZM4UhKzq .

hklai commented 6 years ago

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?

veggiemonk commented 6 years ago

Either the build or the doc needs to be fixed.

Related:

costinm commented 6 years ago

On Wed, Jun 13, 2018 at 9:29 AM Andy Lai notifications@github.com 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 https://github.com/istio/issues/issues/387#issuecomment-397002342, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFI6l2s6GLh8CMLCB8T6tyVgGXvyH7gks5t8T4CgaJpZM4UhKzq .

costinm commented 6 years ago

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 costin@gmail.com wrote:

On Wed, Jun 13, 2018 at 9:29 AM Andy Lai notifications@github.com 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 https://github.com/istio/issues/issues/387#issuecomment-397002342, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFI6l2s6GLh8CMLCB8T6tyVgGXvyH7gks5t8T4CgaJpZM4UhKzq .

sdake commented 6 years ago

@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.

costinm commented 6 years ago

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 notifications@github.com 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 https://github.com/istio/old_issues_repo/issues/387#issuecomment-398151261, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFI6t7-VBTI0Biu-lUKKhqGG9cc1bqSks5t9_GmgaJpZM4UhKzq .

sdake commented 6 years ago

@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.

hklai commented 6 years ago

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.

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.)