search

jayjanssen / vagrant-percona-deprecated

Vagrant setup to launch Percona Server or PXC on virtualbox or AWS
19 stars 14 forks source link

Bugfix + added feature #8

Closed grypyrg closed 10 years ago

grypyrg commented 10 years ago

There's one bugfix in that sysbench was installing percona-server-shard

Other ones are features, which might impact other vagrant environments. I have rewritten the PXC service to another type of provider so that bootstrapping can be done during provisioning

And percona agent can be disabled in my Vagrantfile now, which does not have an impact on the other ones.

grypyrg commented 10 years ago

mysql-shared

I agree, and I don't agree:

Don't agree (but it doesn't matter, it's an opinion): I don't really believe in configuring many puppet provisioning lines in the Vagrantfile. It is really slow. It takes +5 seconds per provisioning line when using AWS. Now I only have this 1 time.

Agree: I understand you want to work like this, it has it's own benefits. So, I'll adapt it so I put dependencies in the main manifest, that way everything is less depended on eachother. Expect that shortly :)

grypyrg commented 10 years ago

bootstrap

I think I have another idea of dealing with the bootstrapping

Do you like this way better?

jayjanssen commented 10 years ago

On Jul 16, 2014, at 12:18 AM, grypyrg notifications@github.com wrote:

mysql-shared

I agree, and I don't agree:

Don't agree (but it doesn't matter, it's an opinion): I don't really believe in configuring many puppet provisioning lines in the Vagrantfile. It is really slow. It takes +5 seconds per provisioning line when using AWS. Now I only have this 1 time.

I agree with the argument that it’s slow. It is slow.

I like it in the Vagrantfile because then there is 1 file to look at to understand the environment, but that’s opinion.

Agree: I understand you want to work like this, it has it's own benefits. So, I'll adapt it so I put dependencies in the main manifest, that way everything is less depended on eachother. Expect that shortly :)

I think what drove me from the monolithic manifest idea was all the module interdependencies we had before. It seemed like anytime we created a new manifest, we had to go fix mysql-shared again in the modules, or whatever. What l like about the Vagrant model is that the lower level puppet modules are necessarily decoupled from each other. This hopefully gets the modules to a more stable state so we don’t need to touch them so often.

If we can maintain such independence between modules and handle dependencies like that in either a manifest or Vagrant provision ordering, I think it makes the modules simpler and easier to maintain, and new manifests easier to write.

grypyrg commented 10 years ago

What you're trying to do is very puppet specific.

In that case, we should look into moving to ansible.

jayjanssen commented 10 years ago

On Jul 16, 2014, at 3:20 AM, grypyrg notifications@github.com wrote:

I think I have another idea of dealing with the bootstrapping

do normal service start always when we declare a node as bootstrap-node, we run an Exec PRIOR to the normal mysql service start which bootstraps it (then the service is already running). This creates a file somewhere which then will never run anymore after it's first provision.

Is a dedicated file (/tmp/pxc_bootstrapped or whatever) better than /var/lib/mysql/grastate.dat? Not sure of the pros and cons.

Jay Janssen http://about.me/jay.janssen Sign up now for Percona XtraDB Cluster/Galera training in San Jose, CA http://bit.ly/2014-07-PXC-training

jayjanssen commented 10 years ago

I can’t invest here in my current position. I’m fine if this is a direction you want to go, but it should probably just be a distinct project.

On Jul 17, 2014, at 2:03 PM, grypyrg notifications@github.com wrote:

In that case, we should look into moving to ansible.

Jay Janssen http://about.me/jay.janssen Sign up now for Percona XtraDB Cluster/Galera training in San Jose, CA http://bit.ly/2014-07-PXC-training