Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation
For Apex, we have a wiki page where we try to keep a log of all the upstream work we have done (although I'm sure we are missing things). Might be a good place to start if we want to try to highlight upstream work: https://wiki.opnfv.org/display/apex/Upstream+Tracking Tim Rozet Red Hat SDN Team - Original Message - From: "Prodip Sen" To: "Heather Kirksey" , "BIN HU" Cc: opnfv-project-le...@lists.opnfv.org, "TECH-DISCUSS OPNFV" Sent: Wednesday, September 7, 2016 11:22:18 AM Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation This is absolutely one of the value-adds that OPNFV brings to the table – very much in line with part of the current mission statement we have been iterating on: “ .. by facilitating the development and evolution of NFV components in upstream open source projects and …”. We may need our Marketing colleagues to help us get the right balance of language as we publicize this, but I think we should absolutely do so. And in terms of tracking OPNFV contributions and progress, we should track and report on these type of artifacts too. - Prodip From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Heather Kirksey Sent: Wednesday, September 7, 2016 10:59 AM To: HU, BIN Cc: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation Tim and Bin Hu, Great stuff, thanks. I'm simply wondering if there's a way for us to communicate more formally to the industry on some of the things that we've learned for those who aren't involved as deeply in the development/bug-fixing work or reading our (awesome) documentation in detail. This would obviously need to be balanced with a desire to be respectful to our upstreams and their evolving capabilities. I'll spend some time noodling on this but I'd continue to love to hear more thoughts from y'all. Heather On Fri, Sep 2, 2016 at 3:14 PM, HU, BIN < bh5...@att.com > wrote: Regarding the knowledge of specific strength and weakness in upstream releases, we have done this type of gap analysis in IPv6. For example: - In Brahmaputra, we evaluated Liberty and Beryllium: o http://artifacts.opnfv.org/opnfvdocs/brahmaputra/docs/userguide/featureusage-ipv6.html - In Colorado we evaluated Mitaka and Boron: o http://artifacts.opnfv.org/ipv6/docs/userguide/index.html o Old NetVirt (odl-ovsdb-openstack) and new NetVirt (odl-netvirt-openstack) were evaluated in terms of IPv6 gap analysis Certainly, this type of gap analysis and knowledge is the value OPNFV provided to industry as well. Thanks Bin From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto: opnfv-tech-discuss-boun...@lists.opnfv.org ] On Behalf Of Heather Kirksey Sent: Friday, September 02, 2016 1:24 PM To: Tim Rozet < tro...@redhat.com > Cc: opnfv-project-le...@lists.opnfv.org ; TECH-DISCUSS OPNFV < opnfv-tech-discuss@lists.opnfv.org > Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation It feels like perhaps we need a more nuanced understanding of what we mean by our "use" of upstream components. If I am understanding some of the conversations correctly, Be might be more generally overall stable, but doesn't enable key capabilities (or has higher instability) around VPN and SFC advancement. B might be more stable around those features but has some instability around other features like HA, and that some scenarios might find one or the other more appropriate depending on their focus. Is this an accurate characterization? If it is, it seems as though we're in an interesting position to understand at system level where specific strengths and weaknesses are in upstream releases, and that knowledge itself might be valuable for our ecosystem. With an overall mission of advancing and accelerating NFV, does this sort of knowledge capture possibly fit into our deliverables as much as release creation and upstream influence. And, yes, I realize our documentation should and likely does capture this sort of thing, but I'm wondering about elevating this sort of knowledge in terms of our value to the industry. This is merely speculative thinking meant to spur some conversation rather than an assertion, but I'm curious to hear thoughts from people. Heather On Fri, Sep 2, 2016 at 11:42 AM, Tim Rozet < tro...@redhat.com > wrote: I don't see any issue here. Colorado 1.0 is set to use Beryllium, which is already released. Even the scenarios that require Boron (FDS/SFC) do not require ODL HA, and we already have Boron
Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation
This is absolutely one of the value-adds that OPNFV brings to the table – very much in line with part of the current mission statement we have been iterating on: “ .. by facilitating the development and evolution of NFV components in upstream open source projects and …”. We may need our Marketing colleagues to help us get the right balance of language as we publicize this, but I think we should absolutely do so. And in terms of tracking OPNFV contributions and progress, we should track and report on these type of artifacts too. - Prodip From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Heather Kirksey Sent: Wednesday, September 7, 2016 10:59 AM To: HU, BIN Cc: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation Tim and Bin Hu, Great stuff, thanks. I'm simply wondering if there's a way for us to communicate more formally to the industry on some of the things that we've learned for those who aren't involved as deeply in the development/bug-fixing work or reading our (awesome) documentation in detail. This would obviously need to be balanced with a desire to be respectful to our upstreams and their evolving capabilities. I'll spend some time noodling on this but I'd continue to love to hear more thoughts from y'all. Heather On Fri, Sep 2, 2016 at 3:14 PM, HU, BIN mailto:bh5...@att.com>> wrote: Regarding the knowledge of specific strength and weakness in upstream releases, we have done this type of gap analysis in IPv6. For example: - In Brahmaputra, we evaluated Liberty and Beryllium: o http://artifacts.opnfv.org/opnfvdocs/brahmaputra/docs/userguide/featureusage-ipv6.html - In Colorado we evaluated Mitaka and Boron: o http://artifacts.opnfv.org/ipv6/docs/userguide/index.html o Old NetVirt (odl-ovsdb-openstack) and new NetVirt (odl-netvirt-openstack) were evaluated in terms of IPv6 gap analysis Certainly, this type of gap analysis and knowledge is the value OPNFV provided to industry as well. Thanks Bin From: opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>] On Behalf Of Heather Kirksey Sent: Friday, September 02, 2016 1:24 PM To: Tim Rozet mailto:tro...@redhat.com>> Cc: opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>; TECH-DISCUSS OPNFV mailto:opnfv-tech-discuss@lists.opnfv.org>> Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation It feels like perhaps we need a more nuanced understanding of what we mean by our "use" of upstream components. If I am understanding some of the conversations correctly, Be might be more generally overall stable, but doesn't enable key capabilities (or has higher instability) around VPN and SFC advancement. B might be more stable around those features but has some instability around other features like HA, and that some scenarios might find one or the other more appropriate depending on their focus. Is this an accurate characterization? If it is, it seems as though we're in an interesting position to understand at system level where specific strengths and weaknesses are in upstream releases, and that knowledge itself might be valuable for our ecosystem. With an overall mission of advancing and accelerating NFV, does this sort of knowledge capture possibly fit into our deliverables as much as release creation and upstream influence. And, yes, I realize our documentation should and likely does capture this sort of thing, but I'm wondering about elevating this sort of knowledge in terms of our value to the industry. This is merely speculative thinking meant to spur some conversation rather than an assertion, but I'm curious to hear thoughts from people. Heather On Fri, Sep 2, 2016 at 11:42 AM, Tim Rozet mailto:tro...@redhat.com>> wrote: I don't see any issue here. Colorado 1.0 is set to use Beryllium, which is already released. Even the scenarios that require Boron (FDS/SFC) do not require ODL HA, and we already have Boron RC builds that work. ODL HA is known to be buggy, so at least in Apex we don't enable it. Tim Rozet Red Hat SDN Team - Original Message - From: "David McBride" mailto:dmcbr...@linuxfoundation.org>> To: "Christopher Price" mailto:chrispric...@gmail.com>> Cc: opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>, "TECH-DISCUSS OPNFV" mailto:opnfv-tech-discuss@lists.opnfv.org>> Sent: Friday, September 2, 2016 1:24:13 PM Subject: Re: [opnfv-project
Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation
Tim and Bin Hu, Great stuff, thanks. I'm simply wondering if there's a way for us to communicate more formally to the industry on some of the things that we've learned for those who aren't involved as deeply in the development/bug-fixing work or reading our (awesome) documentation in detail. This would obviously need to be balanced with a desire to be respectful to our upstreams and their evolving capabilities. I'll spend some time noodling on this but I'd continue to love to hear more thoughts from y'all. Heather On Fri, Sep 2, 2016 at 3:14 PM, HU, BIN wrote: > Regarding the knowledge of specific strength and weakness in upstream > releases, we have done this type of gap analysis in IPv6. For example: > > > > - In Brahmaputra, we evaluated Liberty and Beryllium: > > o http://artifacts.opnfv.org/opnfvdocs/brahmaputra/docs/ > userguide/featureusage-ipv6.html > > - In Colorado we evaluated Mitaka and Boron: > > o http://artifacts.opnfv.org/ipv6/docs/userguide/index.html > > o Old NetVirt (odl-ovsdb-openstack) and new NetVirt > (odl-netvirt-openstack) were evaluated in terms of IPv6 gap analysis > > > > Certainly, this type of gap analysis and knowledge is the value OPNFV > provided to industry as well. > > > > Thanks > > Bin > > > > *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto: > opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *Heather Kirksey > *Sent:* Friday, September 02, 2016 1:24 PM > *To:* Tim Rozet > *Cc:* opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV < > opnfv-tech-discuss@lists.opnfv.org> > *Subject:* Re: [opnfv-tech-discuss] [opnfv-project-leads] > [release][hackfest] Release Milestone Review presentation > > > > It feels like perhaps we need a more nuanced understanding of what we mean > by our "use" of upstream components. If I am understanding some of the > conversations correctly, Be might be more generally overall stable, but > doesn't enable key capabilities (or has higher instability) around VPN and > SFC advancement. B might be more stable around those features but has some > instability around other features like HA, and that some scenarios might > find one or the other more appropriate depending on their focus. > > > > Is this an accurate characterization? > > > > If it is, it seems as though we're in an interesting position to > understand at system level where specific strengths and weaknesses are in > upstream releases, and that knowledge itself might be valuable for our > ecosystem. > > > > With an overall mission of advancing and accelerating NFV, does this sort > of knowledge capture possibly fit into our deliverables as much as release > creation and upstream influence. > > > > And, yes, I realize our documentation should and likely does capture this > sort of thing, but I'm wondering about elevating this sort of knowledge in > terms of our value to the industry. > > > > This is merely speculative thinking meant to spur some conversation rather > than an assertion, but I'm curious to hear thoughts from people. > > > > Heather > > > > On Fri, Sep 2, 2016 at 11:42 AM, Tim Rozet wrote: > > I don't see any issue here. Colorado 1.0 is set to use Beryllium, which > is already released. Even the scenarios that require Boron (FDS/SFC) do > not require ODL HA, and we already have Boron RC builds that work. ODL HA > is known to be buggy, so at least in Apex we don't enable it. > > Tim Rozet > Red Hat SDN Team > > > - Original Message - > From: "David McBride" > To: "Christopher Price" > Cc: opnfv-project-le...@lists.opnfv.org, "TECH-DISCUSS OPNFV" < > opnfv-tech-discuss@lists.opnfv.org> > Sent: Friday, September 2, 2016 1:24:13 PM > Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] > [release][hackfest] Release Milestone Review presentation > > Chris, > > As I understand it, some projects are planning to use Beryllium. Do we > know if the blockers effect both Beryllium and Boron, or is it just Boron? > If it's just Boron, then the projects that depend on Beryllium could > release at Colorado 1.0, while the projects that depend on Boron could > release at Colorado 2.0 or 3.0. > > In fact, I heard from Greg Elkinbard, yesterday, who said that scenarios > running on Fuel will be transitioning to Boron for Colorado 2.0. > > David > > On Fri, Sep 2, 2016 at 2:36 AM, Christopher Price < chrispric...@gmail.com > > wrote: > > > > > > Hi Folks, > > > > Hard rules can be hard to find in an environment like ours.
Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation
Regarding the knowledge of specific strength and weakness in upstream releases, we have done this type of gap analysis in IPv6. For example: - In Brahmaputra, we evaluated Liberty and Beryllium: o http://artifacts.opnfv.org/opnfvdocs/brahmaputra/docs/userguide/featureusage-ipv6.html - In Colorado we evaluated Mitaka and Boron: o http://artifacts.opnfv.org/ipv6/docs/userguide/index.html o Old NetVirt (odl-ovsdb-openstack) and new NetVirt (odl-netvirt-openstack) were evaluated in terms of IPv6 gap analysis Certainly, this type of gap analysis and knowledge is the value OPNFV provided to industry as well. Thanks Bin From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Heather Kirksey Sent: Friday, September 02, 2016 1:24 PM To: Tim Rozet Cc: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation It feels like perhaps we need a more nuanced understanding of what we mean by our "use" of upstream components. If I am understanding some of the conversations correctly, Be might be more generally overall stable, but doesn't enable key capabilities (or has higher instability) around VPN and SFC advancement. B might be more stable around those features but has some instability around other features like HA, and that some scenarios might find one or the other more appropriate depending on their focus. Is this an accurate characterization? If it is, it seems as though we're in an interesting position to understand at system level where specific strengths and weaknesses are in upstream releases, and that knowledge itself might be valuable for our ecosystem. With an overall mission of advancing and accelerating NFV, does this sort of knowledge capture possibly fit into our deliverables as much as release creation and upstream influence. And, yes, I realize our documentation should and likely does capture this sort of thing, but I'm wondering about elevating this sort of knowledge in terms of our value to the industry. This is merely speculative thinking meant to spur some conversation rather than an assertion, but I'm curious to hear thoughts from people. Heather On Fri, Sep 2, 2016 at 11:42 AM, Tim Rozet mailto:tro...@redhat.com>> wrote: I don't see any issue here. Colorado 1.0 is set to use Beryllium, which is already released. Even the scenarios that require Boron (FDS/SFC) do not require ODL HA, and we already have Boron RC builds that work. ODL HA is known to be buggy, so at least in Apex we don't enable it. Tim Rozet Red Hat SDN Team - Original Message - From: "David McBride" mailto:dmcbr...@linuxfoundation.org>> To: "Christopher Price" mailto:chrispric...@gmail.com>> Cc: opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>, "TECH-DISCUSS OPNFV" mailto:opnfv-tech-discuss@lists.opnfv.org>> Sent: Friday, September 2, 2016 1:24:13 PM Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][hackfest] Release Milestone Review presentation Chris, As I understand it, some projects are planning to use Beryllium. Do we know if the blockers effect both Beryllium and Boron, or is it just Boron? If it's just Boron, then the projects that depend on Beryllium could release at Colorado 1.0, while the projects that depend on Boron could release at Colorado 2.0 or 3.0. In fact, I heard from Greg Elkinbard, yesterday, who said that scenarios running on Fuel will be transitioning to Boron for Colorado 2.0. David On Fri, Sep 2, 2016 at 2:36 AM, Christopher Price < chrispric...@gmail.com<mailto:chrispric...@gmail.com> > wrote: Hi Folks, Hard rules can be hard to find in an environment like ours. J I think we need in some cases to have “expectations” and allow the release project to evaluate how those “expectations” are met. In other cases, the “expectations” are pretty straightforward. We need to somehow articulate our developmental and testing needs while making room for the fact that we are not in complete control of our dependencies. For example, I was on the OpenDaylight TSC call yesterday and they are considering a potential small delay in their release dates due to some “blockers” on OpenFlowPlugin and NetVirt specifically for HA. These blockers impact us directly. These issues may further result in a delay for the ODL release version to be built and made available. We have 2 options to take here: 1) Take an older version of ODL, that we know has issues directly related to our use of ODL. (carry these blocking bugs through Colorado 1.0) 2) Iterate our version and take in the release that fixes the blocking bugs. This relates very much to the fact that resolving issues in our
Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation
Chris, HA in the scenario name has traditionally meant OpenStack HA, not SDN controller HA (since it wasn't available in previous OPNFV releases). We tried to enable ODL HA at the beginning of this release cycle, and saw it was unstable so we defaulted it to off in deployments. I'm not sure if other installers are enabling it or not. Tim Rozet Red Hat SDN Team - Original Message - From: "Christopher Price" To: "Tim Rozet" Cc: "David McBride" , opnfv-project-le...@lists.opnfv.org, "TECH-DISCUSS OPNFV" Sent: Friday, September 2, 2016 5:07:52 PM Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][hackfest] Release Milestone Review presentation Hi Tim, Just a clarification. On the wiki I see this scenario listed for Colorado 1.0 - os-odl_l3-vpp-ha. Is this accurate or is it a noha scenario? / Chris Sent from my iPhone > On Sep 2, 2016, at 20:42, Tim Rozet wrote: > > I don't see any issue here. Colorado 1.0 is set to use Beryllium, which is > already released. Even the scenarios that require Boron (FDS/SFC) do not > require ODL HA, and we already have Boron RC builds that work. ODL HA is > known to be buggy, so at least in Apex we don't enable it. > > Tim Rozet > Red Hat SDN Team > > - Original Message - > From: "David McBride" > To: "Christopher Price" > Cc: opnfv-project-le...@lists.opnfv.org, "TECH-DISCUSS OPNFV" > > Sent: Friday, September 2, 2016 1:24:13 PM > Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][hackfest] > Release Milestone Review presentation > > Chris, > > As I understand it, some projects are planning to use Beryllium. Do we know > if the blockers effect both Beryllium and Boron, or is it just Boron? If it's > just Boron, then the projects that depend on Beryllium could release at > Colorado 1.0, while the projects that depend on Boron could release at > Colorado 2.0 or 3.0. > > In fact, I heard from Greg Elkinbard, yesterday, who said that scenarios > running on Fuel will be transitioning to Boron for Colorado 2.0. > > David > > On Fri, Sep 2, 2016 at 2:36 AM, Christopher Price < chrispric...@gmail.com > > wrote: > > > > > > Hi Folks, > > > > Hard rules can be hard to find in an environment like ours. J > > I think we need in some cases to have “expectations” and allow the release > project to evaluate how those “expectations” are met. In other cases, the > “expectations” are pretty straightforward. > > > > We need to somehow articulate our developmental and testing needs while > making room for the fact that we are not in complete control of our > dependencies. > > > > > > For example, I was on the OpenDaylight TSC call yesterday and they are > considering a potential small delay in their release dates due to some > “blockers” on OpenFlowPlugin and NetVirt specifically for HA. These blockers > impact us directly. These issues may further result in a delay for the ODL > release version to be built and made available. > > > > We have 2 options to take here: > > 1) Take an older version of ODL, that we know has issues directly related to > our use of ODL. > (carry these blocking bugs through Colorado 1.0) > > 2) Iterate our version and take in the release that fixes the blocking bugs. > > > > This relates very much to the fact that resolving issues in our own > troubleshooting is for the most part dependent on upstream communities being > able to resolve issues we identify. (or finding workarounds) > > > > In my mind it is very hard to find a “rule” we can apply here as each > situation is different. > > For this example I believe the best way to solve this would be to have a > phase at “code freeze” where we discuss issues and manage the patches that we > allow into the release. Maybe this is something to consider for D release > where David could arrange a small team that facilitates these decisions after > code freeze. > > > > > For now, David has only one recourse and that is to ask the TSC for a > decision on patches and version stepping. > > > > > I do hope however that we can work together for D to continue to drive for a > methodology that keeps us from a massive rush in the last months but enables > fast and efficient integration of new code… > > > > / Chris > > > > > From: < opnfv-tech-discuss-boun...@lists.opnfv.org > on behalf of Ulrich > Kleber < ulrich.kle...@huawei.com > > Date: Friday 2 September 2016 at 11:09 > To: David McBride < dmcbr...@linuxfoundation.org >, opnfv-project-leads < > opnfv-project-le...@lists.opnfv.org >, TECH-DISCUSS OPNFV < > opnfv-tech-discuss@lists.opnfv.org > > Subject: Re: [opnfv-tech-discuss] [release][hackfest] Release Milestone > Review presentation > > > > > > Hi David, > > I remember we had some issues understanding the meaning of the “feature > freeze” milestone. > > While reading again the lessons learned, I remembered that in former projects > I
Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation
Hi Heather, Please see inline. Tim Rozet Red Hat SDN Team - Original Message - From: "Heather Kirksey" To: "Tim Rozet" Cc: "David McBride" , opnfv-project-le...@lists.opnfv.org, "Christopher Price" , "TECH-DISCUSS OPNFV" Sent: Friday, September 2, 2016 4:24:09 PM Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][hackfest] Release Milestone Review presentation It feels like perhaps we need a more nuanced understanding of what we mean by our "use" of upstream components. If I am understanding some of the conversations correctly, Be might be more generally overall stable, but doesn't enable key capabilities (or has higher instability) around VPN and SFC advancement. B might be more stable around those features but has some instability around other features like HA, and that some scenarios might find one or the other more appropriate depending on their focus. Is this an accurate characterization? #trozet> Yeah, that's right. For example, if there are bugs in ODL with netvirt, it doesn't even apply to the FDS scenarios, because they use GBP and don't even load netvirt. So it really depends on the scenario. If it is, it seems as though we're in an interesting position to understand at system level where specific strengths and weaknesses are in upstream releases, and that knowledge itself might be valuable for our ecosystem. With an overall mission of advancing and accelerating NFV, does this sort of knowledge capture possibly fit into our deliverables as much as release creation and upstream influence. And, yes, I realize our documentation should and likely does capture this sort of thing, but I'm wondering about elevating this sort of knowledge in terms of our value to the industry. #trozet> I think we do try to do this. Maybe it isn't highlighted often, but OPNFV engineers are constantly talking to upstream and providing feedback/bugs/fixes. Especially in the ODL/OpenStack projects. ODL guys prioritize fixes for us on OPNFV based on our release schedule, which also is great. This is merely speculative thinking meant to spur some conversation rather than an assertion, but I'm curious to hear thoughts from people. Heather On Fri, Sep 2, 2016 at 11:42 AM, Tim Rozet wrote: > I don't see any issue here. Colorado 1.0 is set to use Beryllium, which > is already released. Even the scenarios that require Boron (FDS/SFC) do > not require ODL HA, and we already have Boron RC builds that work. ODL HA > is known to be buggy, so at least in Apex we don't enable it. > > Tim Rozet > Red Hat SDN Team > > - Original Message - > From: "David McBride" > To: "Christopher Price" > Cc: opnfv-project-le...@lists.opnfv.org, "TECH-DISCUSS OPNFV" < > opnfv-tech-discuss@lists.opnfv.org> > Sent: Friday, September 2, 2016 1:24:13 PM > Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] > [release][hackfest] Release Milestone Review presentation > > Chris, > > As I understand it, some projects are planning to use Beryllium. Do we > know if the blockers effect both Beryllium and Boron, or is it just Boron? > If it's just Boron, then the projects that depend on Beryllium could > release at Colorado 1.0, while the projects that depend on Boron could > release at Colorado 2.0 or 3.0. > > In fact, I heard from Greg Elkinbard, yesterday, who said that scenarios > running on Fuel will be transitioning to Boron for Colorado 2.0. > > David > > On Fri, Sep 2, 2016 at 2:36 AM, Christopher Price < chrispric...@gmail.com > > wrote: > > > > > > Hi Folks, > > > > Hard rules can be hard to find in an environment like ours. J > > I think we need in some cases to have “expectations” and allow the release > project to evaluate how those “expectations” are met. In other cases, the > “expectations” are pretty straightforward. > > > > We need to somehow articulate our developmental and testing needs while > making room for the fact that we are not in complete control of our > dependencies. > > > > > > For example, I was on the OpenDaylight TSC call yesterday and they are > considering a potential small delay in their release dates due to some > “blockers” on OpenFlowPlugin and NetVirt specifically for HA. These > blockers impact us directly. These issues may further result in a delay for > the ODL release version to be built and made available. > > > > We have 2 options to take here: > > 1) Take an older version of ODL, that we know has issues directly related > to our use of ODL. > (carry these blocking bugs through Colorado 1.0) > > 2) Iterate our version and take in the release that fixes the blocking > bugs. > > > > This relates very much to the fact that resolving issues in our own > troubleshooting is for the most part dependent on upstream communities > being able to resolve issues we identify. (or finding workarounds) > > > > In my mind it is very hard to find a “rule” we can apply here as each > situation is different. > > For this example I believe the best way to solve this w
Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation
Hi Tim, Just a clarification. On the wiki I see this scenario listed for Colorado 1.0 - os-odl_l3-vpp-ha. Is this accurate or is it a noha scenario? / Chris Sent from my iPhone > On Sep 2, 2016, at 20:42, Tim Rozet wrote: > > I don't see any issue here. Colorado 1.0 is set to use Beryllium, which is > already released. Even the scenarios that require Boron (FDS/SFC) do not > require ODL HA, and we already have Boron RC builds that work. ODL HA is > known to be buggy, so at least in Apex we don't enable it. > > Tim Rozet > Red Hat SDN Team > > - Original Message - > From: "David McBride" > To: "Christopher Price" > Cc: opnfv-project-le...@lists.opnfv.org, "TECH-DISCUSS OPNFV" > > Sent: Friday, September 2, 2016 1:24:13 PM > Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][hackfest] > Release Milestone Review presentation > > Chris, > > As I understand it, some projects are planning to use Beryllium. Do we know > if the blockers effect both Beryllium and Boron, or is it just Boron? If it's > just Boron, then the projects that depend on Beryllium could release at > Colorado 1.0, while the projects that depend on Boron could release at > Colorado 2.0 or 3.0. > > In fact, I heard from Greg Elkinbard, yesterday, who said that scenarios > running on Fuel will be transitioning to Boron for Colorado 2.0. > > David > > On Fri, Sep 2, 2016 at 2:36 AM, Christopher Price < chrispric...@gmail.com > > wrote: > > > > > > Hi Folks, > > > > Hard rules can be hard to find in an environment like ours. J > > I think we need in some cases to have “expectations” and allow the release > project to evaluate how those “expectations” are met. In other cases, the > “expectations” are pretty straightforward. > > > > We need to somehow articulate our developmental and testing needs while > making room for the fact that we are not in complete control of our > dependencies. > > > > > > For example, I was on the OpenDaylight TSC call yesterday and they are > considering a potential small delay in their release dates due to some > “blockers” on OpenFlowPlugin and NetVirt specifically for HA. These blockers > impact us directly. These issues may further result in a delay for the ODL > release version to be built and made available. > > > > We have 2 options to take here: > > 1) Take an older version of ODL, that we know has issues directly related to > our use of ODL. > (carry these blocking bugs through Colorado 1.0) > > 2) Iterate our version and take in the release that fixes the blocking bugs. > > > > This relates very much to the fact that resolving issues in our own > troubleshooting is for the most part dependent on upstream communities being > able to resolve issues we identify. (or finding workarounds) > > > > In my mind it is very hard to find a “rule” we can apply here as each > situation is different. > > For this example I believe the best way to solve this would be to have a > phase at “code freeze” where we discuss issues and manage the patches that we > allow into the release. Maybe this is something to consider for D release > where David could arrange a small team that facilitates these decisions after > code freeze. > > > > > For now, David has only one recourse and that is to ask the TSC for a > decision on patches and version stepping. > > > > > I do hope however that we can work together for D to continue to drive for a > methodology that keeps us from a massive rush in the last months but enables > fast and efficient integration of new code… > > > > / Chris > > > > > From: < opnfv-tech-discuss-boun...@lists.opnfv.org > on behalf of Ulrich > Kleber < ulrich.kle...@huawei.com > > Date: Friday 2 September 2016 at 11:09 > To: David McBride < dmcbr...@linuxfoundation.org >, opnfv-project-leads < > opnfv-project-le...@lists.opnfv.org >, TECH-DISCUSS OPNFV < > opnfv-tech-discuss@lists.opnfv.org > > Subject: Re: [opnfv-tech-discuss] [release][hackfest] Release Milestone > Review presentation > > > > > > Hi David, > > I remember we had some issues understanding the meaning of the “feature > freeze” milestone. > > While reading again the lessons learned, I remembered that in former projects > I worked on, > > we called that milestone “code complete”. These two words for me quickly > associate that I should > > have now created my code, but would still be able to do some changes for > fixing bugs. > > Just an idea. Maybe give it a thought > > Cheers, > > Uli > > > > > From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto: > opnfv-tech-discuss-boun...@lists.opnfv.org ] On Behalf Of David McBride > Sent: Wednesday, 24 August, 2016 20:55 > To: opnfv-project-le...@lists.opnfv.org ; TECH-DISCUSS OPNFV > Subject: [opnfv-tech-discuss] [release][hackfest] Release Milestone Review > presentation > > > > > > Thanks to those of you that attended
Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation
It feels like perhaps we need a more nuanced understanding of what we mean by our "use" of upstream components. If I am understanding some of the conversations correctly, Be might be more generally overall stable, but doesn't enable key capabilities (or has higher instability) around VPN and SFC advancement. B might be more stable around those features but has some instability around other features like HA, and that some scenarios might find one or the other more appropriate depending on their focus. Is this an accurate characterization? If it is, it seems as though we're in an interesting position to understand at system level where specific strengths and weaknesses are in upstream releases, and that knowledge itself might be valuable for our ecosystem. With an overall mission of advancing and accelerating NFV, does this sort of knowledge capture possibly fit into our deliverables as much as release creation and upstream influence. And, yes, I realize our documentation should and likely does capture this sort of thing, but I'm wondering about elevating this sort of knowledge in terms of our value to the industry. This is merely speculative thinking meant to spur some conversation rather than an assertion, but I'm curious to hear thoughts from people. Heather On Fri, Sep 2, 2016 at 11:42 AM, Tim Rozet wrote: > I don't see any issue here. Colorado 1.0 is set to use Beryllium, which > is already released. Even the scenarios that require Boron (FDS/SFC) do > not require ODL HA, and we already have Boron RC builds that work. ODL HA > is known to be buggy, so at least in Apex we don't enable it. > > Tim Rozet > Red Hat SDN Team > > - Original Message - > From: "David McBride" > To: "Christopher Price" > Cc: opnfv-project-le...@lists.opnfv.org, "TECH-DISCUSS OPNFV" < > opnfv-tech-discuss@lists.opnfv.org> > Sent: Friday, September 2, 2016 1:24:13 PM > Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] > [release][hackfest] Release Milestone Review presentation > > Chris, > > As I understand it, some projects are planning to use Beryllium. Do we > know if the blockers effect both Beryllium and Boron, or is it just Boron? > If it's just Boron, then the projects that depend on Beryllium could > release at Colorado 1.0, while the projects that depend on Boron could > release at Colorado 2.0 or 3.0. > > In fact, I heard from Greg Elkinbard, yesterday, who said that scenarios > running on Fuel will be transitioning to Boron for Colorado 2.0. > > David > > On Fri, Sep 2, 2016 at 2:36 AM, Christopher Price < chrispric...@gmail.com > > wrote: > > > > > > Hi Folks, > > > > Hard rules can be hard to find in an environment like ours. J > > I think we need in some cases to have “expectations” and allow the release > project to evaluate how those “expectations” are met. In other cases, the > “expectations” are pretty straightforward. > > > > We need to somehow articulate our developmental and testing needs while > making room for the fact that we are not in complete control of our > dependencies. > > > > > > For example, I was on the OpenDaylight TSC call yesterday and they are > considering a potential small delay in their release dates due to some > “blockers” on OpenFlowPlugin and NetVirt specifically for HA. These > blockers impact us directly. These issues may further result in a delay for > the ODL release version to be built and made available. > > > > We have 2 options to take here: > > 1) Take an older version of ODL, that we know has issues directly related > to our use of ODL. > (carry these blocking bugs through Colorado 1.0) > > 2) Iterate our version and take in the release that fixes the blocking > bugs. > > > > This relates very much to the fact that resolving issues in our own > troubleshooting is for the most part dependent on upstream communities > being able to resolve issues we identify. (or finding workarounds) > > > > In my mind it is very hard to find a “rule” we can apply here as each > situation is different. > > For this example I believe the best way to solve this would be to have a > phase at “code freeze” where we discuss issues and manage the patches that > we allow into the release. Maybe this is something to consider for D > release where David could arrange a small team that facilitates these > decisions after code freeze. > > > > > For now, David has only one recourse and that is to ask the TSC for a > decision on patches and version stepping. > > > > > I do hope however that we can work together for D to continue to drive for > a methodology that keeps us from a massive rush in the last months but > enables fast and efficient integration of new code… > > > > / Chris > > > > > From: < opnfv-tech-discuss-boun...@lists.opnfv.org > on behalf of Ulrich > Kleber < ulrich.kle...@huawei.com > > Date: Friday 2 September 2016 at 11:09 > To: David McBride < dmcbr...@linuxfoundation.org >, opnfv-project-leads < > opnfv-project-le...@lists.opnfv.org >, TECH-DISCUSS OPNFV <
Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][hackfest] Release Milestone Review presentation
I don't see any issue here. Colorado 1.0 is set to use Beryllium, which is already released. Even the scenarios that require Boron (FDS/SFC) do not require ODL HA, and we already have Boron RC builds that work. ODL HA is known to be buggy, so at least in Apex we don't enable it. Tim Rozet Red Hat SDN Team - Original Message - From: "David McBride" To: "Christopher Price" Cc: opnfv-project-le...@lists.opnfv.org, "TECH-DISCUSS OPNFV" Sent: Friday, September 2, 2016 1:24:13 PM Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][hackfest] Release Milestone Review presentation Chris, As I understand it, some projects are planning to use Beryllium. Do we know if the blockers effect both Beryllium and Boron, or is it just Boron? If it's just Boron, then the projects that depend on Beryllium could release at Colorado 1.0, while the projects that depend on Boron could release at Colorado 2.0 or 3.0. In fact, I heard from Greg Elkinbard, yesterday, who said that scenarios running on Fuel will be transitioning to Boron for Colorado 2.0. David On Fri, Sep 2, 2016 at 2:36 AM, Christopher Price < chrispric...@gmail.com > wrote: Hi Folks, Hard rules can be hard to find in an environment like ours. J I think we need in some cases to have “expectations” and allow the release project to evaluate how those “expectations” are met. In other cases, the “expectations” are pretty straightforward. We need to somehow articulate our developmental and testing needs while making room for the fact that we are not in complete control of our dependencies. For example, I was on the OpenDaylight TSC call yesterday and they are considering a potential small delay in their release dates due to some “blockers” on OpenFlowPlugin and NetVirt specifically for HA. These blockers impact us directly. These issues may further result in a delay for the ODL release version to be built and made available. We have 2 options to take here: 1) Take an older version of ODL, that we know has issues directly related to our use of ODL. (carry these blocking bugs through Colorado 1.0) 2) Iterate our version and take in the release that fixes the blocking bugs. This relates very much to the fact that resolving issues in our own troubleshooting is for the most part dependent on upstream communities being able to resolve issues we identify. (or finding workarounds) In my mind it is very hard to find a “rule” we can apply here as each situation is different. For this example I believe the best way to solve this would be to have a phase at “code freeze” where we discuss issues and manage the patches that we allow into the release. Maybe this is something to consider for D release where David could arrange a small team that facilitates these decisions after code freeze. For now, David has only one recourse and that is to ask the TSC for a decision on patches and version stepping. I do hope however that we can work together for D to continue to drive for a methodology that keeps us from a massive rush in the last months but enables fast and efficient integration of new code… / Chris From: < opnfv-tech-discuss-boun...@lists.opnfv.org > on behalf of Ulrich Kleber < ulrich.kle...@huawei.com > Date: Friday 2 September 2016 at 11:09 To: David McBride < dmcbr...@linuxfoundation.org >, opnfv-project-leads < opnfv-project-le...@lists.opnfv.org >, TECH-DISCUSS OPNFV < opnfv-tech-discuss@lists.opnfv.org > Subject: Re: [opnfv-tech-discuss] [release][hackfest] Release Milestone Review presentation Hi David, I remember we had some issues understanding the meaning of the “feature freeze” milestone. While reading again the lessons learned, I remembered that in former projects I worked on, we called that milestone “code complete”. These two words for me quickly associate that I should have now created my code, but would still be able to do some changes for fixing bugs. Just an idea. Maybe give it a thought Cheers, Uli From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto: opnfv-tech-discuss-boun...@lists.opnfv.org ] On Behalf Of David McBride Sent: Wednesday, 24 August, 2016 20:55 To: opnfv-project-le...@lists.opnfv.org ; TECH-DISCUSS OPNFV Subject: [opnfv-tech-discuss] [release][hackfest] Release Milestone Review presentation Thanks to those of you that attended my presentation at the OPNFV Q3 Hackfest. The questions and feedback I received are welcome and very helpful. I've posted the presentation on the wiki . Let me know if you have additional questions or comments. David -- David McBride Release Manager, OPNFV Mobile: +1.805.276.8018 Email/Google Talk: dmcbr...@linuxfoundation.org Skype: davidjmcbride1 IRC: dmcbride ___ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/ma