<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 23, 2016 at 1:03 PM, roger peppe <span dir="ltr"><<a href="mailto:roger.peppe@canonical.com" target="_blank">roger.peppe@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 23 March 2016 at 15:06, David Ames <<a href="mailto:david.ames@canonical.com" target="_blank">david.ames@canonical.com</a>> wrote:<br>
> On 03/21/2016 06:54 PM, Stuart Bishop wrote:<br>
>><br>
>> On 22 March 2016 at 11:42, Rick Harding <<a href="mailto:rick.harding@canonical.com" target="_blank">rick.harding@canonical.com</a>><br>
>> wrote:<br>
>>><br>
>>> I believe that went out and is ok Stuart. The charmstore update is<br>
>>> deployed<br>
>>> and when you upload a multi-series charm to the charmstore it creates<br>
>>> separate charms that work on older clients. If you hit issues with that<br>
>>> please let me know.<br>
>><br>
>><br>
>> Its only fixed for charms served from the charm store. CI systems and<br>
>> such test branches, for example ensuring tests pass before uploading a<br>
>> release to the charm store. I suspect this is exactly what Ryan needs<br>
>> to do and why I mentioned the open bug. Unless 1.25 is updated to<br>
>> handle the different data types, CI systems will need to work around<br>
>> the issue by either roundtripping through the charm store (in a<br>
>> personal namespace to avoid mid air collisions) or munging<br>
>> metadata.yaml.<br>
<br>
</span>ISTM that munging metadata.yaml could be a reasonable way<br>
to go here. It's not too hard. Here's a program you could use:<br>
<a href="http://play.golang.org/p/xl7yArJhtT" rel="noreferrer" target="_blank">http://play.golang.org/p/xl7yArJhtT</a><br>
<div><div><br></div></div></blockquote><div><br></div><div>Indeed that is an option, and that approach would require additional work on other tooling to enable metadata munging for 1.25.x use.  Such as:  bundletester, amulet, mojo, juju-deployer.</div><div><br></div><div>Whereas, if it is addressed in `juju deploy` for 1.25.x, then it's addressed in one place for every scenario that I've observed.<br></div><div><br></div><div>To summarize:<br></div><div>If we do nothing with regard to juju 1.25.x or the various tools, and if a relevant charm grows a series list in metadata, a load of existing validation and demo bundles will no longer be deployable with 1.25.x because `juju deploy` on 1.25.x traces when receiving a list type as a metadata series value.  These type of bundles often point at gh: and lp: charm dev/feature branches, so the charm series metadata is as it is in the dev charm's trunk (unmodified by the charm store).<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
</div></div></blockquote></div><br></div></div>