I still like the idea of overloading the --to flag rather than having
a new --map-machines flag. It's concise and fits well, I think - we
want the machines in this bundle to mapped *to* the machines we're
specifying here.
I like the thrust of Tim's suggestion for "existing" but I'm not
entirely
I think it's nice to reuse --to because we don't use it with bundles on
juju deploy. A unified --map[-machines] would also be fine to me.
:= ( |
)=(
| )
--to ([,]+[,:] ) | :
Remap two, otherwise use existing:
--to 1=2,3=5,:
The same with app names, but have to error out on lxd:1 or kvm:5 in a
No we aren't going to reuse --to.
The --to directive is just for placement directives. Trying to use that
to overload machine mappings for bundles adds complexity for no real value.
We will use --map-machines. I'm a big proponent of explicit is better
than implicit.
While I'm not 100% fixed on
On 10/11/17 12:12, Dmitrii Shcherbakov wrote:
> It's situations like the following that I am trying to avoid:
>
> rabbitmq-server:
> charm: cs:xenial/rabbitmq-server
> bindings:
> "": *oam-space
> amqp: *internal-space
> cluster: *internal-space
> options:
>
Tim,
Whichever works best in terms of code-base clarity and stability - it's
hard to debug spaghetti code with lots of overrides so fully agreed on --to.
"existing" sounds good to me. I only have to do it once and it's easy to
remember. Extra 3 characters to type are irrelevant when you type 300
Is it possible to accomplish the following using a bundle?
`juju deploy --bind "default-space db=db-space db-admin=admin-space" mysql`
thanks
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
A new development release of Juju is here, 2.3-beta3. This is primarily a
bug fix release which addresses issues carried over from beta2.
## New and Improved
* A new command "remove-saas", aliased to "remove-consumed-application", is
added to remove a SAAS entry from a consuming model.
*
