Perl 6 - the future is here, just unevenly distributed

IRC log for #puppet-openstack, 2013-03-28

| Channels | #puppet-openstack index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:42 comptona joined #puppet-openstack
05:27 comptona left #puppet-openstack
05:27 comptona_ joined #puppet-openstack
05:31 comptona joined #puppet-openstack
05:31 comptona joined #puppet-openstack
07:51 dachary joined #puppet-openstack
09:10 derekh joined #puppet-openstack
09:26 dachary joined #puppet-openstack
10:39 fc__ joined #puppet-openstack
10:53 EmilienM joined #puppet-openstack
10:54 EmilienM Hi there :)
10:55 flepied joined #puppet-openstack
10:56 sileht joined #puppet-openstack
10:56 sbadia joined #puppet-openstack
10:58 flepied hi sbadia, meet the enovance team: sileht, fc__ and EmilienM
10:58 sbadia hello
10:58 EmilienM sbadia: hey :) I've heard that you wand to contribute to Puppet modules for OpenStack :)
10:58 sbadia small presentation
10:59 sbadia i work at INRIA on Grid'5000 platform
10:59 EmilienM we thought that is the best place here to talk about that
10:59 EmilienM sbadia: nice :)
10:59 sbadia and 50% of my time on OpenCloudWare, and yes i would contribute to puppet modules :-)
10:59 EmilienM we guys at eNovance working on OpenStack Deployements
11:00 EmilienM sbadia: good news !
11:00 EmilienM sbadia: I think you are in the right place
11:00 EmilienM sbadia: we are working on Puppet modules too, since we need to deploy the next stable release (Grizzly), we need to improve modules to support it
11:00 EmilienM sbadia: sileht is actually working on it
11:01 EmilienM sbadia: and fc__ of course
11:01 sbadia ok
11:01 sbadia this work is visible on gh ?
11:01 sbadia or openstack gerrit ?
11:01 EmilienM sbadia: since there is a lot of new features in OpenStack subprojects, I think there is many things to do :)
11:01 EmilienM sbadia: yeah
11:01 EmilienM sbadia: 1 min plz
11:02 EmilienM sbadia: everything is on https://github.com/enovance
11:02 EmilienM we use https://github.com/puppetlabs
11:02 sbadia bodepd sent a message this morning to say that the github modules will be migrated gerrit
11:03 fc__ sbadia: indeed, but it's a WIP
11:04 sbadia ok
11:08 EmilienM sbadia: so I've heard that you've already played with OpenStack ? :)
11:08 EmilienM sbadia: which OpenStack project are you feeling good with ?
11:12 sbadia indead, i made a collection of script in order to deploy (openstack,opennebula,cloudstack,…) on g5k
11:12 sbadia with a « on-clic deploy »
11:12 EmilienM sbadia: amazing
11:13 EmilienM sbadia: are you confortable with Nova in Grizzly ?
11:14 EmilienM sbadia: actual puppet modules miss Cells features, and also a new service has been incubated : nova-conductor
11:14 EmilienM sbadia: I think that would be a good start
11:15 fc__ EmilienM: I think I already saw a pull-request concerning nova-conductor
11:15 EmilienM fc__: oops my bad
11:15 sbadia nope I have not yet tested grizzly :-s
11:16 EmilienM nova-cells should be very important to implement via Puppet
11:16 sbadia I looked for conductor
11:16 EmilienM since it allows us to deploy large scale nova
11:16 EmilienM sbadia: what do you think about starting with that ?
11:17 EmilienM sbadia: you can count on us for any OpenStack support if you need, we have a bunch of OpenStack guys here :)
11:17 sbadia large-scale ~ grid5000 :-) it seems great
11:23 sbadia yes i know it ^^
11:23 sbadia s/it/that/
11:23 sbadia anyway, thanks for this infos, i'll wath it all
11:23 EmilienM sbadia: that's why I immediatly thought about it :)
11:23 * EmilienM checks if the official doc is online or under review
11:23 EmilienM oops it seems the website is down :(
11:25 EmilienM sbadia: my pleasure
11:25 mjeanson joined #puppet-openstack
11:26 sbadia (informative case, my gh login is sbadia and openstack gerrit too)
11:31 EmilienM ok
11:45 dachary joined #puppet-openstack
12:38 dachary joined #puppet-openstack
12:51 EmilienM sbadia: the OpenStack Docs website is down but if you need to read the doc about cells, you can catch it here : https://review.openstack.org/#/c/19060/
13:24 gmi joined #puppet-openstack
14:34 gmi I'm trying to apply the 'openstack::all' class from the github master branch and I get this error "Error 400 on SERVER: Invalid parameter local_ip at /etc/puppet/modules/openstack/manifests/all.pp", and of course I'm just starting with Puppet and don't know much yet :(
15:11 mgagne joined #puppet-openstack
17:28 dachary joined #puppet-openstack
17:38 dachary joined #puppet-openstack
20:24 bodepd hi all.
20:24 bodepd lots of chatter today!
20:27 bodepd gmi there are some known issues with quantum atm.
20:27 bodepd EmilienM: question for you or one of the other enovance folks
20:27 bodepd sbadia: let me know how I can help.
20:29 bodepd I want to start getting quantum integrated, and I was looking at ciscosystems and enovance
20:29 bodepd is there a clear favorite that I should be using?
20:29 bodepd is cisco merging their changes upstream?
20:56 d3u joined #puppet-openstack
20:59 dachary joined #puppet-openstack
21:20 mgagne Is the quantum module actively maintained by cisco or enovance? To the best of my knowledges, there is no quantum module available on puppetforge that does not have some kind of issues or missing dependencies.
21:21 mgagne also we are planning on using the linuxbridge core plugin which isn't supported by neither version of the quantum module, even less by the openstack module.
21:30 bodepd I have the same question :)
21:30 bodepd I started looking at the diffs between those two modules
21:33 bodepd starting with the diffs of master.
21:34 bodepd it looks like both repos have some obvious bugs that are resolved in the other one
21:35 mgagne you mean they are both fixing issues with the original version without contributing back? Or is the upstream "dead" ?
21:36 bodepd so, I would consider enovance/openstack-quantum-puppet to be the original version
21:37 bodepd b/c I know the original author I worked with works for enovance
21:37 bodepd that is the upstream of the cisco module
21:37 bodepd and both groups are merging in each others patches
21:37 bodepd the grizzly brances are almost the same (between those repos)
21:37 bodepd but master seems to not be kept in sync
21:38 bodepd I sent an email to cisco to see if I could chat with someone about it
21:38 bodepd there are lots of enovance guys in this channel (but its pretty late in france atm)
21:38 mgagne hehe
21:39 bodepd I can see obvious bugs in master for both repos
21:39 bodepd so I have a feeling those are not tested/maintained
21:39 bodepd and  they diverge alot
21:40 bodepd https://github.com/puppetlabs/​puppetlabs-openstack/pull/167
21:40 bodepd that is probable the current state of thing.
21:40 bodepd dizz says that master from cisco seems to work perhaps with a simple change (the one proposed on this PR)
21:41 mgagne Are either of them used in production?
21:41 mgagne I don't see them at puppetforge: http://forge.puppetlabs.com/modules?q=quantum
21:41 mgagne So I assume they are using a private version or cloning from git directly, bypassing the forge.
21:43 bodepd I assume that certain versions of those repos are used in production
21:43 bodepd both cisco and enovance do production stuff based on their openstack modules
21:43 bodepd its not surprising that neither has published to the forge
21:50 mgagne The forge is bugging me. No everybody is using it nor updating their modules often. If you need the latest version of a module, you have to use the git version. And people are still declaring dependencies in Modulefile which are handled by downloading them from the forge. And then you have this Puppetfile thing coming into the game. And lets not forget .fixtures.yml. So all in all, I'm confused.
21:51 bodepd I agree. I was just working with the forges product manager today looking at the early preview of the auto-publish apis
21:52 bodepd so in ruby-land, the difference between Modulefile/Puppetfile is the difference between gem/bundler
21:53 bodepd right now, since there is no automatical publish apis for forge, its too hard to perform auto-updates, which affects general release cadence
21:53 bodepd in theroy, forge should be stable releases, github is development
21:53 bodepd the modulefile should only depend on other things from the forge (b/c that is all that puppet module tool supports)
21:54 bodepd its too hard to develop and release/test if you have to depend on forge releases (at least for me)
21:54 bodepd I often need to grab something, fork it, update my fork , and run CI.
21:54 mgagne of course, it's hard for me too ;)
21:54 bodepd enter Puppetfile, I can keep a manifest that tells me how to build out my module directory
21:55 bodepd it can include things from the forge, and git  refs from github
21:55 bodepd I am not running CI for forge releases
21:55 bodepd as a part of my plan to improve my own release cadence
21:56 bodepd fixtures is for running unit tests.
21:56 bodepd there are lots of dependencies that are required. it is meant to make it easier for anyone to run unit tests.
21:56 bodepd b/c rake spec will download all modules into the spec/fixtures/modules directory
21:56 mgagne yes
21:57 bodepd each module also needs to be able to install its unit test deps for travis to work
21:57 bodepd (which providers unit test gating)
21:57 bodepd are the answers to your questions in there?
21:57 mgagne yes and no ;)
21:58 mgagne what I find confusing is the disparity between Puppetfile, Modulefile and .fixtures.yml.
21:58 mgagne Puppetfile supports puppetforge and git
21:58 mgagne Modulefile only supports puppetforge
21:58 mgagne .fixtures.yml only supports git (to the best of my knowledge)
21:58 mgagne If I run a unit test with rspec, how can I ensure that my module will work correctly with the latest version on puppetforge, not github?
21:58 bodepd I never thougt about that issue with .fixtures.
21:59 bodepd mgagne: umm. that sounds like a great feature request :)
21:59 mgagne as you are testing against a version that could only be released in 2 days or 4 months.
21:59 mgagne so that's part of my confusion
21:59 bodepd mgagne: I hadn't thought about it. the .fixtures stuff was written for me (under my direction) and at the time, I only cared about master
21:59 mgagne but also, you are duplicating the information, once in .fixtures.yml and once in Modulefile.
21:59 bodepd so, each of those things was written independently
22:00 mgagne my coworker is equally confused, maybe more ;)
22:00 bodepd the idea behind fixtures, was that I always wanted to run tests against master (to help know if changes to external modules would break things)
22:00 bodepd but I agree this is confusing.
22:00 bodepd the reality is that those things were written by different teams with no coordination to solve slightly different problems
22:01 mgagne if there could by profile, it would answer both needs: testing for a future release, testing against the latest and greatest
22:01 bodepd I agree there is duplication.
22:02 mgagne I don't know how to fix that situation, just explaining the situation/confusion we had here in my team ;)
22:02 bodepd that is useful.
22:02 bodepd I dont get too many comments about that stuff.
22:02 bodepd except, I know lots of people are really frustrated that librarian-puppet is not maintained atm
22:02 bodepd (including me)
22:02 mgagne I had to use librarian-puppet-maestrodev
22:03 bodepd yeah, I also started using that
22:03 mgagne puppetlabs-apache crashes librarian-puppet ;)
22:03 mgagne because it's using -rc1 in its version number
22:03 bodepd but I find it to be still too heavy, complicated, error prone, and obtuse to use.
22:03 bodepd I am well aware.
22:04 mgagne can you poke the apache guy then, maybe with a stick? ;)
22:04 bodepd I can release a non rc version
22:04 bodepd I was looking at that today
22:07 mgagne thanks =)
22:44 bodepd just released 0.6.0
22:46 mgagne cool! :D

| Channels | #puppet-openstack index | Today | | Search | Google Search | Plain-Text | summary