ubuntu-phone team mailing list archive

[Chris Wayne <chris.wayne@xxxxxxxxxxxxx>]

On Fri, May 2, 2014 at 4:12 PM, Tony Espy <espy@xxxxxxxxxxxxx> wrote:

> On 05/02/2014 11:56 AM, Ted Gould wrote:
>
>> On Fri, 2014-05-02 at 11:36 -0400, Tony Espy wrote:
>>
>>> On 05/01/2014 09:16 PM, Ted Gould wrote:
>>> > On Thu, 2014-05-01 at 18:28 -0400, Chris Wayne wrote:
>>> >> On Thu, May 1, 2014 at 5:16 PM, Ted Gould <ted@xxxxxxxxxx  <mailto:
>>> ted@xxxxxxxxxx>
>>> >> <mailto:ted@xxxxxxxxxx>> wrote:
>>>
>>> <snip>
>>>
>>> >> That's why we have the -customized images tested by CI daily :)  Any
>>> >> update to the image that breaks customization would be found (and
>>> >> fixed) before an image would be promoted.  I don't see how having
>>> >> custom upstart jobs makes it any more likely to fail than having
>>> >> upstart jobs in the rootfs?
>>> >
>>> > Heh, we're not going to have every customization for every device on
>>> > every carrier. It'd be nice, but we probably won't even have an
>>> > environment that could test things like customized location providers
>>> > (likely to require specific cell towers for instance). What's important
>>> > is that we keep the things that can be customized as a stable API, if
>>> we
>>> > can't guarantee that, we shouldn't allow it be customized.
>>> >
>>> >> All in all, we think this is something that a carrier/oem would
>>> >> want/need to customize, and it'd be much easier to add now, than to
>>> >> scramble later
>>> >
>>> > So the more we talk about this, the more I think it's a bad idea. I'm
>>> > now of the opinion that we shouldn't provide this to customization
>>> > tarballs. If nothing else, because we don't expect to support Upstart
>>> as
>>> > long as we expect the customization tarballs to work.
>>>
>>> So are you implying that systemd doesn't have a similar concept ( ie.
>>> overriding default jobs )?
>>>
>>
>> No, I'm saying if you provide an override for an Upstart job it won't
>> work on a Systemd unit. So to create a customization tarball you'd have
>> to override both. (one of which isn't well defined right now)
>>
>>  One example that was brought up recently was a carrier that wants to
>>> ship a *replacement* apns-conf.xml file ( which currently lives in
>>> /system/etc ).  One way to accomplish this is to set an environment
>>> variable called OFONO_APNDB_PATH which the ofono provisioning plugin
>>> queries before using the default path.  Is there another way to expose
>>> custom environment variables to system upstart jobs besides using an
>>> override?
>>>
>>
>> I'd say that the Upstart job for ofono that we ship should check for
>> /custom/apns-conf.xml and use that if it exists. We should support as an
>> interface shipping the actual override, not changing the way that oFono
>> works.
>>
>
> The provisioning code in question is unique to Touch, and currently
> already implements the environment variable mechanism above, primarily for
> testing.  It came up in a related thread started by Chris about how
> carriers could implement custom APN databases.
>
> As for automatically checking for /custom/apns-conf.xml, that's a great
> idea and it could be used to complement our existing solution.  That said,
> the env var mechanism will still exist.
>
> I just created the following bug to track this:
>
> https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1315509
>
> [ Chris, please give the description a read, and add comments if
> necessary. ]
>

Will do, thanks for logging it!

>
> For other runtime configuration settings we do try to leverage the
> existing ofono upstart job ( which actually is an override as to not
> conflict with the desktop version of ofono ).  For instance the associated
> job ril.conf uses Android properties to set environment variables that the
> ofono job uses to determine which device plugin to load and how many SIMs
> the device supports.
>
> [ Chris, does your customization scheme allow properties to be modified? ]


Yes, we can currently customize properties via the use of
/custom/custom.prop, although I have the feeling this should be used
sparingly, as we may not always have Android bits lying around in the
future :)

>
>
>  Let's say we have a situation where we have an oFono job today. And for
>> what ever reason we decide that we have an ofono-helper job that needs
>> to run first. So if the original job was "start on started networking"
>> we'd change it to "start on started ofono-helper" and then the
>> ofono-helper job would be "start on started networking". But if the
>> ofono job was replaced in a customization tarball it would still have
>> the "start on started networking" so, on that particular configuration,
>> they'd run at the same time and have a race condition.
>>
>> Now that situation is a bit contrived because the ofono-helper could be
>> "start on starting ofono", but I hope it illustrates some of the issues.
>>
>
> Sure, I agree that it's easy to tangle things up with override jobs,
> however I don't think we should prevent this type of usage as a blanket
> statement.
>
> /tony
>
>