390320 - Need https server to host updates for the QA Community Extension (people account?)

Status: RESOLVED WORKSFORME

(Infrastructure & Operations Graveyard :: Account Requests, task)

Description

[Zach Lipton [:zach]]

We're now ready to start rolling out an early version of the QA Community Extension internally and to selected community members for testing and feedback. Since we're still iterating a lot on the project, we need to be able to roll out frequent updates automatically, but we also don't want the exposure yet that comes with a non-sandboxed extension on AMO. As such, we're looking to get some secure webspace where we can serve extension updates. 

For some reason, finding a place to put this has proved rather difficult and time-consuming. Several options that come to mind: 

* Create a people account for Zach. This would probably be the easiest solution (people already does https), but I would need this account after my internship ends (I plan to continue working on this project), which may have policy implications.

* Setup https on litmus.m.o. Reed says this requires a cert for litmus, and this does not seem like something we need to spend money on at all. Alternatively, https on quality.m.o could work fine for this purpose.

* Serve the extension from https://ftp.m.o in webtools/ or somewhere similar. This might make this out to seem more finished than it really is yet, but the URL isn't really user-visible anyway. 

I'm happy with any of these options, or really anything that results in some https webspace from which to host this extension. Any help with this would be much appreciated. Thanks.

Comment 1

[Reed Loden [:reed]]

If you end up wanting to use people, you actually already have a people account when you gave us your SSH public key to store in LDAP. Just login to [e-mail] and get started. Make sure to read https://intranet.mozilla.org/ShellServer for more information.

Comment 2

[Zach Lipton [:zach]]

I had thought that people accounts had to be requested, thanks reed. People works great for my purposes, as long as no one has any issues with me continuing to use this account to host extension updates after I go back to school. Justin: ok by you?

Comment 3

[Justin Fitzhugh]

Unfortunately this account will be disabled after your internship is over.  Could someone else in the QA team host it in their people account?

(In reply to comment #2)
> I had thought that people accounts had to be requested, thanks reed. People
> works great for my purposes, as long as no one has any issues with me
> continuing to use this account to host extension updates after I go back to
> school. Justin: ok by you?
> 

Comment 4

[Justin Fitzhugh]

This seems like it should be in addons.m.o, and fast tracked through the sandbox process.  Why can't it go through this process?

Comment 5

[Ben Hsieh]

Zach can probably answer this better than I can, but it seems that sandbox'd extensions aren't served updates like others are, and we're not ready to take this out of the sandbox yet.

Comment 6

[matthew zeier [:mrz]]

Do we not have the ability to make exceptions?  We already have an existing infrastructure in place to host and server add-on updates.  Mike?

Comment 7

[Justin Fitzhugh]

If they aren't ready for it to be out of the sandbox (per comment 5), there is no exception to make.  I'd say if this is still in a sandbox state, we should keep it there, otherwise fast track it out.

Comment 8

[matthew zeier [:mrz]]

You misunderstand my comment - if sandbox'd items prevent updates, can there be exceptions to some sandbox'd items?

Comment 9

[Chris Cooper [:coop] (he/him)]

Zach: how wide is our intended distribution at this early phase? Extensions aren't that large, all things considered. I would be fine with notifying beta users at each new feature release (via mailing list, or whatever) and having them download full new versions from the sandbox rather than reinvent the AMO wheel.

That said, I think we should polish whatever we have now and get it out of the sandbox and into the AMO mainstream so we *can* get more users and take advantage of the update service.

Comment 10

[Michael Morgan [:morgamic]]

(In reply to comment #8)
> You misunderstand my comment - if sandbox'd items prevent updates, can there be
> exceptions to some sandbox'd items?
Not atm -- it'd mean a widespread change.  Why can't it be a public add-on?

Problem w/ the sandox updates surround updating public add-ons to sandbox versions and also the load issues presented with having to check user accounts and EULA agreements (did they agree to sandbox?) every time an update ping happens.

Right now the model is for sandbox users to re-install new versions as they are made available... until we figure out how to work around the things mentioned above.

Comment 11

[matthew zeier [:mrz]]

Is there any agreement that we go with comment #9 and close this bug?

Comment 12

[Zach Lipton [:zach]]

We found another secure server to host this on, so I think we're set with this. Thank you all for your help here.