Summary from the meeting:
Today in the infrastructure meeting we started talking about how to move the new packages and tagger apps into production and where we want them to live in the layout of urls.
Goals: 1. simple for users and remember 2. not overlapping with any of the older apps or existing urls 3. futureproofing for new apps or different interfaces 4. expanding the number of apps we have w/o having them grouped under a single project (like community was).
Non-Goals of this setup: - no interest in preserving the old admin.fp.o/community urls - no interest in pinning anything/everything behind admin.fp.o
Suggestions:
packages.fedoraproject.org
some concerns about this are it is a bit confusing with pkgs.fedoraproject.org.
A couple of ideas there are: 1. make the new packages app be the frontpage for pkgs.fp.o - since gitweb is.... not performant there.
2. move pkgs.fp.o to git.fp.o or to fedpkg.fp.o and let the new app take over the other urls.
These are just some suggestions we discussed in the meeting.
Please submit more ideas.
-sv
On Thu, 19 Jan 2012 15:11:41 -0500 seth vidal skvidal@fedoraproject.org wrote:
Summary from the meeting:
Today in the infrastructure meeting we started talking about how to move the new packages and tagger apps into production and where we want them to live in the layout of urls.
Goals:
- simple for users and remember
- not overlapping with any of the older apps or existing urls
- futureproofing for new apps or different interfaces
- expanding the number of apps we have w/o having them grouped under
a single project (like community was).
Non-Goals of this setup:
- no interest in preserving the old admin.fp.o/community urls
- no interest in pinning anything/everything behind admin.fp.o
Suggestions:
packages.fedoraproject.org
some concerns about this are it is a bit confusing with pkgs.fedoraproject.org.
A couple of ideas there are:
- make the new packages app be the frontpage for pkgs.fp.o - since
gitweb is.... not performant there.
- move pkgs.fp.o to git.fp.o or to fedpkg.fp.o and let the new app
take over the other urls.
These are just some suggestions we discussed in the meeting.
Please submit more ideas.
The above is a summary - here is an idea from me:
http://app.fedoraproject.org/<appname>/ AND http://appname.fedoraproject.org/
Then we can have an app landing page at app.fedoraproject.org to describe what facilities we have but provide for direct links to apps using a shorter convention.
it also lets us collect apps under fedora w/o necessarily having them all be a single system.
it's relatively future proof, too.
-sv
On Thu, Jan 19, 2012 at 03:25:02PM -0500, seth vidal wrote:
The above is a summary - here is an idea from me:
http://app.fedoraproject.org/<appname>/ AND http://appname.fedoraproject.org/
Then we can have an app landing page at app.fedoraproject.org to describe what facilities we have but provide for direct links to apps using a shorter convention.
it also lets us collect apps under fedora w/o necessarily having them all be a single system.
it's relatively future proof, too.
Another thing I've recalled from past conversations is I think we need:
https://<appname>.app.fedoraproject.org/ if we want the cookies that drive SSO to work. We can, of course, decide that SSO is a non-goal.
Also, I assume that "appname" doesn't always give an applications' proper name here. ie: appname = 'updates' rather than appname = 'bodhi' ?
-Toshio
On Thu, 19 Jan 2012 15:17:18 -0800 Toshio Kuratomi a.badger@gmail.com wrote:
On Thu, Jan 19, 2012 at 03:25:02PM -0500, seth vidal wrote:
The above is a summary - here is an idea from me:
http://app.fedoraproject.org/<appname>/ AND http://appname.fedoraproject.org/
Then we can have an app landing page at app.fedoraproject.org to describe what facilities we have but provide for direct links to apps using a shorter convention.
it also lets us collect apps under fedora w/o necessarily having them all be a single system.
it's relatively future proof, too.
Another thing I've recalled from past conversations is I think we need:
https://<appname>.app.fedoraproject.org/ if we want the cookies that drive SSO to work. We can, of course, decide that SSO is a non-goal.
I think SSO is a good goal for our apps that support login. It would be missed I think if we moved away from it.
Also, I assume that "appname" doesn't always give an applications' proper name here. ie: appname = 'updates' rather than appname = 'bodhi' ?
yeah, I would agree. Or perhaps we could cname them, but then it gets confusing which is the 'right' name, so we should probibly avoid that.
also, this would help us with the issue of the wiki cookies going to any fedoraproject.org domain if it was 'wiki.apps.fedoraproject.org'
If fedoraproject is too long, we could look at something like a new domain 'fedapps.org' ? 'fedoraapps.org', but those could be confusing with applications IN fedora.
kevin
On Thu, Jan 19, 2012 at 03:25:02PM -0500, seth vidal wrote:
On Thu, 19 Jan 2012 15:11:41 -0500 seth vidal skvidal@fedoraproject.org wrote:
Summary from the meeting:
Today in the infrastructure meeting we started talking about how to move the new packages and tagger apps into production and where we want them to live in the layout of urls.
Goals:
- simple for users and remember
- not overlapping with any of the older apps or existing urls
- futureproofing for new apps or different interfaces
- expanding the number of apps we have w/o having them grouped under
a single project (like community was).
Non-Goals of this setup:
- no interest in preserving the old admin.fp.o/community urls
- no interest in pinning anything/everything behind admin.fp.o
Suggestions:
packages.fedoraproject.org
some concerns about this are it is a bit confusing with pkgs.fedoraproject.org.
A couple of ideas there are:
- make the new packages app be the frontpage for pkgs.fp.o - since
gitweb is.... not performant there.
- move pkgs.fp.o to git.fp.o or to fedpkg.fp.o and let the new app
take over the other urls.
These are just some suggestions we discussed in the meeting.
Please submit more ideas.
The above is a summary - here is an idea from me:
http://app.fedoraproject.org/<appname>/ AND http://appname.fedoraproject.org/
Then we can have an app landing page at app.fedoraproject.org to describe what facilities we have but provide for direct links to apps using a shorter convention.
it also lets us collect apps under fedora w/o necessarily having them all be a single system.
it's relatively future proof, too.
+1 to both of your ideas.
The initial suggestion of moving pkgs->git just seems like the right move, as it's just a single page on the wiki about our git setup, yet git.fp.o is blank.
Then, packages.fedoraproject.org (or pkgs) could route to app.fedoraproject.org/packages, etc.
luke
On Thu, Jan 26, 2012 at 7:37 AM, Luke Macken lmacken@redhat.com wrote:
On Thu, Jan 19, 2012 at 03:25:02PM -0500, seth vidal wrote:
The above is a summary - here is an idea from me:
http://app.fedoraproject.org/<appname>/ AND http://appname.fedoraproject.org/
Then we can have an app landing page at app.fedoraproject.org to describe what facilities we have but provide for direct links to apps using a shorter convention.
it also lets us collect apps under fedora w/o necessarily having them all be a single system.
it's relatively future proof, too.
+1 to both of your ideas.
The initial suggestion of moving pkgs->git just seems like the right move, as it's just a single page on the wiki about our git setup, yet git.fp.o is blank.
Then, packages.fedoraproject.org (or pkgs) could route to app.fedoraproject.org/packages, etc.
So is packages.fedoraproejct.org just a redirect or are the app's urls available under both domain names? (Thinks the former is going to be better).
-Toshio
On Thu, Jan 19, 2012 at 03:11:41PM -0500, seth vidal wrote:
Summary from the meeting:
Today in the infrastructure meeting we started talking about how to move the new packages and tagger apps into production and where we want them to live in the layout of urls.
Goals:
- simple for users and remember
- not overlapping with any of the older apps or existing urls
- futureproofing for new apps or different interfaces
- expanding the number of apps we have w/o having them grouped under a
single project (like community was).
Non-Goals of this setup:
- no interest in preserving the old admin.fp.o/community urls
- no interest in pinning anything/everything behind admin.fp.o
Suggestions:
packages.fedoraproject.org
some concerns about this are it is a bit confusing with pkgs.fedoraproject.org.
A couple of ideas there are:
- make the new packages app be the frontpage for pkgs.fp.o - since
gitweb is.... not performant there.
Yeah -- if we have the package's app display a link (maybe from the sources tab) to the gitweb that might just work. Alternately, the only reasons to keep gitweb are 1) urls and 2) history. If the packages application grows hstory viewing capability, perhaps that would not be needed.
- move pkgs.fp.o to git.fp.o or to fedpkg.fp.o and let the new app
take over the other urls.
There was a reason we didn't use git.fp.o... maybe mmcgrath would remember better than me.
fedpkg.fp.o would be slightly confusing since we have a fedpkg package and becomes moreso if we move fedorahosted projects to <appname>.fedorahosted.org domains.
If we do move the gitweb domain we'd be breaking the URLs into gitweb which I know we wanted to avoid in the past... May be an opportunity to move to cgit (I think that was the name) instead of gitweb, though. That might solve our performance issues.
These are just some suggestions we discussed in the meeting.
Please submit more ideas.
I'd love to hear more proposed names. So far, using the new app as the entry point to gitweb and then using packages.apps.fp.o sounds like the best plan but it also seems somewhat hacky.
We should talk about what other things we want to move from pkgdb into the new community. As we talk about a projectwide shift in urls to <appname>.apps.fedoraproject.org/, packages.apps.fp.o, and pkgdb.apps.fp.o are also confusingly similar. We could aim to move all of the pkgdb functionality into the new packages/community app. Or we could make the new community app the front end to it similar to how we're talking about for gitweb. Or we might want to rename in some other way.
-Toshio
How about appengine.fedoraproject.org ?
On 1/21/12, Toshio Kuratomi a.badger@gmail.com wrote:
On Thu, Jan 19, 2012 at 03:11:41PM -0500, seth vidal wrote:
Summary from the meeting:
Today in the infrastructure meeting we started talking about how to move the new packages and tagger apps into production and where we want them to live in the layout of urls.
Goals:
- simple for users and remember
- not overlapping with any of the older apps or existing urls
- futureproofing for new apps or different interfaces
- expanding the number of apps we have w/o having them grouped under a
single project (like community was).
Non-Goals of this setup:
- no interest in preserving the old admin.fp.o/community urls
- no interest in pinning anything/everything behind admin.fp.o
Suggestions:
packages.fedoraproject.org
some concerns about this are it is a bit confusing with pkgs.fedoraproject.org.
A couple of ideas there are:
- make the new packages app be the frontpage for pkgs.fp.o - since
gitweb is.... not performant there.
Yeah -- if we have the package's app display a link (maybe from the sources tab) to the gitweb that might just work. Alternately, the only reasons to keep gitweb are 1) urls and 2) history. If the packages application grows hstory viewing capability, perhaps that would not be needed.
- move pkgs.fp.o to git.fp.o or to fedpkg.fp.o and let the new app
take over the other urls.
There was a reason we didn't use git.fp.o... maybe mmcgrath would remember better than me.
fedpkg.fp.o would be slightly confusing since we have a fedpkg package and becomes moreso if we move fedorahosted projects to <appname>.fedorahosted.org domains.
If we do move the gitweb domain we'd be breaking the URLs into gitweb which I know we wanted to avoid in the past... May be an opportunity to move to cgit (I think that was the name) instead of gitweb, though. That might solve our performance issues.
These are just some suggestions we discussed in the meeting.
Please submit more ideas.
I'd love to hear more proposed names. So far, using the new app as the entry point to gitweb and then using packages.apps.fp.o sounds like the best plan but it also seems somewhat hacky.
We should talk about what other things we want to move from pkgdb into the new community. As we talk about a projectwide shift in urls to <appname>.apps.fedoraproject.org/, packages.apps.fp.o, and pkgdb.apps.fp.o are also confusingly similar. We could aim to move all of the pkgdb functionality into the new packages/community app. Or we could make the new community app the front end to it similar to how we're talking about for gitweb. Or we might want to rename in some other way.
-Toshio
Positives ---------------
- simple for users and remember
- not overlapping with any of the older apps or existing urls
- futureproofing for new apps or different interfaces
- expanding the number of apps we have w/o having them grouped under a
single project (like community was).
Negatives -------------
- no interest in pinning anything/everything behind admin.fp.o
Why can we not forward everything through a filter? For instance:
www.fedoraproject.org/render?project=FOO
where render is a rewrite to a method that determines which host a particular project resides on. This approach would scale and seems to fit the requirements. In terms of making it "easy for users" we would still have to come to a consensus on whether to use FOO.fedoraproject.org or www.fedoraproject.org/FOO. Either way these could then be mapped "internally" through our proxy/webserver of choice to the proper rendering method + option(s).
I imagine this solution might cause a problem with SSO and cookies so it might be a non-starter unless we are able to migrate to more of a unified RBAC model where someone authenticates to our "root" domain but then access to other applications is granted per site. Such an approach might also help cleanup the authentication, authorization and accounting (AAA) issues new applications sometimes experience by enabling us to write a "clean authentication module" developers can import to make their application "Fedora Project AAA Compliant." A big task indeed but it might help with NIHS for new applications.
Maybe I didn't think this through? thoughts, suggestions, explicatives? :-)
On Mon, 23 Jan 2012 09:59:08 -0500 "Adam M. Dutko" dutko.adam@gmail.com wrote:
Why can we not forward everything through a filter? For instance:
www.fedoraproject.org/render?project=FOO
well, thats hard for people to remember and tell to others. ;)
where render is a rewrite to a method that determines which host a particular project resides on. This approach would scale and seems to fit the requirements. In terms of making it "easy for users" we would still have to come to a consensus on whether to use FOO.fedoraproject.org or www.fedoraproject.org/FOO. Either way these could then be mapped "internally" through our proxy/webserver of choice to the proper rendering method + option(s).
Well, we already do this with our proxy setup, but we want to usually keep the url constant so it doesn't confuse people. Also, we need to be carefull with the csrf stuff, and the domains for sharing cookies.
I imagine this solution might cause a problem with SSO and cookies so it might be a non-starter unless we are able to migrate to more of a unified RBAC model where someone authenticates to our "root" domain but then access to other applications is granted per site. Such an approach might also help cleanup the authentication, authorization and accounting (AAA) issues new applications sometimes experience by enabling us to write a "clean authentication module" developers can import to make their application "Fedora Project AAA Compliant." A big task indeed but it might help with NIHS for new applications.
Maybe I didn't think this through? thoughts, suggestions, explicatives? :-)
Yeah, I don't know that I like this for the cookie and readability reasons, but thanks for the ideas. ;)
kevin
well, thats hard for people to remember
I understand which is why I explained the "implementation" later in my original e-mail. As part of the implementation I forsee various Virtual Hosts which would map to a domain (or sub-domain) but then rewrites through the central method I proposed in my first e-mail. These sub-domains (or the other approach yet to be determined) would then rewrite through the filter. It would scale and it would provide a step-by-step process for new applications that could be scripted. The authentication module would probably also help but this approach would be laborious however possibly worth it in the long-run.
keep the url constant so it doesn't confuse people.
It would be constant. We would do various things behind the scense like I mentioned earlier in this e-mail and in my previous one. I probably should have discussed the "implementation" before the theory but I figured it was a putting the "cart before the horse."
carefull with the csrf stuff, and the domains for sharing > cookies.
Yes. The unified RBAC piece would help with this I think. As opposed to relying on cookies for each sub-domain for authentication the person would authenticate once, then based on their permissions be granted access to each application. This might also help in the long-run because it would force us to move more session data into the database which over time would help with load-balancing and failover (not that things are now done poorly, it's just a different approach).
but thanks for the ideas. ;)
Thank you for considering them and for the continued feedback.
On Fri, 20 Jan 2012 13:44:55 -0800 Toshio Kuratomi a.badger@gmail.com wrote:
Yeah -- if we have the package's app display a link (maybe from the sources tab) to the gitweb that might just work. Alternately, the only reasons to keep gitweb are 1) urls and 2) history. If the packages application grows hstory viewing capability, perhaps that would not be needed.
Yeah, that could be the case down the road... but pointing to gitweb now might be fine.
- move pkgs.fp.o to git.fp.o or to fedpkg.fp.o and let the new app
take over the other urls.
There was a reason we didn't use git.fp.o... maybe mmcgrath would remember better than me.
I think it was pointed at fedorahosted for a while for some reason, so it was causing a lot of confusion after fedora switched to git for packages. ;(
fedpkg.fp.o would be slightly confusing since we have a fedpkg package and becomes moreso if we move fedorahosted projects to <appname>.fedorahosted.org domains.
Agreed. I don't like that one.
If we do move the gitweb domain we'd be breaking the URLs into gitweb which I know we wanted to avoid in the past... May be an opportunity to move to cgit (I think that was the name) instead of gitweb, though. That might solve our performance issues.
We could look at it, but I thought it had it's own issues.
Do we need to preserve links into gitweb? I would think if we provided a ok 404 type response most people would just go look at the top level and find what they are looking for.
But perhaps I am not understanding how often people provide gitweb urls?
I'd love to hear more proposed names. So far, using the new app as the entry point to gitweb and then using packages.apps.fp.o sounds like the best plan but it also seems somewhat hacky.
I agree.
We should talk about what other things we want to move from pkgdb into the new community. As we talk about a projectwide shift in urls to <appname>.apps.fedoraproject.org/, packages.apps.fp.o, and pkgdb.apps.fp.o are also confusingly similar. We could aim to move all of the pkgdb functionality into the new packages/community app. Or we could make the new community app the front end to it similar to how we're talking about for gitweb. Or we might want to rename in some other way.
Yeah, perhaps we could generate a list of all types of urls that pkgdb exposes now?
admin.fedoraproject.org/pkgdb bugz.fedoraproject.org etc
kevin
ok. I want to revive this thread and come to some conclusion we can act on. ;)
So, in the specific case of the new packages/tagger:
http://packages.fedoraproject.org and http://apps.fedoraproject.org/packages/ and http://pkgs.fedoraproject.org (front page only, probibly redirect to above page). should go to the packages app. Which is the 'real' url that the others direct to? Or do they all work ? We would have to monitor and support all of them?
http://tagger.fedoraproject.org/ and https://apps.fedoraproject.org/tagger/ and https://tagger.fedoraproject.org go to the tagger application.
This means that we can't share signin on tagger, unless we move our other applications that have login cookies under apps.fedoraproject.org and make that the preferred url right?
Since we have that under admin. Should we instead put tagger:
https://admin.fedoraproject.org/tagger/
At least for now until we move other applications that use admin?
Additionally:
http://apps.fedoraproject.org/ (landing page with links to all the other stuff). (Note: this might be a nice place to show icons/links to upstream projects we use and support too).
http://apps.fedoraproject.org/<name> and http://<name>.fedoraproject.org/
I know mmcgrath had a pretty good policy of "no CNAMES". Ie, everything should be one actual name to avoid confusion about what url people are hitting and what we monitor, etc. I see the above makes things easier in some ways, but also more confusing. I think we should be very clear what the "real" url is and have the other convenience ones just redirect to that.
Thoughts?
How can we make this more clear and not have a forest of urls? :)
kevin
On Mon, 6 Feb 2012 12:53:09 -0700 Kevin Fenzi kevin@scrye.com wrote:
http://tagger.fedoraproject.org/ and https://apps.fedoraproject.org/tagger/ and https://tagger.fedoraproject.org go to the tagger application.
This means that we can't share signin on tagger, unless we move our other applications that have login cookies under apps.fedoraproject.org and make that the preferred url right?
Since we have that under admin. Should we instead put tagger:
https://admin.fedoraproject.org/tagger/
At least for now until we move other applications that use admin?
I would suggest NOT using admin.
1. the name is utterly confusing to users. Admin.fp.o/blah screams "GO AWAY THIS IS FOR NOT YOU" to me 2. Even if the user has to login separately, so be it. It's less intimidating to let the app be simple to see.
I'd rather move toward apps.* and start with tagger, personally.
-sv
On Mon, Feb 06, 2012 at 02:57:57PM -0500, seth vidal wrote:
On Mon, 6 Feb 2012 12:53:09 -0700 Kevin Fenzi kevin@scrye.com wrote:
http://tagger.fedoraproject.org/ and https://apps.fedoraproject.org/tagger/ and https://tagger.fedoraproject.org go to the tagger application.
This means that we can't share signin on tagger, unless we move our other applications that have login cookies under apps.fedoraproject.org and make that the preferred url right?
Since we have that under admin. Should we instead put tagger:
https://admin.fedoraproject.org/tagger/
At least for now until we move other applications that use admin?
I would suggest NOT using admin.
- the name is utterly confusing to users. Admin.fp.o/blah screams "GO
AWAY THIS IS FOR NOT YOU" to me 2. Even if the user has to login separately, so be it. It's less intimidating to let the app be simple to see.
I'd rather move toward apps.* and start with tagger, personally.
wfm.
Also, we need to be sure that we're doing an external redirect and not an internal rewrite to go from the other domain names to the https://apps.fedoraproject.org/tagger/ URL. (otherwise sso won't work when we eventually try to set it up).
-Toshio
infrastructure@lists.fedoraproject.org
-
Adam M. Dutko -
Christopher Meng -
Kevin Fenzi -
Luke Macken -
Seth Vidal -
Toshio Kuratomi