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

Jason Guiditta jguiditt at redhat.com
Wed Apr 4 19:55:18 UTC 2012


On 04/04/12 13:53 -0400, 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.
>
>> >
>> >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.
>
Ah, yeah, I guess unless we switched to something like oAuth (which I
dont know is even supported for redmine), I guess there is no clean
way to do this.  I can live with it being on a different subdomain,
though I dont particularly like it.  Would we be able to set up a
redirect somewhere for people that have bookmarks to the current
redmine?
>>
>> >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.)
>

Ah, so it is a git repo, but the git push is part of the rhc stuff it
sounds like.  I was thinking it was more separate.  In this case, I am
in favor of your suggestion.
>> >
>> >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.
>

No, I was actually suggesting we _remove_ the blogroll thing, so I
dont see how that woudl be a blocker.

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

Ok, then it sounds like this woudl be simply solved by putting up a
page that says 'whitelist this address if you want to receive email
notifications from us'?
>
>> * While I am sure we could 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.

Yes, I was not suggesting redmine was the right tool for arballs,
especially as we dont use it for that now.  However, that _is_ one of
its intended purposes.  I actually personally think we dont really
need RM file upload at all, other than for inlining images, and I
supposed the occassional document, so the space is unlikely to be an
issue in practice. I would lean toward keeping things on fedorapeople,
if only because I dont think a zip file is sufficient/desired.  If
github also allows you to generate a tarball, then I would be ok with
considering that path.

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

Ok, then let's disable it when/if we go openshift (or heck, even now).
But if we are removing these kinds of things (integrated pieces of
redmine), it makes me somewhat wonder if we are getting a benefit from
the other integration points (like the wiki everyone hates so much).
Following that thought a bit too far, if we were to split all that
out (aside from data migration issues), are we even well servied by
this system anymore?  Should we reconsider something more lightweight?
I am not advocating it, just the idea of disabling chunks of
functionality kind of lead me to the thought/question.

>
>> * 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.
>
Ok, and I am not opposed to that recommendation

>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

Ok, so on this point.  In my opinion, if we are going to migrate to
chili, we should do so as part of this process.  That doesnt mean we
necessarily have to go directly to the _latest_ (though I would love
to see that), but as they specifically had a redmine -> chili
migration doc on the chiliproject site, which was geared toward ~ the
redmine we now have, I think it would be less painful to just do it as
part of the vm -> openshift process.  I would propose the following
basic order of steps for this process:

* Do a full dry run of the following steps and verify everything works
   before doing it 'for realz'. If at all possible, this should be
   scripted, to avoid human error on subsequent runs.
1. Get a data dump of current redmine as well as any pertinent config
data and files (images, uploads, etc)
2. Create a redmine instance on openshift using this
information/config.
3. Have a bunch of people beat on it, make some changes, subscribe to
emails, etc
4. Remove the blogroll (and possibly 'static content') plugins, as I
think those pieces of functionality belong elsewhere.
5. Migrate the working app (and backlogs plugin) to a compatible version 
of chiliproject.
6. Have people beat on it again
7. Update that install to the latest release of chiliproject

Assuming all those steps go well, do it for production, adding:

0. Disable access to the current redmine instance so no new data is
added during the switch.
2a. Set up a regularly scheduled backup job for data (and files, if
needed)
8. Add any theming desired.
9. Enable redirects and any needed updated links (though I am not sure
we actually have any on the website anyway)

-j



More information about the aeolus-devel mailing list