On 04/04/2012 01:53 PM, Matt Wagner wrote:
On Wed, Apr 04, 2012 at 12:15:47PM -0400, Jason Guiditta wrote:
<lots of snipping>
>> I have a demo Redmine site running here:
>>
https://redminetest-mattydubs.rhcloud.com/
> While this is indeed fast, I wonder what effect having our full
> dataset would have on the speed, if any. This may be good to find out
> before we make any decision.
That would probably be a good next step. I'd be surprised if the size of
the database impacted performance substantially, but it can't hurt to
try.
Agree that the current speeds are just unworkable and also don't believe
our current data set is so large as to pose a major issue.
>> While OpenShift supports HTTPS, they don't allow custom
certificates
>> (yet?), so we would have to run on the .rhcloud.com domain, or not use
>> HTTPS if we wanted to use a CNAME for an
aeolusproject.org subdomain.
>> However, because we were likely going to end up on some sort of new
>> subdomain to make this work anyway, I would argue that the domain we're
>> on doesn't matter a bunch -- people will either follow a link, or
>> they'll go from bookmarks / their browser's history.
>>
> Could we not just use https for _login_ and leave the rest one our own
> domain? Or is that outside the realm of the possible here?
I think that could work, but the question is whether cookies would work
jumping between domains. (And anyone reasonably paranoid has already
disabled third-party cookies in their browser.) It also wouldn't
surprise me terribly if some browsers freaked out if a secure form tried
to redirect to you a page on another domain. This probably falls into
the category of things, like the above, that should be further tested.
There is another problem with this. After logging in your session key
will be transmitted in the open. If your accessing the redmine instance
on any public network (without being on the vpn or similar of course),
anyone will be able to hijack your session and modify our redmine
instance in any way they want.
I don't think anyone is going to be looking for this traffic, but still
a vulnerability neverless.
> * The sending emails thing is another one that appears to need
an
> external service based on your wiki page. Do we want to incur that
> extra cost, since we can do this ourselves now at no cost? Maybe
> that free one for 200/day is enough for right now, but what about as
> we grow? On a busy day of you editing this page (which I have set
> as a watch), I can easily get 5-10 emails myself. It seems like
> this could easily scale to much larger than we may want from a paid
> service.
My (possibly flawed) understanding is that you may be able to send
emails on your own, but that a whole bunch of people refuse to accept
email from major cloud providers, and lots of them end up on anti-spam
blacklists, because it's so easy for drive-by spammers. We may be able
to deliver mail directly, and we could definitely relay mail through any
SMTP server we wanted. There may be existing infrastructure we can take
advantage of for this; I was just very reluctant to set up anything on
our own, since maintaining our own SMTP server is in no way preferable
to managing our own Redmine server.
+1
> * While I am sure we coudl talk to them about more space, perhaps we
> should consider storage/impact for things like release tarballs. I
> think we put them on our fedorapeople account right now, so his may
> not be an issue, just think we should consider it.
I'm not convinced that Redmine is the right tool for the job here. I'd
prefer to use Fedorahosted / Fedorapeople repos for this, or to take
advantage of GitHub's ability to offer .zip files from tags, rather than
trying to upload large files to our project-management tool.
Hrm I agree the right tools should be used for the job, but also want to
avoid using too many tools. This tends to lead to alot of overhead in
maintaining everything (even if we don't have to maintain the
infrastructure, we still have to maintain user permissions and such) and
if the interfaces aren't themed consistently, the user's experience will
be a bit jarring.
> * Removing the repo browser may be a requirement if we go to
> openshift, as that would at the least impact the disk space we are
> using, and as you say, it does duplicate functionality in github. We
> lose the option to easily hook issues to commits, but nobody has
> used that anyway, so probably not a big loss.
I understand that it has a good purpose, but my personal opinion is that
I actively dislike its existence. Every time I try to search for
something in a ticket, I end up finding it in every previous commit. If
I actually wanted to browse the repo, I find GitHub easier to use. Of
course this is solely my own opinion and I don't know if others see any
value.
+1
-Mo