#opendaylight-meeting: Karaf Mtg #2

Meeting started by phrobb at 01:06:18 UTC (full logs).

Meeting summary

  1. Project Contacts please #info in with the Project you are representing (phrobb, 01:07:42)
    1. colindixon for TTP (colindixon, 01:09:05)
    2. Christine is here for SNMP4SDN (I think) (colindixon, 01:11:22)

  2. project expectations (colindixon, 01:12:27)
    1. at a high level, we need some information about projects like a description, etc. (colindixon, 01:13:15)
    2. https://wiki.opendaylight.org/view/Simultaneous_Release:Project_Expectations the page descripbing expectations (including an example of the metadata in the line above) (colindixon, 01:14:18)
    3. just to be clear, this is *not* a pom.xml flie, it’s a metadata file to descibe key things about a project (colindixon, 01:14:55)
    4. also to be clear, the version in this file has no semantic impact or relation to bundles (colindixon, 01:16:36)
    5. the key element in this is the <component> tag (colindixon, 01:19:02)
    6. the version here does have *some* meaning because it’s used for very high level dependency tracking (colindixon, 01:20:30)
    7. lifecycle here is *not* the lifecycle stage of the project, but it is the stability/lifecycle stage of the component (colindixon, 01:21:24)
    8. colindixon suggests that there should be a lifecycle type at the <project> level that is the project’s lifecycle stage and maybe name lifecycle in a component something else (or at least document it well) (colindixon, 01:23:18)
    9. colindixon asks how many components a project will typically have (colindixon, 01:24:10)
    10. answer is 3-4 max except the controller, for example, the MD-SAL would be a component (colindixon, 01:24:28)
    11. going forward, we’re going to need to define the possible values for things like <type> or <category> , but we wanted to get the idea out first (colindixon, 01:25:17)
    12. phrobb asks if component is *the* level at which users can install and uninstall things, not features, not projects (colindixon, 01:27:05)
    13. mathieu says yes, that’s his idea, it’s up to the community to pick it or not (colindixon, 01:27:30)
    14. LuisGomez adds that this is useful because we can’t have O(100) features, which we do (colindixon, 01:28:32)
    15. at a technical level, features are the unit which can be installed and activated individually, but we’re going to provide extra tooling around it at the component level (colindixon, 01:29:32)

  3. packaging (colindixon, 01:30:07)
    1. the suggestion is to allow for a variety of packaging approaches, one of which is karaf (colindixon, 01:30:50)
    2. https://wiki.opendaylight.org/view/Runtime:Karaf_Features_Guidelines guidelines for creating karaf features (colindixon, 01:31:11)
    3. features are basically a way to group a set of OSGi bundles to make them easier to manage and easier for others to depend on (colindixon, 01:32:37)
    4. there’s a lot of description of guidelines about how to craft features, naming, granularity, versioning, etc. (colindixon, 01:34:19)

  4. documentation (colindixon, 01:35:00)
    1. proposal is to use maven sites to make this somewhat easier to deal with (colindixon, 01:35:16)
    2. https://wiki.opendaylight.org/view/OpenDaylight_Controller:How_To:_Site_Deploy this has documentation on how to do that (colindixon, 01:35:56)
    3. colindixon asks about the <documentation> tag in the <component> tag and how it relates to this because it has a <site> tag and an <apiLocation> tag (colindixon, 01:37:43)
    4. response is that the <apiLocation> is for more traditional REST APIs we used in the AD-SAL (not clear if RESTCONF will fit in here yet) (colindixon, 01:38:54)
    5. the site is the maven site and will include javadoc (colindixon, 01:39:05)
    6. some discussion on RESTCONF and ways we could proceed. Mathieu asks if there’s a way to get a wadl from the stuff. colindixon doesn’t know if this is possible to do that. (colindixon, 01:43:25)
    7. ACTION: colindixon will think about this a bit and get back in touch with people (colindixon, 01:43:42)

  5. testing (colindixon, 01:47:14)
    1. testing will be covered in a similar set of meetings next week at the same time (colindixon, 01:47:29)
    2. ACTION: phrobb to send out meeting invites to cover testing next week (colindixon, 01:47:45)
    3. Thomas Kee packetcable equally useful meeting (xsited, 01:52:06)

  6. other things going forward (colindixon, 01:54:36)
    1. some discussion about how/when we should advertise what a component is and how we’re going to use them (colindixon, 01:55:16)
    2. phrobb says probably tomorrow’s TSC is too soon to do this and we probably do want the TSC to bless this (colindixon, 01:55:55)
    3. maybe take until *next* week’s thing is to get a list of components that we expect in the Helium release (colindixon, 01:57:24)
    4. it seems like something like 1-2 components per project on average is about right, so that means ~50 total in Helium (colindixon, 01:57:51)
    5. part of making that sane to show to the user is using categorization so components that are libraries should *not* be shown to a user (colindixon, 01:58:28)


Meeting ended at 02:04:11 UTC (full logs).

Action items

  1. colindixon will think about this a bit and get back in touch with people
  2. phrobb to send out meeting invites to cover testing next week


Action items, by person

  1. colindixon
    1. colindixon will think about this a bit and get back in touch with people
  2. phrobb
    1. phrobb to send out meeting invites to cover testing next week


People present (lines said)

  1. colindixon (43)
  2. odl_meetbot (4)
  3. phrobb (4)
  4. xsited (1)


Generated by MeetBot 0.1.4.