You're using local charms (./xenial/mongodb) so it's hard to know for sure exactly what you're deploying without having the full set of files.
If it is the same as the "official" mongodb: https://jujucharms.com/mongodb/ Then it has several bindings that aren't listed in your bundle. Your bundle states: bindings: internal: internal-api shared-db: internal-api public: internal-api admin: internal-api However, the upstream charm https://api.jujucharms.com/charmstore/v5/mongodb/archive/metadata.yaml has: nrpe-external-master database configsvr data benchmark mongos-cfg mongos replica-set Now, these clearly are slightly different, as the upstream mongodb doesn't have an "internal", "public", or "admin", and those all look very suspiciously like very generic bindings on Openstack charms (which may or may not be relevant on the mongdb charm.) I'll also note that "juju deploy" appears to not be strict about "bindings". If a value listed in bindings matches an endpoint, we will use it, but we don't warn or fail if a name listed in bundle.yaml doesn't exist. However, you can bind all endpoints of a service using "" as the binding name. So you should be able to do: mongodb: charm: ./xenial/mongodb num_units: 1 bindings: "": internal-api to: - "lxd:nodes/0" The "" binding will set a default binding for all endpoints in the application. You should be able to mix it with concrete bindings as well, so if you wanted to change one of them, you should be able to do (eg): mongodb: charm: ./xenial/mongodb num_units: 1 bindings: "": internal-api shared-db: admin-api to: - "lxd:nodes/0" John =:-> On Sat, Feb 4, 2017 at 2:14 PM, Narinder Gupta <narinder.gu...@canonical.com > wrote: > Hi Nicholas, > I am finding issues when do the deployment. Bundle i used to deploy with > juju 2.1-beta4 does not get deployed with juju-2.1-beta5. > > Reason of that is mongodb lxd container still waiting to get machine which > was not the case for juju 2.1-beta4 > mongodb/0 waiting allocating 0/lxd/3 > waiting for machine > > You can see here http://pastebin.ubuntu.com/23924329/ all services came > up except mongodb and openfv-promise. I can confirm that if I switch to > beta4 everything works. Here is the bundle i am deploying > http://paste.ubuntu.com/23924334/ > > > > Thanks and Regards, > Narinder Gupta (PMP) narinder.gu...@canonical.com > Canonical, Ltd. narindergupta [irc.freenode.net] > +1.281.736.5150 narindergupta2007[skype] > > Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com > > > On Fri, Feb 3, 2017 at 5:54 PM, Nicholas Skaggs < > nicholas.ska...@canonical.com> wrote: > >> The Juju team would like to introduce Juju and conjure-up 2.1-beta5! The >> most visible changes are to container networking and that juju controllers >> now expose Prometheus metrics over an HTTPS endpoint. Finally, conjure-up >> is also a snap, provides juju, and can be installed on trusty as a snap as >> well! >> >> We would especially like feedback on the container networking changes. Do >> let us know of your experiences, and feel free to open bugs and threads to >> discuss. >> >> ## What’s New in Beta 5 >> >> [conjure-up] Now snapped for Trusty and Xenial. >> [conjure-up] Support for Canonical Kubernetes 1.5.2. >> [conjure-up] Ability to teardown models with the new `conjure-down` >> command. >> [juju] Container networking improvements: >> - LXD and KVM guests no longer join all spaces on the host >> machine, but use constraints and bindings to determine what spaces should >> be used >> - Bridges are not created during provisioning, but only created on demand >> for containers that will use them. >> - For clouds other than MAAS, we continue to put containers onlocal >> bridges (lxdbr0) >> [juju] Juju ssh/scp now selects correct address to use to connect to >> the controller. >> [juju] Model config now supports an "extra-info" field for holding >> additional metadata. >> [juju] More memory leaks have been addressed. >> [juju] Stricter rules for validating charm metadata field names to >> conform to data storage requirements. Charm metadata fields can not contain >> dots. >> [juju] controllers now expose HTTPS endpoints under >> “/introspection/”, accessible to controller superusers, and users with read >> access to the controller model:/introspection/debug/pprof/profile, >> /introspection/depengine/,/introspection/metrics. >> >> >> ## Bugs Addressed >> >> Check the milestones for a detailed breakdown of juju and conjure-up bugs >> corrected. >> >> https://launchpad.net/juju/+milestone/2.1-beta5 >> >> https://github.com/conjure-up/conjure-up/milestone/14?closed=1 >> >> ## How do I get it? >> >> If you are running Ubuntu, you can get Juju from the juju devel ppa: >> >> sudo add-apt-repository ppa:juju/devel; sudo apt-get update >> >> sudo apt-get install juju >> >> Or install Juju from the snap store: >> >> snap install juju --beta --devmode >> >> Install conjure-up from the snap store: >> >> snap install conjure-up --classic --beta >> >> If you are on Trusty, you'll need to run a few extra commands: >> sudo apt-get install snapd >> sudo groupadd lxd && sudo usermod -a -G lxd $USER >> sudo reboot >> >> Now you can install snaps, including conjure-up, as normal: >> snap install conjure-up --classic --beta >> >> Windows, Centos, and macOS users can get a corresponding Juju installer >> at: >> >> https://launchpad.net/juju/+milestone/2.1-beta5 >> >> ## Feedback Appreciated! >> >> We encourage everyone to let us know how you’re using Juju. Send us a >> message on Twitter using #jujucharms, join us at #juju on freenode, and >> subscribe to the mailing list at juju@lists.ubuntu.com. >> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
