Tracking bug for all ops pieces needed to deploy Profile images to production. Initial thread: https://mail.mozilla.org/pipermail/dev-fxacct/2014-August/001048.html
I’m sorry if there is confusion about this. Here is a high level timeline (without dates) for profile images: Step 1) Release profile image support for FxA in production in dogfood mode (i.e., not generally available). The UI to add a profile image to your account will not be part of the signup flow and will not be linked anyway in our UI. Internal dogfooders will visit a special URL on FxA to add a profile image. Scalability is not necessarily a requirement for Step 1). Step 2) Internal dogfooding and iteration of FxA profile images. If profile images weren’t scalable when step 1) was released, that work can proceed in parallel with the UX iteration. Step 3) GA of FxA profile images. End-users can add profile images to their accounts and reliers can show users’ images in their pages. The length of Step 2) and date for step 3) are as of now undetermined Step 1) is blocking us. I’d like to get profile images deployed to production in dogfood mode (scalable or not) as soon as we can. The front end UI is ready. Remaining steps for step 1), from my perspective: 1) Land and deploy our avatar API in the profile server: https://github.com/mozilla/fxa-profile-server/pull/37 and maybe https://github.com/mozilla/fxa-profile-server/issues/31 2) Integrate our front end with this API. 3) Figure out where the images are going to live and a URL scheme for them. Sean and Chris, when do you think the back end dependencies for step 1) can be ready? Do you have any concerns with this plan?
Although scalability of the profile image infrastructure is not a requirement for step 1), it's failure for any reason should minimally impact the rest of FxA.
oops. Didn't mean to clear that needinfo... Sorry about that. So, I don't object to the proposed timeline here at all, however I don't feel that the scalability of the worker pool is the hard part here. Right now there are too many unknowns on my side to be able to make some fundamental choices about how we are going to proceed on the AWS front. Having said that, I've sent an email to sean (cc'd :ckarlof) asking for some answers to a couple of questions and those answers may really simplify the overall design of the architecture. If that ends up being the case, Step 1 might be much closer to 2 & 3 than we originally thought.
Depending on if there are architectural changes suggested by ckolos or tblow, the dev side can be done real soon. I've been working on the tests for using SQS and S3, and once I've got those, I can work with dcoates on getting a dannybox to mimic stage. Though, things could change if it's decided we should use a different setup.
:seanmonster - We might not need/want SQS, so there's that ... :)
Hey folks, do we have a profile server standing up anywhere? I'd like to show avatar images in Fennec's Firefox Account status and possibly Remote Tabs panel in the future, but right now I've just got all the oauth test code up and want to verify my trivial profile server client is working.
profile went live in train-14 and is at profile.accounts.firefox.com
To clarify :ckolos's response, yes, we have a profile server in production, but it does not yet support avatars. Nick, you are a bit "ahead of the game" at this point. At this point, you'd be at the bleeding edge (maybe beyond it) trying to do an integration test with avatar images. Things will be better in the next week or two. At this point in time, you could do a "basic" integration test in a dev environment (get an oauth token and use it to read the uid and email from the profile server). That'll at least sanity check your implementation. What'll you need for that is a client_id with the permission to do implicit grants. Zach, what client_id have you been developing with? I suspect we'll need to add some (one for each of Firefox Desktop, Fennec, FxOS, content server) to our dev environments and eventually prod. I created an issue to track that: https://github.com/mozilla/fxa-oauth-server/issues/122 Nick, since this bugzilla bug is for tracking the Prod deployment of profile images, can we take discussion of your issue to the above github issue (or elsewhere?).
(In reply to Chris Karlof [:ckarlof] from comment #8) > To clarify :ckolos's response, yes, we have a profile server in production, > but it does not yet support avatars. > > Nick, you are a bit "ahead of the game" at this point. At this point, you'd > be at the bleeding edge (maybe beyond it) trying to do an integration test > with avatar images. Things will be better in the next week or two. Understood. > At this point in time, you could do a "basic" integration test in a dev > environment (get an oauth token and use it to read the uid and email from > the profile server). That'll at least sanity check your implementation. Done! I used the triple of URIs: https://oauth-latest.dev.lcip.org/v1 https://latest.dev.lcip.org/auth/v1 https://latest.dev.lcip.org/profile/v1 > What'll you need for that is a client_id with the permission to do implicit > grants. Zach, what client_id have you been developing with? I suspect we'll > need to add some (one for each of Firefox Desktop, Fennec, FxOS, content > server) to our dev environments and eventually prod. > > I created an issue to track that: > https://github.com/mozilla/fxa-oauth-server/issues/122 > > Nick, since this bugzilla bug is for tracking the Prod deployment of profile > images, can we take discussion of your issue to the above github issue (or > elsewhere?). Roger that. No need for further discussion, I think, until we stand up a bleeding edge avatar service. Thanks, everybody!
FWIW, I've been using the oauth server's pre-configured client with the ID of 98e6508e88680e1a. It was created to test these implicit grants.
Marking this as resolved, re-open if in error.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
This has been in the wild for a while without incident.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.