Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add Ubuntu 16.04 as default nodeset #229

Closed
wants to merge 1 commit into from
Closed

add Ubuntu 16.04 as default nodeset #229

wants to merge 1 commit into from

Conversation

3flex
Copy link
Contributor

@3flex 3flex commented Sep 24, 2016

Using Ubuntu over CentOS might be contentious... not sure what's generally used more often.

But since these are typically used for automated testing Ubuntu seemed as good a choice as any.

@3flex
Copy link
Contributor Author

3flex commented Sep 24, 2016

Note that this doesn't conflict with #230. If both get merged, then someone running bundle exec rake beaker on their local machine would find acceptance tests run on Vagrant, using this host file for the host's configuration. #230 is only used in Travis.

@dhoppe
Copy link
Member

dhoppe commented Sep 29, 2016

As far as I know, we do not provide a default nodeset for our modules. Travis CI can be configured to test multiple operating systems and the user should be able to choose as they like.

@3flex
Copy link
Contributor Author

3flex commented Oct 5, 2016

This is for people running acceptance tests on their own machine(s), so they don't have to manually set BEAKER_set which is an extra step that's unnecessary if a default nodeset is provided. It reduces friction for new contributors.

I see your argument for not including it, so you can close if you prefer, or wait for feedback from others.

@wyardley
Copy link
Contributor

@3flex: FWIW, rake will already give various options, like:

rake beaker:centos-66-x64
rake beaker:centos-66-x64-pe
[...]
rake beaker:ssh:centos-66-x64
[...]
rake beaker:ubuntu-server-1604-x64

and so on. So it is possible to build on various platforms without setting BEAKER_x directly, however, rake beaker and rake acceptance will fail, I think, without a default nodeset. Is there an easy way for projects to set a per-project default nodeset without messing up the modulesync process?

One other thing we could probably add that might help would be more info in the CONTRIBUTING file.

@wyardley
Copy link
Contributor

ps - 16.04 is not yet working for me, so in any event, let's fix that problem first.
I think there's only -pc1. changing type to 'aio' from 'foss' didn't help, looking into what will fix it...

/usr/local/lib/ruby/gems/2.3.0/gems/beaker-2.51.0/lib/beaker/host.rb:351:in `exec': Host 'ubuntu-server-1604-x64' exited with 8 running: (Beaker::Host::CommandFailure)
 wget -O /tmp/puppet.deb http://apt.puppetlabs.com/puppetlabs-release-xenial.deb
Last 10 lines of output were:
    --2016-10-27 10:21:08--  http://apt.puppetlabs.com/puppetlabs-release-xenial.deb

@igalic
Copy link
Contributor

igalic commented Oct 27, 2016

@3flex why's this not simply a symlink? or will that… make windows sad?

@3flex
Copy link
Contributor Author

3flex commented Jan 5, 2017

@wyardley we could remove the default nodeset from modulesync_config and allow individual modules to set it themselves if desired. Or it could be added to .sync.yml to allow the module to choose the default nodeset, and enhance msync to copy it to nodesets/default.yml on a module sync - this actually might be better as some modules may be more geared to a certain OS and it allows the module to choose its own.

I still firmly believe that SOME default should exist. Just makes it easier for those looking to contribute. More documentation in CONTRIBUTING would also help a lot.

@igalic yep...

@juniorsysadmin
Copy link
Member

Or it could be added to .sync.yml to allow the module to choose the default nodeset, and enhance msync to copy it to nodesets/default.yml on a module sync

That sounds like the best option, but I'm okay with no default or a default

@3flex
Copy link
Contributor Author

3flex commented Apr 10, 2018

Closing as I don't intend to work on this in future. If anyone wants to see forward momentum on this I'd suggest opening a new issue for tracking purposes.

@3flex 3flex closed this Apr 10, 2018
@3flex 3flex deleted the update_nodesets branch April 10, 2018 02:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants