Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
00:00 xarses dalgaaf who does?
00:00 dalgaaf but again there is no default ceph config deployed by the packages
00:00 xarses dalgaaf it's usually broken
00:00 mgagne why bother contributing to a tool you don't trust =)
00:00 dalgaaf because I have to use it ... forced by higher power or policies ;-)
00:00 xarses because its the best of the bad tools
00:01 xarses ;)
00:01 xarses or because you have thousands of other lines of puppet already
00:01 dalgaaf oh ... you don't want to start this discussion ... ;-)
00:03 dalgaaf If I could I would may use something different .. maybe something non-declarative ;-)
00:03 dalgaaf but don't let us start this discussion ... doesn't lead to anything ;-)
00:04 bodepd_ mgagne: you could create a resource that allows you to insert arbitrary values into a template with concat
00:04 mgagne bodepd_: until it becomes managed by the module and now you have duplicated values in your config file ;)
00:05 xarses dalgaaf if i keep working with ceph-deploy i'll end up creating a config validate [host] that would probably be better for comparing configs since puppet and python cant ensure key order
00:05 bodepd_ xarses: you could pretty easily compare configs with puppet
00:06 bodepd_ xarses: just like you can run: puppet resource ceph_config
00:06 bodepd_ xarses: you could eaily make the same API call:
00:06 bodepd_ xarses: for programatic comparision
00:06 bodepd_ xarses: It would be: Puppet::Type.type(:ceph_config).instances
00:07 bodepd_ xarses: I would be happy to help you out with a remote based comparision soon.
00:07 bodepd_ xarses: for remote multi-host comparisons, you could integrate it with mcollective
00:07 bodepd_ dalgaaf: this is kind of the real value of using puppet types
00:08 bodepd_ dalgaaf: is that you can generate/filter/and interath them programatically
00:10 xarses later
00:29 dalgaaf bodepd_: I don't get why inifiles works that way ... it shouldn't be that hard to write a config file in a readable way ... what is so hard do add some kind of alphabetical or logical order in a section (e.g. in python you would may use OrderedDict and sort the keys)?
00:30 dalgaaf but's late ... go to bed now
00:42 tdb joined #puppet-openstack
00:49 mgagne dalgaaf: https://github.com/puppetlabs/puppetl​abs-inifile#a-few-noteworthy-features
00:49 mgagne dachary: "The module tries hard not to manipulate your file any more than it needs to. In most cases, it should leave the original whitespace, comments, ordering, etc. perfectly intact."
00:49 mgagne dalgaaf: ^
00:49 mgagne dachary: sorry, wrong mention
00:53 dalgaaf mgagne: again: there is no default file that could be keept intact so this all wouldn't help ... while I could with concat and erb templates very easy write a config file which would have comments and ordering in one very easy way forced to the conf.
00:53 dalgaaf but I leave now ... till tomorrow/later
00:54 mgagne dalgaaf: I'm telling you why inifile behaves like that. inifile wasn't created for puppet-ceph, it's a general purpose tool.
01:00 ari_ joined #puppet-openstack
01:24 ari_ joined #puppet-openstack
01:45 xingchao joined #puppet-openstack
02:04 ari_ joined #puppet-openstack
02:27 xarses joined #puppet-openstack
02:36 prad joined #puppet-openstack
02:47 xingcha__ joined #puppet-openstack
03:46 tnoor1 joined #puppet-openstack
04:10 bodepd_ dalgaaf: the reason it does not write things in order is more around Puppet's implementation
04:10 bodepd_ dalgaaf: I'm happy to chat about it when we get a chance
05:45 e1mer joined #puppet-openstack
05:45 e1mer joined #puppet-openstack
06:51 francois1 joined #puppet-openstack
08:12 dachary joined #puppet-openstack
08:21 dachary hi
08:26 dachary server irc.freenode.net
08:26 derekh joined #puppet-openstack
08:29 Jean-Roger joined #puppet-openstack
08:30 Jean-Roger Hello
08:32 dachary http://webchat.freenode.net/
08:33 Nicolas joined #puppet-openstack
08:35 dachary http://www.mibbit.com/
08:36 a-ttitude joined #puppet-openstack
08:37 benoitBrayer joined #puppet-openstack
08:37 benoitBrayer hi
08:37 Tim___ joined #puppet-openstack
08:37 benoitBrayer https://kiwiirc.com/client
08:38 benoitBrayer bonjour *
08:40 Tim___
08:40 Tim___
08:41 benoitBrayer joined #puppet-openstack
08:42 hbbr joined #puppet-openstack
08:42 hbbr .
08:45 * hbbr slaps Jean-Roger around a bit with a large trout
08:47 aryan joined #puppet-openstack
08:50 Tim____ joined #puppet-openstack
08:51 joLeVrai joined #puppet-openstack
08:52 a-ttitude joined #puppet-openstack
08:52 * hbbr slaps Jean-Roger around a bit with a large trout
08:53 spruvost joined #puppet-openstack
08:54 ircmed joined #puppet-openstack
08:54 spruvost hi
08:54 benoitBrayer left #puppet-openstack
08:55 hbbr Joannick est 100% soumis
08:55 joLeVrai et alors
08:55 benoitBrayer joined #puppet-openstack
08:56 thomasperrault joined #puppet-openstack
08:56 * spruvost slaps hbbr around a bit with a large trout
08:56 * spruvost slaps spruvost around a bit with a large trout
08:56 Jean-Roger Please stop flood
08:56 Jean-Roger I'll call police
08:56 hbbr Go to Nagios
08:57 thomasperrault yo tout le monde
08:57 hbbr yop asv?
08:57 ircmed joined #puppet-openstack
08:57 spruvost left #puppet-openstack
08:57 LAnthony joined #puppet-openstack
08:57 Retarded joined #puppet-openstack
08:58 E-F joined #puppet-openstack
08:58 Coulommiers joined #puppet-openstack
08:58 thomasperrault jolevrai cbien toi???
08:58 Retarded =)=)=)
08:58 blackst0ff joined #puppet-openstack
08:58 ircmed test
08:58 Coulommiers I believe i can fly
08:58 * hbbr slaps Jean-Roger around a bit with a large trout
08:58 * benoitBrayer slaps Retarded around a bit with a large trout
08:58 joLeVrai cbien moi
08:59 thomasperrault trop fort jtai trouver lol
08:59 Binky joined #puppet-openstack
08:59 tototoghfhfh joined #puppet-openstack
08:59 spruvost joined #puppet-openstack
08:59 * benoitBrayer slaps spruvost around a bit with a large trout
08:59 * spruvost slaps benoitBrayer around a bit with a large trout
09:00 * benoitBrayer slaps spruvost around a bit with a large trout
09:00 * spruvost slaps benoitBrayer around a bit with a large trout
09:00 * Retarded slaps blackst0ff around a bit with a large trout
09:02 tototoghfhfh http://www.pcinpact.com/news/84043​-isohunt-ferme-dans-precipitation-​et-tente-d-eviter-l-archivage.htm
09:03 mister joined #puppet-openstack
09:03 mister yo
09:03 Retarded hey
09:03 mister ya de la meuf
09:03 mister left #puppet-openstack
09:04 Retarded left #puppet-openstack
09:04 thomasperrault joined #puppet-openstack
09:05 * benoitBrayer slaps benoitBrayer around a bit with a large trout
09:07 mjeanson joined #puppet-openstack
09:12 * hbbr slaps joLeVrai around a bit with a large trout
09:13 * joLeVrai slaps hbbr around a bit with a large trout
09:13 marun_ joined #puppet-openstack
09:17 hbbr left #puppet-openstack
09:25 e1mer joined #puppet-openstack
09:44 mmagr joined #puppet-openstack
09:53 blackst0ff left #puppet-openstack
11:03 bkero too many trout
11:29 morazi joined #puppet-openstack
11:57 mmagr joined #puppet-openstack
12:10 e1mer joined #puppet-openstack
12:30 mmagr joined #puppet-openstack
13:04 dprince joined #puppet-openstack
13:18 dmsimard joined #puppet-openstack
13:21 openstackgerrit A change was merged to stackforge/puppet-cinder: Remove package require for cinder-volume  https://review.openstack.org/53029
13:28 dachary OMG what did I do
13:40 dmsimard what did you do ?
13:44 dmsimard dachary: I don't understand your comment on 53014
13:44 mgagne he wants 100% test coverage
13:53 dachary well, that's the idea. Code not tested is code exposed to regression.
13:54 dmsimard well, of course we want 100% coverage
13:54 dachary https://review.openstack.org/#/c/53014/3/​lib/puppet/provider/ceph_conf/ini_setting.rb
13:54 dachary sets the separator to ' = '
13:54 dachary the test checks that the separator is ' = '
13:54 dachary so when a typo removes one the of the space aroute the = it breaks
13:55 dmsimard Okay, so that's what I asked in my comment - what should the test cover
13:55 dachary https://review.openstack.org/#/c/​53014/3/lib/puppet/type/ceph_conf.rb hides secret resources, the test shows that a secret resource is indeed hidden
13:57 dachary dmsimard: do you mean that the comment should list a tests that must be wrtitten ?
13:57 dachary I'm not sure what you're asking :-)
13:58 dmsimard dachary: It's not entirely obvious to me what was to be tested - so I looked at other modules (hence nova) and saw that it tested only key/value pairs
13:58 dmsimard dachary: So that's why my question was around "What needs to be tested other than that?" :)
13:59 dachary I see :-) The answer is : tests that cover 100% of the LOC, at the minimum.
13:59 dachary LOC in the module
13:59 dachary ( setting the key/value won't give you any coverage in the module since it's handled by ini_settings itself )
13:59 dachary s/it's/it is/
14:00 mgagne dachary: better remove what we are not planning to use
14:00 mgagne dachary: less code to test
14:00 dachary mgagne: absolutely !
14:00 mgagne dachary: and I thought about using inifile (or not)
14:00 mgagne dachary: is ceph config moving/changing a lot?
14:00 dachary no
14:00 mgagne dachary: is there some weird configuration combination a user would want?
14:01 dachary possibly, yes, *lots* of configurable values
14:01 e1mer joined #puppet-openstack
14:02 mgagne dachary: as bodepd_ said, openstack configs are moving A LOT and users have a plethora of reasons to want to handle their own configs as it would be near impossible for puppet modules to handle all of them.
14:03 dmsimard Using inifile provides a way to manage the config file without having to modify the module
14:03 mgagne dmsimard: true. I wish to know if there is any valid reasons for the end user to provide his own configuration just like there is one for openstack.
14:03 dmsimard (If there are new config parameters, deprecated ones, etc.)
14:04 dmsimard mgagne: What do you mean by "provide his own configuration" ?
14:04 mgagne dmsimard: providing his own configuration key/value
14:04 mgagne dmsimard: [whatever] baboon = true
14:04 dmsimard dmsimard: using the provider ? or providing the configuration file ?
14:05 mgagne dmsimard: anything, talking about general usage of ceph and puppet
14:05 dmsimard mgagne: yes, yes there is a need for users to provide their own configurations
14:06 mgagne dmsimard: if the puppet module doesn't handle all configs/combination (for whatever reason: complexity), then I would prefer inifile or an other way for the end user to provide configs not handled by the module itself.
14:06 mgagne dmsimard: more about flexibility of the config provider: templates vs inifile
14:07 mgagne dmsimard: with inifile, I can provide my own key/value outside the module without having to fork and patch the template.
14:08 dmsimard mgagne: Yup, not only that but we can use the provider within the module itself
14:09 mgagne dmsimard: I know about that. I question the use of inifile as it looks not everyone is happy about it.
14:09 mgagne dmsimard: and I wish to understand what kind of configs ceph allows
14:11 mjblack mgagne: have you ever setup a dedicated keystone service?
14:12 mgagne mjblack: dedicated?
14:12 mjblack mgagne: yeah, servers that all they do is keystone
14:12 mgagne mjblack: what's your question about it?
14:12 mjblack mgagne: I'm looking to use a shared keystone with multiple regions
14:13 mgagne mjblack: what's the issue?
14:14 mjblack mgagne: its more about fact finding, if someone has done it before they might be able to tell me if there is any gotchas
14:14 mgagne mjblack: haven't tried multi-regions yet ;)
14:14 mgagne mjblack: keystone should be able to handle it, I don't see why not
14:15 dmsimard mjblack: good point about ceph_config I think
14:15 mjblack mgagne: lol yeah I'm gearing up to do 26 regions, the only thing I came across is the keystone process is single worker
14:15 mgagne mjblack: keystone_endpoint already contains the region name in the resource name/title so no risk of duplicates here.
14:15 mgagne mjblack: this can be mitigated by running keystone in a wsgi container/server like apache
14:15 mjblack mgagne: yup but I dont think the puppet module supports it
14:16 mgagne mjblack: I think fcharlier added something about it
14:16 mgagne mjblack: for complex setup, don't rely on openstack::all and such. better build your own ;)
14:17 mjblack mgagne: I'm starting to deviate from using the openstack::controller class
14:17 mgagne mjblack: I deviated at day 1 if you want to know
14:18 mjblack mgagne: we started out with the cisco grizzly which uses them
14:18 bcrochet joined #puppet-openstack
14:18 mjblack mgagne: but at this point we're going to need to deviate from that for the controller when it comes to the keystone
14:21 dmsimard dachary: Can you explain why ceph::package would be a bad idea ? I just noticed the edit you did on the blueprint. In puppet-ceph we currently have ceph::apt::ceph and I more or less explained it's role: https://github.com/TelekomCloud/puppet-cep​h/blob/rc/eisbrecher/manifests/apt/ceph.pp
14:25 mjblack mgagne: hmm I'm not seeing anything in the puppet-keystone that setups the keystone app to run as an apache process
14:25 mgagne mjblack: hold on
14:26 mgagne mjblack: oops, sorry, it was abandonned! :O
14:26 mgagne mjblack: https://review.openstack.org/#/c/29059/
14:27 mjblack hmmm
14:31 mjblack mgagne: I wonder if it can be started up again
14:31 mgagne mjblack: sure, I don't see why not
14:32 mjblack mgagne: the issues brought up in the review look to be superficial, like comments from lint and rspec but mostly about ways around puppet language limitations
14:32 mgagne mjblack: I think what was left is testing
14:33 mgagne mjblack: and maybe concerns about imported code which wasn't up to date
14:33 mjblack mgagne: that should be an easy fix
14:33 mgagne mjblack: yes
14:34 mjblack so if I were to try to help fix it, I would just cherry-pick and when I commit make sure to keep the change id?
14:43 mgagne mjblack: I believe there's no way to resurrect a change unless you ask original author or openstack-infra.
14:43 mgagne mjblack: cherry picking would be a simple solution I guess
14:43 mjblack mgagne: ah so even if I cherry-picked it, it would still start it as a new change
14:44 mgagne mjblack: you will have to change the Change-Id
14:44 mjblack mgagne: right because I cant restart the change so it has to be a new one
14:44 mgagne mjblack: otherwise git review will try to push to an abandoned change and it will be rejected.
14:44 mgagne mjblack: yep
15:02 badiane_ka joined #puppet-openstack
15:28 xingchao joined #puppet-openstack
15:39 dmsimard1 joined #puppet-openstack
15:40 xingchao joined #puppet-openstack
15:57 ari__ joined #puppet-openstack
16:10 ari__ joined #puppet-openstack
16:22 xarses joined #puppet-openstack
16:23 nibalizer joined #puppet-openstack
17:03 ari_ joined #puppet-openstack
17:20 prad joined #puppet-openstack
17:24 dmsimard1 dachary: ping
17:24 dmsimard1 xarses: ping
17:24 xarses pong
17:25 dachary dmsimard: pong
17:26 dtalton joined #puppet-openstack
17:26 dmsimard dachary: You didn't reply to my question this morning :(
17:26 dmsimard xarses: are you going to write the rspec tests or should we help you with that ?
17:27 dachary dmsimard: sorry, could you please rephrase ? I was giving a course at the university and it is entirely possible that I overlooked something.
17:27 dmsimard dachary: Can you explain why ceph::package would be a bad idea ? I just noticed the edit you did on the blueprint. In puppet-ceph we currently have ceph::apt::ceph and I more or less explained it's role: https://github.com/TelekomCloud/puppet-cep​h/blob/rc/eisbrecher/manifests/apt/ceph.pp
17:29 dmsimard In my opinion, it is better to install from a repository than from, for instance, a downloaded .deb package.
17:30 dmsimard And I don't see why installing from the ceph repository would become less common
17:30 dmsimard So I might be missing something
17:30 dachary I think this is outside of the scope of the module. Why do you need to have it here instead of outside ? In addition there are zillion ways people deal with packages and it's going to be very difficult to make sure puppet::ceph is compatible with all of them. It is better left outside of ceph, I think. It's pretty much the same for all openstack puppet module if I'm not mistaken. I'm no expert on this though, I may be wrong :-)
17:32 dachary dmsimard: I certainly hope ceph becomes as mainstream as, say, apache2. And it's very uncommon to specify a separate repository for apache2, because it's very well integrated in all distributions.
17:33 dalgaaf but I see no harm in providing a apt/rpm class which would point to ceph.com to install the official packages
17:34 dalgaaf this could be used optional by everyone who would e.g. test and develop against the offical packages
17:34 mgagne dachary: you are mistaken about puppet modules. there is a openstack::repo manifest which configures the appropriate repository
17:34 mgagne dachary: same for puppetlabs-rabbitmq (which we do not control)
17:35 mgagne dachary: making it optional would be desire
17:35 mgagne desired*
17:35 mgagne dachary: same with puppetlabs-mongodb too
17:36 dmsimard puppet-ceph should provide a mean of installing ceph, just like puppetlabs/mysql can install mysql-client or mysql-server or puppetlabs/apache can install apache
17:36 dalgaaf we should keep in mind: ceph isn't openstack and should work also for other clouds or other usecases ... currently I hear to often openstack and openstack puppet modules as a explanation for  decisions ... I don't say it shouldn't be usable for openstack, but don't keep it to tight
17:36 dmsimard and installing it through the official repository is surely the best way of doing so
17:36 xarses dmsimard, I could use some help, I'm lost with regards to rspec tests for ruby handlers, I'd need an example somewhere to reference before i could create some tests myself
17:37 mgagne dalgaaf: that's our (my) experiences I have with puppet.
17:37 mgagne dalgaaf: but I do know how other puppet modules are doing and I pointed it out.
17:37 dmsimard dalgaaf: I don't think we're relying on puppet-openstack for decisions but rather on the work that has been done in the modules in regards to the best practices
17:38 mgagne dalgaaf: it's not uncommon for modules to provide a mean to configure a repository to install packages
17:38 dalgaaf I would like to have it .. only as clarification
17:39 dmsimard xarses: I linked the nova_config rspec tests, should give us a way to start things - dachary said we should also test the separator and that a secret resource is indeed hidden
17:42 dachary dmsimard: Ok, I apologize for my mistake. Would you like me to re-insert the ceph::package or do you want to do it yourself ?
17:43 dmsimard dachary: I'll re-insert it
17:44 bodepd_ I think we may have been trout bombed by the French last nigh
17:44 dachary dmsimard: cool thanks :-) Since it's optional I guess people who don't like it will use their own ways. I should have seen this, I was too quick at discarding the idea.
17:44 dachary bodepd_: :-)
17:45 dachary dmsimard: I suggested these tests indeed. What we're really after is : whatever code we have has a unit test or an integration tests demonstrating that it works.
17:46 mgagne I would suggest renaming ceph::package to ceph::repo if its purpose is to install a repo
17:47 dmsimard mgagne: sure, I have no problem with that
17:50 * dachary just created 4 low hanging fruits in https://bugs.launchpad.net/puppet-ceph and would be gratefull if they are not taken over in the next 24h :-) I would like students to work them and get used to the openstack way of doing things.
17:50 * bodepd_ learns that everytime he cuts corners on proper tests, it has a huge cost b/c of lack of examples
17:51 dmsimard dachary: Wouldn't that make the readme a bit heavy
17:52 dachary we'll see
17:55 bodepd_ mjblack: if you are moving away from the openstack module, could you have a look at the data replacement that I have been working on?
17:55 dachary I tend to think that use cases with examples are by far the best way to figure out if something is what you're looking for
17:56 dalgaaf mgagne: quick note: we may still need some kind of ceph::package to do some mapping of package names since they differ between the different package systems like apt and rpm
17:56 dmsimard puppet-ceph is to use ceph
17:56 mgagne dalgaaf: this could be handled by ceph::params
17:56 dmsimard the use cases so far do not really represent that
17:57 dmsimard it's stuff like testing, benchmarking and continuous integration
17:57 dmsimard dachary: ^
17:57 mgagne dalgaaf: I would use ceph::package to install base packages so clients or other tools can install/require the package without requiring the configuration of a whole ceph cluster.
17:58 xarses dmsimard: the linked code doesn't appear to have anything useful for testing ' = ' I might be able to scrape some things out of the inifile rspec but i still am at a loss for the printing secret
17:58 mgagne dalgaaf: one problem we have with puppet modules for openstack (yes, openstack again) is that you cannot install/require the base packages without configuring rabbitmq, database and stuff.
17:58 dachary dalgaaf: how do you see ceph::key working ? I'm unclear about it. I kind of assume that when on a mon you want to define / import keys if they don't exist yet. But if you're on an osd you just want to write a key on a keyring : boostrap-osd typically. But I did not think it thru.
17:59 dmsimard xarses: Yup, the nova_config rspec only tests key/value pairs. I would personally be okay with that for the time being and expand on that on another review so we can get started
17:59 dmsimard xarses: I'm not exactly an expert in rspec tests either :(
17:59 xarses dachary: ^?
18:00 dachary dmsimard: the use case shows that if you're looking into using ceph to do benchmarking, that's how you could use puppet-ceph. What kind of use case would be relevant for the README ?
18:01 dmsimard dachary: I wouldn't use ceph to benchmark something - maybe I would like to benchmark ceph itself however. Has it been phrased that way ?
18:01 dachary xarses: dmsimard : if the code to hide the secret is not going to be tested, we may as well remove it.
18:01 dachary dmsimard: the use case is to benchmark ceph itself ( see the "rados bench" at the end ;-)
18:02 dachary I added the "I want to operate a production cluster" use case https://wiki.openstack.org/wiki/Pu​ppet-openstack/ceph-blueprint#I_wa​nt_to_operate_a_production_cluster
18:03 dachary but I'm fuzzy around the ceph::key usage because it assumes that it does something different on the mon and on the osd, which is probably not desirable.
18:03 dachary I'd like to know how keys should be handled.
18:05 mgagne dachary: better remove secret until there is a requirement for it
18:06 dachary mgagne: how do you mean ?
18:07 mgagne dachary: remove support for secret parameter
18:07 mgagne dachary: unless you need it, better not implement it (and having to test it)
18:07 dachary how would you define a user without a secret ?
18:07 dachary oh, gosh
18:08 mgagne dachary: do you know what the secret parameter does?
18:08 dachary mgagne: sorry, thought you meant ceph::key secret argument ! ahhaha.
18:08 dtalton do you mean the mon secret for cephx?
18:08 dmsimard secret in the ceph_config provider
18:08 mgagne ^
18:08 dachary mgagne: ok, let's remove it then ( the secret of ceph_config ;-)
18:08 dachary dtalton: hi !
18:09 * dtalton waves at dachary
18:09 dtalton dachary, I will be in HK afterall, no one told me it was setup :D
18:09 dachary good news
18:09 * xarses makes all of ceph_conf secret just for fun
18:09 xarses ;P
18:09 dtalton so I am confused, where is this provider we are referring to?
18:10 mgagne xarses: good luck debugging: "Puppet changed [something] to [something else]."
18:10 xarses mgagne exactly
18:10 mgagne dtalton: L36-50 and L53-59: https://review.openstack.org/gitweb?p=stackforge/​puppet-ceph.git;a=blob;f=lib/puppet/type/ceph_con​f.rb;h=79bb0e54004efe28b30e3ba0baf2bf42640d3baa;h​b=a68fbbcafd4a54a06f8a3582c225e1a93bb0e87d#l53
18:11 dtalton thanks
18:11 xarses but the rspec tests will ensure it set something to something else =)
18:12 mgagne xarses: you won't be able to test that feature anyway. it only shows in logs and rspec-puppet cannot test that
18:13 xarses mgagne, thats my point about requiring tests for it
18:13 dmsimard xarses: did you see that comment about ceph_conf versus ceph_config ?
18:13 xarses i don't think its possible
18:13 xarses yes
18:13 beddari joined #puppet-openstack
18:13 xarses dmsimard: habbit
18:13 * dachary reading https://github.com/TelekomCloud/puppet-c​eph/blob/rc/eisbrecher/manifests/key.pp
18:13 dmsimard xarses: habbit ?
18:13 xarses calling it ceph_conf
18:15 dmsimard I'm not following you :(
18:16 xarses dmsimard: i renamed everything thismorning to ceph_config
18:16 xarses but i keep calling, and typing ceph_conf
18:23 dmsimard xarses: okay, sorry for not understanding :)
18:23 xarses its ok
18:25 dmsimard dachary: I re-added ceph::package in the form of ceph::repo as suggested by mgagne
18:25 dachary cool
18:25 dachary +1 to consistency :-)
18:27 dmsimard I'll work on ceph::repo, since it's something "optional" - I can do it without stepping on anyone's toes
18:27 dachary ok
18:27 dmsimard with ceph::repo and the config provider, we're starting to have the building blocks
18:28 dachary I guess we should create bugs to keep track. dalgaaf : keys, xarses : conf, dmsimard : repo IIRC, right ?
18:28 xarses dachary sure
18:29 dmsimard yeah, I can create a bug for repo
18:31 dachary dalgaaf: If I read https://github.com/TelekomCloud/puppet-c​eph/blob/rc/eisbrecher/manifests/key.pp correctly, ceph::key inject => true would be done on the mon or whatever host has permission to create a key and ceph::key inject => false would be used on hosts that just want to know about the key for a given user. Is it the semantic you're willing to have ? I'm fine with it BTW ;-)
18:32 * dachary reading https://wiki.openstack.org/wiki/Pu​ppet-openstack/ceph-blueprint#key again
18:35 dmsimard dachary: bodepd_ and dalgaaf discussed a very complicated way to distribute the keys without resorting to stored configs a few days ago - dalgaaf said he was going to try, I'm curious if he's suceeded
18:36 dmsimard dachary: I guess that would change to a certain extent how the current ceph::key works
18:37 dachary dmsimard: ok.
18:39 dachary dmsimard: https://wiki.openstack.org/wiki/Puppe​t-openstack/ceph-blueprint#repository would have no argument ?
18:39 dachary except for the release ?
18:40 dachary it may help to add a link to the openstack::repo implementation to browse how it's used
18:40 mgagne dachary: we use release: https://github.com/stackforge/puppet-o​penstack/blob/master/manifests/repo.pp
18:41 dachary mgagne: cool thanks
18:41 dachary dmsimard: would you like to add a link ?
18:41 * dachary browsing https://wiki.openstack.org/wiki/Puppe​t-openstack/ceph-blueprint#repository
18:41 * dachary browsing https://github.com/stackforge/puppet-o​penstack/blob/master/manifests/repo.pp and cursing copy / paste
18:42 mgagne thanks for the comment
18:42 mgagne not sure what it means
18:43 bodepd_ dmsimard: I don't think that was to distribute the keys
18:43 bodepd_ dmsimard: that was to be able to generate a uuid and use it on the same run
18:45 dachary and all the complexity is gone since handling OSD ids is no longer necessary
18:46 dachary it can be done but does not have any useful purpose
18:51 dachary handling OSD ids was necessary pre-cuttlefish though, there was a reason for doing it ;-)
18:53 dachary I had a doubt about what happens if you move a disk with an OSD on it from one machine to the other.
18:54 dachary It does work when the journal is on the same disk, either in the file system or on a separate partition.
18:54 dmsimard bodepd_: maybe, my memory is sometimes defective !
18:54 dachary But what if the journal is on an external disk, which is most commonly the case with SSD ?
18:54 xarses hmm http://paste.openstack.org/​show/E08WKc3CI7A0lFR1228g/
18:55 derekh joined #puppet-openstack
18:55 dachary It turns out that as long as you plug the disk containing the journal and the disk containing the data ( no mater the order ), it will rejoin the cluster. That's the reason for ceph-disk activate-journal ( handling the case when a journal becomes active after the data has been plugged in ).
18:56 mgagne xarses: you need to add puppetlabs-inifile to .fixtures.yaml
18:56 mgagne xarses: if not done already
18:56 dmsimard dachary: I'll add a link to the bug for reference
18:57 dachary All this logic requires dealing with OSD ids. But is now handled by the udev logic and does not need any manual intervention. puppet could have supported this but to the best of my knowledge no implementation has ever done this.
18:57 dachary dmsimard: I did :-)
18:58 dmsimard dachary: Ah, but I added it here: https://bugs.launchpad.net​/puppet-ceph/+bug/1243348
18:58 dachary dmsimard: ha cool, better !
18:58 dmsimard dachary: Did we agree on a platform/release to do our tests on ?
18:59 dmsimard dachary: Personally I'm going towards Ubutun 12.04 and Dumpling
18:59 dmsimard Ubuntu *
18:59 dachary +1
18:59 dachary but how would that happen ?
18:59 dmsimard I say that because for instance openstack::repo handles redhat-like :)
19:00 ari_ joined #puppet-openstack
19:02 mgagne you (puppet-ceph) decide which platforms to support ;)
19:03 dmsimard I guess what I'm trying to say is that I will develop something that will work on Ubuntu 12.04 and Dumpling - if someone has a use case on redhat-like we can always merge them back
19:05 dachary mgagne: how can an external integration test report back to gerrit ? Is it just a matter of setting up a new gerrit user and have the integration test use it to vote down or up ?
19:05 dachary I suspect it's no more complex than this but ...
19:06 mgagne dachary: http://ci.openstack.org/third_party.html
19:06 Kupo24z anyone have any clue when celiometer will be supported? :)
19:06 mgagne Kupo24z: already supported if you install from git
19:06 Kupo24z is that 2.3?
19:07 mgagne Kupo24z: the situation we have is that no one is packaging and publishing the module
19:07 mgagne Kupo24z: should support Grizzly. 2.x
19:07 dachary mgagne: thanks !
19:07 Kupo24z publishing to forge?
19:07 mgagne Kupo24z: -> so something like 2.x
19:08 mgagne Kupo24z: yea, enovance used to develop the module and hosted it on github under their org account. The module got moved to stackforge and now nobody is packaging it for forge. puppetlabs suggested publishing it under their namespace on forge.
19:10 Kupo24z hmm im not seeing any refernces to https://github.com/stackforge/puppet-openstack, did they just not update the readme?
19:10 Kupo24z to ceilometer*
19:11 mgagne Kupo24z: are you referring to puppet-openstack (the module) supporting puppet-ceilometer?
19:16 dalgaaf dmsimard: please don't depend on dumpling ... we discussed already to start with cuttlefish
19:17 dmsimard dalgaaf: I'm guessing things will be very similar (if not the same) from the module's perspective
19:17 dmsimard dalgaaf: I'm not too worried, if anything, it means that the module will be tested to a certain extent against cuttlefish
19:17 dalgaaf dachary: you still need the OSD ids to add them to the config ... as I already pointed out: there are tools like rcscripts for SUSE/Redhat which depend on them
19:18 dmsimard s/cuttlefish/dumpling/
19:18 dalgaaf that's even the fact on master branch of ceph
19:19 dalgaaf and the start scripts are used even if you have this udev stuff
19:19 otherwiseguy joined #puppet-openstack
19:19 dalgaaf since an operator would use these scripts if he needs to shutdown something and since they are used if you shutdown a server
19:21 Kupo24z mgagne: yes
19:21 dalgaaf and event the documentation at ceph.com still says so: http://ceph.com/docs/master/rado​s/configuration/ceph-conf/#osds
19:24 mgagne Kupo24z: in that case, we don't have plans yet to support ceilometer unless someone step in
19:24 dachary dalgaaf: it is easier for the ceph puppet module to provide a script for the systems that do not yet have a proper implementation. Easier than architecturing the puppet ceph module to accomodate a use case that has been deprecated.
19:25 dalgaaf dachary: yes the ceph::key would work this way. I would be called either on the mon or any other host which has the admin secret available to create a key and inject it (if the parameter is set) ... otherwise it would be used to simply create e.g. a /etc/ceph/client.images file with the correct format and key e.g. on a machine that needs this key
19:25 dachary dalgaaf: re ceph::key +1 on the syntax + semantic
19:26 dalgaaf please don't start distributing start scripts to the system that doesn't change anything since this would be only valid in the context of puppet ... but the system tools that are part of the packages and distributions should be even usable if you create a config with puppet.
19:27 dalgaaf otherwise nobody (e.g. on suse/redhat) will use it !
19:28 Kupo24z mgagne: is there any major difficulties for supporting ceilometer?
19:28 dalgaaf you may see that in a different way ... I worked for a distribution and this is something they and their user don't like
19:29 dalgaaf It makes it really hard for them to support a system
19:29 mgagne Kupo24z: I don't think so, just have to do the job. One thing is that puppet-ceilometer would need to be published to forge first otherwise puppet-openstack won't be able to find the dependency
19:29 dalgaaf don't force incomplete config files to a system which makes services failing
19:30 dalgaaf I don't even see how a script from puppet would handle the shutdown case
19:31 dalgaaf And I think we still need to have a Service{} to get daemon started/stopped
19:32 dalgaaf and this would depend on the upstart as well as on the rcscripts (or even systemd)
19:32 dalgaaf and puppet-ceph should respect the way these systems work
19:33 dachary here is how I propose we do integration tests, because I prefer openstack over vagrant : https://wiki.openstack.org/wiki/Puppet-op​enstack/ceph-blueprint#Integration_tests
19:34 mgagne dachary: what about success?
19:34 dachary mgagne: is there such a thing ? :-)
19:34 dachary mgagne: it would vote +1 I guess
19:37 dachary dalgaaf: what if we make the case that this should be backported to cuttlefish to improve os support ? I think a patch might be accepted for the next stable release. That's a bug (not auto discovering that is), right ?
19:39 dachary dalgaaf: why would puppet be concerned with running osds ?
19:40 dachary it had to, but no longer needs to.
19:41 dachary ceph has been designed this way : to relieve the sysadmin from the burden of handling this logic. I don't understand why you would want to re-implement what already is provided by ceph.
19:41 dachary it does make sense to fix ceph where it fails ( i.e. the failure to autodetect on boot on some systems )
19:52 ari_ joined #puppet-openstack
19:55 dachary bodepd_: since you are the one who suggested to use https://github.com/puppetlabs/rspec-system-puppet in the first place, would you mind if an openstack based integration test is put in place ?
20:00 dalgaaf dachary: why should it be a bug? It's maybe a missing feature, but's not a bug.
20:02 dalgaaf And I don't get why it's such a problem to write the config the way it's documented by ceph currently
20:03 dalgaaf and this would puppet ceph even make depending on a certain release of ceph and not a release
20:04 bodepd_ dachary: can you be more specific about what you mean?
20:05 bodepd_ dachary: to test what exactly?
20:05 dachary bodepd_: this is what I suggest https://wiki.openstack.org/wiki/Puppet-op​enstack/ceph-blueprint#Integration_tests
20:05 dalgaaf dachary: and even the ceph example file adds each osd to the config
20:06 dalgaaf we will add also each radosgw and mds and mon to it ... why stop at the osd
20:06 bodepd_ dachary: something like that would be great
20:07 dachary because dealing with osd ids creates a lot of problems that you don't need to solve. It's unlike the other components.
20:07 bodepd_ dachary: but, I'm not sure if openstack specific tests should be gating the ceph module
20:07 dalgaaf https://github.com/ceph/ceph/b​lob/master/doc/start/ceph.conf
20:08 dachary dalgaaf: what is the sequence of operations you need to perform to move a disk from one machine to another if puppet knows about osd ids ?
20:09 dalgaaf I never do that propably ... the only case would be: replace the chassi and the motherboard and add the disks back to the enclosure at the same place  and it would simply start
20:09 dachary dalgaaf: it is possible to use osd ids, I don't dispute that. My question is rather : why is it useful ?
20:10 dachary dalgaaf: machines die, that happens.
20:10 dalgaaf I don't see the case where you move single disks from one machine to another ... not in any production/enterprise cluster
20:11 dachary ok
20:11 dalgaaf this would IMO contradict the design of ceph where you may even wouldn't to that since you would simply reprovision the machine because the data is replicated anyway and you may get in trouble with old data since the machine failed 2 days ago and contains tainted or outdated data
20:12 dachary let's move this discussion to ceph-devel instead of speculating on the rationale, shall we ?
20:13 dalgaaf I can only tell you what we do and what we expect from a usable puppet-ceph
20:13 dachary you're arguing that disks don't need to be moved and therefore puppet must not support this. It's a tough sale ;-)
20:15 dalgaaf if you move these disks it would work anyways since you also move the root disk or could it simply design in a way that it gets the ids from ceph or the disks ... where is the problem?
20:16 dalgaaf maybe have have simply a different perspective and background/usecase which makes it hard to get to a point
20:16 dachary let me ask this on #ceph
20:16 dalgaaf I'm not at this channel ... sorry
20:17 dachary ah
20:17 dalgaaf have some trouble to connect atm to oftc.net
20:19 dmsimard joined #puppet-openstack
20:19 dachary assuming the bootstrap script that fails to autodetect /var/lib/ceph/osd is fixed in both cuttlefish and dumpling. What is the other technical problem for which you need osd ids ?
20:20 dachary ( I read what you said about contradicting the design of Ceph but let's not go there unless we have the authors with us )
20:20 Totonyus joined #puppet-openstack
20:21 Totonyus left #puppet-openstack
20:22 dalgaaf dachary: and if I read the thread at the ceph ML correctly moving disks isn't expected to work this way ... you have to zap the disk and this would need admin intervention
20:25 dalgaaf it would be okay for me only if this complete osd.id handling is remove offical from any documentation ... a admin or what person ever would read the documentation and would have simply trouble ... And I like to know what's intended to be setup on the machine ... this info I could get always from the config
20:27 dachary you would have to zap the disk if you had osd rm. But if you did not, then it would just work.
20:30 dalgaaf It may would but this is IMO not the normal way to go ... If the cluster is in use and the osd node is only down e.g. 2 hours the data on the disk is old and would be dropped by the cluster and this would cost additional load ... you would simply remove the disk, replace it or if the machine failed you would replace other hardware ... then you would zap the
20:30 dalgaaf disk and reprovision the disk/node ... the cluster would fill the disks again with fresh data ... I don't see how it should work in another way
20:30 dalgaaf if you have a data center with 100s or 1000s of nodes you are not able to replace HW in time to prevent rebalancing
20:31 dachary I agree
20:31 dalgaaf and data migration ... otherwise you would also need to run time consuming filesystem checks etc
20:31 dalgaaf this all would outdate the data ...
20:33 dachary I don't see how that makes you need OSD ids though.
20:33 dalgaaf I could even accept if the part of writing the osd.id sections could be disabled if you don't like it
20:34 dachary I do have four machines each with 5 disk and 8 slots. They are old and I'm quite sure I'll be very happy to move the disk and do nothing else when one of them dies. That's one postiive use case ;-)
20:35 dalgaaf see: I worked for SUSE on ceph ... and I know the rcscripts currently work this way ... even some tools around ceph may work this way ... now we work with Ubuntu, but we even want to have the osd ids there to track what's intended to run on the system ... not depending on puppet information
20:37 dalgaaf the moving would be an manual task what would be the problem? ... you simply design puppet ceph to pick them up and write a new config
20:37 dachary you would be ok with the puppet ceph client walking /var/lib/ceph/ods and update the /etc/ceph/ceph.conf osd.X sections accordingly ? That would be useful for backward compatibility and easy.
20:37 dalgaaf and since you would may move the complete disks incl. root you don't need to to anything
20:37 dachary s/puppet ceph client/puppet agent running on the osd node/
20:39 dalgaaf as long as this happens in one run (the same run as the deployment) : yes ... I never tried to force you to not use the udev/disk-prepare solution .. I don't care how the information ends up in the config but the info should be there latest before the puppet run ends
20:40 dalgaaf that's what I discussed several days ago with bodepd_ to find a way to get the osd ids from the system into the config in the same run
20:41 dalgaaf I might not happy with ceph-disk anyway but this is another story ... I have to check very carefully if it would do what we have as a usescase currently but then I (as a ceph developer) may have to extend this tool anyway.
20:41 dalgaaf this is another discussion
20:41 ari_ joined #puppet-openstack
20:42 dachary note that I'm *not* suggesting a way to let puppet know about ceph ids. I'm merely suggesting that the puppet agent creates the /etc/ceph/ceph.conf file local to the osd node by exploring the /var/lib/ceph/osd directory and create the corresponding [osd.X] sections.
20:42 dachary Would that be agreeable to you ?
20:42 dachary That would happen before the puppet agent finishes
20:43 dachary since ceph-disk waits for udev to settle before returning
20:43 dalgaaf This was always only about the local node for me ... this is how puppet-ceph currently works
20:43 dachary dalgaaf: we have a deal it seems :-)
20:43 dachary one additonal question
20:43 dalgaaf and I only discussed about the outcome (the ceph conf) not about the implementation so far.
20:44 dachary would that /etc/ceph/ceph.conf with osd.id make the suse script work ?
20:45 dalgaaf yes, it would as long as it contains the [osd.id] section with host and disk ... the same for redhat and any other distro using the rcscript
20:46 dalgaaf at least for this node
20:47 dachary excellent
20:48 dalgaaf the /etc/init.d/ceph -a wouldn't work I guess  since this would need a complete config of all machines that are part of the cluster
20:50 dachary dalgaaf: https://wiki.openstack.org/wiki/Pu​ppet-openstack/ceph-blueprint#osd updated to ack our agreement.
20:50 dalgaaf but that's maybe something that would be acceptable and not that critical
20:50 dachary I bet these scritps will gradually do the same as what upstart currently does
20:52 dachary I'm glad we came to an agreement a dalgaaf :-)
20:52 dalgaaf okay ... was hard to find a solution ;-)
20:53 dalgaaf have to leave now ... cu
20:53 dachary night !
21:00 bodepd_ EmilienM: fc__ what mongodb module do you use for ceilometer?
21:00 bodepd_ prad: ^^^
21:06 xarses mgagne: I've gotten close to being able to test the secret redactor in the inifile helper, but I've no clue as to how to invoke the is_to_s and should_to_s functions for the rspec tests https://github.com/stackforge/puppet-nova/b​lame/master/lib/puppet/type/nova_config.rb
21:06 mgagne xarses: those are magically invoked by puppet
21:07 xarses can i make puppet parse them in the rspec?
21:07 mgagne xarses: I think we agreed on drop it until we need it
21:07 mgagne xarses: rspec-puppet won't be able to test it as results are found in puppet logs which rspec-puppet does not support
21:08 mgagne xarses: better check if puppet itself has tests for those
21:08 EmilienM bodepd_: let me check
21:09 EmilienM bodepd_: puppetlabs-mongodb
21:09 EmilienM (upstream)
21:10 bodepd_ EmilienM: prad ran into an issue where he could not set the bind address
21:11 bodepd_ EmilienM: you you connecting via localhost?
21:11 prad seems like that module doesn't support replica sets?
21:11 bodepd_ EmilienM: thanks!!!
21:11 prad thx bodepd_
21:11 EmilienM bodepd_: i don't have details now, i could answer better at work tomorrow
21:12 EmilienM bodepd_: but no, we have separate nodes for mongodb, i'm pretty sure
21:15 dmsimard joined #puppet-openstack
21:20 bodepd_ EmilienM: I'm sure prad will have some questions.
21:20 bodepd_ EmilienM: he is adding/testing ceilometer this week
21:20 EmilienM bodepd_: you know where i am :)
21:21 prad EmilienM: so tomorrow would be good time for you to chat about this? looking at the upstream module its missing a bunch of config options, specifically around replica sets
21:21 prad I'm curious how you guys are handling it
21:22 EmilienM prad: sure, let's talk tomorrow. It's late here, i have to leave :)
21:22 prad EmilienM, sure np
21:27 dwt1 joined #puppet-openstack
21:31 dachary Does someone have resources to provide a dedicated openstack tenant for puppet-ceph integration tests ?
21:31 dachary in a permanent way that is ;-) Something we can rely on to react to gerrit reviews.
21:33 dachary ideally the ability to provision 5 vm + 5 volumes + 5GB RAM + 5 cpu and no need for a public IP.
21:34 dachary insignificant disk space
21:34 dachary 2 networks
21:34 * dachary out for the night
21:35 bodepd_ dachary: cisco may
21:35 bodepd_ dachary: we are in the process of moving our cluster from behind the firewall
21:35 bodepd_ s/we/they/ :)
21:36 mgagne s/they/I/ :)
21:36 mgagne just kidding
21:36 mgagne messing with dachary
21:39 e1mer joined #puppet-openstack
21:39 dwt2 joined #puppet-openstack
21:47 mjblack bodepd_: sure, can you send me a link?
21:48 bodepd_ mjblack: it's bit heavy to get start with
21:49 bodepd_ mjblack: https://github.com/CiscoSystems/opensta​ck-installer/blob/master/data/README.md
21:49 bodepd_ that is the best place to get started
21:50 bodepd_ mjblack: it may be a tiny bit out of date
21:50 bodepd_ mjblack: but for sure good enough to wrap your head around it
21:52 mjblack bodepd_: yeah I'll take a look, we're using hiera right now and we were going to go with defaults and overrides to simplify things even further
21:52 bodepd_ what do you mean by defaults and overrides?
21:52 bodepd_ hiera deaults and overrides?
21:53 mjblack hash merging
21:53 bodepd_ gotcha
21:54 bodepd_ this adds a couple of extra layers to make hiera act a little bit like the openstack module
21:54 mjblack like with our cinder configuration, it allows to specify the backend in the hiera, so its something that we would have as a default and then in the local hiera it could be changed if nessecary
21:54 bodepd_ this is a litte different
21:55 bodepd_ is has a concept of hiera global variables that effect the lookup hierarchy
21:55 mjblack right this is using hiera as an enc :)
21:55 bodepd_ so that you could have different hiera defaults
21:55 bodepd_ based on what backend you select
21:55 bodepd_ mjblack: it's moving towards that
21:55 bodepd_ mjblack: I found hiera too hard to debug
21:56 mjblack it is from puppet
21:56 bodepd_ mjblack: and lacking a few features, and too slow
21:56 bodepd_ mjblack: is that a jab :)
21:56 mjblack no not at all
21:56 mjblack the command line I found easier for debugging
21:56 bodepd_ I think some of my concerns are going to be fixed in 4.x
21:57 mjblack I cant really make fun of puppet, its what gets me the paycheck :D
21:57 bodepd_ I found that I could grok, but other people had trouble understanding what x=y vars had to be set to ensure you get the correct vlaue
21:57 bodepd_ value
21:57 dwt1 joined #puppet-openstack
21:57 bodepd_ mjblack: just chekcing , that could have ben sarcasm
21:58 bodepd_ mjblack: I also didn't like that you had to look up keys individually
21:58 bodepd_ mjblack: b/c what I really want to see is: given this data,
21:58 bodepd_ what classes, and for those classes, what values set the data-bindings
21:58 mjblack right but I think that goes beyond the scope of what hiera intended to be
21:59 mjblack it was meant to be a step up from extlookup, and exceeded that in my opinion too
21:59 bodepd_ absolutely
21:59 ryanycoleman joined #puppet-openstack
21:59 bodepd_ it also introduces intersting patterns that simply a lot of aspects of module development
22:00 mjblack but I really only look at hiera as a way to inject simple external data into puppet
22:00 bodepd_ I guess that for the use case I am working on, the data is not as simple
22:01 bodepd_ I've been focused more on: encoding multiple reference architectures
22:01 mjblack well things that I'm doing are iterative right now, you're far further in your process than me
22:01 bodepd_ and ensuring that you can select either an architecture (ie: AIO) or a plugin (ceph)
22:01 ryanycoleman joined #puppet-openstack
22:01 bodepd_ and get visibility into what set of user data is expected
22:03 mjblack when we were planning our grizzly/havana deployments the decision I made was that we needed to use git, hiera, and standard manifests
22:04 mjblack but even then its a challenge bringing everyone else up to that expectation
22:05 xarses mgagne: I need to add multiple backend support to cinder volumes in the manifests, thoughts? create a bp / wiki to discuss?
22:05 mgagne xarses: blueprint + wiki would be ok to me
22:05 mgagne xarses: as I guess there will be some discussions around it
22:08 bodepd_ xarses: what is missing?
22:08 bodepd_ I thought it was X::backend::Y
22:08 xarses bodepd_: doesn't support https://wiki.openstack.org​/wiki/Cinder-multi-backend
22:13 xarses https://blueprints.launchpad.net/puppet-​cinder/+spec/cinder-volume-multi-backend and  https://wiki.openstack.org/wiki/Puppet-o​penstack/bp-cinder-volume-multi-backend
22:13 bodepd_ ah, gotcha
22:13 bodepd_ it's on the scheduler
22:13 xarses cinder-volume config
22:14 bodepd_ lemme re-read :)
22:14 xarses if its specified that way, the init service spawn's one cinder volume instance per enabled_backend
22:15 xarses then you also need to register some volume_types into the cinder db
22:15 xarses so they show up and are selectable in horizon
22:15 xarses // cli
22:15 mgagne xarses, bodepd_: this would require a refactor of the current implementation. There is currently no way to define 2 times the same backends due to the limitation of puppet classes
22:15 bodepd_ b/c of resource conflicts?
22:16 xarses mgagne, I'm aware
22:16 xarses it will need some major work. But i'm quite sure work is paying for the effort
22:16 bodepd_ make a blueprint. It seems like a reasonble thing to get in icehouse
22:16 mgagne bodepd_: how can you include 2 x cinder::volume::san which are classes?
22:16 mgagne bodepd_: looks more like a job for defines
22:16 bodepd_ yeah.
22:16 xarses mgagne: my thought
22:17 xarses too
22:17 bodepd_ seems like you do in a non-incompat way if the existing classes juse use the defines
22:17 mgagne xarses, bodepd_: unless we find a very clever way to still support current implementation =)
22:18 xarses the hard part i need to think about is how to compile the list of all enabled backends
22:18 mgagne bodepd_: my idea =)
22:18 bodepd_ it's not just going to be with cinder_config?
22:18 mgagne xarses: this could be done with virtual resources
22:18 xarses mgagne: just convert everything to this multi format and only enable 1 for backwards?
22:18 bodepd_ mgagne: I hate virtual resource. yuck
22:18 mgagne bodepd_: I'm sorry =)
22:18 mgagne bodepd_: at least they are not exported
22:19 bodepd_ mgagne: yeah. I can't wait till we don't require that for swift
22:19 mjblack bodepd_: why wait? just switch to ceph :D
22:19 xarses lol
22:19 bodepd_ bodepd_: I still gotta support it for now.
22:19 bodepd_ mjblack: once the shiny new ceph module is done
22:20 mjblack talking to yourself is a sign of insanity
22:20 mgagne mgagne: what bodepd_ said is true, I should listen to him.
22:20 bodepd_ oh yeah
22:20 bodepd_ I'll save it for #bodepd
22:21 ryanycoleman joined #puppet-openstack
22:22 openstackgerrit Andrew Woodward proposed a change to stackforge/puppet-ceph: Add ceph_conf ini helper  https://review.openstack.org/53014
22:23 mjblack so gerrit is now tracking trailing white spaces?
22:23 mjblack https://review.openstack.org/#/c/53014/4/spe​c/unit/provider/ceph_config/ini_setting_spec.rb
22:26 openstackgerrit Andrew Woodward proposed a change to stackforge/puppet-ceph: Add ceph_conf ini helper  https://review.openstack.org/53014
22:26 mgagne mjblack: always has
22:26 xarses their gone now =)
22:26 mjblack mgagne: I dunno I'm sure I've put trailing whitespaces before :D
22:27 mgagne mjblack: I trim whitespaces on save so I don't have this problem ;)
22:27 mjblack I know I've been dinged on tabs before
22:29 mjblack and gerrit doesnt give a good enough indicator of it
22:29 mgagne mjblack: it shows tabs too, a small red arrow is used
22:29 ryanycoleman joined #puppet-openstack
22:29 mjblack yeah but for us old folk its hard to see :)
22:30 mgagne mjblack: I agree that gerrit isn't very good in that aspect. same with change dependencies, you have a little warning in 8px telling you to rebase before merging when dependency is outdated.
22:31 mjblack ah well we should just use github and pull requests :D
22:31 * mjblack ducks
22:32 * xarses throws a duck
22:32 mgagne now I'm hungry and want to eat duck
22:33 mgagne the animal, don't be mistaken
22:33 * xarses raises an eyebrow
22:34 xarses I'm not sure i want to know why you had to clarify that
22:34 mjblack I dont think anyone was mistaken but you o_O
22:41 ryanycoleman joined #puppet-openstack
22:43 ryanycol_ joined #puppet-openstack
22:59 ari__ joined #puppet-openstack
23:09 pabelanger joined #puppet-openstack
23:22 dtalton joined #puppet-openstack
23:24 bodepd_ mgagne: pretty sure I just got bit by swift not supporting inifile
23:24 bodepd_ mgagne: it completely lays down all of the config files
23:24 bodepd_ mgagne: and for sure, swift assumes something differnet for havana
23:25 e1mer joined #puppet-openstack
23:29 mgagne bodepd_: ^^'
23:30 ari_ joined #puppet-openstack
23:30 ryanycoleman joined #puppet-openstack
23:31 xarses updated https://wiki.openstack.org/wiki/Puppet-o​penstack/bp-cinder-volume-multi-backend
23:39 dwt1 joined #puppet-openstack
23:47 bodepd_ mgagne: the supported pipelines changed big-time in swift
23:47 bodepd_ mgagne: it is previous obvious no one has been working on it for Havana
23:47 mgagne bodepd_: yes, I saw your email
23:48 bodepd_ but OpenStack (at least for my initial test case) looks good!
23:48 mgagne :D
23:48 bodepd_ I'll send out another email with the errors/warning I saw in the openstack logs
23:48 bodepd_ probably 10 or so
23:49 mgagne bodepd_: did you find time to test keystone_endpoint?
23:49 bodepd_ at first search, I did not even find installatoion docs for swift
23:49 bodepd_ for Havana
23:49 bodepd_ mgagne: no :(
23:49 bodepd_ I could probably find a few minutes now (in theroy)
23:50 bodepd_ let me deploy a new Havana openstack environment :)
23:50 bodepd_ my days of deploying Grizzly are officially over
23:52 mgagne bodepd_: =)
23:52 mgagne bodepd_: I wish I had more time to test havana or someone else to do it *wink*
23:54 xarses mgagne: we'll start havana integration testing soon @Mirantis
23:54 xarses I'm sure someone will have to kick up a bunch of these issues
23:54 xarses hopefully not me
23:54 xarses ;)
23:55 bodepd_ xarses: you guys are using swift?
23:55 xarses barely, but yes
23:55 xarses its nearly striped out for the ceph module we wrote
23:55 bodepd_ it's really annoying to install
23:56 bodepd_ cool. I have a feeling that is what is happening at least with out community
23:56 bodepd_ s/out/our/
23:56 xarses yes, the best way to fix it is to replace it with the ceph class
23:56 bodepd_ :)
23:56 xarses :D
23:56 bodepd_ I'm ok with that
23:56 bodepd_ I know xingchai is using it
23:56 bodepd_ I haven't seen to many peeps from him lately...
23:57 bodepd_ mgagne: it's ok. someone still needs to test linuxbridge :)
23:58 mgagne bodepd_: :D
23:58 xarses fork

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