Perl 6 - the future is here, just unevenly distributed

IRC log for #puppet-openstack, 2013-10-15

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

All times shown according to UTC.

Time Nick Message
00:04 ryanycol_ joined #puppet-openstack
00:17 ryanycoleman joined #puppet-openstack
00:20 ryanycol_ joined #puppet-openstack
00:52 tnoor joined #puppet-openstack
00:57 ryanycoleman joined #puppet-openstack
01:27 ryanycoleman joined #puppet-openstack
01:47 xingchao joined #puppet-openstack
02:32 ryanycoleman joined #puppet-openstack
03:33 ryanycoleman joined #puppet-openstack
03:39 michchap joined #puppet-openstack
04:34 ryanycoleman joined #puppet-openstack
05:20 tnoor joined #puppet-openstack
05:22 tnoor1 joined #puppet-openstack
05:34 ryanycoleman joined #puppet-openstack
06:31 otherwiseguy joined #puppet-openstack
06:35 ryanycoleman joined #puppet-openstack
06:37 francois1 joined #puppet-openstack
06:56 marun joined #puppet-openstack
07:12 tnoor joined #puppet-openstack
07:13 tnoor2 joined #puppet-openstack
07:26 qba73 joined #puppet-openstack
07:30 beddari before the puppetlabs/grizzly module there was no higher level module to pull stuff together?
07:36 ryanycoleman joined #puppet-openstack
07:38 dafter joined #puppet-openstack
07:38 dafter joined #puppet-openstack
08:08 derekh joined #puppet-openstack
08:15 tvb|afk joined #puppet-openstack
08:20 qba73 joined #puppet-openstack
08:36 ryanycoleman joined #puppet-openstack
08:57 e1mer joined #puppet-openstack
09:37 ryanycoleman joined #puppet-openstack
09:39 pabelanger joined #puppet-openstack
09:42 dafter joined #puppet-openstack
09:49 tvb|afk joined #puppet-openstack
09:49 tvb|afk joined #puppet-openstack
10:36 qba73 joined #puppet-openstack
10:37 dafter joined #puppet-openstack
10:38 ryanycoleman joined #puppet-openstack
10:42 michchap_ joined #puppet-openstack
10:42 tvb|afk joined #puppet-openstack
10:42 tvb|afk joined #puppet-openstack
11:02 dafter joined #puppet-openstack
11:02 dafter joined #puppet-openstack
11:02 otherwiseguy joined #puppet-openstack
11:28 tvb|afk joined #puppet-openstack
11:28 tvb|afk joined #puppet-openstack
11:29 dafter_ joined #puppet-openstack
11:30 dafter_ joined #puppet-openstack
11:36 dmsimard joined #puppet-openstack
11:40 dmsimard1 joined #puppet-openstack
11:44 marun joined #puppet-openstack
11:52 dafter joined #puppet-openstack
11:53 e1mer joined #puppet-openstack
11:54 qba73 joined #puppet-openstack
11:57 tvb|afk joined #puppet-openstack
11:57 tvb|afk joined #puppet-openstack
11:57 tvb|afk joined #puppet-openstack
11:57 tvb|afk joined #puppet-openstack
12:16 dmsimard joined #puppet-openstack
12:18 dmsimard1 joined #puppet-openstack
12:28 dmsimard joined #puppet-openstack
12:28 dmsimard left #puppet-openstack
12:38 ryanycoleman joined #puppet-openstack
12:40 marun joined #puppet-openstack
12:49 qba73 joined #puppet-openstack
13:02 openstackgerrit joined #puppet-openstack
13:07 dafter joined #puppet-openstack
13:15 dafter joined #puppet-openstack
13:18 tvb|afk joined #puppet-openstack
13:18 tvb|afk joined #puppet-openstack
13:22 dmsimard joined #puppet-openstack
13:25 dprince joined #puppet-openstack
13:27 dmsimard1 joined #puppet-openstack
13:31 dguitarbite_ joined #puppet-openstack
13:32 dmsimard1 left #puppet-openstack
13:39 ryanycoleman joined #puppet-openstack
13:50 prad joined #puppet-openstack
14:00 marun hmmm
14:00 marun can anyone tell me if provisioning support exists for nova-network?
14:01 EmilienM marun: provisioning of what ?
14:01 marun errr
14:02 EmilienM marun: install nova-network with puppet ?
14:02 marun does nova network require any of the provisioning that neutron does?
14:03 EmilienM marun: i'm sorry, i don't get the "provisioning" word
14:04 marun create public network/public subnet/etc
14:04 EmilienM oh
14:04 EmilienM marun: got it
14:05 EmilienM marun: not as far i know
14:05 EmilienM marun: it was assumed by puppet-nova with nova-manage CLI
14:05 EmilienM marun: and current puppet-neutron does not run neutron CLI
14:05 EmilienM marun: which would be very necessary imo
14:06 marun hmmm
14:40 ryanycoleman joined #puppet-openstack
14:57 openstackgerrit Francesco Vollero proposed a change to stackforge/puppet-ceilometer: Added alarm-notifier and alarm-evaluator services  https://review.openstack.org/50699
15:05 dmsimard joined #puppet-openstack
15:14 mgagne joined #puppet-openstack
15:40 ryanycoleman joined #puppet-openstack
16:07 hogepodge joined #puppet-openstack
16:17 mmagr joined #puppet-openstack
16:38 ryanycoleman joined #puppet-openstack
16:38 hogepodge_ joined #puppet-openstack
16:43 ari joined #puppet-openstack
16:54 ryanycoleman joined #puppet-openstack
16:59 morazi joined #puppet-openstack
17:05 fvollero EmilienM: mgagne : bodepd_ : You could be so kind to review this? https://review.openstack.org/50699
17:21 fvollero mgagne: about https://review.openstack.org/#/c/​50699/4/manifests/alarm/notifier.pp which would be your solution? third manifest or defined?
17:21 mgagne fvollero: both are valid. we don't have a "design pattern" for common packages yet, we usually rely on if defined for the moment.
17:22 fvollero mgagne: fair enough :) (+1 for puppet design pattern )
17:23 ari joined #puppet-openstack
17:27 fvollero mgagne: but if i'm using undef, the if have to be removed or i should use define?
17:27 mgagne $a = undef;
17:27 mgagne if $a != undef {
17:27 mgagne }
17:27 dafter joined #puppet-openstack
17:27 fvollero mgagne: gotcha
17:36 ryanycoleman joined #puppet-openstack
17:38 openstackgerrit joined #puppet-openstack
17:51 JonnyNomad joined #puppet-openstack
17:55 openstackgerrit Francesco Vollero proposed a change to stackforge/puppet-ceilometer: Added alarm-notifier and alarm-evaluator services  https://review.openstack.org/50699
17:56 fvollero mgagne: hopefully this time there's no code smelling/erorrs
17:57 EmilienM fvollero: i review it now
17:57 fvollero EmilienM: merci
17:59 EmilienM fvollero: fyi, package is not ready for ubuntu yet, only for debian
17:59 EmilienM fvollero: i'll test it tomorrow against debian & rhel
18:00 mgagne fvollero: I would avoid writing the complete history of your review in the commit message. There is already a link provided in git notes to gerrit if people are really interested in history.
18:00 EmilienM otherwise, lgtm
18:01 fvollero mgagne: bad habits
18:01 EmilienM mgagne: fvollero: i would like to see an example in examples/site.pp also
18:01 EmilienM it helps the community to use modules
18:02 fvollero EmilienM: i'll do in a second patch
18:02 EmilienM and avoid making support here
18:02 fvollero +10
18:02 EmilienM fvollero: thank you. It make win some time to all of us
18:02 fvollero sure thing
18:02 EmilienM fvollero: but tomorrow, it's late for us now :)
18:02 mgagne fvollero: did you test your change?
18:03 fvollero mgagne: yeah. 286 examples, 0 failures
18:03 fvollero mgagne: in fact i'm looking now at the jenkins errors
18:03 mgagne fvollero: I'm not talking about unit tests.
18:03 mgagne fvollero: like on a real setup
18:03 fvollero mgagne: validate
18:04 fvollero mgagne: i'm testing in parallel with packstack
18:04 mgagne fvollero: I'm asking because you should have see the conflicting packages (if all manifests were included on the same server)
18:04 fvollero mgagne: in fact, I was having packstack rolling + the patch sent
18:04 fvollero mgagne: you was faster than packstack
18:04 mgagne fvollero: =)
18:05 fvollero mgagne: btw i can't understand why jenkins is complaining while my puppet parser validate didn't
18:05 mgagne fvollero: you are using puppet 3.0
18:05 mgagne 3.0+
18:05 fvollero mgagne: :(
18:05 fvollero mgagne: so i can't use unless in this case
18:06 mgagne puppet 2.7 is used on the slaves, it can't know about possible future syntax.
18:06 mgagne if ! defined
18:06 fvollero mgagne: ok :)
18:25 openstackgerrit Francesco Vollero proposed a change to stackforge/puppet-ceilometer: Added alarm-notifier and alarm-evaluator services  https://review.openstack.org/50699
18:29 mgagne Hunner: ping
18:30 bodepd_ mgagne: where do I open blueprints that are not specific to a module?
18:31 Hunner mgagne: Hi
18:31 mgagne bodepd_: I would put it in puppet-openstack for now
18:31 mgagne Hunner: hi
18:31 bodepd_ mgagne: thanks!
18:31 bodepd_ create a ceph blueprint
18:32 mgagne Hunner: I would like to know if there's any plan for puppetlabs to allow to "pin" to a puppet version without having to rely on package pinning.
18:32 bodepd_ s/create/creating/
18:32 badiane_ka joined #puppet-openstack
18:32 Hunner mgagne: Do you mean for modules to depend on specific puppet versions?
18:32 mgagne Hunner: I mean for puppet itself
18:33 mgagne Hunner: So I can do this instead: deb http://apt.puppetlabs.com precise 3.0
18:33 Hunner Ah. Mmm, that would be a question for haus... let me ask
18:34 mgagne Hunner: I read multiple emails/tickets/blog/bugs/whatever about it and it has always been the same answer: deal with it with pinning.
18:34 Hunner mgagne: Also, 3.3 is backwards-compatible with 3.0... the 2.x series wasn't semver, but 3.0 started semver
18:34 mgagne Hunner: However I don't feel it's the right approach and would like puppetlabs to revisit their statements
18:35 mgagne Hunner: 3.3 is not backward compatible
18:35 Hunner :(
18:35 mgagne Hunner: they changed the protocol between the agent and the master
18:35 blkperl mgagne: I think they fixed the deprecation warnings in 3.3.1
18:35 blkperl 3.3 was a buggy release
18:36 mgagne either ways, it's not the question
18:36 Hunner Yeah, still asking...
18:36 mgagne I don't want to find in production that puppetlabs released a buggy minor version
18:38 mgagne Hunner: with apt, it's easy to pin to a version. with yum, So far, I can only exclude versions I don't want.
18:38 Kupo24z joined #puppet-openstack
18:38 haus joined #puppet-openstack
18:39 Hunner mgagne: So yum is the issue, not apt?
18:39 mgagne Hunner: no
18:40 mgagne Hunner: why can't I configure a single repo and never hear again about a minor version being released without having to pin to versions.
18:41 ari joined #puppet-openstack
18:42 mgagne Hunner: I'm asking because I'm reading about Foreman and they provide the user a way to pin to a version without having to pin themselves to a version: http://theforeman.org/manuals/1.3/index.html#3.3InstallFromPackages
18:43 e-vad hogepodge: i moved the auth_file bits over to profile and cleaned up the role definition
18:45 Hunner mgagne: We don't currently backport security bugfixes to older minor releases (like 3.2.x to 3.0.x) as the 3.x series is *supposed* to be backwards-compatible, even for different master/agent versions (bugs notwithstanding)... I know it's not the same thing as repos providing a specific minor series progression, but that is the reasoning behind it, I believe
18:46 mgagne Hunner: "supposed" is important here and so far, I didn't find it to be true.
18:47 mgagne Hunner: that's why I don't trust puppetlabs anymore on this aspect
18:47 Hunner mgagne: Unfortunately yes, but with decreasing frequency!
18:47 Hunner mgagne: And running a downstream repo is out of the question?
18:47 mgagne Hunner: sorry, I cannot take that risk anymore
18:48 mgagne Hunner: I'm already running a downstream repo because upstream repo is often unreachable.
18:48 mgagne Hunner: I want to remove the pinning configuration altogether
18:48 Hunner mgagne: Looking at foreman... that is one project, but you'd need repos for puppet/hiera/facter/mcollective/puppetdb... that's 5 repos
18:49 * Hunner is just trying to think through this out loud; not necessarily arguing against it
18:51 Hunner mgagne: I wouldn't doubt that this might be a little "open-source wild west" made available by a company that also has a commercial distribution of the product... which is going to be different than the "open-source" mentality of openstack that is the ideal...
18:53 mgagne Hunner: I forgot about hiera and friends... =(
18:54 Hunner Anyway, I'm afraid I don't have an answer that is encouraging as per your original question, but I hope it is not to be taken as a case of semi-intentional malpractice either
18:55 mgagne Hunner: no worries, I guess it isn't as easy as I thought
18:55 ari joined #puppet-openstack
18:55 Kupo24z left #puppet-openstack
18:56 Hunner mgagne: Being an upstream repo has it's growing pains, and a downstream repo has it's slow-growth ails :/
18:56 dprince joined #puppet-openstack
18:56 ryanycoleman joined #puppet-openstack
18:56 mgagne Hunner: I'm already running multiple downstream repos, I unfortunately learned to never trust upstream repos
18:58 Hunner mgagne: You have wisdom. I've met only a few shops that ran ensure => latest and pointed at upstream repos... and that doesn't last for long!
19:01 derekh joined #puppet-openstack
19:01 ashp Let me tell you about the morning I discovered we had ensure => latest
19:01 ashp (it was the day that 3.0.0 released)
19:02 mgagne Hunner: even with ensure => installed, your friend the sysadmin will come see you one day and say: why isn't puppet working anymore on this new server? And you find out that the new backward compatible version of puppet isn't that backward compatible and now you pin everything and become distrustful of upstream.
19:02 blkperl ashp: haha
19:02 blkperl ashp: saw that coming and planned ahead :)
19:04 ashp blkperl: That was the day we started doing ensure => 'x.x.x' :D
19:04 mgagne Hunner: and even if I have a downstream repo which I configured with puppetlabs instructions using rsync, one day it broke and I had to poke someone at PL about it. =)
19:05 mgagne Hunner: anyway, thanks for listening to my mini-rant ^^'
19:10 bodepd_ mgagne: you have to pin the repo versions for the apt repo
19:10 bodepd_ mgagne: otherwise, you will be surprised when Puppet 4 comes out :)
19:11 bodepd_ mgagne: also, the packages do not resolve -common correctly, so you have to handle that installation manually
19:11 bodepd_ s/manually/manual set version and dependency in Puppet/
19:11 mgagne bodepd_: I know the pinning process. I was inquiring about plans for puppetlabs to ease the process by providing a repo with a known minor version.
19:11 bodepd_ mgagne: Puppetlabs has purposedly made the decision not to do that
19:11 hogepodge bodepd_: I just had -common blow up on an upgrade. heh
19:12 bodepd_ mgagne: it was quite a fight, but the person who was in charge
19:12 mgagne bodepd_: I know...
19:12 bodepd_ mgagne: decided they don't like that
19:12 mgagne bodepd_: is he still there? :D
19:12 bodepd_ I have recommended that somone else set up their own repo
19:12 bodepd_ and support pinning. I would use that one!!!
19:12 bodepd_ he's a director.
19:12 bodepd_ so the decision is only getting firmer
19:13 bodepd_ hogepodge: yeah, it's kind of a rediculous known issue
19:13 mgagne bodepd_: Hunner reminded me about hiera, facter and friends...
19:13 bodepd_ if you ask about it in #puppet
19:13 bodepd_ someone will know the answer is to manage those deps themselves
19:13 bodepd_ mgagne: what about them?
19:14 * bodepd_ thought he read the thread
19:14 mgagne bodepd_: to which versions do you pin them? =)
19:14 mgagne bodepd_: or do you create a repo per dependency?
19:14 bodepd_ mgagne: whatever version they are set to in the package version you pin?
19:14 bodepd_ mgagne: what sounds like something that should be solved by packages
19:14 bodepd_ s/what/that/
19:15 mgagne bodepd_: you might not understand the ramification of the question
19:15 bodepd_ https://wiki.openstack.org/wiki/Puppet-openst​ack/ceph-blueprint#ceph_client_implementation
19:15 mgagne bodepd_: hold on
19:15 bodepd_ https://wiki.openstack.org/wiki/​Puppet-openstack/ceph-blueprint
19:16 mgagne bodepd_: puppet requires something above 1.0.0 (for hiera). Which version do you pin to? And what about facter?
19:17 bodepd_ mgagne: that sounds like a bug
19:17 bodepd_ mgagne: I would expect it to be pinned to a bug fix release.
19:17 bodepd_ >1.0.0 < 1.1.0
19:18 mgagne bodepd_: Is the development on hiera/facter synced with puppet?
19:19 bodepd_ the packages have to be synced b/c they are required
19:19 bodepd_ ah. gotcha
19:19 bodepd_ they are decoupled
19:19 bodepd_ but they are coupled based on interfaces that can change between major versions
19:19 mgagne bodepd_: what if I want hiera 1.1 instead because of some cool automagic they added? like hiera variable interpolation :D
19:21 bodepd_ gotcha.
19:22 mgagne bodepd_: supposed I'm superman and wish to create THAT repo you dreamt about, I wouldn't know how to handle those dependencies. Furthermore, puppetlabs provides its own ruby packages.
19:22 bodepd_ I don't know the exactly how package deps are set between those components
19:23 bodepd_ which is context I need.
19:23 bodepd_ I think that consistent versions with only bug fix updates would suffice for 90% of all users
19:24 mgagne bodepd_: and remaining 10% will have to rely on pinning :D
19:27 ryanycoleman joined #puppet-openstack
19:51 tnoor joined #puppet-openstack
19:57 tnoor1 joined #puppet-openstack
20:08 mgagne bodepd_: FYI, a coworker of mine is already working on puppet-ceph. I sent him the link to your email on the list.
20:12 ryanycoleman joined #puppet-openstack
20:27 EmilienM mgagne: does it make sense to move puppet-ceph as a puppetlabs official module ?
20:28 mgagne EmilienM: one thing is sure, my co-worker thinks there's too many outdated forks =)
20:28 EmilienM mgagne: tell him to use one of our github, we maintain it and run it in production
20:29 mgagne EmilienM: he explicitly menttionned yours as being outdated (to his taste)
20:29 EmilienM in fact, there is indeed some feature we miss
20:29 EmilienM like using ceph-deploy
20:30 EmilienM mgagne: but having a module as reference would facilitate the things
20:30 EmilienM and avoid forks
20:30 mgagne EmilienM: I don't have an opinion on it, I'm not working on ceph =)
20:30 EmilienM mgagne: me neither specificaly, i just have to deploy. I'm a puppet user this time
20:31 EmilienM mgagne: what would he recommends ?
20:32 mgagne EmilienM: I sent him the link. I can ask him to comment on it.
20:32 EmilienM sure
20:34 bodepd_ to some extent it has to be
20:35 bodepd_ EmilienM: I know cisco had some specific issues with the orchestration required with the enovance version of the module
20:35 bodepd_ EmilienM: please get involved. I wanted to start with basic requirements to get everyone on the same page
20:35 bodepd_ EmilienM: I believe Loic was of the opinion that many things have changed in ceph since the enovance version was written that should make a future implementation much easer
20:35 bodepd_ easier
20:36 EmilienM sure
20:36 bodepd_ I know the enovance one is cited as an existing example
20:36 bodepd_ for now, dachary is focused on seeing what it out there
20:37 bodepd_ and making recomendations for how the community should consolidate
20:37 bodepd_ I have a feeling the outcome will be something new that borrows from the best parts of each of the existing modules
20:37 bodepd_ dachary: although you could probably speak better about this yourself
20:38 dmsimard EmilienM: ping, i'm the guy using puppet-ceph
20:38 dmsimard bodepd_: ping too
20:38 bodepd_ dmsimard: yessir :)
20:38 dmsimard I already talked to Sage (founder of Ceph and at Inktank now) about the puppet-ceph initiative
20:39 bodepd_ :) I didn't realize it had raised to the level of initiative :)
20:39 EmilienM bodepd_: trust me that we will contribute to this "common" work
20:39 bodepd_ thanks everyone for being so understaning
20:39 bodepd_ and willing to collaborate
20:39 bodepd_ I think it's important to get everyone's requirements first
20:39 bodepd_ which is hte purpose of the wiki doc
20:39 dmsimard the puppet-ceph project is indeed very fragmented (40 forks) and I asked him if Inktank had plans to centralize the effort like they do for chef https://github.com/ceph/ceph-cookbooks
20:40 dmsimard They simply don't have the time/manpower to do that right now
20:40 * EmilienM off (late here)
20:40 bodepd_ I didn't even realize they maintained cookbooks
20:40 dmsimard Yup.
20:40 dmsimard Then, there's two methods of deploying (three, if you will)
20:41 bodepd_ I think there is plenty of mind-share manpower around stackforge/openstack to get it done
20:41 dmsimard ceph-deploy by itself, puppet running "manual" ceph commands or puppet running ceph-deploy commands
20:41 dmsimard puppet-ceph runs "manual" ceph commands, Mirantis wraps ceph-deploy in their recipes
20:41 bodepd_ dmsimard: we had a call about this this morning
20:41 bodepd_ with a few ceph developers
20:41 bodepd_ probably should have made it more of an open invite
20:42 bodepd_ dmsimard: dachary you guys should probably chat. sounds like dmsimard may have a head start on you :)
20:42 dmsimard I'd be glad to contribute - I've been working with Dalgaaf from Deutsche Telekom on their fork: https://github.com/TelekomCloud​/puppet-ceph/tree/rc/eisbrecher
20:43 ryanycoleman joined #puppet-openstack
20:43 ryanycol_ joined #puppet-openstack
20:44 bodepd_ dmsimard: that looks realy robust
20:44 bodepd_ dmsimard: can you add that to the list of existing modules in the wiki?
20:44 bodepd_ I think one of the desired outcomes is to decouple it from exporting/collecting resources
20:45 bodepd_ which IIRC, is part of the reason Cisco chose not to use it
20:45 dmsimard Yeah, it uses stored configurations to build configuration files and such
20:46 dmsimard Then, like I said, there is Mirantis that wraps around ceph-deploy: https://github.com/Mirantis/fuel/t​ree/master/deployment/puppet/ceph
20:46 bodepd_ I think that led to some deployment complexity that was deemed too complicated
20:46 bodepd_ in the call this morning, the author said he advises against using ceph-deploy
20:46 dmsimard The lead developer for ceph-deploy told me we shouldn't wrap around ceph-deploy, however
20:46 dmsimard Yup.
20:46 bodepd_ yeah, he was on the call
20:46 bodepd_ b/c he does not want to have to add every command option to ceph-deploy
20:47 dmsimard Where should I add the repo to the wiki ? Can you point me in the right direction ?
20:48 bodepd_ https://wiki.openstack.org/wiki/​Puppet-openstack/ceph-blueprint
20:48 bodepd_ it's probably more helpful to help define some of the requirements
20:49 bodepd_ s/more/additionally/
20:49 dmsimard I'll have a look, mgagne sent me the link to your post earlier
20:49 bodepd_ and required components
20:51 bodepd_ I would love to allocate some time to work on custom types/providers
20:51 bodepd_ to wrap ceph commands...
20:51 bodepd_ to simply the implementation
20:51 bodepd_ or better yet, teach someone else how :)
20:58 dmsimard I'm not as knowledgeable as mgagne but he's next to me whenever I have questions :)
20:58 ryanycoleman joined #puppet-openstack
20:58 dmsimard It would be awesome to have make puppet-ceph a part of stackforge.
20:59 EmilienM dmsimard: i disagree at this point
21:00 EmilienM dmsimard: i would prefer seeing the module in ceph github or puppetlabs
21:00 EmilienM dmsimard: ceph is not part of openstack, so it can't be hosted on stackforge
21:00 bodepd_ EmilienM: I could go for it being hosted under ceph's namespace
21:00 bodepd_ EmilienM: but open-vswitch was recently moved to stackforge
21:01 EmilienM what the community wants i think, is a common place to contribute, and making an awesome module
21:01 EmilienM bodepd_: indeed, i forget this one...
21:01 bodepd_ EmilienM: I totally agree
21:01 dmsimard EmilienM: Okay, I did not express myself correctly - we agree on what the community wants
21:01 bodepd_ EmilienM: please make that point in the email I sent out
21:01 dmsimard And this is what I meant
21:01 bodepd_ EmilienM: that perhaps it should be hosted under the ceph namespace
21:02 bodepd_ the advantage of stackforge though is that it will be eaiser to develop on in cooridination with openstack
21:02 EmilienM bodepd_: if they already have chef recipes, why not hosting also puppet module ?
21:02 EmilienM that would make sense
21:02 bodepd_ and clearly openstack is driving the creation/maintainance of this module
21:02 EmilienM and continuity
21:02 bodepd_ the disadvantage is that ceph is not openstack specific
21:02 ryanycol_ joined #puppet-openstack
21:03 dmsimard I don't exactly see that as a disadvantage
21:03 dmsimard It simply means that the module should allow easy integration with openstack
21:03 bodepd_ the disadvantage is that potentially, it does not get traction b/c it is viewed as the 'openstack' dolution
21:04 dmsimard Oh, I see where you're going
21:04 bodepd_ s/d/s/
21:06 hogepodge bodepd_: supporting releases on the forge could help with that problem. It wouldn't necessarily appear as an OpenStack product there. I just floated the idea internally of PL supporting the module
21:07 EmilienM bodepd_: sent :)
21:08 dmsimard In my experience though, a ceph cluster is agnostic, is it not ? A ceph cluster used for block or object storage could be used by openstack or anything - the configuration does not change, maybe components (ex: radosgw) are added as necessary
21:10 bodepd_ the question becomes where it will receieve more love
21:10 bodepd_ and have a better development process
21:11 bodepd_ I know we can apply the same development processes as the other modules if its on stackforge
21:11 bodepd_ and have the same community control the quality
21:13 hogepodge bodepd_: would potential developers have to sign the OS CLA?
21:13 bodepd_ if it is in stackforge, then yes
21:13 hogepodge bodepd_: that might be the largest impediment to community uptake outside of OS
21:16 bodepd_ I listed that as a pro :)
21:16 bodepd_ I tried to capture some pros/cons of each location
21:16 bodepd_ everyone feel free to add their thoughts
21:17 hogepodge right :-) Cuts both ways. U Oregon held up my CLA for months.
21:17 bodepd_ I was assuming that a CLA is probabl a good thing
21:18 bodepd_ It's too bad there is not some universal CLA
21:18 bodepd_ for everything
21:18 bodepd_ one CLA to rule them all
21:18 e-vad indeed
21:18 e-vad would make my life easier for sure
21:20 hogepodge In general probably not a big deal. Anyone who is interested probably can get it signed. UO was weird in that sense. Not really an open source player, and much more interested in commercialization. They've even started turning their nose up at just using open source internally. They're killing my OpenStack cluster in favor of vmware.
21:21 dmsimard hogepodge: ew.
21:22 e-vad sorry to hear that
21:22 * dachary reading the backlog dmsimard bodepd_
21:31 otherwiseguy joined #puppet-openstack
21:38 ryanycoleman joined #puppet-openstack
21:40 ryanycol_ joined #puppet-openstack
21:40 dachary dmsimard: bodepd_ EmilienM I added a paragraph to capture the discussion about ceph not being an openstack component https://wiki.openstack.org/wiki/Pupp​et-openstack/ceph-blueprint#Overview
21:42 dmsimard dachary: Makes sense - we were wondering about the sake of consistency though (for instance Chef cookbooks are under the ceph namespace)
21:43 dachary dmsimard: that's right
21:44 dachary I honestly don't know how to make it so chef / puppet / ansible / salt ... somehow share their requirements and architecture.
21:45 dachary there seems to be an opportunity at the moment for puppet & ceph & openstack . Maybe because Ceph is getting traction and the summit is next month ;-)
21:45 dachary an opportunity to bootstrap something sensible
21:47 dmsimard bodepd_: Is there some sort of written resume about the phone call ? Or is that the result of the blueprint ?
21:47 * dachary browsing dmsimard work on https://github.com/TelekomCloud​/puppet-ceph/tree/rc/eisbrecher
21:47 dachary dmsimard: the discussion was about 30 minute and there is no transcript.
21:48 mgagne dachary: ask the nsa for the transcript
21:48 dmsimard mgagne: lol
21:48 dachary mgagne: :-D
21:48 * mgagne takes over
21:48 dmsimard Isn't the NSA on vacation or something since the government is shut down? :p
21:49 dachary mgagne: do you have an opinion on how the Ceph puppet module should be architectured ?
21:50 mgagne dachary: not yet, I don't use ceph myself, dmsimard is. We should ask those people at PL. They recently made multiple refactors.
21:50 dachary PL ?
21:50 mgagne puppetlabs
21:50 dachary oh :-)
21:51 dachary do you know the URL of one of these refactors ?
21:52 mgagne dachary: https://github.com/puppetlabs/puppetlabs-apache
21:52 dmsimard dachary: I know postgresql made a lot of noise
21:53 dachary oh you mean puppetlabs has been refactoring their modules , right ? I thought you meant they had a refactor of a Ceph module, my bad ;-)
21:53 dachary mgagne: ^
21:56 mgagne dachary: yes, their modules. they are now following some kind of design patterns. we should ask them about it.
21:59 hogepodge dachary mgagne : http://docs.puppetlabs.com/gu​ides/module_guides/bgtm.html
22:00 mgagne hogepodge: thanks! this is new (to me)
22:00 hogepodge It's new to us too!
22:00 ryanycoleman joined #puppet-openstack
22:05 michchap joined #puppet-openstack
22:08 dachary hogepodge: thanks for the link :-)
22:08 dachary eisb
22:09 hogepodge A lot of this refactoring/documentation has to do with shifting of resources to explicitly focus on modules and the forge.
22:09 dachary https://github.com/TelekomCloud​/puppet-ceph/tree/rc/eisbrecher is a lot of work dmsimard :-)
22:10 dmsimard dachary: Indeed. I give all the credit to them, though - I just helped testing features :)
22:10 dmsimard I poked the person I've been working with (Dalgaaf) by e-mail and pointed him to the blueprints and the google discussion
22:11 dmsimard We already had a discussion about what we should do to centralize the puppet-ceph efforts so this will surely be of interest to him as well :)
22:28 haus left #puppet-openstack
22:32 iwi hi there, anyone aware of a solution to "Invalid parameter provider at nova/manifests/rabbitmq.pp:68". I've just tried to invoke openstack::all on a new ubuntu 12.04 VM
22:33 iwi puppet 3.1.1, puppetlabs-openstack 2.2 with all dependencies (including rabbitmq 2.1.0)
22:35 openstackgerrit Rob Crittenden proposed a change to stackforge/puppet-horizon: When listen_ssl is true, enable the SSL engine and set a cert/key  https://review.openstack.org/49799
22:40 iwi please help :)
22:56 mgagne iwi: is pluginsync enabled?
22:58 iwi mgagne: it is, it's syncing everything ok
23:00 iwi i just pulled newer version of files from https://github.com/puppetlabs/puppetlabs-rabbitmq​/commit/463c38cb887d2e31bd91172555ba88f12cea3745
23:00 iwi as although the version in module file seems to be this same - the files were different
23:00 iwi s/module file/Modulefile
23:01 mgagne iwi: can you try this branch instead? https://github.com/puppetlabs​/puppetlabs-rabbitmq/tree/2.x
23:03 iwi mgagne: i'm on it
23:03 mgagne iwi: up to some point, master was still marked as "2.1.0" although major refactor has been done. We do not support 3.x yet or anything between the "real" 2.1.0 and the release of 3.0.0.
23:04 iwi mgagne: i'v already noticed that - out of curiosity i've tried with 3.1.0 ;)
23:04 mgagne iwi: 3.1.0 works like a charm (if you don't use nova::rabbitmq) :D
23:07 ryanycoleman joined #puppet-openstack
23:07 mgagne iwi: can you try to reload your puppetmaster? I once had issue where I had to reload it after installing new modules with plugins.
23:08 ryanycoleman joined #puppet-openstack
23:23 e1mer joined #puppet-openstack
23:24 iwi mgagne: sorry for the delay, i had a situation here
23:24 mgagne iwi: np
23:25 iwi mgagne: checkout 2.x branch - with no luck :/
23:27 mgagne iwi: tried to restart puppetmaster?
23:27 iwi mgagne: sure
23:27 iwi mgagne: didn't change anything
23:28 mgagne now I'm a sad panda
23:29 iwi mgagne: when i change rabbit_user to guest the error message complains about same thing but for different provider (rabbitmq_vhost istead of rabbitmq_user)
23:30 mgagne iwi: hmmm...
23:32 iwi mgagne: i was actually thinking about removing the provider parameter from nova/rabbitmq.pp and swapping rabbitmqctl.rb with default.rb inside rabbitmq module
23:32 mgagne iwi: All I can say is that bug looks like the one I had: http://projects.puppetlabs.com/issues/17814#note-4
23:32 mgagne iwi: http://docs.puppetlabs.com/guides/troubl​eshooting.html#err-could-not-retrieve-ca​talog-invalid-parameter-foo-for-type-bar
23:33 mgagne iwi: try restarting both puppetmaster and puppet agent and try again.
23:34 iwi it's a single agent run, (puppet agent -t on the node) - the agent doesn't work atm, but I'm indeed using environments - will have a closer look on that bug
23:36 iwi mgagne: but if it is a pluginsync issue - should i see that the providers' rb files are changing ?
23:37 bodepd_ mgagne: regarding that style guide document
23:37 mgagne iwi: I think the bug isn't about the files not being copied over to the node, but the puppetmaster not picking up the new plugin.
23:37 bodepd_ mgagne: would you recomend that we follow that for all of the openstack modules?
23:37 mgagne bodepd_: I have yet to read it tbh
23:40 ryanycoleman joined #puppet-openstack
23:41 ari joined #puppet-openstack
23:43 ryanycol_ joined #puppet-openstack
23:46 xingchao joined #puppet-openstack
23:49 iwi mgagne: that's just weird
23:50 iwi stopped master, rm -rf environments/production; cp -r testenv production; started master
23:50 iwi guess what happened :)
23:50 mgagne iwi: someone crashed his car at the corner of the street :O
23:51 mgagne iwi: is it working now?
23:51 iwi mgagne: it is indeed
23:51 mgagne iwi: :D
23:51 mgagne could it be artifact left from an older version?
23:52 iwi mgagne: right after it started working i did the following test:
23:53 iwi stopped master, rm -rf production, checked out original production, started master - and the problem occurred again
23:54 mgagne origin production? the one before rm -rf ?
23:54 iwi yeap
23:54 mgagne iwi: what about a diff of the folder content?
23:57 iwi in the original (not working) production folder there is no rabbitmq module at all
23:57 mgagne iwi: well, this could be a problem I guess
23:58 mgagne bodepd_: mind helping me on that one? https://bugs.launchpad.net/p​uppet-keystone/+bug/1234480
23:59 iwi mgagne: i have environment set in puppet.conf, didn't expect that i need to sync anything between my env and production
23:59 iwi mgagne: thanks for pointing me towards that bug, it really helped

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