Giter Club home page Giter Club logo

Comments (4)

silvin-lubecki avatar silvin-lubecki commented on June 21, 2024

Hello @doanac , thank you for filling this feature request.
I'll put here some thoughts about it:

This feature will have sense only if you target a single engine with swarm enabled (which is your case I guess), or which would be the case for a developer running the app on her own host.
But regarding a cluster, only one daemon will pull the images, not all the nodes, so this may not be what's expected (as you don't know which node will execute the workload, so all the nodes but the one targeted will pull the images). A workaround would be to run the docker app pull --include-services on all the nodes 🤔.
Another "issue" is when you have 2 contexts (using --installer-context flag), one to execute the invocation image and the one where you actually run the app itself. It means that only the context running the invocation image (usually the local host and the current context) would have pull the images, which is pretty useless 😅 .

That being said, this feature looks a lot like docker-compose pull, and as it's an optional flag and not the default behavior, I guess it's OK to assume the user has the responsibility to check which node is actually pulling the images 👍 Maybe could we make it a little more explicit with an output explaining which node/context is actually pulling? @thaJeztah any thoughts?

from app.

doanac avatar doanac commented on June 21, 2024

Good point about multi nodes and contexts. I guess we have a bit of an edge case. I'm happy to put notes on the flag saying its a little weird. And if its really too awkward for your team to carry this change, I think I could find away to keep this patch in our OE recipe for build docker-app. That said- pushing upstream is always more desirable from my end :)

from app.

silvin-lubecki avatar silvin-lubecki commented on June 21, 2024

@doanac Please open a PR with your code changes 👍
It would be great to add a test somehow, maybe an e2e test? Please reach me if need help for that!

from app.

dberardo avatar dberardo commented on June 21, 2024

i dont know if this links to a problem i am having, but basically when i run the application, the stack is created properly, but the service dont fire up because they dont find their respective images.

The solution is to manually pull each single image for the individual services manually, so i am wondering ... is it possible to automate this process like it would happen normally in swarm? i cannot understand why this does not happen already

from app.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.