Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
00:00 openstackgerrit A change was merged to stackforge/puppet-nova: Revert "Removes unnecessary api-paste.ini configuration"  https://review.openstack.org/52214
00:00 ryanycoleman joined #puppet-openstack
00:05 openstackgerrit A change was merged to stackforge/puppet-openstack: Add syslog support to the openstack module  https://review.openstack.org/47530
00:05 dmsimard joined #puppet-openstack
00:08 ryanycoleman joined #puppet-openstack
00:10 ryanycoleman joined #puppet-openstack
00:12 ryanycoleman joined #puppet-openstack
00:27 ari joined #puppet-openstack
00:40 openstackgerrit A change was merged to stackforge/puppet-ceilometer: Added alarm-notifier and alarm-evaluator services  https://review.openstack.org/50699
01:08 badiane_ka joined #puppet-openstack
01:28 xingchao joined #puppet-openstack
01:54 ari_ joined #puppet-openstack
01:55 Kupo24z left #puppet-openstack
02:00 ari_ joined #puppet-openstack
02:15 michchap joined #puppet-openstack
02:45 ari_ joined #puppet-openstack
04:00 blentz joined #puppet-openstack
04:03 ryanycoleman joined #puppet-openstack
05:34 e1mer joined #puppet-openstack
06:00 dalgaaf joined #puppet-openstack
06:19 openstackgerrit Xingchao Yu proposed a change to stackforge/puppet-cinder: Add cinder::ceilometer class  https://review.openstack.org/52292
07:03 ryanycoleman joined #puppet-openstack
07:37 bauzas joined #puppet-openstack
07:53 dafter joined #puppet-openstack
08:08 derekh joined #puppet-openstack
08:26 mmagr joined #puppet-openstack
08:36 marun joined #puppet-openstack
08:50 otherwiseguy joined #puppet-openstack
09:05 Trozz joined #puppet-openstack
09:18 dafter joined #puppet-openstack
09:27 bauzas joined #puppet-openstack
09:27 e1mer joined #puppet-openstack
09:31 dafter joined #puppet-openstack
09:39 bauzas joined #puppet-openstack
09:53 dafter joined #puppet-openstack
09:57 dafter joined #puppet-openstack
10:06 tvb|afk joined #puppet-openstack
10:07 tvb|afk joined #puppet-openstack
10:26 dafter joined #puppet-openstack
10:38 openstackgerrit Florian Haas proposed a change to stackforge/puppet-heat: params.pp: correctly define client_package_name  https://review.openstack.org/52341
11:44 e1mer joined #puppet-openstack
11:54 dachary dalgaaf: hi :-) Back from lunch
11:56 dprince joined #puppet-openstack
12:20 openstackgerrit Sandro Mathys proposed a change to stackforge/puppet-nova: Configure libvirt migration on the RedHat osfamily  https://review.openstack.org/52364
12:20 openstackgerrit Florian Haas proposed a change to stackforge/puppet-neutron: params.pp: correctly define client_package_name  https://review.openstack.org/52365
12:37 red_trela joined #puppet-openstack
12:37 michchap joined #puppet-openstack
12:55 openstackgerrit Julie Pichon proposed a change to stackforge/puppet-horizon: Improve the default logging configuration  https://review.openstack.org/51222
13:27 blentz joined #puppet-openstack
13:42 mjblack joined #puppet-openstack
13:44 mjblack joined #puppet-openstack
13:44 dmsimard joined #puppet-openstack
13:58 otherwiseguy joined #puppet-openstack
14:11 red_trela left #puppet-openstack
14:17 dachary dalgaaf: your additions to https://wiki.openstack.org/wiki/​Puppet-openstack/ceph-blueprint made me realize there are different kinds of components. Someone looking at puppet-ceph for the first time wants reasonable defaults and well documented high level components such as osd or mon. Somone working on the RBD cinder backend would want ceph::conf and can be presumed to have time to read the code instead of the documentation ;-)
14:20 dalgaaf dachary: I the ceph::conf would be used from my POV to enable puppet-ceph for fine-tuning regarding several different ceph parameters. I would like to allow that, but would either make the parameter optional or/and give some good defaults (in fact I would add by default only values to these parameter which are really needed to configure ceph itself)
14:21 xingchao joined #puppet-openstack
14:23 dachary I'm with you 100%. I think better to talk directly to the mon instead of writing to ceph.conf. The mons are the storage for configuration anyway.
14:23 dafter joined #puppet-openstack
14:23 dafter joined #puppet-openstack
14:24 dachary Do you see a need for a ceph.conf that contains more than just the mon IPs ?
14:36 openstackgerrit Sandro Mathys proposed a change to stackforge/puppet-ceilometer: Change default database connection to using mongodb  https://review.openstack.org/52402
14:38 leseb joined #puppet-openstack
14:38 dmsimard dachary: Was able to poke Sebastien Han, he says he'll be joining soon
14:39 leseb here I am :)
14:39 dmsimard lol
14:39 leseb kinda busy though
14:39 leseb (middle of a meeting)
14:41 dafter joined #puppet-openstack
14:41 dafter joined #puppet-openstack
14:41 leseb dmsimard: so tell me :)
14:41 dachary dmsimard: cool
14:41 dachary leseb: hi
14:41 leseb dachary: o/
14:42 dmsimard leseb: Nothing outside of the scope of what's already in the blueprint and the puppet-openstack mailing list - aside maybe https://review.openstack.org/#/c/52215/
14:44 leseb dmsimard: I see but you were mentioning reviewers
14:46 dmsimard leseb: Yeah, maybe sometime today - bodepd_ proposed maybe posting on the mailing list to see who would be interested
14:47 leseb dmsimard: which ML?
14:48 dmsimard leseb: https://groups.google.com/a/puppetlab​s.com/forum/#!forum/puppet-openstack
14:49 leseb dmsimard: on this thread? https://groups.google.com/a/puppetlabs.com/forum​/#!msg/puppet-openstack/ibnrmXBAxVg/Y3Z3e6sZoa4J
14:50 dmsimard leseb: Maybe, haven't talked about this with mgagne or bodepd_ yet today
14:51 leseb dmsimard: oh ok, ping me again when the time comes then :)
14:51 dmsimard leseb: *nod*
14:51 leseb dachary: good initiative btw :)
14:52 dachary :-)
14:53 dmsimard dachary: You mentioned talking to sage yesterday about mirroring the repo back to the ceph namespace ?
14:54 dachary dmsimard: yes, he agreed and dalgaaf will do it ( he has permissions to create repositories in the ceph namespace )
14:54 dmsimard dachary: Awesome.
14:57 badiane_ka joined #puppet-openstack
15:00 ryanycoleman joined #puppet-openstack
15:01 dachary dalgaaf: regarding my previous question "Do you see a need for a ceph.conf that contains more than just the mon IPs ? ". I think the answer is : yes, for all things that are not in the mon, such as the location of the log files and such.
15:02 openstackgerrit Julie Pichon proposed a change to stackforge/puppet-horizon: Improve the default logging configuration  https://review.openstack.org/51222
15:08 dachary dalgaaf: strike that, my question does not make much sense I'm afraid.
15:12 ryanycoleman joined #puppet-openstack
15:23 dachary dalgaaf: I moved back conf to puppet user facing components https://wiki.openstack.org/wiki/Pu​ppet-openstack/ceph-blueprint#conf
15:39 dmsimard dachary: so ceph::osd and the other components would be responsible for doing their own configurations as well ?
15:41 dachary dmsimard: say you want to set the backfill scan max of your osd, then yes it would make sense for this to be an argument of ceph::osd that translates into a line in the corresponding [osd.name] stanza.
15:43 ryanycoleman joined #puppet-openstack
15:43 dmsimard dachary: so ceph::conf would only take care of the common options then? (e.g, networks, cluster id..)
15:44 dachary ceph::conf should probably not restrict anything. Only ceph::osd would make use of ceph::conf to set the parameter right  if required, and take care of restarting the osd to take it into account. Does that seem sensible to you ?
15:44 dachary or
15:47 dachary I don't know. I tend to think that it's easier when configuring an osd to think : what parameters can it have ? And look a the list of arguments. And change them. It is less intuitive to require a thinking like : are there configuration values I can use to change the behavior of the osd in addition to the arguments ? How can I find the list ? Oh, I found it, what's the name of the stanza that matches the name of the osd I want to configure
15:47 dachary Oh I made a typo and fixed it etc. ;-)
15:48 dmsimard I believe ceph::osd should call ceph::conf to do stuff but the parameters are passed to ceph::osd
15:48 dmsimard Like you said, I guess
15:50 mkoderer joined #puppet-openstack
15:50 ryanycol_ joined #puppet-openstack
15:54 * dachary browsing all http://ceph.com/docs/master/rados/configuration/
15:55 dmsimard Do we have a general strategy for building the module from scratch ? (Start with a skeleton, etc.)
15:56 badiane_ka joined #puppet-openstack
15:57 dmsimard I have a continuous integration setup built with existing module/recipe, should be fairly easy for me to test things.
15:57 tnoor1 joined #puppet-openstack
15:57 badiane_ka joined #puppet-openstack
15:58 mkoderer bodepd_: danny told me that you wanted to talk about puppet-ceph, is the meeting here or in #openstack-meeting?
16:00 dachary mkoderer: hi
16:00 mkoderer dachary: hi
16:00 tnoor2 joined #puppet-openstack
16:00 mkoderer I am the one that did the radosgw implementation for telekomcloud
16:00 dachary to my knowledge there is no meeting planned but ... we have plans to discuss it with bodepd_
16:00 mkoderer ok cool
16:00 dmsimard dachary: re: ceph::cephfs on the wiki
16:01 dmsimard dachary: I think it's necessary, for the sake of consistency - it would be simple, yes (just a mount resource) but have ceph::msd as a dependency, for example
16:01 dmsimard s/msd/mds/
16:01 dachary mkoderer: your expertise would be most welcome here https://wiki.openstack.org/wiki/Puppet-op​enstack/ceph-blueprint#RadosGW_components :-)
16:02 dmsimard be back in a bit, going out for lunch
16:02 dachary dmsimard: that makes sense to me :-)
16:03 dalgaaf about the ceph::conf: I would prefer to collect there all global parameters to prevent to set them again and again for each OSD for example ... in this case you may need onyl one or two parameters for setup an osd (e.g. only the path to the /dev device)
16:05 dafter joined #puppet-openstack
16:05 dafter joined #puppet-openstack
16:06 dafter joined #puppet-openstack
16:08 dalgaaf dachary: what do you mean with krbd? Does this mean the kernel rbd interface?
16:09 dachary yes
16:12 dachary to get something working and bootstrap the work, I think the mon component would be a good candidate. Without ceph::conf or ceph::key even. It does something actually useful and we can build on that.
16:14 dachary since there is no ceph::conf it would only be able to bootstrap the first mon and not the others :-) But that's the first step for any ceph cluster anyway.
16:14 dachary as bodepd_ would say : one class at a time :-)
16:20 ryanycoleman joined #puppet-openstack
16:20 dalgaaf But you have stuff you need to define in the global section for that and I wouldn't do that via the mon code ... add a basic concat template to write these global stuff needed by the MONs via a config class and each mon then would add his config parts to that.
16:21 dalgaaf or do you plan to work without any config files (not sure if this is possible)?
16:21 ryanycoleman joined #puppet-openstack
16:24 dachary using config files is problematic to update running daemons. We can probably get away with having no [mon][osd][mds] config sections at all if the puppet modules rely on injectargs
16:24 dachary dalgaaf: do you see what I mean ?
16:25 dachary hum
16:25 dachary what if an osd is down at this time
16:26 dachary write the config file + injectargs then :-)
16:26 dalgaaf but the command line tools and startscripts in the system depend on these config files to e.g. shutdown a node from cmd
16:26 marun joined #puppet-openstack
16:27 mkoderer which ceph version introduces the rest-api?
16:28 dachary mkoderer: I don't remember, not before cuttlefish though, that's for sure
16:29 bcrochet joined #puppet-openstack
16:29 dalgaaf It was added Wed Jul 10 17:39:47
16:29 dalgaaf this year
16:30 dalgaaf so if we depend on it we would target dumpling ... that would be a nogo for me ... we need to support cuttlefish too
16:30 ari joined #puppet-openstack
16:30 dachary dalgaaf: I can live with that.
16:31 mkoderer we don't :)
16:31 dachary dalgaaf: I mean I can live with the fact that we don't use rest-api ;-)
16:31 dachary mkoderer: ^
16:32 dachary the burden of running an additional daemon is probably not worth the benefit
16:32 dalgaaf okay ... we could add that later  .. .after implementing a basic verstion
16:32 dachary cli + rest API are on par, I'm not worried. dalgaaf would you like to update the blueprint with this conclusion ?
16:32 dalgaaf do you know what happens with the injected settings if the cluster gets restartet?
16:34 dachary dalgaaf: I should check to be sure but I think it's just stored in the osd/mon/mds metadata storage
16:34 mkoderer dachary: what's par?
16:34 dachary mkoderer: I mean that the same code is use to implement the rest & cli functions therefore there is no deviation between them
16:35 dachary https://github.com/ceph/ceph/bl​ob/master/src/mon/MonCommands.h
16:35 dalgaaf you mean in ceph itself
16:35 dalgaaf okay
16:37 dachary dalgaaf: what do you think about writing the conf + injectargs ? I think it captures all we will ever need.
16:37 dalgaaf Only for understanding: do you think it makes really sense to use puppet to configure a RestAPI?
16:38 mkoderer dachary: any idea about the puppet version that you want to support? 3.x? I guess we will have trouble with 2.7 without exported resources
16:38 dalgaaf where do you want to call the injectarg commands?
16:38 dalgaaf on which machine?
16:38 dachary on the puppetmaster, using the IP of a mon.
16:39 dalgaaf uuhh ... the puppetmaster may have no connection to any mon (especially to the MON puplic address from the security point of view)
16:40 dmsimard Hi, I'm back
16:40 bcrochet joined #puppet-openstack
16:41 dachary if the puppetmaster does not have the admin key and be able to talk to the mon, I think it will make things more difficult. What do you suggest ?
16:41 dmsimard dalgaaf: I think someone (was it bodepd_ ?) said we should try to get everything working without resorting to stored configs
16:41 dalgaaf Since we are strongly focused in our setup on security we have no such connection and wouldn't really place the mon key there since we use puppet-secret for that
16:41 dmsimard dalgaaf: referring here to the concat of config with templates
16:42 dachary interesting
16:42 dalgaaf I would always need the config to be able to manage the cluster for OPS also from the command line
16:43 dmsimard If my experience is relevant at all, I've used TelekomCloud's version of puppet-ceph under puppet 3.3.1 and dumpling
16:43 mkoderer for a security POV a puppetmaster is already somehow evil, but with ceph keys its worse
16:43 dachary where would the admin key be used then dalgaaf ?
16:43 dachary which machines has the admin rights to the ceph cluster ?
16:44 dalgaaf in the current setup the key is only exposed to those ceph components which need them to setup itself ... MON, OSD ...
16:44 dalgaaf the mons have the full right to admin the culter
16:44 dalgaaf cluster
16:44 mkoderer and for openstack cinder and glance machines
16:44 dalgaaf via their own keys
16:44 mkoderer yes they don't need admin keys
16:45 dalgaaf the same for radosgw
16:45 dachary ok, so inject args and other admin things such as creating the keys would need to happen on the mons, right ?
16:45 dalgaaf since radosgw is in fact also only a client to ceph
16:45 dalgaaf yes
16:46 dalgaaf I mean you could also add some kind of config node to make calls to the cluster, but this would add more complexity
16:46 dachary with this constraint, there is no way around using exported resources, is there ?
16:47 dalgaaf I don't use any exported resources if I remember correctly ... but I have to check
16:48 dalgaaf maybe only for concat the stuff to the shared config parts ... but for that I would have to check the concat module
16:48 dachary if you create a key on the mon machine, how do it end up on the osd machine if not with exported resources ?
16:48 dachary s/do it/does it/
16:48 * dachary may be missing something
16:49 dalgaaf by giving the key via the site.pp or via share them via puppet-secret currently which is puppet module developed by us but on github
16:49 dalgaaf s/key/secret/
16:50 dalgaaf or we could may use keystone?
16:50 dalgaaf but this would be openstack specific
16:50 dachary what does puppet-secret do ?
16:51 dachary it's a store that is outside of puppetmaster and contains secrets ?
16:51 mkoderer https://github.com/TelekomCloud/puppet-secret
16:52 dalgaaf yes ... AFAIK
16:52 dalgaaf IIRC it runs on the puppet master but keeps the keys crypted somewhere
16:53 dachary ok
16:53 dalgaaf but you could simply add the secret to the site.pp and since the machine has no access to the ceph network you reduce the security problem here
16:54 ryanycoleman joined #puppet-openstack
16:54 dachary the key point here is that it requires to deviate from a setup where the information flows from the puppetmaster to the nodes
16:54 hogepodge joined #puppet-openstack
16:55 ryanycoleman joined #puppet-openstack
16:55 dachary It's a valid concern though
16:55 dachary dalgaaf: would you like to articulate this in the blueprint ? We need bodepd_ input on how to address this.
16:55 dalgaaf but this is how it works currently ... the config option and puppet scripts come from the puppetmaster
16:56 dalgaaf or do you want some other way?
16:56 dachary dalgaaf: yes but the secret goes to the puppet-secret and then the osd needs to retrieve it. It's information flowing from the mon to the osd.
16:57 dalgaaf not really ... the secret comes from puppet-secret and would be distributed from the puppetmaster to the nodes needing the secret
16:58 dachary puppetmaster asks the mon to create a key => the key is uploaded to puppet-secret => the puppetmaster asks the osd to use the key.
16:58 dachary or am I missing something ?
16:59 dalgaaf no the puppet-secret generates a ceph key and provide this key to puppetmaster to be used in the site.pp to provide that to e.g. the MONs
16:59 dalgaaf it's kind of preshare keys via site.pp
16:59 dachary ah !
16:59 dachary I missed this part
17:00 dalgaaf no need to generate the key on the ceph components except for the osd secrets which are generated by ceph itself ...  we don't need to manage them I think
17:00 dachary now I get it :-)
17:00 prad joined #puppet-openstack
17:00 dalgaaf the problem to generate the key on the first MON and share it was the biggest problem with the existing puppet-ceph module from enovance
17:01 dachary yes
17:01 dalgaaf this leaded to ordering and not really good dependencies betwen the mons and other components
17:02 dalgaaf the current code need only one run for the MONs (all in parallel) and the radosgw
17:02 dachary sorry if it takes time to digest, it's a clever solution
17:02 dalgaaf and two runs for the OSD nodes, but we could also fix that I guess
17:02 dalgaaf ;-)
17:03 dalgaaf On the OSDs it's currently only an issue to get the OSD id from the commands back to write the config and may create the dirs but this could be improved
17:03 dachary is there a page that explains the workflow requiring these runs ?
17:03 dalgaaf unfortunatly not but I could add or send you an example site.pp
17:04 dalgaaf which would explain it
17:04 dachary sure
17:04 mkoderer I think we need to improve the documentation ;)
17:08 ari joined #puppet-openstack
17:08 dalgaaf https://github.com/TelekomCloud/puppet-ceph/​blob/rc/eisbrecher/examples/example-site.pp
17:08 dprince joined #puppet-openstack
17:09 dmsimard dalgaaf: I've seen that somewhere before :)
17:09 dalgaaf ;-)
17:10 dmsimard I can provide my site.pp too which works slightly differently and without puppet-secret
17:10 dachary for the sake of KISS, puppet-ceph should handle both situations : take advantage of a direct connection to the mons if possible or rely on puppet-secret if not. For the vast majority of people the first would be ok, for tests and POCS etc. The trick is to architecture it in a way that is natural to fit both.
17:11 dachary Do you see what I mean ?
17:11 * dachary browsing https://github.com/TelekomCloud/puppet-ceph/​blob/rc/eisbrecher/examples/example-site.pp
17:12 dmsimard dachary: I don't use puppet-secret (keys are stored on the puppet master in hiera config files) - the puppet agents (cluster nodes) have access to the puppetmaster but not the other way around (network security stuff)
17:12 dmsimard I probably missed something where the puppetmaster would need to access the nodes
17:13 mkoderer dmsimard: could you paste your site.pp somewhere?
17:13 dalgaaf correct ... the connection betwenn the MONs and the puppetmaster is on a management network and the ceph networks are separated from that for secruity
17:13 ryanycoleman joined #puppet-openstack
17:13 dachary dmsimard: the whole discussion is about this precisely.
17:14 dalgaaf so you can't connect the puppet master to the ceph network to inject
17:14 dachary ok, I'll try to write that down in a sensible way for bodepd_ to give his expert opinion
17:14 dmsimard mkoderer: sure, just a sec
17:14 dalgaaf in our setup it's the same for all other openstack components
17:15 dalgaaf no connection to the APIs via puppetmaster
17:15 xingchao joined #puppet-openstack
17:15 mkoderer for me both design concepts are totally different. So this will cause forked code if you want to support boths ways
17:15 ryanycoleman joined #puppet-openstack
17:16 dalgaaf or a lot of bad if/else
17:17 seiflotfy joined #puppet-openstack
17:17 dalgaaf IMO the admins are free to configure the cluster also via cmd or injectargs or a RestAPI
17:18 dmsimard mkoderer: this is my site.pp: http://paste.openstack.org/show/48653/ - i'll paste relevant bits in another paste for clarity
17:18 dachary dalgaaf: how do you suggest an existing OSD is updated when its configuration changes ?
17:18 ryanycol_ joined #puppet-openstack
17:18 mkoderer dmsimard: ok thx
17:19 * dachary going back home and think. bbl.
17:20 dalgaaf hm ... is there any reason to reconfigure the running cluster?
17:20 dalgaaf via puppet I mean?
17:20 seiflotfy good point
17:20 dmsimard mkoderer: this is the other relevant bit: http://paste.openstack.org/show/48654/
17:21 dalgaaf currently a change on the config side would may lead to restart the ceph components ... I know that's may not optimal
17:21 dalgaaf need to think about that
17:21 mkoderer dmsimard: you are using hiera to store the secrets, I have to have a closer look to that
17:21 dmsimard mkoderer: It's a bit messy, I need to do some cleanup but that is the gist of it
17:21 dachary puppet-ceph is designed to leverage all ceph can do. I think deciding dynamic reconfiguration of the cluster is not going to be possible by design is against this goal.
17:22 dachary that's what ceph-deploy is for ( limited use case / flexibility )
17:22 dalgaaf but IMO you can't reconfigure everything dynamicly
17:23 dalgaaf there are some parts like paths or may also journal size (not sure) which needs a restart of components
17:23 seiflotfy dachary: but you will end up needing to purge all config, set up new one and then restart the ceph components, to support dynamic configuration ==> not so dynamic after all
17:24 dalgaaf we could think about a ceph::inject class which would run on a MON and would inject something and change the configs ... it's a bit messy but would may be a way ...
17:24 seiflotfy is there a puppet-ceph solution that is already dynamic?
17:24 dalgaaf currently I've never changed a running ceph cluster in production without downtime anyway
17:24 mkoderer maybe we should define the use cases where we want to support dynamic changes?
17:25 dalgaaf the ceph::pool class for example allows dynamic changes to the cluster ... but these are not part of the config anyway
17:26 seiflotfy +1, you cant support 100% dynamic configuration, why not take the best existing solution and iterate over it
17:26 bodepd_ mkoderer: I think I'm going to be on the side-lines for this one. I'm happy to help with the Puppet bits, and getting merge rights approved, other than that, it sounds like things are moving along nicely
17:27 dalgaaf do you see any specific usecase except changing e.g. inject config options or log options into the cluster?
17:27 dalgaaf I have to think about that since I'm not sure if there is a usecase in an enterprise env
17:28 bodepd_ dalgaaf: I would much prefer we use something like: inifile instead of dealing with concat templates
17:28 dalgaaf for dynamic config changes
17:29 dalgaaf you mean some kind of puppet module for inifiles?
17:29 dmsimard dalgaaf: https://github.com/puppetlabs/puppetlabs-inifile
17:30 bodepd_ dmsimard: the specific thing I don't like about storeconfigs is that it creates a separaion issue of having orcheatrate Puppet runs
17:30 mkoderer what it the drawback of concat templates?
17:30 mkoderer bodepd_: ^
17:30 bodepd_ dmsimard: dealing with everything as data is easier, but maybe be a bit more advanced usage for Puppet
17:33 bodepd_ dalgaaf: all of the openstack components use it
17:33 bodepd_ mkoderer:  I think the implementation is messy
17:34 bodepd_ advantages of inifile over concet
17:34 dalgaaf hm ... i never used inifile ... I had no bad provlems with concat so far for ceph
17:35 bodepd_ 1. from a puppet model perspective it is much cleaner
17:35 bodepd_ ceph_conf verbose changed from true -> false
17:35 bodepd_ as opposed to updating a tmp file before running cat
17:35 bodepd_ 2. it can support features like purging
17:35 bodepd_ 3. it can work with puppet resource from the command line
17:35 bodepd_ I'll give you some example links:
17:36 mkoderer bodepd_: ok great I will have a closer look to it :)
17:36 bodepd_ https://github.com/stackforge/puppet-​nova/blob/master/manifests/api.pp#L70
17:37 bodepd_ all of the configuration for the openstack modules looks like this
17:37 bodepd_ the implementation is easy, although a little repetitive
17:37 dmsimard bodepd_: I was trying to find exactly how nova_config was implemented but could not find it
17:37 bodepd_ https://github.com/stackforge/puppet-nova/​blob/master/lib/puppet/type/nova_config.rb
17:38 dalgaaf do you have an example how the config looks then?
17:38 bodepd_ https://github.com/stackforge/puppet-nova/blob/mas​ter/lib/puppet/provider/nova_config/ini_setting.rb
17:38 bodepd_ basically, it's just sections and key=value pairs
17:39 bodepd_ inifile is smart enough to try to place configs where they already exist in a file
17:39 bodepd_ and I think it's smart enough to try to place them under a commented our version of themselves
17:39 bodepd_ s/our/out/
17:39 bodepd_ two disadvantages over concat:
17:39 dalgaaf what about indentation and comments if you generate a config from scratch?
17:39 bodepd_ 1. you have to define things one at a time
17:40 bodepd_ dalgaaf: that is the disadvantage
17:40 mkoderer but the key/values are unsorted, right?
17:40 bodepd_ mkoderer: that is the other disadvantage
17:40 bodepd_ you could use require/before to sort them, but only on write
17:40 dmsimard dalgaaf: Snippet from a nova.conf built with nova_config http://paste.openstack.org/show/48655/
17:41 bodepd_ they support purging,so you coudl specify, that only the defined entried should exist
17:41 bodepd_ but in general, I use them to modify entries inline
17:41 dalgaaf you mean purge config values/params ?
17:42 bodepd_ purge in Pupet's lex means, that only what you define can be in the config file
17:42 bodepd_ (ie: what you defined as resources) everything else is deleted
17:44 dalgaaf but IMO this is also how concat works ... manual changes are purged?
17:44 mkoderer k gents, I will leave for today.
17:44 bodepd_ yep
17:45 dalgaaf so it's the same for concat and inifiles
17:45 bodepd_ yeah, for some reason, I was thinking concat didn't do that
17:46 dalgaaf and does it support sharing parts of the config between nodes?
17:46 dalgaaf concat does
17:47 dalgaaf at the moment we write the entire config from scratch via concat templates
17:49 dalgaaf and I had no real problems with it ... but I will take a look at the inifile module to get a picture
17:51 dalgaaf I will leave for luch ... will be back later and will write down what we discussed so far to the blueprint
17:51 dalgaaf s/luch/dinner/
17:53 ryanycoleman joined #puppet-openstack
17:56 badiane_ka joined #puppet-openstack
18:01 dmsimard dalgaaf: Maybe resorting to inifile instead of concat with templates would make it more simple
18:02 dmsimard dalgaaf: sharing parts of the config relies on stored configs
18:03 hogepodge joined #puppet-openstack
18:04 dmsimard dalgaaf: I don't personally know how we could do it without stored configurations, though.
18:05 ryanycoleman joined #puppet-openstack
18:09 ryanycoleman joined #puppet-openstack
18:10 bodepd_ dmsimard: pass them in as class parameters
18:11 bodepd_ dmsimard: I'm interested to see that part come together
18:11 mmagr joined #puppet-openstack
18:11 dmsimard but as puppet runs, you may have to pass parameters that are not yet known - this is the part where I'm a bit confused
18:12 bodepd_ I'm kind of a storeconfigs hater
18:12 bodepd_ so I may not be the best person for this :)
18:12 bodepd_ we use it for swift disk definitions
18:12 bodepd_ atm in the openstack code
18:12 dmsimard It's understandable, I guess if it can be avoided it should be as it adds a certain complexity
18:13 bodepd_ yes
18:13 bodepd_ and it also couples how data gets to nodes with a specific implementation
18:13 bodepd_ ie: run puppet here, then run it here
18:13 bodepd_ I much prefer a model of : everything is a class parameter
18:13 dmsimard But then how would the puppetmaster be "aware" of the different nodes of the cluster ?
18:13 bodepd_ https://github.com/dalen/puppet-puppetdbquery
18:13 bodepd_ getting to that :)
18:14 bodepd_ the problem is that this is a bit on the bleeding edge for Puppet
18:14 bodepd_ bacically, a hiera syntax that says: query puppetdb
18:14 bodepd_ you could even have rules so that part is optional
18:15 bodepd_ the easiest model is just to know your ip addresses ahead of time
18:15 bodepd_ and that could be viewed as no-automated-enough
18:15 bodepd_ or dns :)
18:16 bodepd_ when the openstack modules started, there was tons of exported resources
18:16 bodepd_ over time, everythign except swift disk has been removed
18:16 bodepd_ (or at least made optional)
18:17 dmsimard I'll have to do some reading
18:19 dmsimard Right now I'm relying on facters such as $::ipaddress_eth0 so I don't have to worry about that part - but I can see where you're going
18:19 bodepd_ It sounded like Loic said that as long as everyone can find the mon server, they can query that for everything they need
18:19 dmsimard Yes, that could be a way
18:20 bodepd_ dmsimard: in our testing environment, we boot VMs against an openstack API endpoint, and then use their ip addresses to populate our hiera data
18:21 dmsimard Interesting way of doing it
18:23 dmsimard We leverage vagrant, vagrant-openstack-plugin (openstack provider) and openstack for our continuous integration, but have crafted modules and recipes in a way where we don't need to know details ahead of time
18:41 ryanycoleman joined #puppet-openstack
18:46 * dachary reading the backlog
18:49 bodepd_ dmsimard: interesting. I am still using vagrant/VBox for testing, but we wanted to move our testing against the openstack API endpoint
18:49 bodepd_ dmsimard: I actually worked with the iweb fork of the vagrant-plugin
18:50 dmsimard Yup, that would be our work :)
18:50 bodepd_ dmsimard: and would have implemented it using that, but the decision was made to do it in a way that would better migrate to Heat
18:50 bodepd_ dmsimard: I've mainly been focused on a data-layer for specifying multiple reference architectures for testing
18:51 bodepd_ I saw folks were asking about REST vs. CLI
18:51 * dachary thinking about what should be done to interact with the mon for configuration purposes. The mon is the only authority to create osd : they give back the osd number.
18:51 bodepd_ we find that there are not guarentees about backwards compat with CLI in openstack
18:51 bodepd_ in generaly versioned APIs only exist with RESTFUL interfaces
18:52 bodepd_ which make them the preferred way of doing things
18:52 bodepd_ but, since our puppet-openstack crowd is more sysadminy
18:52 bodepd_ they are more comfortable implementing providers that wrap CLI commands
18:52 dmsimard dachary: The idea is to configure the first monitor node and then poke it to get information populated for other servers instead of using storedconfigs
18:53 bodepd_ dmsimard: dachary if that is sane, I'm all about it :)
18:53 bodepd_ the fewer cross node dependencies, the better
18:55 dachary dmsimard: poke it how ?
18:55 dachary poke it from the puppetmaster ?
18:56 dachary dmsimard: https://github.com/TelekomCloud/puppet-ceph/bl​ob/rc/eisbrecher/examples/example-site.pp#L12
18:56 dmsimard I'm throwing an idea here because I personally have no clue how we would achieve this.. but maybe a custom fact on the nodes ?
18:57 dmsimard I don't like the idea of the puppetmaster communicating towards the cluster
18:57 dmsimard A custom fact on an OSD/MON could communicate with a pre-defined monitor to retrieve information
18:58 dachary bodepd_: would custom facts be a sane idea ?
18:59 dachary to share information between nodes ?
18:59 dachary the only reason we would need this is if the puppetmaster is *forbiden* to talk to the mons
18:59 dachary if it was... there would not be this problem
19:00 dmsimard You would need to install the ceph packages on the puppetmaster in order to be able to do that ?
19:00 dmsimard And provide a ceph.conf ?&
19:00 dachary and it looks like telekom is not going to be the only context in which the puppetmaster is not allowed to discuss with the mon ... although it has the power to *destroy* them entirely ;-)
19:01 dachary dmsimard: yes
19:01 dmsimard dachary: I don't like the idea :(
19:02 dmsimard Maybe it's just the way we do things, but our puppetmasters cannot talk to our nodes either - it's the other way around
19:02 dachary from the point of view of logic, the puppetmaster has ultimate power over the ceph cluster. It creates it and can destroy it. I don't see why, even from the point of view of security, it would be required to restrict access to the mon. However, I acknowledge that people partitioning the network have made decisions that cannot be undone.
19:02 badiane_ka joined #puppet-openstack
19:03 dmsimard dachary: It's about good network security practices, if it doesn't need access, it doesn't have it
19:03 dmsimard dachary: We start with everything closed and locked down and open things if need be
19:03 dmsimard be back in a bit, meeting
19:04 dachary having access would make things way easy
19:04 dachary no brainer
19:04 dmsimard Got to make sure we do something that works regardless of network context though
19:04 dachary but again, dmsimard I don't dispute the need. Even if *you* would relax this, others won't have the option.
19:06 dachary bodepd_: how do you think we should solve this ?
19:07 dachary one way or the other, the puppetmaster will need to acquire information from the mon. If it can't be by talking directly to them ( which is technically possible as soon as one mon is up ), what are the options ?
19:08 dachary creating an osd implies calling "ceph create osd" that will return an osd id that only the mon can provide. All osd configuration after that can be done without resorting to the mons.
19:10 dachary one option would be that the puppetmaster has a ceph admin key and uses it to interact with the mon from the target node each time it needs it.
19:11 dachary the admin key will constantly go from puppetmaster to puppet client which is a little hazardous but does not violate any network policy
19:11 dachary to create an osd
19:12 dachary run the following sequence on the machine that needs the osd installed:
19:12 dachary a) setup ceph.conf with the mon IPs
19:12 dachary b) install the admin key
19:12 dachary c) run ceph osd create to retrieve the osd number + configure it
19:12 dachary d) remove the admin key
19:12 dachary e) complete the osd setup + run it
19:13 dachary no back and forth
19:14 dachary the admin key is a kind of sudo ;-)
19:14 dachary dmsimard: what do you think ?
19:16 bodepd_ dachary: why could the ndoes themselves not contact the mon servert?
19:17 dachary bodepd_: that's what I'm suggesting. They can contact the mons but they normaly don't normaly have admin permisions.
19:17 bodepd_ I don't really like the id of the puppetmaster contacting the mon server
19:17 bodepd_ dachary: what information needs to be shared?
19:17 dachary the admin key
19:17 bodepd_ dachary: perhaps we can just docuement that in the blueprint wiki?
19:18 bodepd_ why does every node need the admin key?
19:18 dachary they don't need the admin key for normal operations
19:18 dachary just to create themselves
19:18 bodepd_ it is secure to leave the key there?
19:18 bodepd_ and how does the key get created?
19:19 dachary there == puppetmaster ?
19:19 bodepd_ there == osd server
19:19 dachary I think it should not stay on the osd server, just be set temporarily when an admin operation is required
19:20 bodepd_ who controls when it is available? and how could you prevent a root user from not getting access to it?
19:21 beddari joined #puppet-openstack
19:21 bodepd_ perhaps it makes senes just to document what the data-sharing requirements are
19:21 dachary there is no way you can prevent a root user on the osd to get access to it when it is installed
19:21 bodepd_ I don't have enough context to be useful atm
19:21 dachary the admin key is the root password of the ceph cluster
19:21 bodepd_ I mean that even if we setup some process where the key was delivered just for initial node configuration
19:21 dachary it is created during the bootstrap process
19:21 dachary of the first mon
19:21 bodepd_ what is the bootstrap process?
19:22 bodepd_ is it possible to feed a key into that mon?
19:22 bodepd_ or does the mon have to generate it?
19:22 dachary let me check this chicken and egg problem :-)
19:23 * dachary reading http://ceph.com/docs/next/dev/mon-bootstrap/ & ceph-deploy code
19:24 dachary bodepd_: it is fed to the mon, not obtained from it
19:25 dachary the puppetmaster can create the key and setup the first mon to use it
19:25 dachary it can then deliver the key for temporary use to the osd as well as the IP of the mon so that it can create itself by talking to the mon
19:25 dachary bodepd_: does that make sense ?
19:25 bodepd_ for the sake of simplicity, I would pre-generate the key from the puppetmaster and have it fed to all of the nodes so they can communicate
19:26 dachary that would make it easy indeed
19:26 dachary if it is acceptable from a security point of view
19:26 bodepd_ I'm sure there are security concners about that
19:27 dachary if security mandates that a OSD *never* receives, even temporarily, the admin key ... then it's not a viable solution
19:28 bodepd_ if you can't pre-populate the key, then does that kill the whole idea of osd node's being able to configure themselves?
19:28 dachary pretty much
19:28 bodepd_ that is probably why people are looking at ceph-deploy
19:29 dachary ceph-deploy is even worse : it requires password less ssh + sudo rights on each machine it is targeting ;-)
19:29 bodepd_ so that it can centrally provision the osd's from the mon server? (or a server who has rights to ssh into the osds)
19:29 bodepd_ except he security implication may be different
19:30 bodepd_ that it is more reasonable for a mon to be able to ssh into an osd server
19:30 dachary oh, I see
19:30 dachary you're right
19:30 bodepd_ I guess I can see why people did not like the other approach, it's probably very swift-like
19:31 bodepd_ -install the volume hosts (so that they can centrally provide disk info)
19:31 bodepd_ - configure those volumes on the mon
19:31 bodepd_ - reconfigure the volumes with info from the mon
19:31 bodepd_ which requires 3 puppet runs in a certain order with storeconfigs?
19:32 dachary yes
19:32 bodepd_ where every additional volume manager requires all 3 of those runs
19:32 bodepd_ this is probably a good question for the cep developers if they are around
19:32 bodepd_ can you document all of the data sharing requirements?
19:32 bodepd_ I have a feeling this is the basic of why people can't agree
19:33 dachary ok
19:33 bodepd_ that is probably what we want to present to the ceph team:
19:33 bodepd_ 1. we want to be able to add osd's with a single run and without cross host interactions
19:33 bodepd_ 2. this is why people are using ceph-deploy and here is how
19:34 bodepd_ I'm kind of guessing that is what is going on here with very little data, so perhaps if it was documented, people could come to an agreement
19:35 dachary One additional question:
19:35 bodepd_ mgagne: pabelanger says you weere wrong about not needing an upstream
19:35 mgagne bodepd_: doc is wrong then :D
19:36 bodepd_ mgagne: can you give me the link?
19:36 mgagne bodepd_: http://ci.openstack.org/stackforge​.html#add-a-project-to-stackforge
19:36 pabelanger bodepd_, mgagne: are you expecting the repo in stackforge to be created?
19:36 pabelanger or imported
19:36 bodepd_ pabelanger: created
19:37 pabelanger okay, then my comments relate to import
19:37 pabelanger and can be ignored
19:37 mgagne "The description [...] and the upstream [...]. Both of these are optional."
19:37 bodepd_ pabelanger: thanks!
19:37 pabelanger will update review
19:38 dachary ceph-deploy does not require the osd to talk to the mon because ceph-deploy talks to the mon and communicates the result to the osd ( the osd number ). Forbiding the puppetmaster from interacting with the mon is the core difference with ceph-deploy. Why is it a bad idea for the puppetmaster to talk the mon ?
19:40 bodepd_ dachary: from my perspective it is unclear where it fits in to the overall process.
19:40 bodepd_ dachary: perhaps with a custom puppet function? That would work.
19:40 bodepd_ dachary: I just wish I had some precedence of what projects already do this. I may take it to the puppet users list to see if people have thoughts
19:41 dachary I think I have enough to write the mail to the ceph-devel list
19:41 dalgaaf dachary: back ... any questions?
19:42 dalgaaf maybe I can give you some information
19:42 bodepd_ dachary: scroll up?
19:42 bodepd_ dalgaaf: scroll up?
19:42 dachary bodepd_: could you remind me what garantees the precedence of the operations to create a mysql user before a cinder host needs it although the database is on a different node ?
19:42 bodepd_ sorry dachary too many lettter in commonfor my autocomplete skills
19:42 dachary dalgaaf: :-)
19:42 dachary bodepd_: :-)
19:43 bodepd_ dachary: right now, this problem is pushed out to the end user
19:43 dmsimard I'm back, reading backlog
19:43 dachary bodepd_: how do you mean ?
19:43 dalgaaf what we currently do: we preshare the admin secret via the site.pp to the hosts
19:44 bodepd_ dachary: 2 separete questions
19:44 bodepd_ dachary: or 2 answers
19:44 bodepd_ dachary: if they are on different hosts, then it is up to the user to run puppet in the right order
19:44 dachary ok, that answers the question
19:44 bodepd_ dachary: if they are on the same host, you can set conditional dependencies using resource collection
19:44 bodepd_ dachary: I know how I want this to be solved eventually
19:45 bodepd_ dachary: but havent had time to finsh it
19:45 dachary dalgaaf: the admin secret key is sent to all hosts ? including osds ? or do you mean the mon hosts ?
19:46 bodepd_ dalgaaf: that is what I was saying I would recommend, but we weren't sure if it is again security policies
19:46 dalgaaf first they are shared to the MON so that they are able to startup in parallel
19:47 bodepd_ dachary: I think this would be the best way to coordinate resource events across hosts: https://github.com/cprice404​/puppet-connection-validator
19:47 bodepd_ I worked with chris on the concept, but never had time to implement it
19:47 dalgaaf then the secret get also shared to e.g. the OSDs to be able to setup themself based on what disks should be setup ... the osds needs currently 2 runs to come up, but this is planed to resolved ...the problem was to get  the osd id from the creation process back to be added to the config
19:47 dachary bodepd_: ok, thanks
19:48 bodepd_ why does it need 2 runs?
19:48 dalgaaf From our security team it's not a problem ... but i guess it depends on your general security concept for your cluster
19:48 bodepd_ b/c it exports somethign that is collected by the mon servert?
19:48 dachary dalgaaf: cool, thanks
19:48 bodepd_ dalgaaf: ^^^
19:49 dalgaaf bodepd_: they need 2 runs because they call a ceph command which returns the id of the osd ... and we need this id to write the config for this node (we need the config for administration on cmdline tool)
19:49 bodepd_ dalgaaf: I know how to solve that :)
19:50 dalgaaf but I guess this could be solved via a provider which would get the information i guess
19:50 bodepd_ dalgaaf: exactly
19:50 bodepd_ dalgaaf: there are a few examples of this in the openstack code
19:50 dalgaaf I had no time yes to add this step
19:50 dalgaaf yet
19:50 dalgaaf but I planed to do it ...
19:50 bodepd_ dalgaaf: I would be happy to help you understand how to do it. I've done this a few times already
19:51 bodepd_ dalgaaf: excuse me if I don't properly understand your Puppet skill level, but passing uuids between providers is super-advanced stuff :)
19:51 dalgaaf after the MONS you simply start all OSDs (finally in one run) and then for example the radosgw (which depends on the OSDs to setup itself)
19:51 bodepd_ dalgaaf: I'm happy to help with those specific bits
19:51 dalgaaf okay ... nice !!!
19:52 bodepd_ dalgaaf: there are examples in teh native types for neutron
19:52 bodepd_ let me find a link
19:52 dalgaaf I guess I have, compared to you, only basic scills ;-)
19:52 bodepd_ even the fact that you understand that you should be able to retrieve the uuid at apply and that it maps to provider apis is a pretty good understanding ;)
19:52 dalgaaf that would be really nice ... then I could fix that step tomorrow and reduce the current code dramatically
19:53 dalgaaf and we would have one run less on our current setup
19:53 bodepd_ dalgaaf: https://github.com/stackforge/puppet​-neutron/blob/master/lib/puppet/prov​ider/neutron_subnet/neutron.rb#L70
19:54 bodepd_ that tranlates from a string to a uuid, where it assumes that uuid is accessible via anotother provider
19:54 bodepd_ let me see if I can find a better example
19:55 bodepd_ basically, I can searcn the code for anything that makes that model.catalog call
19:55 bodepd_ b/c you can access the provider instances form that,and then call a getter method on them
19:55 bodepd_ you should implement it as a property on the type
19:56 bodepd_ and just fail in the validate block
19:56 dalgaaf So there are some dependencies between the nodes ... we solve that currently simply but starting up the cluster in the correct order ... which is no problem for us since we don't even have everything on baremetal ...
19:56 bodepd_ (b/c the user cannot set it)
19:56 dalgaaf MONs and RadosGW are currently on VMs for additional security and better ressource management
19:56 bodepd_ yeah, when we get crazy advanced, I sent a link before for a connection validation type/provider
19:56 bodepd_ ttps://github.com/cprice404/​puppet-connection-validator
19:57 bodepd_ it's a native type that blocks catalog applicaton until a remote web service can be reached
19:58 bodepd_ I had intended to implement it for the openstack modules, but never quite found the time
19:58 bodepd_ it's used by the puppetdb module
19:58 * dachary thinks that another way to solve this would be that ceph accepts that an osd is created with a pre-defined osd id
19:59 bodepd_ you can even insert it in another scope, so that you would not have to couple it with a low level component
19:59 dalgaaf in the example the values are returned via @property_hash ?
19:59 bodepd_ let me look at the code
19:59 bodepd_ it probably assumes it was created on the same tun
19:59 bodepd_ run
19:59 bodepd_ but yes, the propoery hash is a magic place where state is maintained
19:59 dalgaaf dachary: maybe, but IIRC that would need changes in ceph
20:00 dalgaaf that was a problem since a long time  ... some time back I worked on that issue with ceph/crowbar and there we had similar problems ...
20:00 dachary yes. but it looks like it would be an easy way to reduce the complexity
20:01 bodepd_ dalgaaf: basically, you should be able to call: mode.catalog.resource(<res​ource>).<property_getter)
20:01 bodepd_ for any property
20:01 dalgaaf maybe, but then you have to take care of the OSD numbering in your code, which is may not what you want
20:01 bodepd_ dalgaaf: le me find some easier examples
20:02 bodepd_ dalgaaf: you also may want to call Type.instances if you are not sure the resource will be in the same catalog
20:02 dalgaaf that would be nice ... hard to understand
20:03 bodepd_ https://github.com/stackforge/puppet-t​empest/blob/master/lib/puppet/provider​/tempest_glance_id_setter/ruby.rb#L16
20:04 bodepd_ much easier example. basically, tempest need the uuid of glance images in a config file
20:04 bodepd_ and puppet wants to create those images by name on the same run
20:04 dalgaaf it would simply be some call to ceph (cmdline tools or something else) to check for the osd ID for the given blkid of the device .... then it should return this info to ceph::osd on the same run to finish
20:04 dalgaaf that would be something similar
20:05 bodepd_ get the catalg, pull a resource out of it, get it's provider, call a property_getter on it
20:05 mgagne bodepd_: isn't there a way to get a resource property without relying on a custom function?
20:06 bodepd_ mgagne: you mean is it in the provider api?
20:06 mgagne bodepd_: why can't I do File['/var/log/whatever']['mode'] ? :D
20:06 bodepd_ mgagne: what would you do with that?
20:06 mgagne bodepd_: and this would return the mode of the file resource as seen by puppet
20:06 mgagne bodepd_: getting the ID of a resource for example?
20:06 bodepd_ mgagne: ah, I've written code before to translate that syntax into the call I sent the link to
20:06 bodepd_ mgagne: but that is not a feature in Puppet (I'm pretty sure I've opened a ticket on it)
20:07 bodepd_ mgagne: but you have to pass it as a string
20:07 mgagne bodepd_: that is probably 3 years old :D
20:07 bodepd_ mgagne: b/c Resource_type[][]
20:07 bodepd_ mgagne: breaks the parser without quotes
20:07 bodepd_ dalgaaf: https://github.com/stackforge/pupp​et-glance/blob/master/lib/puppet/p​rovider/glance_image/glance.rb#L16
20:07 bodepd_ https://github.com/stackforge/pupp​et-glance/blob/master/lib/puppet/p​rovider/glance_image/glance.rb#L74
20:07 bodepd_ and
20:08 bodepd_ https://github.com/stackforge/pupp​et-glance/blob/master/lib/puppet/p​rovider/glance_image/glance.rb#L26
20:08 bodepd_ are what ensures that method exists
20:08 bodepd_ do you know how mk_resource_methods work?
20:08 bodepd_ it creates methods for all propoerties that just look up the value in the property hash
20:08 bodepd_ (getter methods)
20:13 dwt0 joined #puppet-openstack
20:15 dalgaaf Okay ... from what I understand it would be a provide in ruby which would call ceph, parse the info for the uuid, find the correct osd ID matching this uuid (or whatever is needed to get the info) then it would return this information via @propert_hash .... right?
20:16 dalgaaf and then I have to add a type for that to get the id as with glance_image
20:18 bodepd_ maybe I will try to exaplain from a differetn direction
20:18 bodepd_ puppet types have parameters and properties
20:18 bodepd_ properties may to queryable and settable values on the system
20:18 bodepd_ s/may/map/
20:19 bodepd_ properties are implemented as getters and setters
20:19 bodepd_ so for a property called id:
20:19 bodepd_ it's getter would be:
20:19 bodepd_ https://gist.github.com/bodepd/7031555
20:20 bodepd_ dalgaaf: follow so far?
20:20 dalgaaf yes
20:20 bodepd_ from another provider, we can actually accesss the catalog
20:20 bodepd_ so, we can pull out resources that were defined as a part of the same catalog via
20:20 bodepd_ model.catalog.resource()
20:20 bodepd_ we can call their property getters via:
20:21 bodepd_ resource.provider.<property_getter_method>
20:21 bodepd_ the rest of it has to do with writing optimized providers
20:21 bodepd_ so, to start, if you just implemented the id method, it would work
20:22 bodepd_ dalgaaf: good so far? then we can move to provider optimizations
20:22 dachary FWIW there is a key / value store that can be used for generic purposes in the mon ( https://github.com/ceph/ceph/blob/​master/src/mon/MonCommands.h#L558 ) I don't think it's helpful but ...
20:22 dalgaaf okay
20:22 dmsimard bodepd_: lol, mgagne just shown me the book you wrote on this very topic
20:23 bodepd_ often when we want to query for the state of the system, there are two types of APIs
20:23 dmsimard bodepd_: (we have a copy)
20:23 bodepd_ (for example restful APIs)
20:23 bodepd_ some APIs list all objects, and some get specific objects
20:23 bodepd_ for performance reasons, it often makes sense use the list method to capture the state of all resources on the system
20:24 bodepd_ as opposed to having to check their existance one-by-one
20:24 bodepd_ that is what the self.instances and self.prefetch methods do
20:24 mgagne unless you have a million entities =)
20:24 bodepd_ yes, there are reasons not to use those APIs
20:25 bodepd_ the standard is to capture these properties in an instances propety hash
20:25 bodepd_ @property_hash
20:25 bodepd_ the method mk_resource_methods can be used instead of having to implement all of the getter methods
20:25 bodepd_ it assumes that all values can be pull from the property hash
20:27 bodepd_ https://github.com/puppetlabs/puppet/b​lob/master/lib/puppet/provider.rb#L417
20:27 bodepd_ so, if we are just relying on the @property_hash to retrrieve values, we need to ensure it is always updated when those values chnage
20:27 bodepd_ hence, when create is call, it is updated
20:27 bodepd_ # end lesson
20:29 dalgaaf okay I think I understand it now better
20:30 ryanycoleman joined #puppet-openstack
20:32 ryanycol_ joined #puppet-openstack
20:34 xarses joined #puppet-openstack
20:45 ryanycoleman joined #puppet-openstack
20:50 ryanycoleman joined #puppet-openstack
20:59 dalgaaf_ joined #puppet-openstack
21:02 mgagne bodepd_: What's the purpose of the flush method in provider? Does it replace create/destroy?
21:05 bodepd_ it's more for the update case
21:05 bodepd_ let's say we have a single update method
21:05 bodepd_ mgagne: ^^^
21:06 bodepd_ mgagne: then you would want to queue up changes (which map to invocation of property setters)
21:06 mgagne bodepd_: I'm confused by what's writing in the book as it looks flush is called once in all cases (create, update, destroy)
21:06 bodepd_ and call update once
21:06 bodepd_ yeah. It's lame
21:06 bodepd_ when we wrote the book we thought it was only called for update
21:06 mgagne bodepd_: wait
21:06 bodepd_ we actually had to rewrite that part b/c when we went through our examples
21:06 mgagne bodepd_: I'm confused
21:06 bodepd_ they didn't work
21:06 bodepd_ flush is always calle
21:06 bodepd_ called
21:07 bodepd_ but I disagree with that implementation
21:07 mgagne bodepd_: the book says: flush method will always be invoked at the end whether Puppet is creating, destroying or modifying resource.
21:08 mgagne bodepd_: does it mean I have to implement a logic so flush does not update my resource if create has already been called?
21:09 bodepd_ mgagne: that is true
21:09 bodepd_ mgagne: we added some logic for that in the example
21:09 bodepd_ but I forget how we handled it
21:09 mgagne bodepd_: do you have a clue where I'm running with this? =)
21:10 bodepd_ I think we just told it not to flush unless we were in the update case
21:10 bodepd_ ah, keystone fix
21:10 bodepd_ git endpoints
21:10 mgagne bodepd_: yes
21:10 bodepd_ that would be weird
21:10 bodepd_ b/c you want flush to behave differently depending on which prop is updated
21:10 bodepd_ wait... is that true?
21:11 mgagne bodepd_: taking personal notes on how to write those custom types, I have to relearn from scratch each time I work with them
21:11 bodepd_ does endpoint have an update operation?
21:11 mgagne bodepd_: no
21:11 bodepd_ :(
21:11 mgagne bodepd_: no update
21:11 mgagne bodepd_: as per your comment and cli help =)
21:11 bodepd_ yeah, then flush is for that
21:11 bodepd_ some of these types/providers, I wrote while I was learning undocumented things
21:11 mgagne =)
21:12 bodepd_ so, some of the oldest ones: ie keystone
21:12 bodepd_ have the worst implementations
21:12 mgagne bodepd_: and all I have for examples of those custom types :D
21:13 bodepd_ you have the book :)
21:13 bodepd_ allright, I gotta get back to the task at hand...
21:13 mgagne bodepd_: true, I still find it hard to follow without rewriting it in my own words
21:15 bodepd_ I'm for sale :) I would gladly fly to Canada and teach a class :) preferably in the summer :)
21:15 bodepd_ mgagne: but seriously, feel free to ask me any questions.
21:15 mgagne bodepd_: doing it =)
21:15 bodepd_ I think the book does a good job of covering, and I'm happy to explain things further
21:15 ryanycoleman joined #puppet-openstack
21:16 bodepd_ sometimes the best way to learn the edge cases is to poke it
21:16 bodepd_ try things out, see what happens, etc
21:16 dmsimard bodepd_: yeah you don't want to come here during the winter.
21:18 ryanycol_ joined #puppet-openstack
21:19 mgagne bodepd_: you still can come during winter, I'll gladly give you away a shovel
21:24 tnoor1 joined #puppet-openstack
22:04 ryanycoleman joined #puppet-openstack
22:12 mgagne bodepd_: why was @endpoint_hash used instead of @property_hash in keystone_endpoint? Is it to allow to flush the cache at each puppet run?
22:36 bodepd_ mgagne: I didn't understand how property hash worked back then
22:36 mgagne bodepd_: alright, I'll do some tests
22:36 bodepd_ I'd have to check the code to remember
22:37 bodepd_ I think it was all just for caching results to improve performance
22:40 michchap joined #puppet-openstack
22:42 ryanycoleman joined #puppet-openstack
22:45 ryanycoleman joined #puppet-openstack
22:47 ryanycoleman joined #puppet-openstack
23:01 ryanycoleman joined #puppet-openstack
23:02 mjblack_ joined #puppet-openstack
23:03 ryanycoleman joined #puppet-openstack
23:22 blentz joined #puppet-openstack
23:26 dachary long story short : using ceph create <uuid> is idempotent and the puppetmaster won't need to care about the osd id at all.
23:26 dachary bodepd_: ^ dalgaaf ^
23:26 dachary I meant ceph osd create <uuid>
23:28 dachary it looks like puppet-ceph could be real simple
23:29 dachary with information flowing only from the puppetmaster to the nodes
23:31 dachary there is no per-osd configuration setting that would require to know the osd.
23:32 dachary and the crush map placement is done when the osd starts ( both upstart & systemv scripts implement this )
23:33 dachary the user / key can be created locally and imported to the mon
23:33 dachary and that's about it
23:37 e1mer joined #puppet-openstack
23:48 dmsimard joined #puppet-openstack
23:55 bodepd_ dachary: dalgaaf and I had an offfline discussion, and there is a way to let the system generate the uuids and still do everything on one run
23:57 bodepd_ I'll still defer to you guys on what approach is preferred.
23:59 ryanycoleman joined #puppet-openstack

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