16:04:04 <regXboi> #startmeeting neutron northbound
16:04:04 <odl_meetbot> Meeting started Fri Mar  6 16:04:04 2015 UTC.  The chair is regXboi. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:04:04 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:04 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
16:04:14 <edwarnicke> #info edwarnicke
16:04:17 <regXboi> and even worse
16:04:20 <regXboi> #info regXboi
16:04:35 <regXboi> folks that are interested - please #info in
16:04:39 <regXboi> #chair edwarnicke
16:04:39 <odl_meetbot> Current chairs: edwarnicke regXboi
16:04:41 <dfarrell07> #info dfarrell07
16:04:47 <tbachman> #info tbachman
16:05:05 * tbachman waits for it....
16:05:26 <regXboi> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Lithium_Release_Plan current NN Lithium status
16:05:33 * regXboi lets tbachman wait
16:05:41 <tbachman> lol
16:05:43 <dfarrell07> lol
16:06:04 <regXboi> sorry folks - I don't have a real published agenda for this meeting - I've been fighting brush fires for the last 24 hours
16:06:19 <regXboi> let's go through the lithium status and talk about the yang model
16:06:23 <regXboi> and that should eat up the hour
16:06:31 <regXboi> do we have flaviof?
16:07:01 <regXboi> anyway - we submitted our M3 status report yesterday, but we are honestly yellow
16:07:30 <regXboi> We need to get our Karaf Features defined, Documentation started, and Testing updated
16:07:34 <edwarnicke> #link https://git.opendaylight.org/gerrit/16144 <- Our features patch to integration
16:07:49 <regXboi> ed, can you update the project page?
16:07:53 <edwarnicke> Sure
16:08:33 <edwarnicke> regXboi: Done
16:08:47 <edwarnicke> regXboi: flaviof We need to get folks moved off of the controller featurezs
16:09:13 <edwarnicke> Because other wise we will get collisiosn where the controller neutron features stuff grabs ports before we do (like we saw on Wednesday)
16:09:18 <regXboi> #action flaviof and edwarnicke to get folks moved off neutron controller features
16:09:30 * regXboi delegates
16:09:44 <edwarnicke> flaviof: Could you send out email with instructions to help folks get migrated off the neutron features in controller, and a timeline for when we will remove them from controller entirely ?
16:09:51 <edwarnicke> regXboi: Lets delegate that to flaviof ;)
16:10:05 <regXboi> edwarnicke: you are a chair, you can undo and action :)
16:10:10 <edwarnicke> #undo
16:10:10 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x1b78f10>
16:10:16 * tbachman notes is easy to delegate things to folks where aren’t here ;)
16:10:33 <regXboi> yeah, it's not fair, but it does encourage attendance :)
16:10:37 <tbachman> lol
16:10:41 <tbachman> edwarnicke: is there a timeline?
16:10:42 <dfarrell07> I just talked to flaviof a few seconds ago, he's not far lol
16:11:00 <edwarnicke> #action flaviof to send out email to folks on how to migrate to the new neutron features, with a time a week out for when those features coming from controller will be deactivated (aka, no longer work, and thus no longer collide)
16:11:16 <edwarnicke> tbachman: I think there should be a timeline
16:11:17 <regXboi> so edwarnicke, if I read these patches correctly, the list of features is odl-neutron-0.5.0-snapshot and odl-neutron-spi?
16:11:25 * tbachman agrees with edwarnicke
16:11:30 <tbachman> just didn’t know what it was
16:11:39 <edwarnicke> regXboi: Where are you getting that?
16:11:40 <regXboi> the timeline is pre M4
16:11:49 <regXboi> looking at features.xml
16:12:12 <regXboi> oh I see
16:12:16 <edwarnicke> :)
16:12:31 <regXboi> odl-neutron-service?
16:12:32 <flaviof> can you see me now?
16:12:33 <edwarnicke> The recommended one for most folks is probably odl-neutron-service
16:12:35 * tbachman waves to flaviof
16:12:37 <edwarnicke> flaviof: Welcome :)
16:12:42 <regXboi> #chair flaviof
16:12:42 <odl_meetbot> Current chairs: edwarnicke flaviof regXboi
16:12:45 <regXboi> and #info in :)
16:12:49 <edwarnicke> flaviof: We sort of assigned you an action item ;)
16:12:53 <tbachman> lol
16:13:05 <flaviof> dunno how this is possible, but I was in the meeting all along, but you could not hear me at all
16:13:10 <flaviof> 'hear;
16:13:11 <regXboi> edwarnicke: I'm being pedantic and wanting to list the feature names in that page before we change that status to green
16:13:12 <edwarnicke> flaviof: Ah
16:13:13 <edwarnicke> OK
16:13:15 <flaviof> like I was a ghost :)
16:13:23 <edwarnicke> flaviof: Does the action item look good to you?
16:13:48 <flaviof> edwarnicke: yes. delegation accepted.
16:13:54 <flaviof> :)
16:13:56 <edwarnicke> flaviof: many thanks :)
16:14:03 <regXboi> ok... moving back to the feature list
16:14:07 <edwarnicke> flaviof: Given the potential for collision, I think we need to set a date when:
16:14:10 <regXboi> can we please be pedantic and list them?
16:14:20 <edwarnicke> a)  neutron will be removed from the odl-nsf-* features entirely
16:14:20 <flaviof> edwarnicke: i would like to actually submit gerrits to the affected projects
16:14:30 <edwarnicke> b)  features-neutron will be emptied out
16:14:42 <edwarnicke> Otherwise we could get the same sort of issues you guys hit Wednesday
16:14:49 <flaviof> edwarnicke: +1
16:14:50 <edwarnicke> flaviof: That is most generous of you :)
16:15:25 <flaviof> edwarnicke: regXboi: any idea how many odl projects use neutron feature?
16:15:50 <regXboi> flaviof: none
16:16:00 <flaviof> regXboi: ?
16:16:01 <tbachman> regXboi: ?
16:16:03 <edwarnicke> flaviof: Well... that I know of, ovsdb, vtn, groupbasedpolicy, vpn, lisp, plugin2oc... I feel like I'm missing some...
16:16:17 <regXboi> I was answer the "any idea question"
16:16:21 <regXboi> I have no idea :)
16:16:23 <tbachman> lol
16:16:24 <regXboi> so none
16:16:31 <flaviof> regXboi: lol. tricky guy
16:16:35 * edwarnicke is full of ideas... most of them inadvisable...
16:16:40 <tbachman> ROFL
16:16:43 * regXboi snorts
16:16:59 * regXboi wanders away to the call of caffeine and a double chocolate muffin
16:17:12 <edwarnicke> regXboi: flaviof We should talk testing
16:17:22 <edwarnicke> regXboi: and moxy
16:17:37 * tbachman loves it when edwarnicke talks moxy
16:17:40 <regXboi> edwarnicke: will get there
16:17:43 <edwarnicke> regXboi: And whether we should institute traditional chocolate muffins at the end of our meeting
16:17:44 <flaviof> yes. for that we have the presence of a great ally: dfarrell07
16:17:54 <regXboi> first let's finish features
16:17:55 * dfarrell07 is frantically reading scroll-back
16:18:11 * edwarnicke thinks chocolate muffins should trump features... but will defer
16:18:13 <flaviof> dfarrell07: no need; nothing you missed
16:18:23 <regXboi> #action edwarnicke to list karaf features on project page and update status to green
16:18:33 <regXboi> edwarnicke: ok with that?
16:18:49 * regXboi notes he forgot to set a topic :)
16:19:15 * regXboi notes he will do so now for the next topic
16:19:20 <regXboi> #topic documentation
16:19:26 <edwarnicke> regXboi: Done
16:19:33 <regXboi> edwarnicke: thanks
16:19:40 <regXboi> documentation is on my plate for now
16:20:08 * edwarnicke hands regXboi another chocolate muffin
16:20:34 <regXboi> edwarnicke: there are 7 more here - made a dozen fresh this morning
16:20:46 * edwarnicke is clearly in the wrong place
16:21:04 * tbachman is getting hungry
16:21:07 <regXboi> anyway - I'll be drafting outlines of developer and contributer docs over the weekend and will post links onto the project page
16:21:21 <regXboi> #action regXboi to draft outlines of developer and contributer docs over the weekend and will post links onto the project page
16:21:25 <regXboi> ok, testing
16:21:29 <regXboi> #topic testing
16:21:39 <regXboi> edwarnicke: you wanted to talk moxy?
16:21:43 <regXboi> and testing :)
16:21:48 <flaviof> let's tal testing for a sec, pls
16:21:52 <edwarnicke> regXboi: I think moxy is a good example of why we need testing
16:22:04 <flaviof> talk
16:22:07 <edwarnicke> regXboi: We have a basic need to be able to test that we have not fucked up the basic translation of the rest API
16:22:17 <edwarnicke> regXboi: To do that I think we need the following:
16:22:29 <regXboi> edwarnicke: agreed on the basic need
16:22:38 <edwarnicke> a)  A dummy provider that just returns 200 and does nothing, purely for testing purposes
16:22:54 <regXboi> #agreed We have a basic need to be able to test that we have not hammered the basic translation part of the rest API
16:23:24 * regXboi notes these minutes will be interesting :)
16:23:27 <edwarnicke> b)  An integration test that launches a karaf container with odl-neutron-service, and odl-neutron-test-dummy, and a process that hits the rest and confirms the transcriber has transcribed the right thing
16:23:39 <regXboi> whoa
16:23:49 <edwarnicke> That way we can know on build that we haven't busted the damn rest api
16:23:49 <regXboi> a is no problem
16:23:53 <edwarnicke> whoa ?
16:23:58 <regXboi> I have no problem with (a)
16:24:22 <regXboi> but are you predicating (b) on yang or on the current cache storage?
16:24:42 <edwarnicke> (b) is agnostic as to yang
16:24:50 <edwarnicke> But basically
16:24:52 <regXboi> um... I don't agree
16:24:58 <edwarnicke> When a rest call comes in we need to check the following:
16:25:02 <regXboi> in my mind (b) is split into (b1) and (b2)
16:25:12 <edwarnicke> a)  Do the *Aware APIs get called with the correct info
16:25:15 <edwarnicke> b)  Do we transcribe it
16:25:19 <regXboi> (b1) we transcribe the neutron object into the current cache storage
16:25:23 <edwarnicke> c) When we get there, did it get into the yang model
16:25:30 <regXboi> (b2) we transcribe the neutron object into the yang model
16:25:36 <regXboi> so your c is my b2
16:25:41 <edwarnicke> Yep
16:25:46 <regXboi> ok, then we agere
16:25:49 <regXboi> er agree even
16:25:55 <edwarnicke> But I also see b2/c as something we bring up as the yang model comes up
16:25:59 <regXboi> ok... so I'll take the action item for (a)
16:26:01 <edwarnicke> a/b we need to do asap
16:26:20 <edwarnicke> regXboi: Many thanks :)
16:26:32 <edwarnicke> regXboi: a will also help a ton with manual testing :)
16:26:51 <regXboi> #action regXboi to write a dummy provider that answers 200 for all can I*Aware interfaces and dumps the received neutron data in log for the rest of the I*Aware interfaces
16:26:58 <regXboi> I think that action covers it
16:27:09 <regXboi> who can take an action for (b1)/(b)
16:27:15 * regXboi brb
16:27:36 <edwarnicke> TNadeau: Welcome to the party :)  We have chocolate muffins :)
16:28:11 <edwarnicke> regXboi: I can take a piece of b1, in that I am already working on how to do karaf based integration tests
16:28:51 * regXboi back
16:28:59 <flaviof> regXboi: edwarnicke: can we talk about this tests in terms of: 1) junit 2) integration+pax-exam 3) jjb 4) big+complicated test framework that requires special infra ?
16:29:00 <regXboi> ok, please action yourself
16:29:12 <regXboi> flaviof: certainly
16:29:21 <edwarnicke> flaviof: Only if you are willing to illudicate more about what you mean :)
16:29:26 <regXboi> our junit/etc is .... well .... pretty bad :)
16:29:38 <regXboi> or should I say ... pretty non-existent
16:29:44 <edwarnicke> regXboi: I'm not entirely sure our junit should be better... but am open to discussion there ;)
16:30:00 * regXboi gazes at the code coverage report in jjb and sighs
16:30:04 <flaviof> regXboi: ah, ok. well, junit is where we start then.
16:30:06 <edwarnicke> regXboi: I think the meet for us is the integration testing, because that's really where the rubber hits the road
16:30:17 <edwarnicke> flaviof: What do *you* mean by junit?
16:30:23 <edwarnicke> flaviof: In this case
16:30:41 <regXboi> edwarnicke: yes, but there are a bunch of new things that have to get added to come into line with http://developer.openstack.org/api-ref-networking-v2.html
16:30:47 <flaviof> edwarnicke: I mean tests that can run as part of 'mvn verify' and does not require pas-exam
16:30:50 <regXboi> and having unit test for them would not be a bad thing
16:31:03 <edwarnicke> flaviof: What interesting thigns can we test without pax-exam ?
16:31:53 * mestery walks in late
16:31:54 <flaviof> edwarnicke: with mock, we can make tests that ensure things like transcribe does what it is supposed to do, based on 'pretend' northbound msgs
16:32:22 <edwarnicke> regXboi: My point is... as I am thinking about unit tests (which may not match what you are thinking) I can't think of anything that moves that ball forward in the unit test sphere.  Now integration tests with pax-exam, that I can see doing lots of useful stuff with
16:32:25 <flaviof> edwarnicke: to me that is basid tdd stuff
16:32:32 <edwarnicke> tdd ?
16:32:37 <regXboi> test driven design
16:32:45 <regXboi> or something like that
16:32:52 <flaviof> edwarnicke: https://en.wikipedia.org/wiki/Test-driven_development
16:32:59 * regXboi remembers too late that development is the last d
16:33:06 <regXboi> :)
16:33:21 <edwarnicke> flaviof: Sure... but lets not be pedantic
16:33:30 <flaviof> edwarnicke: np.
16:33:41 <edwarnicke> flaviof: The fundamental thing we do is test that when REST comes in, stuff comes out
16:33:45 <regXboi> well
16:33:48 <edwarnicke> If we test rest coming in, and stuff going out
16:34:01 <edwarnicke> Then we cover all the stuff you might write unit tests for
16:34:16 <regXboi> so I'm not as worried about the JAX-B transcribing
16:34:17 <edwarnicke> Mocking it actually tells us very very little about whether we've done anything wright
16:34:19 <regXboi> that's pretty basic
16:34:19 <edwarnicke> right
16:34:28 <edwarnicke> I am hugely worried about that part
16:34:32 <regXboi> edwarnicke: that's not 100% true her
16:34:34 <edwarnicke> Because particularly replacing moxy
16:34:34 <regXboi> er here
16:34:40 <edwarnicke> That's what we need to preserve
16:34:49 <regXboi> ok, I hear your concern
16:34:56 <edwarnicke> And testing is fundamentally about measuring things you care about and insuring they don't change
16:34:59 <flaviof> edwarnicke: understood. so we start at pax-exam level.
16:35:06 <edwarnicke> Since what we care about is that when REST goes in, stuff comes out
16:35:09 <edwarnicke> That's what we should measure
16:35:17 <regXboi> but when I look at testing, there are methods in the objects that do things to other objects, and *those* can get j-unit test
16:35:33 <edwarnicke> flaviof: Don't let me run over you here... if you have thought of other important unit test level stuff to do... I am all ears ;)
16:35:43 <edwarnicke> regXboi: Example?
16:36:06 <edwarnicke> regXboi: And are those things that are not exercised in the REST-to-stuff path way?
16:36:22 <regXboi> example: IPAllocationPool has a method split, which is designed to allocate an address out of a pool and possibly split it into two pools
16:36:34 <regXboi> we've had defects field against it because it got it wrong in  some cases
16:36:40 <regXboi> and I don't have to stand up rest to test that
16:36:49 <edwarnicke> regXboi: Excellent :)
16:36:53 <regXboi> all I need to do is build junit tests for ALL the necessary cases
16:37:02 <edwarnicke> regXboi: That sort of shit *should* be unit tested once we are confident we are doing it correctly, I agree
16:37:17 <regXboi> so there are methods in the classes that can stand some sort of junit testing in mvn build
16:37:25 * edwarnicke has a slight allergy to accidently requiring bugs in testing by writing tests prematurely
16:37:28 <regXboi> because I don't need a REST framework to tst them
16:37:34 * dfarrell07 thinks this is a great discussion
16:37:42 <edwarnicke> regXboi: I hear you, and agree :)
16:37:48 <edwarnicke> dfarrell07: :)
16:37:51 <regXboi> edwarnicke: good then I'm happy
16:37:58 * edwarnicke is a testing heretic, non-repenting
16:38:08 <regXboi> but I do agree we should also have pax-exam
16:38:15 <edwarnicke> (which does not mean he opposes testing...)
16:38:20 <regXboi> and worry about transcribing as we will be replacing the element that does that for us
16:38:21 <edwarnicke> regXboi: I think we have to
16:38:32 <edwarnicke> regXboi: And I'd like to focus on it for the REST-to-stuff testing
16:38:51 <regXboi> so how about we divide it up this way
16:39:18 <regXboi> I'll look at the low level junit stuff, because I know most of those routines and can point at the ones that need it
16:39:44 <regXboi> the output of that would be wiki pages for what the methods are and what the test cases are so htat we all agree BEFORE we write junit tests
16:39:46 <edwarnicke> regXboi: Many thanks :)
16:40:12 <regXboi> edwarnicke, you get to look at setting up the pax exam for the potential transcribing headaches
16:40:34 <regXboi> and flaviof, I look to you for jjb and the big fancy stuff?
16:40:42 <edwarnicke> regXboi: I am already doing that for: archetype, ovsdb-md-sal-sb, etc, etc,etc so sure
16:40:54 * dfarrell07 has thought/work on big fancy testing stuff
16:41:04 <regXboi> dfarrell07: please, chime in :)
16:41:25 <flaviof> regXboi: right, fancy stuff.
16:41:32 <dfarrell07> I'm doing ODL+O/S integration stuff for the ODL Integration team
16:41:56 <dfarrell07> Been getting feedback on a plan, will share draft...
16:42:12 <dfarrell07> https://gist.github.com/dfarrell07/c2433a7d44c85d77c897
16:42:52 <dfarrell07> More info to come, iterations on that to be made
16:43:00 <dfarrell07> I'll share it via the relevant lists ASAP
16:43:11 <regXboi> #link https://gist.github.com/dfarrell07/c2433a7d44c85d77c897 draft of ODL+O/S integration team plans
16:43:24 <edwarnicke> dfarrell07: Do your efforts include the ability to specify as a parameter the feature(s) to install in ODL for the testing to run (because we have quite a few neutron providers)
16:43:25 <dfarrell07> But vs typing it all here, /me dumps link that will be updated
16:43:27 <regXboi> flaviof: have you see that link?
16:43:38 <flaviof> regXboi: the testing dfarrell07 is talking about touches a lot more than northbound neutron; but is very dependent on it.
16:43:43 * regXboi goes and reads
16:43:48 <dfarrell07> edwarnicke: yes :)
16:43:54 <dfarrell07> edwarnicke: it's a param to the Puppet mod
16:44:01 <edwarnicke> dfarrell07: rockstar :)
16:44:02 <flaviof> regXboi: yes, I see the link ok
16:44:10 <dfarrell07> edwarnicke: so pass diff features and Puppet will re deploy your ODL
16:44:44 <regXboi> dfarrell07: have you got mestery plugged in to this?
16:44:58 <flaviof> edwarnicke: for starters that is odl-ovsdb-openstack, mostly.
16:44:59 <mestery> regXboi: no
16:45:02 <dfarrell07> regXboi: I've just been taking to the devs who built the parts so far
16:45:14 <dfarrell07> hey mestery :)
16:45:21 <mestery> I'm kind of surprised to see that given the overlap in the work already being done there :|
16:45:34 <mestery> I've literally been working on that for 2 weeks now
16:45:51 <mestery> Although dfarrell07's works is in the opposite direction, so yay! :)
16:46:09 <regXboi> mestery: that's why I pulled you in - can you work with dfarrell07 ?
16:46:18 <dfarrell07> mestery: sorry to not have sync'd up sooner
16:46:20 <mestery> Only if flaviof joins in too ;)
16:46:21 <flaviof> mestery: right. for starters, dfarrell07's work does not use devstack.
16:46:28 <dfarrell07> mestery: would love to hear about what you've been up to
16:46:30 <mestery> flaviof: Looks like that way
16:46:32 <regXboi> how about I action the three of you :)
16:46:36 <edwarnicke> mestery: The Iron Law of Open Source: What ever you are working on, there are three other people you don't know who are also working on it :)
16:46:45 <mestery> Honestly folks, until we can pass the Tempest smoke tests, all of this is moot in my opinion
16:46:52 <mestery> Because there are gaping holes in functinoality
16:46:53 <flaviof> mestery: +1
16:46:59 <dfarrell07> +1
16:47:03 <edwarnicke> mestery: What is Tempest smoking ;)
16:47:12 <edwarnicke> mestery: The neutron-northbound stuff is actually *not* moot
16:47:24 <mestery> We fail 56 of 528 smoke tests: http://logs.openstack.org/07/161407/4/gate/gate-tempest-dsvm-networking-odl/78d4cd1/logs/testr_results.html.gz
16:47:29 <edwarnicke> mestery: Because we *know* we need to rip out moxy (we are hacking around its brokenness)
16:47:31 <regXboi> edwarnicke: that is not how I interpreted mestery's statement
16:47:37 <edwarnicke> mestery: And that is a goes-in-goes-out kind of testing
16:47:48 <edwarnicke> mestery: Sorry if I misheard ;)
16:47:49 <regXboi> I interpreted the "all" to mean the fancy testing
16:47:54 <mestery> That is the first run of tempest smoke tests that I posted
16:47:58 <mestery> Good news is we pass a lot
16:48:00 <edwarnicke> mestery: totally concur on fanciness
16:48:02 <mestery> bad news is we fail 56 :)
16:48:19 <edwarnicke> mestery: Does this mean you sorted out the HP Cloud issue?
16:48:20 <regXboi> #link http://logs.openstack.org/07/161407/4/gate/gate-tempest-dsvm-networking-odl/78d4cd1/logs/testr_results.html.gz results of ODL/OS tempest smoke tests
16:48:28 <mestery> edwarnicke: Nope :)
16:48:28 <regXboi> #info we fail 56 of 528
16:48:36 <mestery> thanks regXboi ;)
16:48:41 <regXboi> mestery: no worries
16:48:48 <regXboi> these minutes will be fascinating :)
16:48:49 <mestery> It's not all doom and gloom, because we'll soon be running this in the ODL CI side as well :)
16:48:54 <edwarnicke> mestery: Question... does Helium *eventually* come up?
16:49:12 <mestery> edwarnicke: Yes, for me it does, takes 10+ minutes
16:49:29 <edwarnicke> mestery: OK... so I am all out of ideas on how to make Helium better save one:
16:49:32 <flaviof> mestery: do you think the hp cloud issue is isolated enough we can live w/out it? this odl-nsf-all feature seems like a big hack on Helium... :(
16:49:36 <edwarnicke> mestery: Could we simply wait for Helium to come up?
16:49:52 <mestery> flaviof: To be clear, the "odl-nsf-all" hack doesn't work for me when I try it :)
16:50:10 <mestery> flaviof: But for some reason, it's only my instances that fail this way, the CI ones seem to operate ok most of hte time
16:50:10 <regXboi> time check folks - we've got 10 minutes left - should we take this to post meeting and spend some time on the Yang model?
16:50:12 * mestery is out of ideas
16:50:15 <mestery> ++
16:50:16 <mestery> thanks regXboi
16:50:37 <flaviof> mestery: gotcha. the issue, as I know it is that neutron is buried in a spagetthi bowl we refer to as odl-nsf-all. dep's hell.
16:50:50 <mestery> flaviof: Agreed, that summarizes it well ;)
16:50:54 <regXboi> mestery: not trying to cut you off, just wanting to see if we should spend some time on the other elephant in the room
16:51:00 <mestery> regXboi: We should
16:51:02 <mestery> Please move on
16:51:23 <regXboi> #info testing discussion to continue on IRC and mailing list
16:51:27 <regXboi> #topic Yang Model
16:51:32 * edwarnicke opposes the abuse of elephants
16:51:39 <flaviof> before we move on, its good to know how we could work around this, if possible... wait 10 mins?!?
16:52:00 <regXboi> #undo
16:52:00 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x1a83d50>
16:52:29 <edwarnicke> flaviof: You remember me going on and on and on about how dangerously bad indeterminancy in startup could be?
16:52:35 * edwarnicke sometimes even bores himself
16:53:09 <flaviof> edwarnicke: yeah. i sympathize.
16:53:13 <edwarnicke> flaviof: That 10 minutes is happening because of that
16:53:32 <flaviof> once 10mins do go by, does it work ok?!?
16:54:08 * flaviof recalls other lingering issues with what we thought was related to userManager...
16:54:17 <regXboi> ok folks, I'm sorry, but we really need to spend time on the yang model
16:54:23 <regXboi> #topic yang model
16:54:28 <flaviof> regXboi: np.
16:54:36 <regXboi> #link https://git.opendaylight.org/gerrit/#/c/15989/ a proposed yang model
16:54:45 <regXboi> that tried to merge in and failed
16:54:52 <regXboi> which bothers me a bit
16:55:12 <edwarnicke> TNadeau: Is Kiran around ?
16:55:22 <edwarnicke> regXboi: There are also a lot of comments on that model that need processing
16:55:47 <regXboi> yes, but I thought there was a second proposal out there?
16:55:54 <regXboi> or am I smoking something?
16:56:24 <edwarnicke> regXboi: I don't recall a second proposal currently
16:56:37 <regXboi> edwarnicke: ok, never mind
16:56:57 <regXboi> so in addition to the comments that are on this model that still need to be addressed
16:57:16 <edwarnicke> regXboi: I think Kiran said he would be updating with responses to the comments shortly
16:57:21 <regXboi> I believe we have the outstanding issue that this isn't compatible with http://developer.openstack.org/api-ref-networking-v2.html
16:57:37 <edwarnicke> regXboi: We have lots of outstanding issues right now... lots of comments
16:57:41 <regXboi> one question that came up was whether to have the model as a single file or to break it up
16:57:50 <regXboi> I'm in favor of keeping it as one file for the moment
16:57:55 <edwarnicke> regXboi: and if we break it up, how
16:58:24 <regXboi> edwarnicke: I was thinking of trying to treat the neutron extensions as things that could be overlaid on the basic yang model
16:58:35 <regXboi> and if that is possible, then those items can got into separate files
16:58:59 <regXboi> but I admit to not knowing enough yang to know if I'm just chasing a pipe dream
16:59:01 <edwarnicke> regXboi: So I see two possible dimensions to split
16:59:12 <edwarnicke> a)  Along API (network.yang, router.yang, etc)
16:59:28 <regXboi> edwarnicke: I'm not in favor of (a)
16:59:32 <regXboi> so what's b?
16:59:38 <edwarnicke> b)  Extension-wise (aka, put extensions in their own yang files
16:59:45 <edwarnicke> These are not mutually exclusive
16:59:51 <regXboi> so I was chasing (b)
17:00:02 <edwarnicke> So... I actually also personally like (a)
17:00:16 <regXboi> (a) has the potential for all sorts of version mismatch
17:00:16 <edwarnicke> Because as a habit, (a) requires less updating a particular model over time
17:00:22 <edwarnicke> regXboi: Say more
17:00:30 <regXboi> well, so let's be honest
17:00:48 <regXboi> if you look at http://developer.openstack.org/api-ref-networking-v2.html
17:00:58 <regXboi> then the base neutron (non-extension) yang model has
17:01:19 <regXboi> extensions, netowrks, subnets, and ports
17:01:29 <regXboi> everything else would fall under (b)
17:02:02 <regXboi> *but*
17:02:11 <regXboi> if I look down further under the extensions
17:02:27 <regXboi> I see networks and ports
17:02:38 <edwarnicke> regXboi: Yes
17:02:55 <regXboi> so I'll already have extension models that change the networks and ports
17:03:09 <regXboi> and at that point I might as well break them out
17:03:16 <regXboi> leaving only extensions and subnets
17:03:23 <regXboi> but extensions is itself extended
17:03:26 <regXboi> so...
17:03:33 <regXboi> we're doing both (a) and (b)
17:03:36 <regXboi> Q.E.D.
17:03:45 * regXboi shudders at what he just did
17:03:52 <edwarnicke> regXboi: That was kind of my thought
17:04:00 <flaviof> regXboi: don't forget routers
17:04:11 <regXboi> flaviof: routers are an extension, not base neutron
17:04:43 <flaviof> regXboi: agreed, networks, ports and routers
17:04:50 <regXboi> edwarnicke: yeah I've argued myself around to your approach
17:05:01 <regXboi> but I really don't like the possibility of schema mismatches
17:05:09 <edwarnicke> regXboi: Say more about that
17:05:43 <regXboi> my question is how multiple neutron extensions to say networks, get overlaid on the base yang model
17:05:51 <edwarnicke> regXboi: Ah
17:06:08 <edwarnicke> regXboi: So... I think we should be a little cautious here in how we speak
17:06:18 * regXboi notes we've run over, but I think we need to finish this :)
17:06:27 <edwarnicke> regXboi: Because there are some neutron extensions which just introduce new objects (like router) and some that introduce new fields into existing objects
17:06:41 <regXboi> edwarnicke: agreed - I know that certain terms are dangerous when it comes to yang
17:06:53 <flaviof> edwarnicke: your point is, lets not go crazy on augmentations in yang, right?
17:07:29 <edwarnicke> flaviof: My point is, lets use them appropriately
17:07:31 <edwarnicke> flaviof: Example
17:07:57 <edwarnicke> Router is a brand new object... yes, it an extension from the OpenStack point of view, but from ours it can just be another yang file
17:08:18 * regXboi listens
17:09:41 <regXboi> well, if you are doing the OpenStack extension for routers, then you are also adding "router:external" as an attribute to the network object
17:09:46 <edwarnicke> So you'd have network.yang, port.yang, subnet.yang
17:09:49 <edwarnicke> For the *base* API
17:09:51 <regXboi> and so that modifies the network.yang
17:09:59 <regXboi> that's where I get nervous :)
17:10:11 <edwarnicke> regXboi: yes, and that would be an augmentation coming *from* router.yang
17:10:16 <edwarnicke> No change to network.yang
17:10:30 <regXboi> so here's a thought
17:10:36 <regXboi> we also have extensions.yang
17:10:55 <regXboi> can we use that to help SB providers know what to expect in terms of the yang models?
17:11:43 <kkoushik> hi folks - this is kiran from Brocade - sorry my irc client got timed-out
17:12:05 <regXboi> i.e. if we have the routers OS extension, we say so in the instance data covered by extensions.yang and then SBs know they can depend on router.yang and its augmentation?
17:12:10 <regXboi> kkoushik: welcome
17:12:14 <regXboi> we are running over
17:12:20 <regXboi> but talking the yang model
17:12:25 <edwarnicke> regXboi: I don't like pooring *all* extensions into extensions.yang... they also have logical grouping etc
17:12:44 <regXboi> edwarnicke: ....welll.....
17:12:55 <kkoushik> sure - Anil is going to push the model that we've coded till now(after addressing all open comments)
17:13:07 <regXboi> I'll admit that extensions is RO in neutron
17:13:13 <regXboi> so there is nothing to "put" there
17:13:23 <regXboi> which renders it pretty moot
17:13:54 <kkoushik> I'm working on adding all the extensions into the model
17:13:58 <regXboi> but I was thinking of using it as a form of meta data
17:14:12 <regXboi> kkoushik: yeah, we're likely going to split into multiple files
17:14:19 <regXboi> that's where this conversation has been going
17:14:25 <edwarnicke> kkoushik: Did you follow the conversation about breaking the model up into parts?
17:14:34 <regXboi> edwarnicke: hey may not have been here
17:14:36 <regXboi> er he
17:14:44 <kkoushik> edwarnicke: still catching up
17:14:51 <regXboi> or did I just make a faux-pas?
17:14:56 * regXboi wonders
17:15:22 <edwarnicke> regXboi: kkoushik just joined the channel, and so probably doesn't have the context
17:15:42 <regXboi> edwarnicke: that's what I was worried about
17:15:51 <edwarnicke> regXboi: Could you re-cap for him?
17:16:13 <TNadeau> irc is great except you loose the context if you're using a broken client :P
17:16:14 <kkoushik> if somebody pastes the conversation, its good too
17:16:21 * regXboi notes the wooden ties beneath his feet at the moment he here's the train whistle
17:16:29 * regXboi er hears
17:16:32 <TNadeau> ill copy/paste to you in skype
17:16:36 <TNadeau> so not to pollute the thread here
17:16:44 <regXboi> TNadeau: thanks
17:16:54 <regXboi> but we should recapture with #info
17:17:04 <edwarnicke> regXboi: Do you want to summarize?
17:17:15 <regXboi> #info proposal to break yang model into individual pieces based on the following analysis:
17:17:34 <regXboi> #info base neutron consists of networks, ports, & subnets
17:17:43 <regXboi> #info all other objects/modifications are parts of extensions
17:18:08 <regXboi> #info so if we assume that extensions are covered in separate models to allow for selection
17:18:34 <regXboi> #info then a review of http://developer.openstack.org/api-ref-networking-v2.html shows that extensions will include new network and ports yang models
17:18:54 <regXboi> #info at which point, we might as well break the original base into separate yang models
17:19:04 <regXboi> that cover it?
17:19:10 <edwarnicke> regXboi: Sounds about right :)
17:19:30 <regXboi> and now it is in the minutes
17:19:42 <kkoushik> Thanks for the summary
17:20:10 <regXboi> ok folks, can we add a #action for this and close the meeting down?  we're 20 minutes over and I have a phone call in 10 that I can't ignore
17:20:18 <edwarnicke> sure :)
17:20:29 <regXboi> edwarnicke, can I ask you to draft the action?
17:20:37 <edwarnicke> Who is taking the action?
17:21:11 <kkoushik> #action - kkoushik to add all the extensions into a single model - After a review, it can be split up into multiple models
17:21:26 <edwarnicke> kkoushik: It might be more productive to start with the splitting
17:21:38 <edwarnicke> kkoushik: Because if we can get a nice clean network.yang without exstensions
17:21:46 <edwarnicke> kkoushik: Then folks can start working on transcribing to it etc
17:21:53 <edwarnicke> Break things up into piecs
17:21:54 <edwarnicke> pieces
17:22:02 <kkoushik> ewarnicke: Sure - either way works for me
17:22:02 <edwarnicke> kkoushik: When could you get the first piece by?
17:22:29 <kkoushik> I can get the first piece in by next Wednesday?
17:22:37 <edwarnicke> kkoushik: Way to slow sadly
17:22:38 <kkoushik> If urgent, earlier than that..
17:22:42 <edwarnicke> We are already past M3
17:22:55 <regXboi> #action regXboi to set up meeting wiki page to capture meetbot minutes and create next agenda
17:23:01 <edwarnicke> It would be nice to have all the pieces, reviewed by the community, and in decent starting shape by then
17:23:22 <kkoushik> OK - I'll have all the pieces by Monday for review?
17:23:29 <edwarnicke> kkoushik: Perfect :)
17:23:49 <edwarnicke> kkoushik: My advice would be to throw the patches over the wall piece by piece (first network.yang, etc)
17:23:53 <edwarnicke> kkoushik: Commit early commit often
17:24:05 <edwarnicke> kkoushik: Also makes it easier to discuss
17:24:23 <edwarnicke> kkoushik: And easier to catch things that need to be fixed (like banishing the bizarre use of '.' identifiers etc
17:24:24 <kkoushik> edwarnicke: Agreed - will get to it asap
17:24:30 <edwarnicke> kkoushik: Many thanks
17:24:38 <edwarnicke> kkoushik: Feel free to ping me if you need anything :)
17:24:40 <regXboi> ok, I think that covers it?
17:24:43 <regXboi> accept for...
17:24:44 <edwarnicke> regXboi: Shall we endmeeting ?
17:24:49 <regXboi> #topic chocolate muffins
17:24:52 <regXboi> #endmeeting