Default-Image-Id

[anirup dutta]

I can understand the inclination towards not supporting image ids in case
of Juju. However for small community of people who use juju to deploy
instances to do some experiments and tore them down after few hours, the
amount of time it takes to setup the instances is huge. I am talking about
experiments where I am going to deploy instances in range of hundreds. In
such a case starting with vanilla version and making all the changes takes
time since, I am not talking of a simple customized but a heavily
customized ami.

Anyway thanks for all your comments. I think running a older version of
pyjuju which supported image ids would serve my purpose.


On Mon, Apr 22, 2013 at 6:17 AM, Marco Ceppi <marco.ceppi at canonical.com>wrote:

> I think it is and was depreciated based on a decision made at either UDS-Q
> or UDS-R. The topic came up during what should be included in machine
> constraints. As I recall there was a bit of discussion but the end result
> was that support different image-id's was a bad implementation of the
> machine constraints as most anything you could add at the image level could
> be achieved with a charm. The idea is to provide a consistent base that is
> mostly universal between all charms and that base as it became was the
> cloud images. The logistics of questions like "how do we handle charms that
> need custom images", and the like, become far more complex to support than
> what we currently have. I think at this point it might be worth a
> discussion again but I agree with the original decision to remove it from
> pyjuju and would be an advocate for not implementing it in future versions.
> I will hunt through the etherpads to find the session that this came up in
> if anyone is interested in the reference.
>
> Thanks,
> Marco Ceppi
>
>
> On Mon, Apr 22, 2013 at 12:32 AM, Tim Penhey <tim.penhey at canonical.com>wrote:
>
>> On 22/04/13 16:29, Ian Booth wrote:
>> > Hi
>> >
>> > On 22/04/13 13:41, anirup dutta wrote:
>> >> Hey Ian,
>> >>
>> >> Thanks for the information. I am kind of surprised because, the earlier
>> >> versions of Juju allowed specifying a user defined default image by
>> putting
>> >> it up in the environmental configuration (
>> >> https://juju.ubuntu.com/docs/provider-configuration-ec2.html) so I
>> didn't
>> >> expect the feature to be removed. Good to hear that it is making a
>> >> comeback.
>> >>
>> >
>> > The documentation you refer to is for the old Python version of juju,
>> which is
>> > being replaced in 13.04 with a version written in Go. Both versions
>> will be able
>> > to co-exist but the Go version is the way forward. In the new version,
>> the use
>> > of default-image-id is currently deprecated as a means to explicitly
>> choose a
>> > specific image to run (that's *my* understanding at least).
>>
>> I don't think it is deprecated, just not implemented.
>>
>> Getting constraints right is a big hunk of work, and it is work in
>> progress.  I think the development team is in agreement that we should
>> support instance-id as a valid constraint as people will want it,
>> however it is not currently implemented.
>>
>>
>> Cheers,
>> Tim
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>


-- 
Anirup Dutta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130422/3cd3e76c/attachment.html>