Older URL format is what is needed until the change lands (targeted for beta4).
The URL based format for bundle charms is all that is supported by the original
local bundles work. The upcoming feature drop fixes that, as well as removing
the support for local charm URLs - all local charms, whether
So this means the older format should work? Antonio, have you poked through
that thread at the original working setup for local charms?
On Mon, Mar 28, 2016 at 9:45 PM Antonio Rosales <
antonio.rosa...@canonical.com> wrote:
>
>
> On Monday, March 28, 2016, Ian Booth wrote:
>
>> Hey Antonio
>>
>>
On Monday, March 28, 2016, Ian Booth wrote:
> Hey Antonio
>
> I must apologise - the changes didn't make beta3 due to all the work
> needed to
> migrate the CI scripts to test the new hosted model functionality; we ran
> out of
> time to be able to QA the local bundle changes.
>
> I expect this w
Hey Antonio
I must apologise - the changes didn't make beta3 due to all the work needed to
migrate the CI scripts to test the new hosted model functionality; we ran out of
time to be able to QA the local bundle changes.
I expect this work will be done for beta4.
On 29/03/16 11:04, Antonio Rosale
+ Juju list for others awareness
On Thu, Mar 10, 2016 at 1:53 PM, Ian Booth wrote:
> Thanks Rick. Trivial change to make. This work should be in beta3 due next
> week.
> The work includes dropping support for local repositories in favour of path
> based local charm and bundle deployment.
Ian,
Thanks Rick. Trivial change to make. This work should be in beta3 due next week.
The work includes dropping support for local repositories in favour of path
based local charm and bundle deployment.
On 10/03/16 23:37, Rick Harding wrote:
> Thanks Ian, after thinking about it I think what we want to
Thanks Ian, after thinking about it I think what we want to do is really
#2. The reasoning I think is:
1) we want to make things consistent. The CLI experience is present a charm
and override series with --series=
2) more consistent, if you do it with local charms you can always do it
3) we want t
I've implemented option 1:
error if Series attribute is used at all with a store charm URL
Trivial to change if needed.
On 10/03/16 12:58, Ian Booth wrote:
> Yeah, agreed having 2 ways to specify store series can be suboptimal.
> So we have 2 choices:
>
> 1. error if Series attribute is used a
Yeah, agreed having 2 ways to specify store series can be suboptimal.
So we have 2 choices:
1. error if Series attribute is used at all with a store charm URL
2. error if the Series attribute is used and conflicts
Case 1
--
Errors:
Series: trusty
Charm: cs:mysql
Series: trusty
Charm: cs:tr
Bah maybe you're right. I want to sleep on it. It's kind of ugh either way.
On Wed, Mar 9, 2016, 9:50 PM Rick Harding
wrote:
> I think there's already rules for charmstore charms. it uses the default
> if not specified. I totally agree that for local charms we have to have
> this. For remote cha
I think there's already rules for charmstore charms. it uses the default if
not specified. I totally agree that for local charms we have to have this.
For remote charms though this is providing the user two ways to do the same
thing
On Wed, Mar 9, 2016, 9:46 PM Ian Booth wrote:
> If the charm st
If the charm store charm defines a series in the URL, then we will consider it
an error to specify a different series using the attribute. But charm store URLs
are not required to have a series, so we can use the attribute in that case. It
also allows users to easily switch between store and local
I'm not sure we want to make this attribute apply to charmstore charms.
We've an established practice of the charmstore url being the series
information. It gives the user a chance to have conflicting information if
the charmstore url is cs:trusty/nova-compute and the series attribute is
set to xen
One additional enhancement we need for bundles concerns specifying series for
multi-series charms, in particular local charms now that the local repo will be
going away.
Consider:
A new multi-series charm may have a URL which does not specify the series. In
that case, the series used will be the
So to clarify what we'll do. We'll support the same syntax in bundle files as we
do for deploy.
Deploys charm store charms:
$ juju deploy cs:wordpress
$ juju deploy wordpress
Deploys a local charm from a directory:
$ juju deploy ./charms/wordpress
$ juju deploy ./wordpress
So below deploys a l
Long term we want to have a pattern when the bundle is a directory with
local charms in a directory next to the bundles.yaml file. We could not do
this cleanly before the multi-series charms that are just getting out the
door. I think that bundles with local charms will be suboptimal until we
can g
On 05/03/2016, Ian Booth wrote:
>>
>> How will bundles work which reference local charms? Will this work as
>> expected where nova-compute is a directory at the same level as a bundle
>> file?
>>
>> ```
>> series: trusty
>> services:
>> nova-compute:
>> charm: ./nova-compute
>> num_units
>
> Does this mean it won't be possible to deploy old single-series
> charms with Juju without modifying metadata.yaml to add the supported
> series?
>
You can use the --series argument
$ juju deploy ./trusty/mysql --series trusty
We could look at pulling the series out of the path if it's an
Hey Marco
>
> I'm a +1
>
> How will bundles work which reference local charms? Will this work as
> expected where nova-compute is a directory at the same level as a bundle
> file?
>
> ```
> series: trusty
> services:
> nova-compute:
> charm: ./nova-compute
> num_units: 2
> ```
>
The
Hi Marco,
What happens if I have a multi series/OS bundle:
```
series: trusty
services:
nova-compute:
charm: ./nova-compute
num_units: 2
nova-hyperv:
series: win2012hvr2 # is there a series override per charm ?
charm: ./nova-hyperv # this can run on win2012
Hi Ian,
We were just having a discussion about this for charm development. We
currently recommend the following setup for layered charms:
LAYER_PATH=$JUJU_REPOSITORY/layers
INTERFACE_PATH=$JUJU_REPOSITORY/interfaces
So you typically get
charms
├── deps
│ ├── interface
│ └── layer
├── interf
No, right now charms can be multiple series but must be of the same OS. If
there is truly portable code they can be wrapped as Layers to be shared
among the charms, but in practice, it turns into to much ifdef style
development that's difficult to debug and things like resources that are
vastly dif
2016-03-04 8:55 GMT+03:00 Ian Booth :
> Hopefully everyone is aware that Juju 2.0 and the charm store will support
> multi-series charms. To recap, a multi-series charm is one which can declare
> that it supports more than just the one series; you no longer need to have a
> separate copy of the cha
On 4 March 2016 at 05:55, Ian Booth wrote:
> Hi folks
>
> TL;DR we want to remove support for old style local charm repositories in
> Juju 2.0
>
> Hopefully everyone is aware that Juju 2.0 and the charm store will support
> multi-series charms. To recap, a multi-series charm is one which can decl
Hi folks
TL;DR we want to remove support for old style local charm repositories in Juju
2.0
Hopefully everyone is aware that Juju 2.0 and the charm store will support
multi-series charms. To recap, a multi-series charm is one which can declare
that it supports more than just the one series; you
25 matches
Mail list logo