Re: official images status quo
On 12 May 2013 22:34, Stefano Zacchiroli <email@example.com> wrote:
> On Sun, May 12, 2013 at 04:01:42PM -0400, Jimmy Kaplowitz wrote:
>> but honestly I'm not all that eager to continue what feels like petty
>> quibbling about the status quo since we all want the same basic
>> outcome here and nobody's acting in bad faith. Lucas's original
>> wording was AIUI not intended as a final judgment but as a starting
> I've no idea why you took it that way, but I can assure you that I had
> very productive reasons to ask the questions I've asked, far from being
> "petty quibbling". If I expressed myself badly, giving you that
> impression, I apologize.
> So, what I've had in mind since very long time (as readers of this list
> know) is to advertise more broadly than we currently have done the
> "official" images we have. Therefore the reasons for my questions was to
> understand if, as you seemed to believe, none of the current images we
> currently have qualify for some official communication by the project.
> From this sub-thread, which I consider quite productive in fact, I think
> we can conclude that at least the EC2 images "roughly qualify". There
> are things that can be done better, certainly, and in particular:
> - the used euca2ools version (Anders, if you've a moment, can you
> explain if there are blockers that stop you from using one of the
> euca2ools version available in Debian, and in particular version
> 2.0.2-1 which is now in Debian stable)
> - the boto patch pulled from a BTS: is there any reason not to at least
> copy that patch in the build-debian-cloud repo? I think that would be
> an improvement and, actually, not that different from our usual
> practices (we do routinely embed 3rd party patches in package source
> Do we agree that, once the above is done, the EC2 images would be fine
> for being Debian-stamped? Note that I do agree that having a proper
> *package* of build-debian-cloud would be even better, but I note that
> that's a higher quality standard than the rest of the Debian toolchain,
> which IMHO shouldn't be a blocker.
> Now, that's for the EC2 images, only because I'm a little bit more
> familiar with them than with the other ones. I'd love if people
> familiar with Azure and GCE images can do similar analyses and report
> here, at least what the major blockers wrt the criteria as we understand
> them up to now.
> Once we have a better understanding of the blockers, probably, it would
> be useful to report them as bugs against cloud.d.o.
>> It's probably more productive to refine the list of requirements Lucas
>> has kindly recorded in the wiki, maybe culminating in a discussion/BoF
>> at DC13, and to work to address outstanding issues. Any email
>> pre-discussion should probably be under a more descriptive subject
>> than "Adding cloud-init in the next Wheezy point release", too. :)
> I totally agree that would be useful as well. Feel free to start a
> thread on that, I'll be happy to participate :-) FWIW, I think that
> benchmarking the current images against our current understanding of the
> criteria (as I propose above) would actually be synergistic with what
> you propose here.
> Stefano Zacchiroli . . . . . . . firstname.lastname@example.org . . . . o . . . o . o
> Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
> Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o .
> « the first rule of tautology club is the first rule of tautology club »
> Anders, if you've a moment, can you explain if there are blockers that stop you from using one of the euca2ools version available in Debian, and in particular version 2.0.2-1 which is now in Debian stable
I had to check the source to figure out my original reasoning for that
:-), it says:
# We use euca2ools to communicate with AWS
# The package in squeeze is v 1.2, which does not support EBS images
Are we still concerned with bootstrapping *from* squeeze? Otherwise we
can easily just use the one from the repo.
> the boto patch pulled from a BTS: is there any reason not to at least copy that patch in the build-debian-cloud repo? I think that would be an improvement and, actually, not that different from our usual practices (we do routinely embed 3rd party patches in package source packages)
No reason; not sure why I haven't done that long ago. I have to check
if this is fixed in wheezy, maybe we can avoid it entirely, or simply
fix it in the repo.
If we do those things, we can install *everything* from the repo, no
third-party stuff needed.