Removing 32-bit architectures from juju-core source package

Wed Sep 21 06:29:02 UTC 2016

On Tue, Sep 20, 2016 at 10:35:51AM -0400, Nicholas Skaggs wrote:
> >>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.

> I agree it's better to cut this off now rather than later. That was the
> initial point of my mail, and my continuing concern with shipping packages
> that don't have upstream support. The counter-arguments given in response to
> my initial mail pointed out that juju is not unique in this regard and that
> efforts should be made to support 32-bit.

It would be nice if those who feel that way would present those
counter-arguments here for discussion, rather than putting you in the middle
:)

But in fact, there's a lot about juju that's unique (or at least, not
default).  We have a standing SRU exception for this package that says we
will track upstream for client-server compatibility; the upstream is
dependent on third-parties for some of the components, and upstream is not
in a position to extract a committment for 32-bit architecture support from
those third-parties; and upstream themselves never consciously committed to
supporting 32-bit architectures in the first place under the SRU exception -
the package was marked Architecture: any in error.

So there's a lot here that argues that juju is different.  We should treat
the package appropriately for the circumstances.

> My concerns haven't gone away; I think removing the package and being
> clear to users about what is supported is a "better" user experience, but
> I am open to feedback that would seek alternative solutions.  My concern
> either way is that we're blocked on fixing issues because of 32-bit
> failures later on, which I consider a big risk.  The proposal of making it
> so we could simply disable the broken bits on 32-bit and retain as much as
> we can was a reasonable request, and one I wanted to try and fulfill.

*If* the juju team are willing to support a subset of the package
functionality on 32-bit archs, then it's ok for them to decide to do this,
disabling those features that they can't or won't support.  But whatever
pieces are made available on 32-bit should then be supported for the
duration of the LTS; we shouldn't be having this conversation again in 6
months or 2 years because supporting 32-bit has gotten too hard.

> I also agree that now is the time to decide, hence my mails. I felt the risk
> of "dropping" a 32-bit package, while never an ideal thing, was best done
> now early in the cycle and before adoption. If we think there is any chance
> the package would have to be removed during the course of the cycle, I would
> be firmly in the camp of removing it now. I'm also concerned about the value
> and overhead that will be placed on keeping the 32-bit package useful over 5
> years. Speaking as a user personally, I really don't like neutered packages.
> They are like landmines sometimes; I've personally been bitten by this on
> armhf. I laid out a worst case scenario of having a juju package that works
> only with the local provider. Others felt would this would retain value even
> if that came to pass (which I agreed wasn't the most likely outcome at the
> time). I think if there is value even in the worst case scenario, it makes
> sense to try and support it. So I sent my follow-up mail to do just that.

I'm not sure I understand the value in having a local-provider-only package
available on 32-bit archs.  I expect people orchestrating lxd containers to
be doing so on a 64-bit install.  That you *could* launch a bunch of
containers on an armhf system doesn't mean that anybody *would* do so.  Does
anyone have a real-world case where this is useful to do?

E.g., I saw in the #ubuntu-devel logs that there was this comment from
William:

 <wgrant> It's really useful to be able to use our key deployment technology
  in parts of the Launchpad build farm, for example.

That's absolutely true - I just don't see that dropping the juju package
from the 32-bit archs would have any impact here.  AIUI we aren't using the
local provider for any of this; we use the openstack provider, and in order
to manage 32-bit guests we need to have a jujud that we can deploy on those
guests but that jujud doesn't come from the package in the Ubuntu archive
/anyway/ so that's not a rationale for keeping 32-bit support in the client
package.

Now, maybe "we need jujud on 32-bit archs" means you have to deal with this
question anyway, in which case you might as well continue to make the
package available on those archs.  But if having the juju package on 32-bit
archs means increased support costs that the juju team aren't otherwise
willing to bear, let's just kill it off on those archs (i.e. replace it with
the dummy package w/ debconf note as discussed), instead of binding
ourselves with a committment to some purely hypothetical good.

> Fast-forwarding to today, I made an effort to get a sustainable 32-bit
> package. I also wanted to gain reassurance I could easily deal with further
> issues should they crop up to truly alleviate my concerns about being
> blocked, hence "sustainable". This was not the first 32-bit build issue, and
> xenial is quite young. Thus I requested the juju core team provide a way of
> compiling without various provider support or other things that may trip up
> builds in the future. In addition, I worked again on trying to get a working
> 32-bit build myself with the idea of breaking providers, tests, or anything
> else as needed. With the caveat in mind that I am not a go developer, I
> discovered that as I tore parts away, more things started breaking. The
> build failures were not unique to a specific provider as we had thought, and
> making things work was not an easy task. I also began to seriously wonder
> how well juju would function with the amount of edits I was doing. I was
> ultimately not successful in getting a build, nor was I confident that the
> build would work reasonably. At the same time, the core team investigated
> breaking out provider by provider support and found it was going to be
> onerous, and represent a continual burden due to the intrinsic nature of go.
> Armed with the knowledge that this was not going to be easily solved by
> disabling providers, I don't think this failure changes the outcome.

> Given the lack of results, I'm not confident about the 32-bit builds going
> forward. After my investigation and attempts to produce a current working
> build, I think the safest option remains the package removal. I'm even less
> convinced now that 32-bit builds can be supported in the future. Sadly, the
> window for discussion and exploring alternatives on this is closing. Juju 2
> is releasing an RC today, and adoption will begin. I would like to resolve
> this matter asap. I want to get the RC into the archive for our LTS users
> especially, as well as yakkety for our QA and stabilization efforts there.

I think we're in agreement that supporting a juju package on 32-bit in
xenial is not required, and should be dropped now rather than later.  If the
underlying portability problems translate to not supporting jujud on these
architectures, that's rather a large issue for Launchpad infrastructure; we
really do need juju to support 32-bit units.  But there's no reason that
this should block the update of the package in SRU, given that jujud is
delivered separately via simplestreams.

-- 
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/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20160920/a7e7393a/attachment-0001.pgp>