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

Matt Wagner matt.wagner at redhat.com
Wed Apr 4 21:58:21 UTC 2012


On Wed, Apr 04, 2012 at 03:55:18PM -0400, Jason Guiditta wrote:
> On 04/04/12 13:53 -0400, Matt Wagner wrote:
> >
> >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?

As long as we continue to host the static www.aeolusproject.org site on
Apache, we could probably set up rewrite rules to make this work.
(There's probably a larger discussion here -- if we move Redmine out,
we're left with just a static site, which might make sense to move to
something like GitHub Pages... Or we could even move the whole site
wholesale to OpenShift, I suppose.)

> >
> >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'?

After talking a bit more about this, I was slightly off. It sounds like
there's no local mailserver in place, but outbound port 25 is not
blocked. So it sounds like we would need to use someone's SMTP service.
I'll look more into this tomorrow. (It sounds like some users are using
Gmail for this -- register a Gmail account, and just use their SMTP
service.)

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

Sure, this makes sense.

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

This has actually crossed my mind. (Although as far as "the wiki
everyone hates so much", my objections are just that it's unbearably
slow and doesn't support Markdown. Both of those are easily fixed.)

I'm not necessarily proposing this, but for the sake of discussion,
we could probably move *everything* over to GitHub. Use their wiki. Use
GitHub Pages for our static site. (Automatically updated once we push to
the repo.) And use their Issues feature for tracking issues and
features. Really the only issue that comes to mind is that their Issues
page is pretty basic, though that might have some benefits.

I'm not sure we *should* do that, but it would probably not be
a disastrously bad idea.

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

I completely agree with this line of thinking. I think we make use of a
decent number of plugins that we'd want to evaluate compatibility of,
but that's a small implementation detail, not a problem. I also agree
with all of your steps below, so I won't quote them all here. :)

-- Matt



More information about the aeolus-devel mailing list