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

Matt Wagner matt.wagner at redhat.com
Wed Apr 4 17:53:07 UTC 2012


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.

> >
> >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.

> 
> >If people are so inclined, what we should do is set up an account on
> >OpenShift that's not in an individual's name (perhaps using the
> >aeolus-devel list like we did on some other sites), and share the
> >password with a handful of maintainers. You can attach multiple public
> >keys, allowing everyone to use their own ssh key for management. (This
> >means that access to the web interface isn't strictly necessary; you
> >could get someone to add your key and work from the CLI tools.)
> >
> Maybe I am remembering wrong, but I thought I saw something about
> openshift apps being deployed via git repos.  If that is the case,
> could we just make a repo that all developers have access to so we can
> make fixes quickly, and then also do the subset/group you mention
> above for pushing those updates to openshift?

Yes, it's all based on git, and a push causes the app to re-deploy.

We could try to mirror the repo somewhere, but I think it would end up
just complicating things. (And we have some stuff, like the key used to
sign cookies, that we wouldn't want public.) In general, I think that if
people wanted to be able to browse the Redmine code for some reason, we
could just give them access to the account. I think it's beneficial to
have a number of people who can push to the site anyway. (But at the
same time, since it's "just" Redmine, I don't see the need to update it
terribly often.)

> >
> >As a tangent, I also set up WordPress on OpenShift, as I referenced in a
> >previous email. It ended up being pretty easy; I would really like to
> >make it official. I think all we need to do to get that working is set
> >up a CNAME (if we want one), since there's no need for SSL for
> >non-management stuff, and maybe customize the theme to not look so
> >"default". This isn't the main focus of this, though.
> >
> I think this is a nice idea/addition to the community, especially as
> it supports much the same functionality as our current blogroll plugin
> for redmine, but in a way that makes more sense to me, since it is
> actually a blog.  If we did this, I propose we add any existing blogs
> the blogroll lists, and then retire it.  One less thing to clutter the
> RM interface, imo.  I would like to mention another plus of this
> direction is that we have the option for developers and other
> community members to have their own hosted aeolus blog, while also
> providing the flexibility for them to run their own and have it
> included (at least that is how I understaood what you told me when we
> chatted about this, please correct here if I misunderstood).

I would be fine with that, but I don't want "rejigger the
blogroll/aggregator" to become a blocker for any of this.

> Questions based on wiki page:
> 
> * You mention evaluating stability, how would we do this other than
>   setting up a long-running test app there?

That's a great question, and I honestly don't know the answer. Though
really, I was more wondering about stability as a boolean than trying to
quantify stability -- are they stable enough to be an improvement, or
are they too unstable to use? Based on very short-term testing/use,
they're plenty stable, but as you point out, it doesn't mean much with a
small sample size.

> * Would your suggestion to use 'something lie cloudfront' be needed,
> * and if so, is the cost acceptable?

No, it's not needed, and I probably shouldn't have confused matters by
pulling that in. It does speed things up, but the difference is probably
not worth any money. Static images like stylesheets and icons were
taking around 250ms to load according to the waterfall charts I was
using to compare status quo and OpenShift, which struck me as kind of
slow. It's still quite acceptable. I wondered if CloudFront would be
faster. (It was.) But since these things can be cached long-term in
your browser, it really only impacts the page load speed of first-time
visitors, and perhaps saves 150ms. It's not terribly significant, though
it may be a little more noticeable for the large contingent of people
outside the United States.

That said, I use CloudFront in a similar capacity on my own site, and
just got my bill today. I paid 13 cents last month for 60,351 HTTP
requests totalling 163MB. So the cost is entirely reasonable, but it's
also entirely unnecessary to making anything work.

> * is this the same version we have, or a newer one?  You mention
> looking   at upgrading, but I didnt see you say anywhere if you in
> fact did that.

We did end up on a newer version when I did the install, though it's not
the latest and greatest. I don't believe many of our performance
problems are directly related to Redmine itself, versus the host it's
running on, so I didn't sweat this too much. Slightly more further down
the page when talking about Chili.

> * 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.

> * 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.

> * 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.

> * If we do go this route (and I am not sure really if you are
>   recommending we do), what are your thoughts on moving to
>   chiliproject as part of the migration?  Any issues, thoughts
>   pro/con?  I looked at their latest release, and it is soooo much
>   nicer looking by default than redmine, ans appears more easily
>   skinnable.  It also has support for liquid templates, which is kind
>   of cook, though I'd prefer to just have markdown as well, like you
>   said.  I just took a quick look and our backlogs plugin is supported
>   for chiliproject as well.  My take is that chili is much more active
>   than redmine, which seems to be doing only infrequent bugfix
>   releases vs new feature dev and enhancements like chili is
>   (including moving to rails 3.1 or so in the next few months).

I am recommending that we go the OpenShift route.

As for Chiliproject -- I do think it would be great to look at
upgrading, but I haven't looked into it yet. Part of it is that I fear
that there are a *lot* of digressions we can go on, and I don't want to
so over-complicate the project that it never gets done. (Case in point:
the minority of replies to this thread have talked about whether we
should or should not use OpenShift.) The second is that I think this is
something we should look at whether we switch to OpenShift or not. We
are running a fairly dated version of Redmine right now. If we're going
to switch, it would be good to fit this in as part of the migration. If
we're not going to switch, we should look at upgrading some time anyway.

-- Matt



More information about the aeolus-devel mailing list