Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
00:09 xarses joined #puppet-openstack
00:22 tnoor1 joined #puppet-openstack
00:29 tnoor1 joined #puppet-openstack
00:44 tnoor1 joined #puppet-openstack
01:02 openstackgerrit A change was merged to stackforge/puppet-tempest: Adds support for mariadb in f19  https://review.openstack.org/51283
01:08 openstackgerrit A change was merged to stackforge/puppet-cinder: Clean up errors in the README examples  https://review.openstack.org/52717
01:10 openstackgerrit A change was merged to stackforge/puppet-cinder: Add solidfire manifest  https://review.openstack.org/50736
01:12 openstackgerrit A change was merged to stackforge/puppet-neutron: params.pp: Rename client_package_name to client_package, and correctly define it  https://review.openstack.org/52365
01:14 openstackgerrit A change was merged to stackforge/puppet-cinder: Add cinder::ceilometer class  https://review.openstack.org/52292
01:19 openstackgerrit A change was merged to stackforge/puppet-heat: params.pp: correctly define client_package_name  https://review.openstack.org/52341
01:28 openstackgerrit A change was merged to stackforge/puppet-openstack: repo.pp: Support havana  https://review.openstack.org/52012
01:29 openstackgerrit A change was merged to stackforge/puppet-openstack: repo.pp: Switch default release to Havana  https://review.openstack.org/52589
01:49 tnoor1 joined #puppet-openstack
01:58 comptona joined #puppet-openstack
02:16 xingchao joined #puppet-openstack
03:15 tnoor1 joined #puppet-openstack
03:25 comptona joined #puppet-openstack
03:38 tnoor1 joined #puppet-openstack
04:56 tnoor1 joined #puppet-openstack
05:18 marun joined #puppet-openstack
05:46 openstackgerrit Dan Bode proposed a change to stackforge/puppet-ceph: Add project files  https://review.openstack.org/52791
07:09 pabelanger joined #puppet-openstack
07:33 Alssi joined #puppet-openstack
07:42 dachary morning
07:45 Alssi joined #puppet-openstack
08:02 beddari morning, and a great one! :)
08:04 mmagr joined #puppet-openstack
08:11 derekh joined #puppet-openstack
11:00 mmagr joined #puppet-openstack
11:12 dachary dalgaaf: I wrote two user stories that matter to me https://wiki.openstack.org/wiki/Puppet​-openstack/ceph-blueprint#User_Stories . It would be useful if you could write the user story/stories that matter to you.
11:44 dalgaaf dachary: okay will do that later ... very busy currently
11:44 dachary cool
12:09 dachary bodepd_: how do you suggest we do integration testing ? I think all scenarios can be covered with 2 virtual machines, 2 interfaces and one disk attached to one of them.
12:10 dachary And a number of scenarios can be based on a single machine, using directories instead of disks and a single interface.
12:26 markvoelker joined #puppet-openstack
12:51 dprince joined #puppet-openstack
13:18 morazi joined #puppet-openstack
13:35 dmsimard joined #puppet-openstack
13:39 dmsimard1 joined #puppet-openstack
13:55 prad_ joined #puppet-openstack
14:01 dachary pabelanger: https://review.openstack.org/#/c/52791/ could be merged. Could it be speed up if people who are motivated get additional permissions to move thing forward ?
14:04 dmsimard1 dachary: Did I miss anything since friday evening ? Are we going to use the existing puppet-ceph (although requiring a license-change) ?
14:06 dachary dmsimard1: it was decided to start from scratch, before this week-end even.
14:06 dachary and cherry pick where relevant
14:06 mjblack joined #puppet-openstack
14:07 dmsimard dachary: okay
14:11 ianw joined #puppet-openstack
14:12 dachary dmsimard: it would be great if you could add the use case that matters to you in https://wiki.openstack.org/wiki/Puppet​-openstack/ceph-blueprint#User_Stories .
14:17 dmsimard dachary: I'll put my current use case.
14:17 dachary cool
14:18 mjblack joined #puppet-openstack
14:27 dmsimard dachary: Trying to be as concise as possible, not easy !
14:27 dachary dmsimard: it's an interested exercise, isn't it ? :-)
14:27 dmsimard dachary: Yeah, it's clear in my head, putting it into words though ..
14:40 dmsimard added it, hope that makes sense.
14:42 dmsimard Is there some sort of list of who will be doing what at first so we don't step on each other's toes ?
14:45 * dachary reading
14:50 mmagr joined #puppet-openstack
14:52 mgagne joined #puppet-openstack
14:57 morazi joined #puppet-openstack
14:58 openstackgerrit Maru Newby proposed a change to stackforge/puppet-openstack: Ensure Nova Network-compatible provisioning  https://review.openstack.org/52938
15:02 ari__ joined #puppet-openstack
15:13 badiane_ka joined #puppet-openstack
15:15 marun joined #puppet-openstack
15:17 mmagr joined #puppet-openstack
15:22 openstackgerrit A change was merged to stackforge/puppet-ceph: Add project files  https://review.openstack.org/52791
15:26 dmsimard dachary: yay
15:26 ari__ left #puppet-openstack
15:27 openstackgerrit A change was merged to stackforge/puppet-keystone: Switch from signing/format --> token/provider.  https://review.openstack.org/45933
15:28 marun joined #puppet-openstack
15:52 openstackgerrit A change was merged to stackforge/puppet-horizon: Improve the default logging configuration  https://review.openstack.org/51222
16:02 marun dprince: re: your review comment, do you mean that configuration of tempest should be handled separately from the provision module?
16:03 dprince marun: yes. Just a thought.
16:03 dprince marun: I see that it is already optional. Just thinking that it might sit better if it were a separate file.
16:04 marun dprince: I think bodepd made the same comment when I added provision.pp.   My thinking hasn't really changed to be honest - provisioning and tempest configuration share enough of the same parameters that having them conjoined seems to make sense.
16:05 mgagne marun: I share the same opinion as dprince on this aspect
16:05 marun dprince: But maybe I'm missing the point.  Is there value to breaking out the tempest class?
16:05 marun dprince: That long parameter list would have to be duplicated, and the dependencies are still important.
16:07 marun dprince, mgagne: I guess it doesn't really matter, though.
16:08 mgagne marun: this class design is heavily influenced by tempest and offers little flexibility/reusability outside tempest.
16:08 marun mgagne: ?
16:09 marun mgagne: the point is demo provisioning, just enough to allow a user to work.  That provisioning happens to coincide with what tempest needs.
16:09 marun mgagne: I'm not sure how extending the usage for general purpose usage makes any kind of sense.
16:09 mgagne marun: better add examples to examples/ then
16:09 dprince marun: we could have a provisioning_params.pp class or something?
16:10 dprince marun: that way we share params but the two could live separately.
16:10 mgagne dprince: I think calling it provision is kind of misleading as it's main purpose is and will always be provisioning for tempest
16:10 dprince marun: I'm okay with it as is for now. This is just an organizational thing... and I have a slight preference for splitting them if possible.
16:11 marun mgagne: I agree that the name is ambiguous.  provision_demo?
16:11 ryanycoleman joined #puppet-openstack
16:11 mgagne tempest_provision? provision_tempest?
16:11 dprince mgagne: my use case is different sometimes though and I most often just use provision.pp without using the tempest part
16:11 marun dprince: Do you have an example of how manifests share parameters as you are suggesting?  My puppet-foo is weak? :(
16:12 marun mgagne: It's not just provisioning for tempest, I'm afraid
16:12 dprince marun: see params.pp in the puppet-nova module. Similar to that I guess.
16:12 marun mgagne: As I said, it's 'demo' provisioning.  The fact that tempest has similar a similar provisioning requirement is incidental
16:12 marun mgagne: We can use demo provisioning in packstack/foreman regardless of whether tempest gets configured.
16:13 marun mgagne: (and we do)
16:13 mgagne ok
16:13 marun dprince: Ok, thanks.
16:13 mgagne marun: my concerns is that people starts relying on this particular class to provision production and starts adding a bunch of parameters to handle various use cases.
16:14 marun mgagne: So let's change the name to 'demo_provision' or something similar.  'tempest' doesn't belong in the name, but something to make it clear that it's not for production use makes sense.
16:14 mgagne marun: looks like an idea
16:16 marun mgagne: Does 'demo_provision' work for you?
16:17 mgagne marun: ok with me.
16:17 marun mgagne: Ok, I'll submit a patch.
16:17 mgagne dprince: what do you think?
16:17 dprince mgagne: I'd say lets just leave it as is.
16:17 mgagne marun: this would however breaks backward compatibility :-/
16:18 marun mgagne: oy
16:18 dprince marun: ^^ leave it as is?
16:18 mgagne marun: can we add a comment/disclaimer about the purpose of the class?
16:19 marun mgagne: That's definitely doable.
16:19 dprince marun: isn't worth moving at this point... If it evolves to something else then maby.
16:19 marun I'm easy.
16:19 mgagne marun: I wish to avoid an other all.pp ^^'
16:20 * marun goes to look at all.pp
16:20 mgagne *never comes back*
16:20 ari_ joined #puppet-openstack
16:20 marun oy
16:20 marun agreed, let's avoid doing that again
16:21 mgagne lets create provision_all.pp, not. :D
16:21 morazi joined #puppet-openstack
16:22 marun mgagne: wait, are the docs on provision.pp not sufficient?
16:22 marun mgagne: I'm reading it and I think it makes it clear what the intention is.
16:22 marun mgagne: Or do you want a disclaimer at the top 'NOT INTENDED FOR PRODUCTION USE'
16:22 mgagne marun: maybe I'm overly concerned
16:23 ari_ joined #puppet-openstack
16:24 marun mgagne: I would hope that anyone abusing the module could be pointed to the docs when they come crying that it isn't easily extensible.
16:24 marun module -> manifest, sorry
16:24 mgagne marun: alright
16:24 marun mgagne: If you decide differently, though, and think a more explicit warning is required, feel free to do so or ask me to.
16:25 marun mgagne: I'm sensing that you've been having trouble with things like all.pp though?
16:25 marun mgagne: Or other abuse of manifests?
16:25 mgagne marun: =)
16:26 ari_ joined #puppet-openstack
16:26 mgagne marun: it's like THAT function with 78 parameters, 68 being optionals and some being mutually exclusives. Can't be right. ;)
16:27 marun mgagne: I wish it weren't so, but welcome to openstack.
16:27 hogepodge joined #puppet-openstack
16:27 mgagne s/openstack/puppet
16:27 marun hah, fair enough
16:30 ryanycoleman joined #puppet-openstack
16:37 marun mgagne: Is there anything I can do to convince you to make merging this a priority?  https://review.openstack.org/#/c/52938/
16:37 mgagne marun: checking
16:37 marun mgagne: Packstack needs it to be able to configure tempest testing for nova network deployments.
16:38 dachary dmsimard: I like your use case :-)
16:38 marun mgagne: The aim is to be able to test a grizzly deployment and then after it's been upgraded to havana.
16:38 dachary mgagne: good morning :-)
16:38 dmsimard dachary: I guess it kind of covers the integration tests portion of the blueprint
16:38 marun mgagne: Yay!  Thank you!
16:38 dmsimard dachary: this is what I already do
16:39 dmsimard dachary: I just want to keep on doing it :D
16:39 dachary dmsimard: could you write down a minimal site.pp to show how it relates to ceph ?
16:40 dmsimard Maybe I could document how I do it, yes
16:40 xarses joined #puppet-openstack
16:43 openstackgerrit A change was merged to stackforge/puppet-horizon: Set LOGOUT_URL properly in horizon settings  https://review.openstack.org/52699
16:46 dachary dalgaaf: https://wiki.openstack.org/wiki/Pu​ppet-openstack/ceph-blueprint#osd I think it would be very convenient to auto discover the disks. Let me know what you think when you can ;-)
16:49 openstackgerrit A change was merged to stackforge/puppet-openstack: Ensure Nova Network-compatible provisioning  https://review.openstack.org/52938
16:51 iwi joined #puppet-openstack
16:54 bodepd_ I would like to try using https://github.com/puppetlabs/rspec-system-puppet
16:54 bodepd_ dachary: for the integration tests ^^^
16:55 bodepd_ dachary: it's basically a vagrant/ssh integration with rspec focused on testing Puppet
16:58 marun bodepd_: yay testing!
16:58 dachary bodepd_: thanks. Is there a puppet / openstack module using it at the moment ? To get inspiration that is ;-)
17:02 bodepd_ dachary: it is unfortunately not
17:03 bodepd_ dachary: I think parts of it would be appropriate for openstack
17:03 bodepd_ dachary: but I'm not sure about using it for that
17:03 bodepd_ dachary: some of the larger openstack testing scenarios get a bit large for vagrant
17:03 dachary bodepd_: ok.
17:04 bodepd_ dachary: I guess I would also like to consider it for openstack, but I haven't had a chace to look into it
17:09 ari_ joined #puppet-openstack
17:17 dmsimard dachary: about that osd blueprint
17:17 dmsimard dachary: I do it in a kind of crafty way - I guess it could be done cleaner
17:19 dmsimard dachary: http://paste.openstack.org/show/48886/
17:20 dmsimard dachary: We could probably pass a parameter of disks NOT to be used by ceph and partition/prepare the other ones
17:31 ari_ joined #puppet-openstack
17:56 ari___ joined #puppet-openstack
18:09 dachary dmsimard: interesting idea :-) Did you add it to the blueprint ?
18:11 dmsimard dachary: No, wanted to know what you thought about it first :p
18:12 dachary if there is a use case I don't see why not
18:12 dachary +1
18:25 openstackgerrit Loic Dachary proposed a change to stackforge/puppet-ceph: project overview and initial README.md  https://review.openstack.org/52755
18:31 openstackgerrit Konrad Scherer proposed a change to stackforge/puppet-openstack: Prevent dollar signs and single quotes in variables from being removed by shell  https://review.openstack.org/51314
18:41 xarses dachary: trailing whitespace
18:42 xarses L23
18:51 ari_ joined #puppet-openstack
18:58 mgagne dachary: you look to have 2 accounts on gerrit. Which one is good?
18:59 ari_ joined #puppet-openstack
19:03 mgagne dachary: ping
19:04 mgagne dachary: can you tell me which user id you are using? I found 4556 and 2064. One needs to be cleared out from the database. I can't add your user to the group because of the duplication.
19:07 Kupo24z joined #puppet-openstack
19:07 Kupo24z Hey all, how do you enable neutron networking in openstack::compute ?
19:10 dachary mgagne: loic@dachary.org / dachary is good
19:10 dachary mgagne: 2064
19:10 mgagne dachary: they both have the same email. according to fungi, 2064 looks like the right one.
19:10 dachary there was a mixup long ago that required some bizarre intervention from the launchpad dev
19:11 dachary yes, it's the right one
19:11 mgagne dachary: fixed
19:11 dachary cool, thanks
19:15 ari_ joined #puppet-openstack
19:17 ari_ joined #puppet-openstack
19:23 hogepodge joined #puppet-openstack
19:24 badiane_ka joined #puppet-openstack
19:25 xarses I'd like to join the LP team
19:25 xarses mgagne
19:26 mgagne xarses
19:26 mgagne xarses: do you wish to join the core reviewers group or the bug team?
19:26 mgagne LP team isn't linked to gerrit (reviews)
19:26 xarses mgagne: both
19:31 mgagne xarses: done
19:31 xarses mgagne thanks
19:31 mgagne xarses: you are the one at mirantis writing puppet modules right?
19:32 xarses correct
19:32 mgagne dachary: I'll send an email about it. We would like people to not approve their own stuff.
19:33 mgagne dachary: as it would otherwise defeat the purpose of the review process.
19:33 dachary mgagne: that would defeat the purpose of gerrit indeed.
19:33 dachary :-)
19:34 dachary I did not know that was possible even.
19:34 xarses gerrit appears to not consider the submittors review in the score
19:34 dachary indeed
19:35 mgagne a core reviewer can approve anything, even his own work.
19:35 xarses ah
19:38 dachary dalgaaf: bodepd_ since there does not seem to be a decision regarding the conf file and although I don't really mind either way, I vote in favor of ini . The main reason is that it's used consistently in all other openstack related puppet modules and we'll have better expertise. In my opinion that outweights the possible weaknesses in terms of human readability.
19:39 xarses dachary: +1
19:39 dachary dalgaaf: I'm good with the changes you made to the roadmap https://wiki.openstack.org/wiki/Pupp​et-openstack/ceph-blueprint#Roadmap and it seems ceph::conf is going to be the first ;-)
19:40 dmsimard dachary: +1 for inifile with a provider like nova_config
19:42 mgagne Can entries be duplicated in ceph conf files?
19:42 mgagne That's one thing inifile provider doesn't handle well.
19:42 xarses in the actual ceph.conf?
19:42 dachary how do you mean ?
19:42 xarses it complains, but allows it
19:42 dachary [a]
19:42 dachary foo = bar
19:43 dachary foo  = bar
19:43 xarses ini file format prohibits it
19:43 dachary that kind of duplication ?
19:43 gabriel-bezerra Hi guys. Might you tell me whether puppet-openstack can deploy a stable havana production environment on Ubuntu 12.04?
19:43 mgagne dachary: foo = bar \n foo = bar2
19:43 dachary no
19:43 mgagne ok then, nothing else to add =)
19:43 dachary mgagne: there is no entry duplication
19:44 xarses you can end up with a duplicate in the multi word parmaters
19:44 xarses but we just need to always use the same delimiter
19:45 xarses for example
19:45 xarses filestore_xattr_use_omap = ture
19:45 xarses filestore xattr use omap = false
19:46 xarses the ruby provider cant descern that they are the same
19:46 xarses and will write duplicates
19:46 xarses but ceph will complain of them
19:47 xarses since we forced ceph-deploy to always use _ i would think we should use the same
19:48 xarses ceph -s
19:48 xarses warning: line 9: 'filestore_xattr_use_omap' in section 'global' redefined
19:51 larsks joined #puppet-openstack
19:51 larsks I'm running into what looking like parsing problems in the puppet-keystone module and I'm looking for a second opinion...
19:52 larsks Anybody around who cares to answer questions about the keystobe.rb provider?
19:52 dachary I updated https://wiki.openstack.org/wiki/Pu​ppet-openstack/ceph-blueprint#conf to reflect the decision to use white space over _ . It was discussed between dalgaaf  and bodepd_ a few days ago
19:53 xarses then ceph-deploy should also use space
19:53 dachary xarses: could you please add a comment to point that ceph-deploy uses _ by default ?
19:54 xarses we cant keep confusing people with seperate usages
19:54 dachary it's cosmetic and consistency trumps cosmetics IMO
19:54 xarses like i said, the inifile provider cant tell the difference between the two
19:55 xarses which is why i fixed ceph-deploy to only use one seperator
19:55 xarses it thinks they are seperate configs
19:55 dachary I see that https://github.com/ceph/ceph-deploy/commit​/53f46a8451dd8e10a3b9e8f2b191044f9863ae83
19:56 dachary or is it another commit ?
19:56 xarses thats it
19:56 dachary ok
19:56 xarses before that it was using space on ceph-deploy new
19:56 xarses and "_" every other time it wrote the config to nodes
19:57 ari_ joined #puppet-openstack
19:58 xarses I don't care which seperator is used, just that the "tools" need to use the same one, if the Chef modules also use space and it looks like most of the ceph docs use space, then we should use space, and so should ceph-deploy
20:07 bodepd_ xarses: can you expand on what that means: ini provider can't tell the diff
20:07 bodepd_ xarses: there was a patch that went in recently so that it can work with settings with spaces
20:08 xarses using a slighly old version of ini_file
20:08 dachary xarses: I recorded your comment about the consistency with ceph-deploy here https://wiki.openstack.org/wiki/Pu​ppet-openstack/ceph-blueprint#conf
20:08 xarses (12:45:25 PM) xarses: filestore_xattr_use_omap = ture
20:08 xarses filestore xattr use omap = false
20:08 xarses are considered seperate
20:08 bodepd_ xarses: you mean, that inifile treats them as the same?
20:08 xarses no
20:09 bodepd_ xarses: of you mean, it should?
20:09 xarses it will write two lines to the file
20:09 bodepd_ as it should :)
20:09 xarses it should consider them the same
20:09 bodepd_ is that an inifile thing?
20:09 xarses because ceph.conf allows _ " " - as seperators
20:09 bodepd_ I mean part of the accepted standard
20:09 bodepd_ ah, gotcha
20:10 bodepd_ you coudl fix that with a munge call in the Type
20:10 xarses ini_file should support knowing multiple seperators
20:10 xarses then the problem is moot
20:10 bodepd_ (in that case, if the users specifies ' ', or _), Puppet would always treat them as _
20:11 bodepd_ in that context, I'm not sure they are separators
20:11 bodepd_ the separator is =
20:11 xarses well, word delimiters
20:11 bodepd_ the spaces vs. the _ are part of the kye
20:11 bodepd_ key
20:12 openstackgerrit Loic Dachary proposed a change to stackforge/puppet-ceph: project overview and initial README.md  https://review.openstack.org/52755
20:12 xarses yes
20:13 bodepd_ xarses: that could be a patch into inifile, but it coudl get ugly
20:13 bodepd_ what about: this is a_key
20:13 mgagne bodepd_: my hope isn't high on that one.
20:14 mgagne bodepd_: as I think this behaviour looks to be specific to ceph, not to ini.
20:15 mgagne bodepd_: see the kind of answer we got from puppetlabs-inifile regarding duplicated keys: https://github.com/puppetlabs​/puppetlabs-inifile/issues/41
20:15 xarses mgagne, yes most ini_file consumers don't have fexability in the key like this
20:15 mgagne xarses, bodepd_: better handle it from custom provider for now
20:20 dachary dmsimard: xarses would you like to try your new +2 on https://review.openstack.org/#/c/52755/ ? :-)
20:20 xarses looking
20:21 xarses ahh \cr\lf and no hanging space
20:22 prad joined #puppet-openstack
20:24 dachary unless someone is willing to takeover in the next 15 minutes I'll start with the ceph::conf class ( dalgaaf xarses dmsimard mgagne bodepd_ )
20:24 mgagne dmsimard is in a meeting
20:25 * dachary has been in  meetings with lots of time to develop things ;-)
20:25 openstackgerrit A change was merged to stackforge/puppet-ceph: project overview and initial README.md  https://review.openstack.org/52755
20:26 xarses happy first (real) file
20:26 dachary xarses: thanks, we're in business ;-)
20:27 xarses dachary oh, also we need ' = ' for the seperator to maintain the same as ceph-deploy
20:29 xarses we have a working provider in https://github.com/Mirantis/fuel/tree/m​aster/deployment/puppet/ceph/lib/puppet
20:30 mgagne xarses: I like that one :D https://github.com/Mirantis/fuel/blob/master/deplo​yment/puppet/ceph/lib/puppet/type/ceph_conf.rb#L14
20:30 * dachary looking
20:30 mgagne xarses: and the one below :P
20:31 dachary xarses: cool. Makes more sense for you to copy it over then, right ?
20:32 ari_ joined #puppet-openstack
20:32 xarses dachary: if you want to start with them, sure
20:32 mgagne dachary: implementation looks to be taken from our own puppet modules for openstack ;)
20:32 dachary xarses: that's the first in the roadmap https://wiki.openstack.org/wiki/Pupp​et-openstack/ceph-blueprint#Roadmap
20:33 dachary mgagne: really ? I'm surprised :-)
20:33 dachary xarses: since there is no CLA, please make sure to add the proper copyright notice at the beginning
20:37 bodepd_ that blueprint is so cool!
20:37 bodepd_ this is the first time I know of a module being developed like this ;)
20:40 dachary :-)
20:41 dachary bodepd_: I'm not sure I understand how  https://github.com/puppetlabs/rspec-system-puppet can be used to launch the integration tests. I mean it would have to somehow leverage things ( what ? how ? ) in the openstack-ci infrastructure ?
20:42 mgagne dachary: rspec tests the compiled catalog only, it's not an integration test.
20:42 mgagne dachary: unless I'm mistaken
20:43 dachary I'm confused then because bodepd_ refered to this as a mean to do integration testing
20:43 * dachary looking closer and may have been misunderstanding
20:43 mgagne dachary: reading, I might be mistaken
20:43 mgagne dachary: you are right, rspec-system-puppet does integration tests, rspec-puppet does not.
20:44 dachary mgagne: what would you suggest for integration testing of a module like ceph ?
20:44 mgagne dachary: rspec-system-puppet looks to leverage vagrant/virtualbox to run such tests. Those tools won't be available on jenkins slaves at stackforge afaik.
20:45 dachary ah
20:45 dachary is there a way to integration test ceph using the openstack-ci as it is ?
20:46 bodepd_ dachary: as of now, openstack-ci does not have support for integration tests
20:46 bodepd_ dachary: this may have changed in this release cycle
20:46 xarses dachary, our ostf guys have some CI tests
20:47 mgagne dachary: we would have to ask openstack-infra as you don't have root access on jenkins slaves
20:47 bodepd_ dachary: rspec-system is a way to write groups of tests and then run them on vagrant
20:47 xarses we added some for ceph
20:47 dachary tempest is not run on openstack-ci ?
20:47 mgagne dachary: there is a way to listen to gerrit events and trigger external CI tests.
20:47 bodepd_ dachary: only on a single code with devestack
20:47 bodepd_ devstack
20:47 bodepd_ uggh
20:47 bodepd_ single node with devstack
20:48 bodepd_ I only recommended it b/c if I were writing integration tests from scratch it is what I would use
20:48 dachary there are a number of integration tests that we can do even on a single node.
20:48 bodepd_ xarses: my understanding is that the fuel CI/CD stuff is not open?
20:48 mgagne A set of slaves have root access but can only run devstack/tempest. I don't think it's designed to run arbitrary integration tests.
20:48 bodepd_ (if it is open, could you point it upstream as a gate :) )
20:49 xarses https://github.com/stackforge/fuel-ostf
20:49 bodepd_ xarses: cool, I didn't realize they were availbel
20:49 xarses fuel library is still on github.com/Mirantis/fuel
20:50 xarses everything else is in stackforge
20:50 openstackgerrit Andrew Woodward proposed a change to stackforge/puppet-ceph: Add ceph_conf ini helper  https://review.openstack.org/53014
20:53 dmsimard I'm back
20:53 dmsimard dachary: It's already merged :)
20:54 dachary ?
20:54 dachary oh, the readme, yes :-)
20:54 dachary dmsimard: https://review.openstack.org/53014 is waiting for you though ;-)
20:55 xarses ;)
20:55 dmsimard I'll have a look
21:00 xarses oopps, helps if i read first
21:02 dmsimard dachary: You beat me to it
21:02 dachary mgagne: beat us both ;-)
21:02 dachary we'll get over the eager reviewer syndrom soon enough ;-)
21:03 mgagne I do not believe complete authorship is required in apache license header, only copyright holders. no?
21:04 tnoor1 joined #puppet-openstack
21:04 xarses we have asignment agreements
21:04 xarses i can't be the copyright holder
21:05 xarses only the author
21:05 xarses If we want authors thats fine, but it dosn't do anything for the license
21:07 mgagne xarses: better not add authors if not required as this could get huge IMO
21:07 mgagne xarses: what do you think?
21:08 dachary it's not required by apache, but it's nice to have. Plus it's something that is a right in countries where moral rights are recognized (i.e your employer cannot force you to hide and not reveal you're the author of a work )
21:08 xarses mgagne: I will add Author: below the license
21:08 mgagne dachary: I'm not a lawyer unless you point me to resources, I can't take your words on it =)
21:08 dachary http://fr.wikipedia.org/wi​ki/Droit_de_paternit%C3%A9
21:08 dachary Précisons que cette question de droit moral existe dans les régimes de droit d'auteur (exemple : France), mais qu'elle est absente des régimes de copyright (USA…), où l'ayant droit possède tous les droits, sauf si a été établi un contrat explicite en disposant autrement. Un certain nombre de pays possèdent cependant des systèmes intermédiaires où un certain droit moral est reconnu aux auteurs sans pour autant l'être de façon
21:08 dachary aussi claire (Japon…).
21:09 xarses dachary has a point, if the author want's to maintain some of their moral rights
21:09 xarses its their job to add it to the file
21:09 xarses but the copyright license doesn't require it
21:11 mgagne bodepd_: ping
21:11 dachary that being said, even if there were no "Moral rights", it's nice to at least acknowledge one human being for being the "author".
21:11 tnoor1 joined #puppet-openstack
21:11 mgagne dachary: doesn't git log already take care of it?
21:11 dachary xarses: do you mind including the name of author who wrote most of the code ?
21:12 xarses if i can find it
21:12 dachary xarses: git log will tell you ;-)
21:12 dachary mgagne: in this case, because the code is copied over, it does not.
21:12 mgagne dachary: https://github.com/stackforge/puppet-cinder/b​lame/master/lib/puppet/type/cinder_config.rb
21:12 mgagne dachary: mostly dan and myself
21:13 xarses dachary, i think someone internal copied it from one of the openstack modules
21:13 tnoor2 joined #puppet-openstack
21:13 dachary xarses: then just add bodepd_ and mgagne and that will be good enough :-)
21:13 xarses it smells afuly like cinder's
21:14 dachary xarses: ^^ mgagne  link
21:14 mgagne or https://github.com/stackforge/puppet-nova/b​lame/master/lib/puppet/type/nova_config.rb
21:14 dachary we have no CLA in place and must be careful when importing code. Here it's easily traced back to the source but sometime it's difficult.
21:14 mgagne dachary: why not adding CLA then? =)
21:15 dachary because signing an OpenStack CLA might push Cloudstack etc. contributors away ? That was the primary reason IIRC.
21:17 xarses bodepd_ ping:
21:21 dachary dalgaaf: you mentionned you had code for ceph::key that could be cherry-picked or that you could re-write it quickly . Do you have a URL for this code ?
21:23 xarses mgagne: re the copyright line; what would you propose that the copyright holder be for the puppet packages, i've looked at 3 and none assert a copyright holder
21:23 xarses apache license allows derivative work to be re-licensed, I figured something was better than no holder
21:23 dachary xarses: the code comes from openstack modules requiring a CLA, meaning the code belongs to the openstack foundation as all other openstack code
21:24 xarses otherwise we remove license header
21:24 dachary xarses: there is no such thing as "no copyright holder" ;-)
21:24 xarses dachary, correct
21:25 xarses i mean that no declared holder
21:25 xarses We cant assert the license at the top of the file with out a designated holder
21:25 mgagne xarses: afaik, code does not belong to openstack, they have a copyright license to use it and distribute it.
21:26 * dachary checking https://wiki.openstack.org/wiki/CLA-FAQ
21:26 xarses so we wither need to assert (C) Some entity
21:26 xarses or remove it from the file
21:27 bodepd_ xarses: pong
21:27 mgagne dachary: https://review.openstack.org/static/cla.html
21:28 dachary ok
21:29 marun joined #puppet-openstack
21:29 dachary So that could be Copyright 2013 Dan Bode <...> and Copyright 2013 Mathieu Gagne <...> since they are both the licensors and OpenStack is only the licensee.
21:30 mgagne dachary: work is owned by iWeb Technologies Inc., which is the company I work for.
21:30 dachary mgagne: I stand corrected :-) I should have written "the openstack foundation has a copyright license on all openstack code"
21:30 dachary Ah :-)
21:30 mgagne license, not ownership
21:31 xarses bodepd_ https://github.com/stackforge/puppet​-cinder/blob/master/lib/puppet/provi​der/cinder_config/ini_setting.rb#L22 and  https://github.com/stackforge/puppe​t-nova/blob/master/lib/puppet/provi​der/nova_config/ini_setting.rb#L27
21:32 dachary mgagne: would you like to be listed as an author or do you not care ? In the end that's what it boils down to ;-)
21:32 mgagne dachary: I don't care
21:33 dachary xarses: then just add Copyright Dan Bode <...> and that will be clear enough : one coypright holder ( we need that ) and one human being ( we like that )
21:33 xarses and the license text?
21:34 dachary Apache coypright notice as you did ?
21:34 xarses Danny didn't like it
21:34 dachary ?
21:34 * dachary reading
21:34 xarses dalgaaf
21:36 bodepd_ xarses: you have a question about that?
21:36 bodepd_ xarses: it probably doesn't matter anymore
21:36 bodepd_ xarses: I had to move path from the provider instances to the class instance
21:36 bodepd_ xarses: so that I could support purging
21:36 xarses So should we leave it or remove it?
21:36 bodepd_ xarses: older versions of inifile (super-old)
21:37 bodepd_ let me track down the commit and see what version it relates to
21:37 xarses so maybe keep it
21:37 bodepd_ if you remove it, it will break with super-old versions of inifile
21:37 bodepd_ but they are crazy old
21:37 bodepd_ probably back when I was the only user :)
21:38 dachary The reason why it's needed is because files have a life of their own. When considering this file for inclusion, because it had not header, we had to spend time to figure out where it came from and make sure it had the proper license. This one is easy but you get the idea ;-)
21:38 dachary dalgaaf: ^ regarding your comment on the apache header.
21:39 mjblack joined #puppet-openstack
21:39 bodepd_ xarses: 2f22483c87dbaee9b45d121a65f2a09dbe638eaa
21:40 bodepd_ xarses: it is required for versions < 0.10.0
21:40 xarses Ok, do we want to keep it then?
21:40 dalgaaf dachary: I'm currently reading the backlog ...
21:40 dachary xarses: I don't mind
21:41 dachary dalgaaf: I can provide you with an executive summary if you'd like
21:42 dalgaaf about the ini file: btw there are also other puppet modules at openstack which use concat (e.g. puppet-swift IIRC)
21:42 mgagne dalgaaf: puppet-swift is old. We (I) are moving it to inifile
21:43 mgagne dalgaaf: managing concat and templates is a huge pain
21:43 xarses darchary: I don't have any rspec tests for it, we will need to define them
21:43 dalgaaf It's for the the same pain as with inifiles but I can force the format better with concat and templates
21:44 xarses dachary even
21:44 mgagne dalgaaf: format?
21:44 Kupo24z can puppet-openstack install ceilometer?
21:44 dachary mgagne: could you point me to a documentation I can read about how to control the test environment of openstack-ci and its limitations ?
21:44 mgagne dachary: http://ci.openstack.org/
21:45 mgagne dachary: and https://github.com/openstack-infra/config
21:45 mgagne dachary: you will get a clue of how it's installed and its limitation.
21:45 dalgaaf format in meaning of: keep and add comments, always the same position in the file (since there is no default config installed by the package etc.)
21:45 dachary instead of trying something involving multiple machines, I'm thinking we can do a lot with just being able to launch a few daemons and run on directories. Now I'm not sure if even running one daemon is acceptable.
21:45 * dachary reading
21:45 dalgaaf about OSD: don't do autodiscovery of disks
21:46 dachary dalgaaf: why not do autodiscovery ?
21:46 dalgaaf There should be the need to add each disk you really need to use ... a list of what you intend to not use wouldn't work
21:46 dachary do you mean never ? or do you mean not unless you know what you're doing ?
21:46 mgagne dalgaaf: comments are preserved with inifile. Unless you start from scratch then there is nothing to preserve.
21:47 dalgaaf usecase: a server machine with 36 disks per node, but I would like to use ony 10 or 15 disks out of them
21:47 dalgaaf mgagne: that's the problem I guess: we start from scratch
21:47 dachary dalgaaf: I agree 100% with the fact that you want to be able to designate the disk you want an osd to run on. I did not mean to imply that it's no longer necessary.
21:47 mgagne dalgaaf: maybe I don't fully understand your concerns.
21:49 dachary dalgaaf: I think you got the impression that I'm suggested ceph::osd must *not* designate disks. I'm just proposing a behavior that would be quite useful when you don't specify any disk ( autodiscovery ).
21:49 dalgaaf dachary: 1) if you replace a broken disk you often get a new /dev/sdX device and you don't want to have this disk to be picked up since it would replace a broken OSD ... and I don't want to give a list of e.g. 20 disks which shouldn't be picked up plus all the disks which may get added later
21:50 dachary dalgaaf: how would it replace the broken OSD ?
21:50 dalgaaf dachary: that is risky the same way that it would be to use some default key for client.admin
21:50 dachary A new disk can never replace an existing OSD unless you explicity do something to make that happen ( as in osd rm )
21:51 dalgaaf dachary: the replacement would need manual steps to get the machine even prepared if you use a RAID controller on a big storage node. And you don't want to have puppet to pick up any disk that may was replace remote inbeetween
21:52 dachary dalgaaf: I don't dispute the fact that you would not want this because that would interfere with how you do things.
21:52 badiane_ka joined #puppet-openstack
21:52 dachary but I don't see how it would be generaly bad for everyone ( as in having a default key for client_admin, which is a security risk indeed ).
21:53 dalgaaf If I start up a cluster and miss only one machine to setup only the disks that I really want to use I end up in a cluster with e.g. to much ressources  etc.
21:53 dachary Say I have two machine with 8 slots and 5 disk each. I hot swap one disk from one machine to the other. With ceph::osd and not argument, it would just work. And I think it's an attractive use case.
21:54 dalgaaf If you want to have auto discovery, then use an extra parameter and the user has to enable it if he want to use it
21:54 openstackgerrit Andrew Woodward proposed a change to stackforge/puppet-ceph: Add ceph_conf ini helper  https://review.openstack.org/53014
21:55 dachary dalgaaf: what about 'use_all_possible_disks': true ?
21:55 dachary 'format_unknown_disks': true
21:56 dachary it's more like it
21:57 dalgaaf Is there any logic behind that to prevent disks from being used if there is data on the disk?
21:57 dachary yes
21:57 dachary ceph-disk list | only use 'unknown'
21:59 dachary but again, only use this if you have the appropriate infrastructure, dedicated machines . Even if you trust ceph-disk I would not go as far as suggest that such autodetection should be trusted to share disks on a single machine in a way that implies that a detection bug means you lose data unrelated to ceph. That would be ill advised to say the least ;-)
22:01 dachary there is protection : https://github.com/ceph/ceph/b​lob/master/src/ceph-disk#L334
22:01 dachary but that would be no excuse
22:02 xarses mgagne: do you want a mail in author https://review.openstack.org/#/c/​53014/2/lib/puppet/type/ceph_conf.rb?
22:02 dachary let me put it another way : you can very well setup your cluster so that it's safe to use. Just because it makes your life so much simpler.
22:04 dachary It essentially means you never need to mention any disk in your puppet files :-)
22:04 mgagne xarses: no thanks
22:04 openstackgerrit Andrew Woodward proposed a change to stackforge/puppet-ceph: Add ceph_conf ini helper  https://review.openstack.org/53014
22:08 tnoor1 joined #puppet-openstack
22:10 xarses dachary: I have no rspec tests to give
22:11 xarses jesus i keep doing that
22:11 xarses dachary
22:11 xarses hmm acutally i got it right i think
22:11 xarses blah
22:11 tnoor1 joined #puppet-openstack
22:12 dalgaaf dachary: that's no kind of protection at all ... it would only detect if the disk is in use ... if this is all that ceph-disk provides, then I'm not really able to use a puppet-ceph module which depends on the use of ceph-disk ... sorry that I didn't see that one yet
22:13 dalgaaf what I need is something I already have in place: Don't use any disk where is data in the first 10 MB of the disk ... only if there are only zeros: touch this disk to partition and format it
22:13 dachary hum
22:13 dalgaaf it's about protect data of customers
22:14 tnoor2 joined #puppet-openstack
22:14 dachary the code I link is not the only protection
22:14 dalgaaf from accidentally being deleted
22:14 dachary it's one of the protections
22:14 dalgaaf I searched the code and couldn't find any useful other protection
22:15 dalgaaf but would be happy to see if there is one
22:15 dachary can you link me the code you're using to avoid reformating something unintended ?
22:16 dalgaaf no, I can't since it's currently not on a public repo ...sorry .... but I could add it if we find some place to integrate it
22:17 xarses we had to pre-part our disks for ceph in fuel, so we created a fact to find partitions with the CEPHOSD fs label.
22:17 dachary the protection lies in the output of ceph-disk list and it's ability to not list as "unknown" a device that is already possibly used
22:17 dachary if checking the 10MB being zero is protection enough for you, a patch to ceph-disk would achieve this
22:18 ari_ joined #puppet-openstack
22:18 dalgaaf but even this would fail if I remove a OSD disk from a system and add it later back ... or not? It would be picked up and would be used again
22:18 dachary to ensure that ceph-disk will *never* list a disk with data (whatever it is) in the for 10MB as unknown ( which it does not currently do, indeed)
22:18 dalgaaf a patch would not work for already released versions since we then would need to target special versions of a release
22:20 dalgaaf so we would need to have some kind of protection in puppet-ceph itself
22:20 dachary I'm not sure I follow. Are you advocating that this feature is bad ? Or that you would not use as a drop in replacement for your current production system dalgaaf ?
22:21 dalgaaf the feature wouldn't be bad for ceph-deploy ...
22:22 dalgaaf but then puppet-ceph needs to depend on these versions where the patch was added
22:22 dalgaaf or puppet-ceph would add this kind of protection to its code
22:25 dachary dalgaaf: http://tracker.ceph.com/issues/6607 plugable rules to figure out if a disk / partition is "unknown"
22:26 dachary dalgaaf: what about people who are perfectly happy with the definition of "unknown" as it has been since cuttlefish ?
22:27 dalgaaf btw. if you add use_all_possible_disks then please use false as default since this would prevent any accident
22:27 dachary dalgaaf: I updated to something like 'disk': discover https://wiki.openstack.org/wiki/Pu​ppet-openstack/ceph-blueprint#osd
22:28 dachary dalgaaf: you are correct, it should not be the default behavior because it has a potential of disruption that is non null ;-)
22:29 mjblack joined #puppet-openstack
22:29 dachary also updated https://wiki.openstack.org/wiki/Puppe​t-openstack/ceph-blueprint#I_want_to_​run_benchmarks_on_three_new_machines accordingly and it still looks good
22:30 iwi hi there, any idea on when a new puppetlabs-openstack module (supporting havana) is going to get to puppet forge ?
22:30 mgagne Is ceph::conf a class, a define or a custom type?
22:30 dalgaaf dachary: I don't know what to say about these users ... for us it's unusable then and we have to stick to our own code of puppet-ceph
22:30 dachary it can be a string that is more scary than "discover" if you'd like, feel free to update accordingly ;-)
22:30 mgagne iwi: it should be available before the end of the month according to emails on the mailinglist.
22:31 dachary dalgaaf: the existence of a feature you're not using would drive you away from puppet-ceph ?
22:31 dachary or am I misunderstanding ?
22:31 iwi mgagne: cool, thanks
22:33 dalgaaf We protect this way even disks which we currenlty list from being redeployed ... there is no demcrypt setup, partition or format if there is data on the disk ... this disk would be simply not used ... until the admin dd's the first 10 MB
22:35 dachary this disk would not be listed as unknown by ceph-disk, would it ?
22:35 dalgaaf That's may also the reason why ceph-disk wasn't used by the enovance module ... it forces a workflow  and takes flexibility away
22:36 dalgaaf what's the criteria for unknown exaclty .. have to read the code
22:36 dachary https://github.com/ceph/ceph/b​lob/master/src/ceph-disk#L1948
22:38 mjblack joined #puppet-openstack
22:38 dachary but I'm not trying to convince you that it is better than designating the disks explicity as you currently do. And I don't see any reason why you should use this feature in your context since you have more protective methods that already work.
22:38 hogepodge iwi: we're working out a branch date right now. I'm considering making a tech preview for the summit if we haven't branched stable/havana by then.
22:40 dachary now if you're saying that it's out of the question for you to use ceph-disk, we have an entirely different kind of problem ;-)
22:40 ari_ joined #puppet-openstack
22:40 dachary on that note, I'll get some sleep and read you in the morning :-)
22:41 dalgaaf dachary: I have only one other question open:
22:41 iwi hogepodge: would be nice to have something to test on. Is it as simple as s/quantum/neutron/g ?
22:42 dalgaaf as you may remember we discussed how to deploy a OSD and the involvement of the MON into this to be able to write the config  in the same run
22:42 dachary ( although the puppet-ceph module could have a safeguard with a test ofr the 10MB until it's upstream as a consquence of http://tracker.ceph.com/issues/6607. And that could be an option of ceph::ods to accomodate your use case. And probably others with different rules to define "unknown".
22:42 hogepodge iwi: The overhead is to branch stable/havana, set up the module files, test, package and release
22:42 hogepodge iwi: if I do a preview it's just grabbing from head and bundling up.
22:43 dalgaaf is this still in place or did it change?
22:44 dachary dalgaaf: yes, I do remember. Since there is no need for puppet to know anything about OSD ids, ( I wrote a paragraph about what that means from the point of view of init scripts with no disocovery abilities ) there is no longer a problem.
22:44 iwi hogepodge: sure thing, stable/havana will need to be release anyway so I totally get it
22:44 dalgaaf the question is for me: how do we get the OSD id on the same run?
22:44 hogepodge all: I asked this on the mailing list, but are there any outstanding Havana commits that haven't happened yet?
22:45 dachary dalgaaf: the conclusion is that we don't need the OSD id, therefore there is no problem. Nice isn't it ? :-)
22:47 dalgaaf dachary: not really ... since that only moves the problem away to other ppl
22:47 dachary broadcasting the bootstrap-osd key to all tentative osd hosts is all that matters
22:47 dachary dalgaaf: to who ?
22:48 dalgaaf to e.g. the users of the rcscripts as SUSE or Redhat ... or did I read something wrong?
22:48 dalgaaf and could you clarify what you mean with boot time
22:48 dalgaaf refers it to the bootstrap of the OSD or the boot of the system ?
22:50 dachary dalgaaf: I think the answer is that the ceph module must provide alternate scripts with this capability until it's upstreamed.
22:50 dachary the boot of the ssystem
22:50 dachary https://github.com/ceph/ceph/blob/master/​src/upstart/ceph-osd-all-starter.conf#L14
22:51 dalgaaf I really would recommend to write a config file which contains all OSDs used by the system since this also allows admins to check what's  really intended to be up and runing
22:51 dalgaaf maybe I'm too old-school
22:51 dachary dalgaaf: it does not shift the problem from the ceph module to the implementor of the init scripts. I t meansthe ceph module has to provide such scripts and push for them to be upstream to get rid of them.
22:52 dachary dalgaaf: I very much understand it's your use case. And I don't see why you could not do that with the way we approach things ?
22:52 dalgaaf hm ... the line in the upstart script is broken by design ... since this wouldn't work if you use another place to mount your osds
22:53 dalgaaf which is supported by the ceph configuration
22:53 dalgaaf hardcoded paths are EVIL
22:53 openstackgerrit Andrew Woodward proposed a change to stackforge/puppet-cinder: Remove package require for cinder-volume  https://review.openstack.org/53029
22:54 dalgaaf dachary: since there is no config file written to disk ... or do I missunderstood you?
22:54 dachary ceph-disk supports using alternate locations and just symlink them in /var/lib/ceph/osd , using it as a central repository to simplify the setup.
22:55 dalgaaf I mean this is broken if you don't use ceph-disk ... which is also supported ... but I think i have to discuss this on ceph or I have to change it there
22:55 dachary dalgaaf: if you're into listing all osds with their osd number and controling the placement of the disks precisely, the puppet file could contain the ceph::conf lines [osd.4] ... [osd.5].... and it would be written on all machines
22:56 mgagne xarses: oops, you missed rspec tests ;)
22:56 xarses seems that way
22:56 dalgaaf but for that I need the get the osd ID since I cant force the ID for a osd
22:57 dalgaaf or I have to move the "write the config" part to a provider
22:58 dalgaaf have to think about it ...
22:58 openstackgerrit Andrew Woodward proposed a change to stackforge/puppet-cinder: Remove package require for cinder-volume  https://review.openstack.org/53029
22:59 dalgaaf dachary: I will write down ceph::key tomorrow
22:59 dalgaaf have to add my comments to the blueprint now
23:00 dachary dalgaaf: cool :-) Have a good night !
23:14 xarses mgagne: bodepd: dachary do you have an example rspec for the ini_file provider
23:15 mgagne xarses: we don't. we did some manual tests and it works well. we therefore don't feel the need to add tests for now.
23:15 xarses dachary: keeps asking for rspec, hence my asking
23:16 xarses didn't think there was anything to do with out having the manifests to use it
23:16 mgagne xarses: I'm not an expert in puppet custom provider unit testing, even less with ruby...
23:17 xarses same
23:17 mgagne xarses: I spent last Friday learning custom providers and a little of ruby so I could patch something.
23:18 mgagne xarses: if people are already using the code (in production), I don't feel the need to require tests until we have a very good reason IMO.
23:27 dalgaaf mgagne: IMO you have to test at least if you get written what you expect
23:28 dalgaaf xarses: do you have somewhere an example for a ceph.conf written by this code?
23:28 mgagne dalgaaf: I know what TDD is and the culture around it. I'm telling we didn't write tests because we didn't feel the need for it.
23:29 xarses http://paste.openstack.org/show/48910/
23:30 xarses derived from  https://github.com/Mirantis/fuel/tree/m​aster/deployment/puppet/ceph/manifests
23:30 xarses dalgaaf: ^^
23:34 bodepd_ xarses: I'm not really sure what to test
23:34 bodepd_ xarses: the underlying providers work and are well tested
23:35 bodepd_ xarses: maybe you could test type validation and verify that it creates an instance of the expected partent provider
23:35 bodepd_ s/partent/parent/
23:44 dalgaaf xarses: that file is exactly the reason why I don't like inifile: 1.) indentation in sections missing 2) ordering within the section ... this is unreadable for e.g. an admin if he needs to check some values without using search to find e.g. network settings -> check this example from existing puppet-ceph: https://gist.github.com/da​lgaaf/2e72c28cfe5549c134e5
23:44 dalgaaf each block is very easy to read and to find ... every auth setting is together and so on
23:48 xarses i don't disagree that it's ugly, but both problems should be fixable with patches to ini_file
23:49 xarses I don't particularity have any fondness for it, other than nearly every other openstack module does
23:49 xarses use it
23:51 Alssi joined #puppet-openstack
23:53 mgagne dalgaaf: devil's advocate: an admin should look at puppet first and not the config file IMO. If you have a configuration manager, you shouldn't try to circumvent it. Only times I had problem is production is because someone tried to modify a config file by hand because he thought it was the right thing to do. That being said, this could be fixed with patch to puppetlabs-inifile
23:53 ari_ joined #puppet-openstack
23:54 bodepd_ mgagne: order is hard with puppet resources
23:55 bodepd_ you could queue up all of the changes (like concat)
23:55 bodepd_ but at that point they are not atomic
23:55 dalgaaf I don't speak about modification of the file .. but it's clearly impossible even for me a s a developer to check on on of the 100 OSD nodes if the configuration is correct if everything is mixed bug
23:55 mgagne bodepd_: well, tbh, puppetlabs-inifile goes to great length to not change the original order.
23:55 dalgaaf s/bug/up/
23:55 bodepd_ mgagne: based on default values
23:55 mgagne dalgaaf: at that scale, doing it by hand would be crazy
23:55 bodepd_ mgagne: the main motivation for it was b/c openstack config files were changing too fast to keep up
23:56 dalgaaf If I have a node that makes trouble I check the configvalues and this is impossible in this case
23:57 dalgaaf the ceph.conf is pretty static as soon as the cluster is deployed. especially in enterprise production systems
23:57 mgagne bodepd_: unless we find a clever way to use templates, I don't see it scaling well. If someone wants to add a custom value for whatever reason, they won't be able to do so easily as they would need to override the template.
23:57 dalgaaf you couldn't even diff files between nodes without reordering the content
23:57 xarses dalgaaf, i would say that in that case, as would be the same with ceph-deploy (since it cant guarantee order either (python-dict)) is that you would need an inifile parser to maks sure it was correct
23:58 mgagne dalgaaf: configs are resources in puppet. you can consult the catalog if needed. if you don't trust puppet doing its job properly, why bother?
23:59 xarses puppetlabs-inifile tries to re-use the existing location of the key, so much to the fact that if you look at files configured for openstack they are almost always with their comments (if someone didn't purge the original config)
23:59 mgagne xarses: ^
23:59 dalgaaf to be honest: I don't trust puppet ;-)
23:59 bodepd_ mgagne: concat does that

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