Perl 6 - the future is here, just unevenly distributed

IRC log for #puppet-openstack, 2013-11-17

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

All times shown according to UTC.

Time Nick Message
00:38 thumpba joined #puppet-openstack
01:53 thumpba joined #puppet-openstack
02:04 thumpba joined #puppet-openstack
02:06 tnoor joined #puppet-openstack
02:08 tnoor1 joined #puppet-openstack
02:56 thumpba joined #puppet-openstack
03:08 rongze joined #puppet-openstack
03:13 thumpba joined #puppet-openstack
03:36 mjblack_ joined #puppet-openstack
04:14 marun joined #puppet-openstack
05:47 rongze joined #puppet-openstack
07:33 rongze joined #puppet-openstack
08:28 rongze joined #puppet-openstack
09:49 rongze joined #puppet-openstack
09:50 rharrison joined #puppet-openstack
10:02 rongze joined #puppet-openstack
11:22 rongze joined #puppet-openstack
12:00 rongze joined #puppet-openstack
12:43 rongze joined #puppet-openstack
12:52 _ilbot joined #puppet-openstack
12:52 Topic for #puppet-openstack is now Place to collaborate on Puppet/OpenStack tools: logs at http://irclog.perlgeek.de/puppet-openstack/today
13:02 rongze joined #puppet-openstack
13:08 rongze_ joined #puppet-openstack
14:27 dachary I'm stuck because of https://projects.puppetlabs.com/issues/23186#note-1
14:27 dachary I must be missing something obvious
14:34 dachary https://projects.puppetlabs.com/issues/23187
14:34 dachary ( I filed the bug against PE ... ;-)
14:35 dachary I don't care much about network-interface but ceph-mon is in the same situation and service just won't handle it
14:52 dachary The workaround is to use the init provider and provide start/stop/status commands.
16:12 thumpba joined #puppet-openstack
16:47 rongze joined #puppet-openstack
17:18 mmagr joined #puppet-openstack
17:28 xarses dachary: I found that you can just set the provider to debian for the ceph services
17:28 brdude joined #puppet-openstack
17:28 xarses puppet appears to refuse to allow stderr output in the service commands
17:52 rongze joined #puppet-openstack
18:16 dachary xarses: yes :-)
18:53 rongze joined #puppet-openstack
19:02 EmilienM joined #puppet-openstack
19:20 thumpba joined #puppet-openstack
19:21 thumpba joined #puppet-openstack
19:21 thumpba joined #puppet-openstack
19:24 openstackgerrit Martin Mágr proposed a change to stackforge/puppet-nova: Removes unnecessary api-paste.ini configuration  https://review.openstack.org/54306
19:49 badiane_ka joined #puppet-openstack
19:53 rongze joined #puppet-openstack
20:00 dachary xarses: I'm curious to know if you filed a bug against the upstart provider already ? I did not find any ...
20:15 ric` joined #puppet-openstack
20:26 thumpba joined #puppet-openstack
20:54 rongze joined #puppet-openstack
20:56 thumpba joined #puppet-openstack
21:18 tnoor joined #puppet-openstack
21:20 tnoor1 joined #puppet-openstack
21:31 mkoderer_ joined #puppet-openstack
21:33 finch_ joined #puppet-openstack
21:51 xarses dachary: i haven't tested it against 3.3 when i have a chance, i will file the bug. but it refuses in 2.7.19
21:52 dachary xarses: refuses ? do you mean it also fails on 2.7.19 ?
21:53 xarses I only tested it on 2.7.19, in which case any stderr from the init script causes it to fail
21:53 sanman_ joined #puppet-openstack
21:54 rongze joined #puppet-openstack
22:06 thumpba joined #puppet-openstack
22:18 openstackgerrit Loic Dachary proposed a change to stackforge/puppet-ceph: draft implementation of mon::ceph  https://review.openstack.org/56841
22:36 openstackgerrit Loic Dachary proposed a change to stackforge/puppet-ceph: draft implementation of ceph::mon  https://review.openstack.org/56841
22:55 rongze joined #puppet-openstack
23:02 openstackgerrit Loic Dachary proposed a change to stackforge/puppet-ceph: draft implementation of ceph::mon  https://review.openstack.org/56841
23:06 thumpba joined #puppet-openstack
23:11 dachary dalgaaf_: is there a way to make it so facter returns facts from ceph --show-config as soon as ceph is installed ? To avoid the two pass which I don't like either ;-)
23:20 dalgaaf_ dachary: Sorry I have no time today ... on the way to the bed ...  I don't get for what you need facter at all .... I can only point to the puppet-ceph implementation I did
23:20 dalgaaf_ sorry ... cu
23:20 dachary I explained in the comments
23:20 dachary cu tomorrow :-)
23:21 michchap joined #puppet-openstack
23:21 dachary dalgaaf_: we don't need the facter. We need ceph --show-config. With facter or something else. But we need it.
23:23 dalgaaf_ for what do you need --show-config ?
23:24 dachary how else do you konw where mon-data is ?
23:24 dalgaaf_ and what do you need to support multiple clusters? simply a new site.pp or a new fsid in the config
23:25 dalgaaf_ from the config passed to the mon ... or you hardcode some simple defaults
23:25 dachary the reason for puppet-ceph is to defragment the implementations out there. It must address all known use cases ( at least the one that are not super strange ;-) otherwise there is no point. Multiple cluster and handling various key management patterns is part of it.
23:26 dachary dalgaaf_: re mon-data : that does not work, it ends up being incompatible with what ceph-mon does. It's already happening.
23:27 dalgaaf_ and what does ceph-mon?
23:30 dachary dalgaaf_: that's a fair question. I have to demonstrate the inconsistencies of the current implementations otherwise I'll be told they do not exist. There is no point in trying to fix a problem that does not exist, you first have to show what the problem is.
23:30 dachary That's not because I see them that everybody does.
23:30 dalgaaf_ if you mean the mon_data path ...  this is a leftover from bobtail ... can be changed very easy
23:31 dachary if it was the only one
23:33 dachary dalgaaf_: is there a way for ceph::mon to query a value set in ceph_config ?
23:34 dalgaaf_ via provider for sure but what you get in a provider stays in the provider
23:34 dachary say you set [mon.a] mon-data = /tmp and [mon] mon-data = /foobar and [global] mon-data = /frob
23:35 dachary how do you get it to behave the same way ceph will ?
23:35 michchap joined #puppet-openstack
23:35 dachary it's a rabbit hole from which you will never come back ;-)
23:35 dalgaaf_ if you set that why do you want it to behave like ceph does?
23:35 dalgaaf_ you are always free to change the location of the data on your disk/ceph setup
23:36 dachary when you ceph-mon --mkfs you want to give it a mon-data that matches the one ceph will use, not another one
23:36 dalgaaf_ that parameter can be changed for each OSD/MON/MDS/RGW
23:37 dachary dalgaaf_: yes, it can. In quite complex ways.
23:37 dalgaaf_ there is no need to have a common location except maybe for the tools that may use the common location to loop over the information in there ... like the upstart script
23:37 dachary furthermore, by default it relies on meta-variables
23:37 dachary and will change according to the cluster
23:37 dalgaaf_ but it works perfectly ...
23:38 dachary /${cluster}-${id}
23:38 dalgaaf_ by default, yes ... but this isn't forced
23:38 dalgaaf_ that is simply a location on your disk, it works what ever you are fine with AFAIK
23:39 dalgaaf_ thats why /osd.$id also works
23:39 dachary you lose the benefit of upstart if you do that
23:39 dachary upstart won't find what it is supposed to
23:39 dachary my point is that with ceph --show-config we would not even have this discussion
23:40 dalgaaf_ I don't use upstart ... that's a dead horse ... there is SysV or systemd ... I don't get why ubuntu still tries to ride this dead h.
23:40 dachary we would just rely on what ceph provides and not have to create and understand *perfectly* how ceph requires things to be setup by default
23:40 dachary why would you want such a burden, that's what's at stake, I think
23:40 dachary dalgaaf_: we get to support multiple use cases, you can't discard upstart just becasue you don't like it ;-)
23:41 dalgaaf_ at stake is: any run more than one is a failure
23:41 dachary dalgaaf_: why ?
23:42 dachary strike that
23:42 dachary I don't want to run twice.
23:42 dachary But
23:42 dalgaaf_ If I have to rely an puppet running a second time to deploy my cluster It fails because that needs time ... IIRC by default 30min if you are not masterless
23:42 dachary You have to admit that it simplifies greatly the complexity ( we have *not* to worry about any default , no more than any sysadmin does ).
23:43 dalgaaf_ btw. if upstart relies on the default location and not on what's defined in the config as default, then upstart is broken by design
23:43 dachary it would fail really ?
23:44 dmsimard joined #puppet-openstack
23:44 rharrison joined #puppet-openstack
23:44 dalgaaf_ since it doesn't take in consideration that this is only a "proposal" and nothing hardcoded
23:44 dachary dalgaaf_: I agree that upstart should not rely on a fixed location. But why should we even discuss this ? If we just rely on ceph defaults instead of creating new ones, we never have to deal with this. Ever.
23:45 dachary Creating a new set of defaults is trouble.
23:45 dalgaaf_ but then you may fail if someone define some other values
23:45 dachary No.
23:45 dachary If someone defines a broken ceph.conf it's on him.
23:46 dachary If puppet-ceph creates broken ceph.conf default, it's on us.
23:46 dachary We are not going to create a puppet-ceph that is moron proof.
23:46 dalgaaf_ why not... the first mon only knows about the defaults in ceph and not about what I set myself to take place in the config
23:46 dachary no !
23:47 dachary the first mon knows the ceph.conf *you* defined
23:47 dalgaaf_ that config isn't broken only because you reset a default value to something other
23:47 dalgaaf_ ok
23:47 dachary https://review.openstack.org/#/c/56841/4/spec/system/ceph_mon_spec.rb
23:47 dachary line 31
23:48 dalgaaf_ but this is only correct if you can make sure the config is in place before you run puppet the first time on your node
23:48 dachary before ceph::mon you must ceph with the list of monitors you intent to deploy
23:48 dalgaaf_ that's why you will always need a second run ... correct?
23:50 dalgaaf_ even if you don't deploy the facter script from your ceph::mon ... which is IMO broken since this has to go into lib/facter as all other facter scripts
23:50 dachary dalgaaf_: yes, I think. My point is that you cannot possibly know for sure what a configuration variable will be ( because of the interpolation rules, metavariables, ordering of the sections and what not ) before you actually write the config file to the target host and ask ceph --show-config about it.
23:50 dalgaaf_ and would be deployed correctly before the first run
23:51 dachary would it be in lib/facter prevent a second run ?
23:51 dachary if so I'm happy to move it there.
23:51 dalgaaf_ no ... since with facter it will never until the ceph.conf is on the disk already before the first puppet run ... and this won't be possible except you scp it there
23:52 dachary right
23:52 dachary dalgaaf_: you got a point here.
23:52 dachary the reason why there is a second run is not so much the facter.
23:52 dachary it's the ceph.conf file
23:53 dalgaaf_ that's why I would tend to define these *_data parameter in ceph::param and get it from there or allow them to be overwritten by site.pp
23:53 dalgaaf_ similar to the existing implementation
23:53 dachary I would agree with you if the ceph configuration file and options were limited in number and if determining their actual value followed well documented and rarely changing rules. But we both know it's not the case.
23:53 dalgaaf_ or you have to accept the fact that you need always 2 runs
23:54 dachary dalgaaf_: you know better than anyone how tricky the configuration of ceph can be ;-)
23:54 dalgaaf_ what does the mon need to deloyed? only the auth settings and the dir to put the data on ... the rest comes from the config which is deployed in the same run
23:54 michchap joined #puppet-openstack
23:55 dalgaaf_ I know there are ~599 config parameter, but the mon itself doesn't need that many at deploy time to run in one run
23:55 dachary mon-data is the only one that is mandatory to create it
23:56 dalgaaf_ it's the mon_data. IP:port, ceph auth settings and a key
23:56 dalgaaf_ or did I miss something
23:56 dachary no you are correct
23:56 dachary that actually gives me an idea
23:57 rongze joined #puppet-openstack
23:57 dalgaaf_ only the mon_data is needed to create the correct dir the rest comes from the config or needs to be passed to the config anyway and can be retrieved from there
23:57 dachary we can live with defining in puppet-ceph the limited number of options that are necessary to deploy. And use ceph --show-config to sanity check them *afterwards* to prevent regressions.
23:57 dachary such sanity checks could be run in integration tests against newer versions
23:58 dachary or even each time it's run, if the facter is available
23:58 dalgaaf_ but wouldn't show-config show you the actual settings and not the default settings if you have a config with these parameter set?
23:59 dalgaaf_ so you are may not able to verify them ?
23:59 dachary say you ceph::mon { mon-data: /tmp } and ceph_config { globa/mon-data: /foobar } : ceph-config will raise hell on you, the second time around.

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