No worries, that actually works in my favor. App wants mongodb 2.4+ for some reason and I really didn't want to have to create a custom cartridge or whatever you guys call it. :)
On Wed, Jan 15, 2014 at 12:14 AM, Grant Shipley <gship...@gmail.com> wrote: > On Wed, Jan 15, 2014 at 12:04 AM, S. Dale Morrey <sdalemor...@gmail.com > >wrote: > > > Grant, I'm a little confused. It looks like OpenShift only supports > > MongoDB 2.2 deployment. I need 2.4 or better, but I can't find how to > > deploy it anywhere. > > > This is actually an embarrassing bug that I hope will be fixed very soon > (next week or two). Even though it says MongoDB 2.2, it is actually 2.4. > We just missed updating the text. :( I just verified it by creating a > test application, embedded mongodb-2.2 and then ssh in and ran mongo > command: > > [test-packt.rhcloud.com 52d634074382ec6197000043]\> mongo > MongoDB shell version: 2.4.6 > connecting to: 127.2.184.130:27017/admin > > > Sorry for the confusion. > > > > Some of the comments in the forums indicate that an > > upgrade path exists, but I don't see any information on how to do this > > especially in a way that would scale. > > Are you just supposed to login to the gear and run an update or is that > > even possible? > > > > Thanks! > > > > > > On Tue, Jan 14, 2014 at 10:39 PM, Grant Shipley <gship...@gmail.com> > > wrote: > > > > > comments inline. Thanks for the very well thought out and detailed > > > comments! > > > > > > > > > On Tue, Jan 14, 2014 at 10:03 PM, Richard Esplin > > > <richard-li...@esplins.org>wrote: > > > > > > > Last summer I did a hobby project on OpenShift. I really like the > > > platform, > > > > but left with the following lessons: > > > > > > > > * OpenShift is a neutered Git repo, so deployment to OpenShift is a > git > > > > push. > > > > This has a number of ramifications: you have to understand git's > arcane > > > > syntax > > > > for simple stuff, you have to commit a change to get anything to > update > > > on > > > > the > > > > server, code on the server is ephemeral so the results of debugging > > have > > > > to be > > > > copied off the server to be checked in, initial deployment is > > cumbersome, > > > > etc. > > > > > > > > > > This is mostly accurate. OpenShift recommends that all source code > > > deployments happen via git. However, the platform does support binary > > > deployments for languages where that is the standard (Java for > example). > > > > > > You can view logs a couple of different ways on the platform. You can > > use > > > the 'rhc tail' command which really just opens up a tail command over > ssh > > > to your logs files. You can also SSH in to the server and view the log > > > files like you normally do. > > > > > > > > > > > * The development workflow with OpenShift took some getting used to. > > The > > > > deployment process is all through git. I moved an existing repo to > > > > OpenShift, > > > > so the initial push to took a fork on Github, a merge with my repo, > and > > > > another merge with OpenShift. Then I can push to either my Github > repo > > or > > > > my > > > > OpenShift repo. > > > > > > > > * OpenShift is a fast moving platform. Last summer I found a lot of > > rough > > > > edges, strange bugs, and out-of-date documentation. Things change > like > > > what > > > > version of Django works with what version of Python and PostgreSQL. > > Some > > > of > > > > the problems I found last summer appear to have been fixed. However, > > > > something > > > > appears to have changed and broken my app. I couldn't get it working > > > again > > > > after thirty minutes of poking around. > > > > > > > > It went GA in June of last summer. We were in beta before then and > > > absolutely moved at a lightening pace. We continue to do so and strive > > to > > > always allow backwards compatibility. Sometimes this doesn't happen. > > Now > > > that we are production and have actual paying customers, things are > > getting > > > better. > > > > > > > > > > * Last Summer there were strange limitations like you have to declare > > > your > > > > application to be scale-able when you first initialize the cartridges > > > > (though > > > > you can cap how it scales). When we decided we wanted to start > > scaling, I > > > > had > > > > to destroy and re-create the application from scratch. (At least I > had > > > good > > > > instructions the second time.) > > > > > > > > > > This is still the case. Once you create a non-scalable application, > you > > > can't convert to a scalable app on the fly. You can take a snapshot of > > > your app and then recreate it with the scaling flag. You will see > > downtime > > > while doing this. This will be fixed in the future but I don't have a > > date > > > yet. Speaking of which, because this is a true open source project, > all > > > roadmaps and dates are on the public trello boards for people to > follow. > > > > > > > > > > > * We ran three separate accounts with copies of our repository: one > for > > > > development, one for testing, and one for production. Each account > had > > > > three > > > > gears: one for Python Django + HAProxy, one for the database, and one > > for > > > > Python Django at scale. Staging and production on OpenShift work > well, > > > > except > > > > you should be aware that HAProxy eats all the errors so we had to > > disable > > > > it > > > > to debug. The advantage is that on the production server we can > remove > > > the > > > > scalability limits with a paid account and still have everything > > working > > > in > > > > the same way. > > > > > > > > * I thought OpenShift would let me get out of setting up a local dev > > > > environment, but doing actual development on OpenShift is annoying. > The > > > > deployment process is too slow, getting access to the logs is not > > great, > > > > and > > > > having to do everything through git makes it hard to experiment. > > > > > > > > > > Two options here. You can enable hot_deploy which will no longer > restart > > > the server (apache etc) for each deployment. This speeds things up a > > lot. > > > However, for my development that still wasn't fast enough. What I do > is > > > configure my IDE to use SFTP to immediately copy the files to my server > > as > > > I save them. This allows me to have close to local speed development. > > By > > > the time I refresh the webpage, the new file is already running on the > > > openshift server. I wrote a blog post a while ago on how to do this > for > > > PHP: > > > > https://www.openshift.com/blogs/getting-started-with-sftp-and-openshift > > > > > > > > > > > > > > * It took me a long time to figure out and understand how the service > > is > > > > structured. However, once I understood it I really liked it. Having > the > > > > source > > > > available on Github is awesome. There is very little coupling between > > my > > > > code > > > > and the OpenShift environment, so my code is very portable and no > > > lock-in. > > > > My > > > > code can detect if it is on my local environment, staging, or > > production, > > > > and > > > > adapt accordingly. > > > > > > > > > > This was one of the top design goals of the platform. No vendor lock > in > > at > > > all. Developers should not have to modify their code to run on the > > > OpenShift platform. We still have a few minor things to cleanup before > > > this is 100% but we are getting closer. Mostly I am talking about some > > > weird directory structures we have for some languages. PHP is a good > > > example of this where openshift expects your source code (app-root) to > be > > > in a directory named 'php' in your application directory. This will be > > > going away soon. > > > > > > > > > > > > > > * Compared to Google AppEngine and Amazon Elastic Beanstalk, I found > > > > OpenShift > > > > to be much closer to a normal Linux development environment. The fact > > > that > > > > I > > > > can inspect the entire service helped me a lot. I loved not having to > > use > > > > all > > > > the crazy libraries that Google and Amazon require. > > > > > > > Under the covers, OpenShift in running on Red Hat Enterprise Linux 6. > > > Security is handled via SELinux. Process and memory allocations via > > > Cgroups and we use pam_namespaces for polyinstantiated directories. > > > > > > > > > > > I think a lot of my complaints would apply to any PaaS; hosting an > > > > application > > > > on a third-party platform means giving up some flexibility and > control. > > > It > > > > looks like OpenShift has already addressed some of my other concerns. > > > > > > > > > > > > > > > > > > > > > I really like OpenShift and hope to use it for my next project. I > hope > > it > > > > continues to mature in capability and stability, and I hope it gets a > > lot > > > > of > > > > adoption. > > > > > > > > As a side note, I spent way too long developing on Drupal, and I > would > > > not > > > > recommend it to others. If you are interested in my reasoning, I put > a > > > > rant up > > > > on my blog (http://richard.esplins.org/siwi/70/ ). > > > > > > > > Cheers, > > > > > > > > Richard > > > > > > > > On Tuesday, January 14, 2014 19:27:29 S. Dale Morrey wrote: > > > > > Ok so this is not intended as flamebait or a troll or anything. > > > > > But earlier I mentioned my site running on Drupal is basically > > falling > > > > down > > > > > under it's own weight. > > > > > > > > > > I have an extremely limited budget upfront. I'm open to completely > > > > > dropping Drupal at this point and exploring other options. > > > > > > > > > > One of the options I'm looking at is KeystoneJs. It looks really > > nice, > > > > and > > > > > I figure if I go with with it, I may as well go whole hog and move > > > > > providers as well. > > > > > > > > > > Keystone requires nodejs & mongo. For obvious reasons I would > > greatly > > > > > prefer to have a development environment and a production > > environment. > > > > > Since Redshift offers 3 servers I can see myself setting it up as > > > > > "development 1 box all inclusive", "production 2 boxes, 1 would be > > node > > > > and > > > > > 1 would be mongo". > > > > > > > > > > I know we have someone from OpenShift on the list, so I figured I > > would > > > > ask > > > > > if that is feasible. Also is there any way to spin up additional > > > > instances > > > > > based on load similar to AWS's AutoScale feature. > > > > > > > > > > For the rest of the list, does structuring my environment this way > > make > > > > > sense? Or would it be better to have the development box talking > to > > > the > > > > > production DB? > > > > > Also has anyone actually used OpenShift to power a site that > > > experiences > > > > > reasonably heavy loads? > > > > > > > > > > Thanks! > > > > > > > > > > > > /* > > > > PLUG: http://plug.org, #utah on irc.freenode.net > > > > Unsubscribe: http://plug.org/mailman/options/plug > > > > Don't fear the penguin. > > > > */ > > > > > > > > > > /* > > > PLUG: http://plug.org, #utah on irc.freenode.net > > > Unsubscribe: http://plug.org/mailman/options/plug > > > Don't fear the penguin. > > > */ > > > > > > > /* > > PLUG: http://plug.org, #utah on irc.freenode.net > > Unsubscribe: http://plug.org/mailman/options/plug > > Don't fear the penguin. > > */ > > > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
