Hi Nicholas,

On Mon, Sep 12, 2016 at 06:47:31PM -0400, Nicholas Skaggs wrote:
> On 09/07/2016 04:57 PM, Nicholas Skaggs wrote:
> >Hello all. I'd like to discuss the removal of 32-bit architectures from
> >the juju-core source package. The current packaging in the xenial and
> >yakkety archive for juju-core specifies it's architecture as 'All'. This
> >was an oversight as we officially support only the following
> >architectures:

> >amd64 ppc64el arm64 s390x

> >We don't test or support 32-bit builds of juju. This is in-line with the
> >clouds upon which juju runs which don't support 32-bit servers, as well as
> >our own support of xenial server and mitaka -- 64-bit only.

> >With this in mind, I'd like to update the archive packaging in both xenial
> >and yakkety to remove these unsupported builds. I realize removing
> >previously published binaries from the xenial archive isn't ideal, however
> >we cannot update the current packages in order to deal with changes in
> >cloud providers.

> >I am looking for feedback and help to accomplish this. I would propose the
> >following, but am open to other ideas to best accomplish this task.

> >1) Upload a new conjure-up package to xenial and yakkety that changes the
> >architecture to 'Any'

From my POV this is not required.  Anyway, changing its architecture to
'any' would probably not be what you want since that would still build the
package on all architectures; if you were going to change it at all,
presumably you would want to restrict the architecture list, or add the same
kind of warning-message-on-upgrade dummy package.  But provided that we are
handling the architectures appropriately in juju-core itself, I don't think
you need to change anything in conjure-up.

> >2) Upload a new juju-source package to xenial and yakkety that:
> >        -- specifies the architecture as 'amd64 ppc64el arm64 s390x'
> >        -- provides a second binary package for 32-bit users that ensures
> >they upgrade to a message informing them the package isn't supported.

This seems like the best available option.  Ideally we would not get
ourselves in the situation in the first place that a package we can't
support has made it into a release.  But seeing that we're here, I think
it's better to bite the bullet now rather than let it drag on further.

> >I want to ensure a smooth experience for anyone who installed a 32-bit
> >version of juju on xenial. It is not found on any images, and juju itself
> >is not yet final. Production deployments should still be utilizing juju-1.
> >I would like to remove this package before wider adoption as juju2 enters
> >RC and final release stages. I would especially appreciate ideas about
> >ensuring a good upgrade story for current users. I don't suspect there are
> >many at all, but I don't want to leave unsupported and abandoned packages
> >in the archive.

> I'd like to update this mailing to reflect a series of discussions today on
> #ubuntu-devel surrounding this topic. It has been proposed that a solution
> be found to provide as much support for the existing 32-bit packages as
> possible. I've requested the juju-core team to provide compile-time support
> for disabling providers as a means to mitigate issues where upstream code
> stops support for 32-bit builds. For 32-bit users, they will retain support
> to the extent possible for providers on a best effort basis.

> Most importantly, I trust this relieves my concerns about the inability to
> landed needed SRU's and regular updates in the development version of ubuntu
> due to a failing build in an unsupported architecture. I'd like to thank
> everyone involved for there feedback and discussions. For now, consider this
> request canceled.

This implies that the package will be available on 32-bit now, but that you
are not committing to keep that package free of functional regressions in
SRU on 32-bit architectures.  That seems much worse, to me, than disabling
the package altogether on 32-bit now, or immediately disabling all the
providers that upstream has not committed to providing 32-bit support for.

One of the arguments made for why it's ok to drop the 32-bit package right
now in xenial is that juju 2 is not yet at its final release and isn't yet
used in production.  Tabling this request "for now" just means that the next
time it comes up, it will have much worse impact on the end user.  Let's
please sort out now what the juju team can commit to support on 32-bit for
the lifetime of the LTS and do that, rather than pulling the rug out from
under the users later.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slanga...@ubuntu.com                                     vor...@debian.org

Attachment: signature.asc
Description: PGP signature

Ubuntu-release mailing list
Modify settings or unsubscribe at: 

Reply via email to