17:30:34 <dougwig> #startmeeting networking_lib
17:30:35 <openstack> Meeting started Wed Dec 16 17:30:34 2015 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:30:38 <openstack> The meeting name has been set to 'networking_lib'
17:30:50 <dougwig> agenda:
17:30:51 <dougwig> https://wiki.openstack.org/wiki/Network/Lib/Meetings
17:30:56 <dougwig> #topic Welcome
17:31:00 <dougwig> hiya all, who all is around?
17:31:04 <kevinbenton> o/
17:31:06 * HenryG needs a minute
17:31:52 * dougwig hands HenryG a minute.
17:32:01 <dougwig> #topic Announcements
17:32:15 <dougwig> coordinating work and trying to get relevant info in this wiki page:
17:32:15 <dougwig> https://wiki.openstack.org/wiki/Network/Lib/Meetings
17:32:46 <dougwig> this next part should be fun with gerrit down...
17:32:51 <dougwig> #topic Finalize callbacks interface
17:33:04 <dougwig> kevinbenton, armax, ping
17:33:13 <dougwig> https://review.openstack.org/#/c/253661/
17:33:15 <kevinbenton> so i was thinking about this
17:33:16 <armax> dougwig: pong
17:33:24 <kevinbenton> will neutron-lib have releases?
17:33:33 <dougwig> yes, into pypi.
17:33:42 <kevinbenton> what i was hoping is that the first patch just takes exactly what we have for callbacks and move it over
17:33:45 <HenryG> dougwig: don't troll us with gerrit links now
17:33:45 <dougwig> neutron will grab it via requirements.txt, via global requirements.
17:33:53 <kevinbenton> and then we iterate on that
17:34:03 <kevinbenton> so the changes are easier to understand from what we have now
17:34:24 <dougwig> i'm ok with that, if you're ok maintaining the old interface if it ever hits pypi ?
17:34:57 <kevinbenton> well if we need to do a pypi release and this isn't resolved yet, we can temporarily break it for the release
17:35:14 <HenryG> when are pypi releases done? who controls when they are done?
17:35:40 <dougwig> HenryG: mestery is the release manager for the stadium, and i expect when we say 'go' and then he has time.
17:35:47 <kevinbenton> a random number generator between 1 and 100 runs every hour
17:35:52 <kevinbenton> if it pulls a 50, a release is done
17:35:53 <dougwig> kevinbenton: what do you mean? hide the interface in that case?
17:35:57 <kevinbenton> dougwig: yeah
17:36:23 <kevinbenton> dougwig: make it unusable from outside the module with the hidden magic var
17:37:04 <dougwig> that's fine.  as long as tests of neutron against neutron-lib master and neutron-lib (latest pypi) are always green, i'm happy.
17:37:10 <dougwig> does anyone object to phasing it in that way?
17:37:20 <HenryG> sounds good to me
17:37:26 <kevinbenton> dougwig: sounds good
17:37:39 <dougwig> #action someone make a note in gerrit on this when it's up
17:37:55 <dougwig> #topic Do we hate pylint?
17:38:00 <dougwig> this was 90% a joke, but
17:38:06 <armax> dougwig: what would be the note?
17:38:07 <kevinbenton> so i didn't get to see this review yet
17:38:14 <dougwig> it costs a lot to maintain, and i've only ever found *ONE* bug on top of flake8 with it.
17:38:18 <HenryG> I hate 90% of pylint
17:38:31 <kevinbenton> armax: oh, to merge callbacks as they currently exist
17:38:36 <dougwig> armax: revert paul's patch to a basic move, with a plan to iterate it in place before release.
17:38:37 <armax> that the typical effort of bootstrapping neutron-lib is to copy and paste and to iterate in tree?
17:38:40 <kevinbenton> armax: and then iterate on them so it's easier to understand the change
17:38:58 <dougwig> #undo
17:38:59 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xaaf9910>
17:39:08 <dougwig> armax: want to chime in on that?
17:40:00 <armax> dougwig: that’s fine by me, assumed that we just don’t ‘simply forget’ phase 2 :)
17:40:19 <dougwig> armax: i assumed that plan meant that i get to exercise my asshole mode regularly. :)
17:40:30 <armax> otherwise neutron-lib becomes a missed opportunity
17:40:32 <armax> dougwig: ack
17:41:01 <dougwig> do i hear a new tagline in there?  "Neutron: A Missed Opportunity".
17:41:12 <dougwig> sorry, i'm pulling myself into the weeds.
17:41:18 <dougwig> #topic Do we hate pylint?
17:41:34 <kevinbenton> no
17:41:36 <kevinbenton> next topic
17:41:39 <dougwig> so, do we pull in this maintenance nightmare as the status quo, or do we shoot it in the head?  yes, i'm biased.  and i'm also totally cool either no.
17:41:48 <kevinbenton> :)
17:41:54 <dougwig> ha, timebox is set to 60 seconds.
17:42:35 <kevinbenton> so i was thinking we could actually use pylint to enforce some stricter standards
17:42:45 <kevinbenton> like method length limits
17:42:51 <dougwig> won't your plan of moving then iterating get in the way of that?
17:42:51 <kevinbenton> and whatnot
17:43:12 <HenryG> You can put pylint exceptions in inline comments
17:43:28 <kevinbenton> right, or make the existing code compliant before enabling the check
17:43:41 <armax> pylint is useful when we have 500 contributors against the same repo
17:44:09 <armax> when we have 5, it becomes easier to have a consistent set of coding guidelines
17:44:30 <armax> that said, it can provide a decent safety net for a language like python
17:44:46 <HenryG> yeah but we are moving over code that was implemented by 500 contributors
17:45:11 <kevinbenton> so i vote 'keep status quo' for now. we can always yank it out later
17:45:25 <armax> we could trim down the list of pylint violation checks to those that are clearly bad
17:45:36 <HenryG> armax: +1
17:45:36 <dougwig> ok, so it stays, sounds like. i expect this wouldn't even be a topic but for my personal change in beliefs over whether it's worth the cost.
17:46:02 <dougwig> let's move on.
17:46:04 <dougwig> #topic db modules - what moves, what changes?
17:46:17 <dougwig> HenryG: how do we figure out how we attack this?
17:46:37 <HenryG> still not sure
17:46:48 <HenryG> I would like to see less dicts, more objects
17:46:54 <kevinbenton> what do we mean by db modules in this regard?
17:47:02 <HenryG> less mixins, more composition
17:47:21 <kevinbenton> so not the db models themselves
17:47:27 <kevinbenton> but the tools to manipulate them?
17:47:29 <dougwig> if you look in the wiki link above, under 'db rework', you can see a list of db modules used by just a single subrepo. i can break that down further into objects within those modules, but it becomes a big list, fast.
17:48:21 <dougwig> either we move things like the base mixins, or we make something new and update all the subprojects. i'm fine with either approach, but a LOT of modules end up with a dependency chain that ends in neutron.db somewhere, so it's a blocker.
17:48:53 <dougwig> (even some stuff in neutron.common, which just seems like a broken dependency chain that should be fixed)
17:50:00 <dougwig> ok then, let's step back.  do we want to move the mixins and support them alongside something new?  or go straight to something new?
17:50:28 <kevinbenton> something new would be cool
17:51:12 <HenryG> not excited about supporting old stuff in the -lib
17:51:59 <dougwig> ok, that's fine, it just adds urgency to getting the 'new' done.  what is everyone envisioning there?  or put another way, what do you *really* hate today, that needs to die in fire?
17:52:42 <kevinbenton> well what mixins are used by other projects?
17:52:48 <kevinbenton> that would be the first ones to tackle
17:52:50 <kevinbenton> those*
17:53:24 <dougwig> from neutron.db import common_db_mixin as base_db
17:53:45 <kevinbenton> oh
17:53:47 <kevinbenton> that
17:53:49 <kevinbenton> :)
17:53:55 <dougwig> one quick spot check shows: base_db.CommonDbMixin
17:53:55 <HenryG> yeah
17:54:45 <dougwig> i've certainly seen worse subclasses in my life.
17:56:11 <dougwig> if we're not moving that, what were y'all thinking of instead?
17:56:59 <kevinbenton> model_base can probably go
17:57:54 <HenryG> ok that looks fine I think
17:58:27 <dougwig> kevinbenton: go, or not move? are subprojects allowed to use the standard attributes table?
17:59:25 * dougwig hands around the coffee pot.
18:00:21 <kevinbenton> dougwig: hmm
18:00:40 <dougwig> ok, let's take this item offline.
18:00:49 <kevinbenton> dougwig: well as long as they aren't adding automatic relations that will affect everyone
18:00:52 <kevinbenton> dougwig: yes, that should be fine
18:01:31 <dougwig> let's move on, we'll talk about this more, maybe in person soon.
18:01:39 <dougwig> #topic Open discussion
18:01:44 <dougwig> HenryG: i believe you had a question here.
18:02:26 <HenryG> Gerrit is down but the question is there: https://wiki.openstack.org/wiki/Network/Lib/Meetings
18:03:07 <dougwig> i'm not sure we can block reviews for needing neutron-lib first when it hasn't released yet?  it's not even gated against.
18:03:30 <HenryG> yeah but those constants are not used anywhere yet
18:03:56 <HenryG> they're new constants
18:03:59 <kevinbenton> but we don't have to use debtcollector in the constants in neutron
18:04:05 <kevinbenton> for new ones at least
18:04:13 <dougwig> then why are we adding them?  and will subprojects need them?
18:04:17 <kevinbenton> we can let them in and just say they will be in neutron-lib next release
18:04:22 * dougwig shakes fist at gerrit.
18:04:53 <dougwig> my removal review will get a merge conflict, so it won't get lost ( https://review.openstack.org/242219 )
18:06:36 <HenryG> allright, let's let constants go in neutron until we are ready
18:06:58 <kevinbenton> i think it's fair to immediately move any that were added this cycle too
18:07:05 <kevinbenton> so we dont' have to debt collect them
18:07:46 <dougwig> right, i don't think we need to debtcollector the new ones. but i'll have the maintenance item to move the interim stuff.
18:09:00 <HenryG> dougwig: are you keeping a list of todo's?
18:09:09 <kevinbenton> #todo make todo list
18:09:27 <dougwig> HenryG: in the wiki and in my list of open reviews, yes. i know the constants will get caught, because i'll get a conflict.
18:10:10 <HenryG> sounds good
18:10:26 <HenryG> I'll add to the wiki anything without a review or bug yet
18:10:41 <dougwig> anything else today?  my biggest action item will be to hunt down HenryG and kevinbenton and get more db change details.  today.
18:11:42 <dougwig> todo list item to create todo list created.  jk.
18:11:44 <kevinbenton> dougwig: how about neutron.db.api?
18:12:21 <dougwig> kevinbenton, HenryG: is that good to move, or do we want changes there?
18:12:32 <kevinbenton> dougwig: ah, but that depends on the common_db_mixin
18:12:39 <kevinbenton> dougwig: what's our rule for this kind of stuff?
18:12:46 <kevinbenton> dougwig: can't depend on neutron at all, right?
18:12:51 <dougwig> kevinbenton: didn't you both say it was ok to move common_db_mixin?
18:13:06 <dougwig> kevinbenton: must not depend on neutron.  we can move the child dependencies, or sever them.
18:13:12 <HenryG> kevinbenton: only getobject/s
18:13:16 <dougwig> the latter via dup or passing in callbacks.
18:14:00 <kevinbenton> dougwig: we need to go through common_db_mixin and make sure stuff that is only used internally is appropriately named so it looks private
18:14:16 <kevinbenton> used internally - only used by the mixin itself
18:14:35 <dougwig> ok, can one of you do so, and when?
18:15:53 <HenryG> I can start later tomorrow or Friday
18:16:05 <kevinbenton> HenryG: thx
18:16:25 <dougwig> ty.
18:16:43 <kevinbenton> for neutron lib, should we start doing internal methods prefixed with double underscore so name mangling takes place?
18:16:55 <HenryG> seems like a good place to start focus, thanks kevinbenton
18:17:13 <dougwig> you hit a python bit of trivia i'm unaware of.  isn't __ for stuff internal to python itself?
18:17:18 <kevinbenton> no
18:17:29 <dougwig> ooh neat, please tell.
18:17:30 <kevinbenton> if you prefix a class method with __ it makes it difficult to access
18:17:50 <dougwig> really?? why are we not using it more places??
18:17:50 <kevinbenton> it gets translated
18:18:00 <kevinbenton> to _classname__method
18:18:04 <kevinbenton> for external callers
18:18:14 <kevinbenton> so it's quite clear you are reaching into the bowels of something
18:18:33 <dougwig> that's really good, i'd say yes.
18:18:38 <HenryG> interesting, yes
18:18:41 <kevinbenton> https://docs.python.org/2/tutorial/classes.html#private-variables-and-class-local-references
18:18:42 <dougwig> any py3 issues or something like that?
18:18:48 <kevinbenton> not that i'm aware of
18:19:14 <HenryG> The oslo folks have been doing libs for some time. Anything we can learn from them?
18:19:35 <kevinbenton> so something to note is that it doesn't suggest doing this to prevent people from accessing things
18:19:39 <kevinbenton> because this is python
18:19:45 <kevinbenton> "we're all adults"
18:20:02 <kevinbenton> the convention is just a single underscore means 'internal' and that it might break
18:21:11 <HenryG> So a single underscore should suffice really
18:21:39 <dougwig> switch it to ruby, so i can just mark it private.
18:21:42 * dougwig hides.
18:21:51 * dougwig inside ruby's private namespace.
18:21:53 <kevinbenton> yes, and if a subclass tries to override a double-prefix it won't do the normal thing
18:22:06 <kevinbenton> since that's actually translated to _classname__method
18:22:10 <kevinbenton> they will be different
18:22:29 <dougwig> so if it's not recommended that we use it, should we? why does it even exist?
18:22:51 <kevinbenton> it's mainly for classes to ensure they have a reference to the function they defined
18:23:07 <kevinbenton> and not the one overridden by a subclass in inheritance
18:23:31 <kevinbenton> so it's really to make things private to a class for inheritance purposes
18:23:50 <kevinbenton> not to prevent people from using it
18:23:58 <dougwig> that makes sense. at least as much as any of python's namespacing makes sense.  so a single underscore is the right answer for a library.
18:24:01 <kevinbenton> i'm now regretting bringing it up :)
18:24:17 <kevinbenton> now that i'm thinking it through
18:24:21 <dougwig> anything else before we wrap up for today?  HenryG, i'll ping you offline and setup a time to chat.
18:24:37 <HenryG> I enjoyed learning about __method kevinbenton
18:24:43 <kevinbenton> we could add an @private decorator that inspects the call stack and ensures it comes from neutron-lib :)
18:24:58 <kevinbenton> however, it will probably come at a terrible performance cost
18:25:17 <HenryG> dougwig: ack
18:25:27 <kevinbenton> one thing that is used by libraries at the module level is the __all__ magic var
18:25:37 <kevinbenton> it defines what is importable by other modules
18:25:37 <dougwig> kevinbenton: i mean, if people call and _internal routine and we break it, i won't lose any sleep.
18:25:47 <dougwig> /and/an/
18:25:49 <kevinbenton> so we can use that for module-level methods
18:25:57 <viveksa> Hi, I would like to know if there is a way to fetch Meatadata of VolumeSnapshot from DB
18:26:12 <kevinbenton> viveksa: wrong channel. check out #openstack
18:26:21 <viveksa> thanks
18:26:48 <dougwig> ok, let's wrap up this python tutorial session.  :)
18:26:53 <HenryG> I wonder if they have an "effective oslo" guide?
18:27:04 <kevinbenton> not sure
18:27:16 <kevinbenton> ok
18:27:19 <kevinbenton> anything else?
18:29:09 <dougwig> ok, let's close this.
18:29:11 <dougwig> #endmeeting