Hi,
I find another issue:
c3: etherpad does not work with the following error
[2013-10-28T16:36:13.296Z] ERROR: etherpad/2733 on ip-10-151-75-70: Could not
create an etherpad group. (contentId=c:tenant1:ek98wKX-4)
err: {
"code": 4,
"message": "no or wrong API Key"
}
Hope someone can help.
Thanks!
Harry
On Oct 27, 2013, at 9:40 AM, Harry Wang <[email protected]> wrote:
> Hi again,
>
> After trying the followings, I finally made Vagrant to work with AWS (still
> with hilary: unrecognized service error) but still have some issues:
>
> Changes I made:
>
> a1. change web domain in puppet-hilary/environments/local/hiera/common.json
> to the real domain names
> a2. change host names to match changes in 1 in
> /puppet-hilary/environments/local/modules/localconfig/manifests/hostnames.pp
>
> Then run vagrant up --provider=aws
>
> After that I have to manually do the following:
>
> b1. create /opt/files folder manually on the AWS machine
> b2. start Hilary manually at /opt/oae by running sudo node app.js |
> node_modules/.bin/bunyan
>
> The problems I have are:
>
> c1. once I close the terminal that running sudo node app.js |
> node_modules/.bin/bunyan, the server goes down and shows 502 error: I tried
> to use setsid or nohup but they did not work
> c2. the preview does not seem to work. It shows "Processing this file. Grab
> some tea and sit back." forever.
>
> Any one can help with c1 and c2?
>
> Thanks,
>
> Harry
>
>
> On Oct 25, 2013, at 3:14 PM, Harry Wang <[email protected]> wrote:
>
>> Hi Simon and Stuart,
>>
>> Based on your help, I tried to setup Vagrant with AWS. I was able to startup
>> the box in AWS and see the puppet script finished (with errors) - it says
>> that "hilary: unrecognized service" and some other errors as seen in the log
>> attached.
>>
>> My Vagrantfile is shown below (I removed the port mapping - do I have to do
>> that? I hope I can directly access the server via real IP assigned to the
>> box later:
>>
>> # -*- mode: ruby -*-
>> # vi: set ft=ruby :
>>
>> Vagrant.configure("2") do |config|
>>
>> # Use the "oae" box to host
>> config.vm.box = "dummy"
>>
>> # Share the backend and front-end code with vagrant.
>> # It's assumed that Hilary and 3akai-ux are on the same level as
>> puppet-hilary.
>> # Note that puppet will change some files in these directories
>> config.vm.synced_folder "../Hilary", "/opt/oae"
>> config.vm.synced_folder "../3akai-ux", "/opt/3akai-ux"
>>
>> # Run a shell script that will do some basic bootstrapping and finally
>> runs puppet.
>> config.vm.provision :shell, :path => "provisioning/vagrant/init.sh"
>>
>> # Allow us to create symlinks on the FS
>> config.vm.provider :aws do |aws, override|
>> aws.access_key_id = "xxx"
>> aws.secret_access_key = "xxx"
>> aws.keypair_name = "xxx"
>>
>> aws.ami = "ami-7747d01e"
>> aws.instance_type = "m1.medium"
>> aws.tags = {
>> 'Name' => 'oae-demo-vagrant'
>> }
>>
>> override.ssh.username = "ubuntu"
>> override.ssh.private_key_path = "/Users/harrywang/keys/hjwangkey.pem"
>> end
>>
>> end
>>
>>
>> Any help is greatly appreciated.
>>
>> Thanks!!
>>
>> Harry
>>
>> <Vagrant-AWS.txt>
>>
>>>>>>>>>>>>>> On Oct 10, 2013, at 12:18 PM, D. Stuart Freeman
>>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If someone wants to take on the task of making an AMI, we
>>>>>>>>>>>>>>> already have
>>>>>>>>>>>>>>> Vagrant set up, so it should be possible to use the vagrant aws
>>>>>>>>>>>>>>> provider
>>>>>>>>>>>>>>> at https://github.com/mitchellh/vagrant-aws though you'll have
>>>>>>>>>>>>>>> to set up
>>>>>>>>>>>>>>> a new config file that conforms to the provider's box format.
>>>>>>>>>>>>>>> The plugin
>>>>>>>>>>>>>>> provides an example that could be combined with the values from
>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>> existing virtualbox vagrant config.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Oct 10, 2013 at 04:53:59PM +0100, Nicolaas Matthijs
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Hi Harry,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Even though I think that your request for having an OAE AMI
>>>>>>>>>>>>>>>> makes a lot of sense, I'm going to resist executing on it
>>>>>>>>>>>>>>>> ourselves to try and make a point.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's important to understand that OAE is an open source
>>>>>>>>>>>>>>>> project that requires a community of institutions and
>>>>>>>>>>>>>>>> individuals to participate and contribute for the project to
>>>>>>>>>>>>>>>> become sustainable. OAE is fortunate to have a number of
>>>>>>>>>>>>>>>> institutions that are putting time, staff and money into the
>>>>>>>>>>>>>>>> project, which makes it possible for a set of people to
>>>>>>>>>>>>>>>> provide some continuity and help move things ahead, but this
>>>>>>>>>>>>>>>> is not the same as being a vendor product. Just acting on
>>>>>>>>>>>>>>>> requests from various places in the community and dealing with
>>>>>>>>>>>>>>>> them ourselves is not helping the sustainability and is
>>>>>>>>>>>>>>>> potentially distracting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The project is already providing a QA environment [1] that's
>>>>>>>>>>>>>>>> available for everyone to use, but is redeployed every night.
>>>>>>>>>>>>>>>> In the medium term future, it will be providing a demo
>>>>>>>>>>>>>>>> environment that will be retaining data. There is also a
>>>>>>>>>>>>>>>> repository [2] available that contains all of the puppet
>>>>>>>>>>>>>>>> scripts required to set up a single box environment, a
>>>>>>>>>>>>>>>> clustered environment, etc. On top of that, it's also possible
>>>>>>>>>>>>>>>> to run OAE using Vagrant. I would say that that is already
>>>>>>>>>>>>>>>> more than what most projects are offering out of the box.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As I said, having an AMI makes a lot of sense. However, there
>>>>>>>>>>>>>>>> will be some work involved in making an AMI available, as well
>>>>>>>>>>>>>>>> as a lot of time required to maintain that AMI. Therefore, I'd
>>>>>>>>>>>>>>>> prefer to see these things come in as contributions rather
>>>>>>>>>>>>>>>> than requests, or at least having a different contribution
>>>>>>>>>>>>>>>> (e.g. full Chinese translation) would help justify spending
>>>>>>>>>>>>>>>> some time on the request.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I just want to be clear that I'm not picking on the idea or
>>>>>>>>>>>>>>>> you and I think it's absolutely fine for ideas like these to
>>>>>>>>>>>>>>>> be floated and discussed on list, but I do think it's
>>>>>>>>>>>>>>>> sometimes helpful to remind ourselves that we are an open
>>>>>>>>>>>>>>>> source project and need to be building a community of
>>>>>>>>>>>>>>>> contributors around that.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1] http://oae.oae-qa0.oaeproject.org
>>>>>>>>>>>>>>>> [2] https://github.com/oaeproject/puppet-hilary
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>>> Nicolaas
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10 Oct 2013, at 14:11, Harry Wang <[email protected]>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Nicolaas and Branden,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I have tried to configure a demo server using AWS by
>>>>>>>>>>>>>>>>> following the Readme but ended up with tons of problems due
>>>>>>>>>>>>>>>>> to the various package dependencies and etc.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Given that the QA environment is on a single box, I wonder
>>>>>>>>>>>>>>>>> whether it is possible for you guys to make it into an Amazon
>>>>>>>>>>>>>>>>> Machine Image (https://aws.amazon.com/amis) so that it is
>>>>>>>>>>>>>>>>> much easier for the community to setup a testing environment
>>>>>>>>>>>>>>>>> in the cloud?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Harry
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sep 5, 2013, at 5:35 AM, Nicolaas Matthijs
>>>>>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Harry,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As Branden indicated, there's a spectrum of ways in which a
>>>>>>>>>>>>>>>>>> system can be deployed and configured, determined by the
>>>>>>>>>>>>>>>>>> requirements around number of concurrent users you want to
>>>>>>>>>>>>>>>>>> support, whether or not you want the components to be fully
>>>>>>>>>>>>>>>>>> redundant, etc.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For example, we have a QA environment that is automatically
>>>>>>>>>>>>>>>>>> redeployed every night. As this environment is only used for
>>>>>>>>>>>>>>>>>> testing and demo purposes, it uses a single box with (I
>>>>>>>>>>>>>>>>>> believe) 3.75GB of memory and 1 vCPU, which is one of the
>>>>>>>>>>>>>>>>>> standard Joyent Ubuntu machines, and that seems to be plenty
>>>>>>>>>>>>>>>>>> for the limited use it is seeing. It does mean that if that
>>>>>>>>>>>>>>>>>> box goes down for any reason, the environment will be
>>>>>>>>>>>>>>>>>> unavailable as well.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The existing production environment is currently driven by
>>>>>>>>>>>>>>>>>> redundancy rather than number of concurrent users. It means
>>>>>>>>>>>>>>>>>> that we deploy each component at least 2 times to make sure
>>>>>>>>>>>>>>>>>> that there is no downtime associated to losing one of the
>>>>>>>>>>>>>>>>>> servers. In order to do this, we are currently opting to use
>>>>>>>>>>>>>>>>>> a larger number of small (a lot of these are single CPU
>>>>>>>>>>>>>>>>>> 512MB VMs), rather than a smaller number of beefier
>>>>>>>>>>>>>>>>>> machines. Because of what needs to be deployed to have a
>>>>>>>>>>>>>>>>>> minimum fully redundant deployment, we are expecting that we
>>>>>>>>>>>>>>>>>> won't be hitting the number of concurrent users this
>>>>>>>>>>>>>>>>>> environment can support anytime soon (in which case we'd
>>>>>>>>>>>>>>>>>> scale out and the system would be defined by concurrent
>>>>>>>>>>>>>>>>>> usage).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Obviously, it is possible to combine any number of
>>>>>>>>>>>>>>>>>> components onto a single box, but this can cause problems
>>>>>>>>>>>>>>>>>> for a highly loaded system where multiple components are
>>>>>>>>>>>>>>>>>> fighting for the same physical resources.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> All of these different configurations can be found in the
>>>>>>>>>>>>>>>>>> oae-provisioning repository.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hope that helps,
>>>>>>>>>>>>>>>>>> Nicolaas
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 5 Sep 2013, at 01:34, Branden Visser wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Harry, what machines you should run on dedicated
>>>>>>>>>>>>>>>>>>> hardware and how
>>>>>>>>>>>>>>>>>>> many of them very much depends on your requirements, both
>>>>>>>>>>>>>>>>>>> performance
>>>>>>>>>>>>>>>>>>> and SLA. The way the system is divided can be found in our
>>>>>>>>>>>>>>>>>>> technical
>>>>>>>>>>>>>>>>>>> overview [1], slide 16 and onward -- this is probably the
>>>>>>>>>>>>>>>>>>> information
>>>>>>>>>>>>>>>>>>> you've seen in status updates and presentations.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Everything we use to setup our deployment can be found in
>>>>>>>>>>>>>>>>>>> our puppet
>>>>>>>>>>>>>>>>>>> scripts [2], and our specific VM provisioning manifests for
>>>>>>>>>>>>>>>>>>> the Joyent
>>>>>>>>>>>>>>>>>>> cloud can be found in our oae-provisioning [3] repository.
>>>>>>>>>>>>>>>>>>> These will
>>>>>>>>>>>>>>>>>>> give a very detailed view of our configuration. In summary,
>>>>>>>>>>>>>>>>>>> you would
>>>>>>>>>>>>>>>>>>> find that we run a fully scaled out environment in
>>>>>>>>>>>>>>>>>>> production and
>>>>>>>>>>>>>>>>>>> staging, almost identical to what is on the technical
>>>>>>>>>>>>>>>>>>> overview slide
>>>>>>>>>>>>>>>>>>> #16. However, such redundancy and scale might not be
>>>>>>>>>>>>>>>>>>> necessary for
>>>>>>>>>>>>>>>>>>> most deployments.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We run all Ubuntu machines, but we have had success wildly
>>>>>>>>>>>>>>>>>>> hammering
>>>>>>>>>>>>>>>>>>> performance testing environments with smartos (for the app
>>>>>>>>>>>>>>>>>>> nodes,
>>>>>>>>>>>>>>>>>>> redis, rabbitmq, nginx) and CentOS (for Cassandra and
>>>>>>>>>>>>>>>>>>> ElasticSearch).
>>>>>>>>>>>>>>>>>>> We brought everything onto Ubuntu because puppetizing all
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> components for multiple OS' (which was necessary for mixed
>>>>>>>>>>>>>>>>>>> environments like QA) was a total nightmare.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hope that helps,
>>>>>>>>>>>>>>>>>>> Branden
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>> http://www.slideshare.net/nicolaasmatthijs/apereo-oae-architectural-overview
>>>>>>>>>>>>>>>>>>> [2] https://github.com/oaeproject/puppet-hilary
>>>>>>>>>>>>>>>>>>> [3]
>>>>>>>>>>>>>>>>>>> https://github.com/oaeproject/oae-provisioning/blob/master/production
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Wed, Sep 4, 2013 at 5:29 PM, Harry Wang
>>>>>>>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I wonder whether there is any documentation on the
>>>>>>>>>>>>>>>>>>>> recommended OAE production configuration, such as how many
>>>>>>>>>>>>>>>>>>>> application servers, database servers, server for preview
>>>>>>>>>>>>>>>>>>>> processing, recommended OS and hardware configuration, etc.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Given the many systems used in OAE, this information could
>>>>>>>>>>>>>>>>>>>> be of great help.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Harry
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> oae-dev mailing list
>>>>>>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> oae-dev mailing list
>>>>>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> oae-dev mailing list
>>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> D. Stuart Freeman
>>>>>>>>>>>>>>> Georgia Institute of Technology
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> oae-dev mailing list
>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
oae-dev mailing list
[email protected]
http://collab.sakaiproject.org/mailman/listinfo/oae-dev
