RFC: Moving Redmine to OpenShift (and adding a blog!)

Mo Morsi mmorsi at redhat.com
Fri Apr 6 11:27:41 UTC 2012


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




More information about the aeolus-devel mailing list