16:00:06 <dhellmann> #startmeeting oslo
16:00:08 <openstack> Meeting started Fri Apr 25 16:00:06 2014 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:12 <openstack> The meeting name has been set to 'oslo'
16:00:20 <dhellmann> who's around for the oslo meeting?
16:00:25 <GheRivero> o/
16:00:37 <sileht> o/
16:01:23 <markmc> hey
16:01:26 <dhellmann> do we have any liaisons with us today?
16:01:38 <dhellmann> beekneemech, dims, jd__, ping?
16:01:40 <beekneemech> o/
16:01:44 <GheRivero> me
16:01:45 * dhellmann needs to make a list of everyone's irc handles
16:01:47 <dims> dhellmann, pong
16:01:55 <dhellmann> welcome, GheRivero, thanks for joining us!
16:02:08 <nacim> here too.
16:02:16 <dhellmann> hi, nacim!
16:02:20 <dhellmann> our agenda:
16:02:21 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
16:02:35 <dhellmann> #topic Review action items from previous meeting
16:02:44 <dhellmann> well, we don't have any so...
16:02:54 <dhellmann> #topic Welcome Oslo/ProjectLiaisons!
16:03:46 <dhellmann> Thank you all for volunteering to work with us this cycle! I hope that we're able to smooth out some of the communications challenges we've had in the recent past.
16:04:10 <beekneemech> +1
16:04:23 <dhellmann> If you have something you'd like to discuss in the meetings, just add it to the agenda. Of course you don't have to wait for the meetings, and can use the mailing list of #openstack-oslo as well
16:05:04 <dhellmann> #topic Please review code in all our repos
16:05:17 <dhellmann> core reviewers, we have a bunch of new repositories to look at now
16:05:33 <dhellmann> I created a few helper links for finding reviews that could use attention:
16:05:37 <dhellmann> #link https://wiki.openstack.org/wiki/Oslo#Review_Links
16:05:50 <dhellmann> let's make sure the smaller repos aren't forgotten :-)
16:05:54 <jd__> o/
16:05:54 <markmc> nice, helpful
16:06:18 <morganfainberg> dhellmann, nice to have a central repo for the links
16:06:30 <dhellmann> I should probably update the graduation instructions to include a step to add the new repo to that list
16:06:36 <morganfainberg> dhellmann, s/repo/place
16:07:14 <dhellmann> morganfainberg, markmc: I completely cribbed those links from something sdague posted a while back
16:08:27 <dhellmann> liaisons, we would also like your help with reviews when you have time, so dive in when you can
16:08:34 <beekneemech> I think those links eliminate all of dhellmann's submissions :-)
16:08:49 <beekneemech> I'm assuming that's what "-owner:doug.hellmann@dreamhost.com" means.
16:08:55 <dhellmann> oops, yes
16:09:02 <dhellmann> I copied those from my bookmarks
16:09:09 <dhellmann> thanks for noticing that, beekneemech
16:09:17 <beekneemech> np
16:09:21 * dhellmann makes a note to fix the links
16:09:32 <dhellmann> let's talk libraries!
16:09:34 <dhellmann> #topic Start roll-out of oslotest
16:09:37 <morganfainberg> beekneemech, it might be a subtle hint :P
16:09:52 * dhellmann doesn't tend to subtlety
16:10:14 <dhellmann> during icehouse, we used oslotest as our process test library
16:10:23 <dhellmann> it is graduated and ready to be used
16:10:40 <dhellmann> so, liaisons, that would be a good place to start with adoption
16:10:52 <dhellmann> note that the repo is oslo.test but is going to be renamed oslotest to match the library name
16:11:02 <beekneemech> Are we punting on the cross-testing for now?
16:11:11 <dhellmann> #link http://git.openstack.org/cgit/openstack/oslo.test
16:11:13 <bknudson> keystone is using oslotest, but we also need to get rid of our use of incubator fixtures
16:11:33 <dhellmann> beekneemech: there's a summit session on that. I haven't had a chance to rework the script
16:11:41 <bknudson> https://review.openstack.org/#/c/83968/2
16:11:49 <dhellmann> #link https://etherpad.openstack.org/p/juno-infra-library-testing
16:12:01 <dhellmann> bknudson: nice!
16:12:24 <beekneemech> dhellmann: Okay, will make sure to attend.
16:13:07 <dhellmann> #topic oslo.db status (viktors or rpodolyaka)
16:13:36 <dhellmann> #link https://blueprints.launchpad.net/oslo/+spec/oslo-db-lib
16:13:50 <dhellmann> I didn't see viktor or roman raise their hands earleir
16:13:59 <dhellmann> the repo they set up has been approved for import
16:14:16 <dhellmann> we're waiting, I think, on the planned gerrit upgrade before proceeding
16:14:32 <dhellmann> I think that will still give us time to have the new repo created before the summit
16:14:45 <dhellmann> which will put us on track for an initial release not long after
16:15:19 <dhellmann> any questions about oslo.db before we move on?
16:15:20 <beekneemech> Nice
16:15:49 <bknudson> we'll want to get oslo.db into keystone early so we get as much runtime as possible
16:16:08 <dhellmann> bknudson: keystone would be a great test for an early adopter
16:16:09 <bknudson> since it's pretty fundamental to keystone... we really don't do much else.
16:16:36 <sileht> In ceilometer code have already moved to the facade engine, so migration should be very simple.
16:17:05 <dhellmann> oh, that's good, I wasn't sure whether ceilometer was going to require extra work because of the separate plugin layer there
16:17:56 <dhellmann> ok, one more lib status update:
16:17:57 <dhellmann> #topic oslo.i18n status
16:18:09 <dhellmann> the API changes were approved and merged yesterday
16:18:15 <dhellmann> #link https://review.openstack.org/#/c/87386/
16:18:45 <dhellmann> I plan to work on creating the repo for the new library next week
16:19:35 <dhellmann> does anyone want to volunteer to be the guinea pig for adoption on this one? :-)
16:20:08 <bknudson> I'm sure we can pick it up in keystone when it's avail
16:20:16 <morganfainberg> bknudson, ++
16:20:28 <dhellmann> the keystone team is my new best friend
16:20:34 <bknudson> looking at 87386, I don't think we're affected
16:20:35 <beekneemech> :-)
16:20:47 <bknudson> the keystone team wants to maintain as little code as possible
16:21:24 <dhellmann> bknudson: the tricky part is that each app will need a very small integration module to create those marker functions with the right translation domain -- I plan to write some docs for that before releasing the first version of the library
16:22:00 <dhellmann> the new API sets it up to make that easy, but it's not automatic
16:22:06 <morganfainberg> dhellmann, if we have the info, i don't think thats a huge hurdle
16:22:11 <bknudson> yea, I guess keystoneclient doesn't translate messages... not sure how that would be done
16:22:26 <dhellmann> yeah, "tricky" may be too strong a word -- "not obvious from that changeset" perhaps
16:23:17 <dhellmann> yeah, any lib or app that uses the translation functions needs their own copy -- they get that for free now as a feature of update.py, where "oslo" is replaced with "target project name"
16:24:09 <dhellmann> we have one more topic on the formal agenda:
16:24:12 <dhellmann> #topic Should we create a specs repo?
16:24:34 <dhellmann> everyone else seems to be doing it, would it be useful for us, too?
16:25:30 <dhellmann> I held off suggesting it to see how it worked for some of the other teams first. Nova seems to like their new process.
16:25:45 <beekneemech> Makes sense to me.  The only concern I would have is getting enough reviews for blueprints.
16:25:50 <morganfainberg> dhellmann, the question that would direct the answer is how much of an issue is LP and how messy are blueprints for oslo at the moment?
16:26:19 <dhellmann> well, this wouldn't eliminate our use of LP, just supplement it (if I understand what nova is doing)
16:26:21 <morganfainberg> dhellmann, and is there the bandwidth for the reviews as beekneemech just pointed out.
16:26:55 <morganfainberg> dhellmann, it does supplement it, but the reasoning is to help deal with issues with LP.
16:26:57 <dhellmann> the other question is whether it would be needed for each library, or just for the incubator
16:27:40 <morganfainberg> dhellmann, you could probably get away with a single repo with directories for each library (nova is moving to that for nova vs novaclient if i understand the ML topics)
16:27:41 <dhellmann> morganfainberg: LP is already a pain for me, because we have several different projects I need to track (incubator, messaging, stevedore, cliff, taskflow, pycadf)
16:28:18 <morganfainberg> dhellmann, ++ that sounds like this makes a lot of sense for oslo, provided there is enough reviewer bandwidth.
16:28:37 <dhellmann> I like the idea of one directory per lib
16:28:57 <dhellmann> morganfainberg: do you know if they have the process written up in the wiki?
16:29:36 <morganfainberg> dhellmann, not sure where the documentation is.  i think they have the documentation in the spec repo it self
16:29:50 <dhellmann> ok, I'll look that over
16:30:08 <dhellmann> are there any objections? mehs?
16:31:05 <dhellmann> such a quiet group :-)
16:31:39 <dhellmann> that's all I had for the formal agenda today
16:31:40 <dhellmann> #topic Open Discussion
16:31:47 <dhellmann> does anyone have anything they need to bring up?
16:32:12 <beekneemech> Nothing for me
16:32:23 <GheRivero> I love this short meetings to finish the week :)
16:32:27 <dhellmann> :-)
16:32:51 <bknudson> we've had some discussions here about encryption the secret options in oslo.config
16:32:53 <creiht> hehe
16:33:09 <bknudson> haven't gotten too far with it, but was wondering if there had been interest in this elsewhere, too?
16:33:12 <dhellmann> bknudson: encrypting them in the config file?
16:33:21 <bknudson> yes, the config file would contain ecrypted values
16:33:37 <dhellmann> at one point someone wanted to add support for finding options using the keyring library
16:33:38 <bknudson> and then you'd be able to get the unencrypted values by... supplying a key on CONF() or something
16:33:54 <morganfainberg> interesting.
16:34:08 <dhellmann> I think we decided that the key would have to be shared somehow anyway, and at that point having the values encrypted didn't buy much
16:34:35 <dhellmann> but maybe there's a way to do it that we just didn't see?
16:34:36 <morganfainberg> dhellmann, maybe a mechanism to reteive a config value from an external source?
16:34:49 <bknudson> yea, that's the problem is then you'll need to read the key from a file
16:35:03 <bknudson> but that key file can be protected more than the config file
16:35:21 <dhellmann> morganfainberg: yeah, the config code already sort of supports that, though it's not pluggable there is a sort of search algorithm for looking through multiple sources
16:35:32 <dhellmann> bknudson: so just with filesystem permissions?
16:35:40 <bknudson> yes, filesystem
16:35:42 <morganfainberg> dhellmann, yeah this sounds like something that should be made more pluggable
16:35:46 <morganfainberg> dhellmann, in that case
16:36:34 <dhellmann> bknudson: could we use the fact that oslo.config can read multiple files, combined with the tighter permissions, to achieve a similar goal?
16:37:06 <dhellmann> i.e., put the secrets in a file other than the main config file with stricter permissions
16:37:10 <bknudson> the real complaint that we get is that some groups don't want things to be so easy to read
16:37:19 <dhellmann> yeah, that part makes sense
16:37:44 <bknudson> so some of this is not really about needing some real security
16:37:51 <dhellmann> it's just not clear how to share the secret so the file can be decrypted without basically exposing everything you're encrypting
16:37:57 <bknudson> it's just they don't want someone to be able to look at the file
16:38:03 <dhellmann> ah, so just obfuscation?
16:38:21 <bknudson> yes, I think what's really wanted is obfuscation
16:38:34 <bknudson> so maybe provide a plugin for how to obfuscate
16:38:36 <dhellmann> ok, I guess I can see that
16:38:43 <bknudson> and maybe it's base64 and maybe it's something that requires a key?
16:39:20 <morganfainberg> dhellmann, i think that could be solved by allowing "external" plugins to source data - just one plugin could be b64+key?
16:39:27 <dhellmann> right
16:39:37 <morganfainberg> dhellmann, would also open the door if say someone wanted to source config data from LDAP
16:39:47 <dhellmann> true
16:39:53 <morganfainberg> dhellmann, kills 2 birds (more flexibility) with one stone
16:40:31 <dhellmann> it sounds like there's something here, who wants to write up a bp?
16:40:36 <morganfainberg> dhellmann, i actually have had that specific request, can we put config in LDAP.
16:40:53 <bknudson> we've got some people here who are interested in it, so I'll see if they'll propose a bp
16:40:56 * dhellmann vaguely remembers a proposal to build a config distribution tool on top of oslo.messaging
16:41:09 <dhellmann> bknudson: sounds good, thanks
16:41:10 <morganfainberg> bknudson, let me know if you need anything from me. Happy to help on this front
16:41:32 <dhellmann> it's probably 2 bps, one for the pluggability and one for the specific plugin(s)
16:41:34 <bknudson> morganfainberg: will do
16:41:49 <morganfainberg> dhellmann, i didn't see it, but i might just be missing it, can oslo do config opt refreshes?
16:42:07 <dhellmann> morganfainberg: yes, there are methods to clear out the existing settings and then you can reload them
16:42:36 <morganfainberg> dhellmann, cool. that is super valuable for externally sourced data
16:43:06 <dhellmann> the other thing that would need to be solved is how to determine the order all of the input sources are searched
16:43:59 <dhellmann> with the files, I think we use the order of arguments to the app, so that may just carry over to the new system
16:44:18 <morganfainberg> dhellmann, ++ order would probably be the easiest to maintain that way
16:44:54 <dhellmann> morganfainberg: we just need to figure out how order is implied if some of the external sources are mentioned in a config file :-)
16:45:36 <dhellmann> if there's nothing else, we can adjourn a bit early this week
16:45:37 <morganfainberg> dhellmann, something to mull over in this process
16:45:44 <dhellmann> morganfainberg: yep
16:46:39 <dhellmann> alright, thanks for coming everyone and I'm looking forward to seeing you all at the summit in a few weeks!
16:47:31 <dhellmann> #endmeeting