Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
Not sure how the database will be versioned. The spec does not deal with stuff like this. On 1/12/16, 6:38 PM, "Doug Wiegley" wrote: >Move, refactor, or remove and code around, yes. If it¹s meant to be a >stable internal neutron api, some form of it will move and be versioned. > >Thanks, >doug > > >> On Jan 12, 2016, at 9:20 AM, Gary Kotton wrote: >> >> So Doug are you planning on moving all of the extensions and mixins to >>the Neutron lib? >> My understanding was that was not part of the scope, but maybe I missed >>that with all of the moving parts. >> Thanks >> Gary >> >> >> >> On 1/12/16, 4:46 PM, "Doug Wiegley" >>wrote: >> >>> Hi Gary, >>> >>> Thanks for filing. Take a look at >>>http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron >>>-lib.html , which is work in progress to address the same issue. At the >>>end of that, no one should be importing directly from neutron. >>> >>> Thanks, >>> doug >>> >>> On Jan 12, 2016, at 5:31 AM, Gary Kotton wrote: Hi, I have drafted https://blueprints.launchpad.net/neutron/+spec/better-defined-apis and have up as an example (https://review.openstack.org/266304) for people to chew on... Thanks Gary On 1/12/16, 1:08 PM, "Smigiel, Dariusz" wrote: >> >> Hi, >> At the moment private methods are used all over the place. Examples >>for >> this are the address pairs and the security groups. If you do a >>grep of the ML2 >> plugin you will see these innocent private methods being used. >> The end goal would be for us to have these as public methods. >> Thanks >> Gary >> > > OK, get it. But just wanted to know, what is the outcome from email >discussion. > Do we need to match changed/removed private methods with deprecation >warning, > or just modify and tell plugins: "deal with it" :) > > BR, > Dariusz (dasm) Smigiel > >> >> >> >> On 1/12/16, 11:52 AM, "Smigiel, Dariusz" >> wrote: >> >>> >>> Doug Wiegley wrote: > > >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka >> wrote: >> >> Sean M. Collins wrote: >> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: > On Fri, 8 Jan 2016, Gary Kotton wrote: > > The commit > https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__github.com > _openstack_neutron_commit_5d53dfb8d64186- >> 2D&d=BQICAg&c=Sqcl0Ez6 > M0X8aeM67LKIiDJAXVeAw-YihVMNtXt- >> uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8Y > Teq9N3- >> diTlNj4GyNc&m=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9 > w&s=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8&e= > b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins > that make use of the method _get_tenant_id_for_create Just out of curiosity, is it not standard practice that a plugin shouldn't use a private method? >>> >>> +1 - hopefully decomposed plugins will audit their code and >>>look >>> +for >>> other calls to private methods. >> >> The fact that it broke *aas repos too suggests that we were not >> showing a proper example to those decomposed. I think it can be >> reasonable to restore the method until N, with a deprecation >> message, as Garry suggested in his patch. Especially since there >> is no actual burden to keep the method for another cycle. > > The neutron community has been really lax about enforcing private methods. > And while we should absolutely reverse that trend, likely we >should > give some warning. I agree with not going whole hog on that >until N. > > I'd suggest putting in a debtcollector reference when putting the > method back. Done. https://review.openstack.org/265315 >>> >>> >>> Do we have any consensus about treating private methods? Any >>>general >> tips about it, or every time should it be left for author decision? >>> >>> Should we use deprecation warning for all refactored private >>>methods, >> treating it as "API" and rewriting underneath code? >>> >>> Thanks, Dariusz (dasm) Smigiel >>> > > >__ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: >openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ ___ OpenStack Development Mailing List (
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
Move, refactor, or remove and code around, yes. If it’s meant to be a stable internal neutron api, some form of it will move and be versioned. Thanks, doug > On Jan 12, 2016, at 9:20 AM, Gary Kotton wrote: > > So Doug are you planning on moving all of the extensions and mixins to the > Neutron lib? > My understanding was that was not part of the scope, but maybe I missed that > with all of the moving parts. > Thanks > Gary > > > > On 1/12/16, 4:46 PM, "Doug Wiegley" wrote: > >> Hi Gary, >> >> Thanks for filing. Take a look at >> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-lib.html >> , which is work in progress to address the same issue. At the end of that, >> no one should be importing directly from neutron. >> >> Thanks, >> doug >> >> >>> On Jan 12, 2016, at 5:31 AM, Gary Kotton wrote: >>> >>> Hi, >>> I have drafted >>> https://blueprints.launchpad.net/neutron/+spec/better-defined-apis and have >>> up as an example (https://review.openstack.org/266304) >>> for people to chew on... >>> Thanks >>> Gary >>> >>> >>> >>> On 1/12/16, 1:08 PM, "Smigiel, Dariusz" wrote: >>> > > Hi, > At the moment private methods are used all over the place. Examples for > this are the address pairs and the security groups. If you do a grep of > the ML2 > plugin you will see these innocent private methods being used. > The end goal would be for us to have these as public methods. > Thanks > Gary > OK, get it. But just wanted to know, what is the outcome from email discussion. Do we need to match changed/removed private methods with deprecation warning, or just modify and tell plugins: "deal with it" :) BR, Dariusz (dasm) Smigiel > > > > On 1/12/16, 11:52 AM, "Smigiel, Dariusz" > wrote: > >> >> >>> Doug Wiegley wrote: > On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka >>> wrote: > > Sean M. Collins wrote: > >>> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: On Fri, 8 Jan 2016, Gary Kotton wrote: The commit https://urldefense.proofpoint.com/v2/url?u=https- > 3A__github.com _openstack_neutron_commit_5d53dfb8d64186- > 2D&d=BQICAg&c=Sqcl0Ez6 M0X8aeM67LKIiDJAXVeAw-YihVMNtXt- > uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8Y Teq9N3- > diTlNj4GyNc&m=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9 w&s=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8&e= b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that make use of the method _get_tenant_id_for_create >>> >>> Just out of curiosity, is it not standard practice that a plugin >>> shouldn't use a private method? >> >> +1 - hopefully decomposed plugins will audit their code and look >> +for >> other calls to private methods. > > The fact that it broke *aas repos too suggests that we were not > showing a proper example to those decomposed. I think it can be > reasonable to restore the method until N, with a deprecation > message, as Garry suggested in his patch. Especially since there > is no actual burden to keep the method for another cycle. The neutron community has been really lax about enforcing private >>> methods. And while we should absolutely reverse that trend, likely we should give some warning. I agree with not going whole hog on that until N. I'd suggest putting in a debtcollector reference when putting the method >>> back. >>> >>> Done. https://review.openstack.org/265315 >> >> >> Do we have any consensus about treating private methods? Any general > tips about it, or every time should it be left for author decision? >> >> Should we use deprecation warning for all refactored private methods, > treating it as "API" and rewriting underneath code? >> >> Thanks, Dariusz (dasm) Smigiel >> __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-r
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
So Doug are you planning on moving all of the extensions and mixins to the Neutron lib? My understanding was that was not part of the scope, but maybe I missed that with all of the moving parts. Thanks Gary On 1/12/16, 4:46 PM, "Doug Wiegley" wrote: >Hi Gary, > >Thanks for filing. Take a look at >http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-lib.html > , which is work in progress to address the same issue. At the end of that, no >one should be importing directly from neutron. > >Thanks, >doug > > >> On Jan 12, 2016, at 5:31 AM, Gary Kotton wrote: >> >> Hi, >> I have drafted >> https://blueprints.launchpad.net/neutron/+spec/better-defined-apis and have >> up as an example (https://review.openstack.org/266304) >> for people to chew on... >> Thanks >> Gary >> >> >> >> On 1/12/16, 1:08 PM, "Smigiel, Dariusz" wrote: >> Hi, At the moment private methods are used all over the place. Examples for this are the address pairs and the security groups. If you do a grep of the ML2 plugin you will see these innocent private methods being used. The end goal would be for us to have these as public methods. Thanks Gary >>> >>> OK, get it. But just wanted to know, what is the outcome from email >>> discussion. >>> Do we need to match changed/removed private methods with deprecation >>> warning, >>> or just modify and tell plugins: "deal with it" :) >>> >>> BR, >>> Dariusz (dasm) Smigiel >>> On 1/12/16, 11:52 AM, "Smigiel, Dariusz" wrote: > > >> Doug Wiegley wrote: >>> >>> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka >> wrote: Sean M. Collins wrote: >> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: >>> On Fri, 8 Jan 2016, Gary Kotton wrote: >>> >>> The commit >>> https://urldefense.proofpoint.com/v2/url?u=https- 3A__github.com >>> _openstack_neutron_commit_5d53dfb8d64186- 2D&d=BQICAg&c=Sqcl0Ez6 >>> M0X8aeM67LKIiDJAXVeAw-YihVMNtXt- uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8Y >>> Teq9N3- diTlNj4GyNc&m=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9 >>> w&s=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8&e= >>> b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins >>> that make use of the method _get_tenant_id_for_create >> >> Just out of curiosity, is it not standard practice that a plugin >> shouldn't use a private method? > > +1 - hopefully decomposed plugins will audit their code and look > +for > other calls to private methods. The fact that it broke *aas repos too suggests that we were not showing a proper example to those decomposed. I think it can be reasonable to restore the method until N, with a deprecation message, as Garry suggested in his patch. Especially since there is no actual burden to keep the method for another cycle. >>> >>> The neutron community has been really lax about enforcing private >> methods. >>> And while we should absolutely reverse that trend, likely we should >>> give some warning. I agree with not going whole hog on that until N. >>> >>> I'd suggest putting in a debtcollector reference when putting the >>> method >> back. >> >> Done. https://review.openstack.org/265315 > > > Do we have any consensus about treating private methods? Any general tips about it, or every time should it be left for author decision? > > Should we use deprecation warning for all refactored private methods, treating it as "API" and rewriting underneath code? > > Thanks, Dariusz (dasm) Smigiel > >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >__ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/opens
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
Hi Gary, Thanks for filing. Take a look at http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-lib.html , which is work in progress to address the same issue. At the end of that, no one should be importing directly from neutron. Thanks, doug > On Jan 12, 2016, at 5:31 AM, Gary Kotton wrote: > > Hi, > I have drafted > https://blueprints.launchpad.net/neutron/+spec/better-defined-apis and have > up as an example (https://review.openstack.org/266304) > for people to chew on... > Thanks > Gary > > > > On 1/12/16, 1:08 PM, "Smigiel, Dariusz" wrote: > >>> >>> Hi, >>> At the moment private methods are used all over the place. Examples for >>> this are the address pairs and the security groups. If you do a grep of the >>> ML2 >>> plugin you will see these innocent private methods being used. >>> The end goal would be for us to have these as public methods. >>> Thanks >>> Gary >>> >> >> OK, get it. But just wanted to know, what is the outcome from email >> discussion. >> Do we need to match changed/removed private methods with deprecation warning, >> or just modify and tell plugins: "deal with it" :) >> >> BR, >> Dariusz (dasm) Smigiel >> >>> >>> >>> >>> On 1/12/16, 11:52 AM, "Smigiel, Dariusz" wrote: >>> > Doug Wiegley wrote: >> >> >>> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka > wrote: >>> >>> Sean M. Collins wrote: >>> > On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: >> On Fri, 8 Jan 2016, Gary Kotton wrote: >> >> The commit >> https://urldefense.proofpoint.com/v2/url?u=https- >>> 3A__github.com >> _openstack_neutron_commit_5d53dfb8d64186- >>> 2D&d=BQICAg&c=Sqcl0Ez6 >> M0X8aeM67LKIiDJAXVeAw-YihVMNtXt- >>> uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8Y >> Teq9N3- >>> diTlNj4GyNc&m=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9 >> w&s=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8&e= >> b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins >> that make use of the method _get_tenant_id_for_create > > Just out of curiosity, is it not standard practice that a plugin > shouldn't use a private method? +1 - hopefully decomposed plugins will audit their code and look +for other calls to private methods. >>> >>> The fact that it broke *aas repos too suggests that we were not >>> showing a proper example to those decomposed. I think it can be >>> reasonable to restore the method until N, with a deprecation >>> message, as Garry suggested in his patch. Especially since there >>> is no actual burden to keep the method for another cycle. >> >> The neutron community has been really lax about enforcing private > methods. >> And while we should absolutely reverse that trend, likely we should >> give some warning. I agree with not going whole hog on that until N. >> >> I'd suggest putting in a debtcollector reference when putting the >> method > back. > > Done. https://review.openstack.org/265315 Do we have any consensus about treating private methods? Any general >>> tips about it, or every time should it be left for author decision? Should we use deprecation warning for all refactored private methods, >>> treating it as "API" and rewriting underneath code? Thanks, Dariusz (dasm) Smigiel >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
Hi, I have drafted https://blueprints.launchpad.net/neutron/+spec/better-defined-apis and have up as an example (https://review.openstack.org/266304) for people to chew on... Thanks Gary On 1/12/16, 1:08 PM, "Smigiel, Dariusz" wrote: >> >> Hi, >> At the moment private methods are used all over the place. Examples for >> this are the address pairs and the security groups. If you do a grep of the >> ML2 >> plugin you will see these innocent private methods being used. >> The end goal would be for us to have these as public methods. >> Thanks >> Gary >> > >OK, get it. But just wanted to know, what is the outcome from email discussion. >Do we need to match changed/removed private methods with deprecation warning, >or just modify and tell plugins: "deal with it" :) > >BR, >Dariusz (dasm) Smigiel > >> >> >> >> On 1/12/16, 11:52 AM, "Smigiel, Dariusz" wrote: >> >> > >> > >> >> Doug Wiegley wrote: >> >> > >> >> > >> >> >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka >> >> wrote: >> >> >> >> >> >> Sean M. Collins wrote: >> >> >> >> >> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: >> >> > On Fri, 8 Jan 2016, Gary Kotton wrote: >> >> > >> >> > The commit >> >> > https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__github.com >> >> > _openstack_neutron_commit_5d53dfb8d64186- >> 2D&d=BQICAg&c=Sqcl0Ez6 >> >> > M0X8aeM67LKIiDJAXVeAw-YihVMNtXt- >> uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8Y >> >> > Teq9N3- >> diTlNj4GyNc&m=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9 >> >> > w&s=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8&e= >> >> > b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins >> >> > that make use of the method _get_tenant_id_for_create >> >> >> >> Just out of curiosity, is it not standard practice that a plugin >> >> shouldn't use a private method? >> >> >>> >> >> >>> +1 - hopefully decomposed plugins will audit their code and look >> >> >>> +for >> >> >>> other calls to private methods. >> >> >> >> >> >> The fact that it broke *aas repos too suggests that we were not >> >> >> showing a proper example to those decomposed. I think it can be >> >> >> reasonable to restore the method until N, with a deprecation >> >> >> message, as Garry suggested in his patch. Especially since there >> >> >> is no actual burden to keep the method for another cycle. >> >> > >> >> > The neutron community has been really lax about enforcing private >> >> methods. >> >> > And while we should absolutely reverse that trend, likely we should >> >> > give some warning. I agree with not going whole hog on that until N. >> >> > >> >> > I'd suggest putting in a debtcollector reference when putting the >> >> > method >> >> back. >> >> >> >> Done. https://review.openstack.org/265315 >> > >> > >> >Do we have any consensus about treating private methods? Any general >> tips about it, or every time should it be left for author decision? >> > >> >Should we use deprecation warning for all refactored private methods, >> treating it as "API" and rewriting underneath code? >> > >> >Thanks, Dariusz (dasm) Smigiel >> > > >__ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
> > Hi, > At the moment private methods are used all over the place. Examples for > this are the address pairs and the security groups. If you do a grep of the > ML2 > plugin you will see these innocent private methods being used. > The end goal would be for us to have these as public methods. > Thanks > Gary > OK, get it. But just wanted to know, what is the outcome from email discussion. Do we need to match changed/removed private methods with deprecation warning, or just modify and tell plugins: "deal with it" :) BR, Dariusz (dasm) Smigiel > > > > On 1/12/16, 11:52 AM, "Smigiel, Dariusz" wrote: > > > > > > >> Doug Wiegley wrote: > >> > > >> > > >> >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka > >> wrote: > >> >> > >> >> Sean M. Collins wrote: > >> >> > >> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: > >> > On Fri, 8 Jan 2016, Gary Kotton wrote: > >> > > >> > The commit > >> > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__github.com > >> > _openstack_neutron_commit_5d53dfb8d64186- > 2D&d=BQICAg&c=Sqcl0Ez6 > >> > M0X8aeM67LKIiDJAXVeAw-YihVMNtXt- > uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8Y > >> > Teq9N3- > diTlNj4GyNc&m=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9 > >> > w&s=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8&e= > >> > b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins > >> > that make use of the method _get_tenant_id_for_create > >> > >> Just out of curiosity, is it not standard practice that a plugin > >> shouldn't use a private method? > >> >>> > >> >>> +1 - hopefully decomposed plugins will audit their code and look > >> >>> +for > >> >>> other calls to private methods. > >> >> > >> >> The fact that it broke *aas repos too suggests that we were not > >> >> showing a proper example to those decomposed. I think it can be > >> >> reasonable to restore the method until N, with a deprecation > >> >> message, as Garry suggested in his patch. Especially since there > >> >> is no actual burden to keep the method for another cycle. > >> > > >> > The neutron community has been really lax about enforcing private > >> methods. > >> > And while we should absolutely reverse that trend, likely we should > >> > give some warning. I agree with not going whole hog on that until N. > >> > > >> > I'd suggest putting in a debtcollector reference when putting the > >> > method > >> back. > >> > >> Done. https://review.openstack.org/265315 > > > > > >Do we have any consensus about treating private methods? Any general > tips about it, or every time should it be left for author decision? > > > >Should we use deprecation warning for all refactored private methods, > treating it as "API" and rewriting underneath code? > > > >Thanks, Dariusz (dasm) Smigiel > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
Hi, At the moment private methods are used all over the place. Examples for this are the address pairs and the security groups. If you do a grep of the ML2 plugin you will see these innocent private methods being used. The end goal would be for us to have these as public methods. Thanks Gary On 1/12/16, 11:52 AM, "Smigiel, Dariusz" wrote: > > >> Doug Wiegley wrote: >> > >> > >> >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka >> wrote: >> >> >> >> Sean M. Collins wrote: >> >> >> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: >> > On Fri, 8 Jan 2016, Gary Kotton wrote: >> > >> > The commit >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_neutron_commit_5d53dfb8d64186-2D&d=BQICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9w&s=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8&e= >> > >> > b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that >> > make use of the method _get_tenant_id_for_create >> >> Just out of curiosity, is it not standard practice that a plugin >> shouldn't use a private method? >> >>> >> >>> +1 - hopefully decomposed plugins will audit their code and look for >> >>> other calls to private methods. >> >> >> >> The fact that it broke *aas repos too suggests that we were not >> >> showing a proper example to those decomposed. I think it can be >> >> reasonable to restore the method until N, with a deprecation message, >> >> as Garry suggested in his patch. Especially since there is no actual >> >> burden to keep the method for another cycle. >> > >> > The neutron community has been really lax about enforcing private >> methods. >> > And while we should absolutely reverse that trend, likely we should >> > give some warning. I agree with not going whole hog on that until N. >> > >> > I'd suggest putting in a debtcollector reference when putting the method >> back. >> >> Done. https://review.openstack.org/265315 > > >Do we have any consensus about treating private methods? Any general tips >about it, or every time should it be left for author decision? > >Should we use deprecation warning for all refactored private methods, treating >it as "API" and rewriting underneath code? > >Thanks, Dariusz (dasm) Smigiel > >__ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
> Doug Wiegley wrote: > > > > > >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka > wrote: > >> > >> Sean M. Collins wrote: > >> > On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: > > On Fri, 8 Jan 2016, Gary Kotton wrote: > > > > The commit > > https://github.com/openstack/neutron/commit/5d53dfb8d64186- > > b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that > > make use of the method _get_tenant_id_for_create > > Just out of curiosity, is it not standard practice that a plugin > shouldn't use a private method? > >>> > >>> +1 - hopefully decomposed plugins will audit their code and look for > >>> other calls to private methods. > >> > >> The fact that it broke *aas repos too suggests that we were not > >> showing a proper example to those decomposed. I think it can be > >> reasonable to restore the method until N, with a deprecation message, > >> as Garry suggested in his patch. Especially since there is no actual > >> burden to keep the method for another cycle. > > > > The neutron community has been really lax about enforcing private > methods. > > And while we should absolutely reverse that trend, likely we should > > give some warning. I agree with not going whole hog on that until N. > > > > I'd suggest putting in a debtcollector reference when putting the method > back. > > Done. https://review.openstack.org/265315 Do we have any consensus about treating private methods? Any general tips about it, or every time should it be left for author decision? Should we use deprecation warning for all refactored private methods, treating it as "API" and rewriting underneath code? Thanks, Dariusz (dasm) Smigiel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
Doug Wiegley wrote: > > >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka wrote: >> >> Sean M. Collins wrote: >> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: > On Fri, 8 Jan 2016, Gary Kotton wrote: > > The commit https://github.com/openstack/neutron/commit/5d53dfb8d64186- > b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that make > use of the method _get_tenant_id_for_create Just out of curiosity, is it not standard practice that a plugin shouldn't use a private method? >>> >>> +1 - hopefully decomposed plugins will audit their code and look for >>> other calls to private methods. >> >> The fact that it broke *aas repos too suggests that we were not showing a >> proper example to those decomposed. I think it can be reasonable to >> restore the method until N, with a deprecation message, as Garry >> suggested in his patch. Especially since there is no actual burden to >> keep the method for another cycle. > > The neutron community has been really lax about enforcing private methods. > And while we should absolutely reverse that trend, likely we should give > some warning. I agree with not going whole hog on that until N. > > I'd suggest putting in a debtcollector reference when putting the method > back. Done. https://review.openstack.org/265315 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka wrote: > > Sean M. Collins wrote: > >>> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: On Fri, 8 Jan 2016, Gary Kotton wrote: The commit https://github.com/openstack/neutron/commit/5d53dfb8d64186- b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that make use of the method _get_tenant_id_for_create >>> >>> Just out of curiosity, is it not standard practice that a plugin >>> shouldn't use a private method? >> >> +1 - hopefully decomposed plugins will audit their code and look for >> other calls to private methods. > > The fact that it broke *aas repos too suggests that we were not showing a > proper example to those decomposed. I think it can be reasonable to restore > the method until N, with a deprecation message, as Garry suggested in his > patch. Especially since there is no actual burden to keep the method for > another cycle. The neutron community has been really lax about enforcing private methods. And while we should absolutely reverse that trend, likely we should give some warning. I agree with not going whole hog on that until N. I'd suggest putting in a debtcollector reference when putting the method back. Doug > > Ihar > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
Sean M. Collins wrote: On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: On Fri, 8 Jan 2016, Gary Kotton wrote: The commit https://github.com/openstack/neutron/commit/5d53dfb8d64186- b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that make use of the method _get_tenant_id_for_create Just out of curiosity, is it not standard practice that a plugin shouldn't use a private method? +1 - hopefully decomposed plugins will audit their code and look for other calls to private methods. The fact that it broke *aas repos too suggests that we were not showing a proper example to those decomposed. I think it can be reasonable to restore the method until N, with a deprecation message, as Garry suggested in his patch. Especially since there is no actual burden to keep the method for another cycle. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote: > On Fri, 8 Jan 2016, Gary Kotton wrote: > > >The commit https://github.com/openstack/neutron/commit/5d53dfb8d64186- > >b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that make > >use of the method _get_tenant_id_for_create > > Just out of curiosity, is it not standard practice that a plugin > shouldn't use a private method? +1 - hopefully decomposed plugins will audit their code and look for other calls to private methods. -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
Gary Kotton wrote: > commit > https://github.com/openstack/neutron/commit/5d53dfb8d64186b5b1d2f356fbff8f222e15d1b2 > may > break the decomposed plugins that make use of the method > _get_tenant_id_for_create Note that this is a private method. Plugins should avoid using private methods. Unfortunately during the decomposition efforts not enough effort was expended on scrubbing private methods from the plugins. This should be something that plugin maintainers continue to work on and keep an eye out for. > It would have been nice if there was a deprecation warning. I don't think we should have deprecation warnings for private properties. > Options: > > 1. Decomposed plugins fix this > 2. Revert the patch and find a solution that does not break the plugins > > If we do go for #1 then we can start to stop enforcing the usage of the > deprecation warnings… We will continue to use deprecation warnings for changes to non-private methods affecting plugins. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
On Fri, 8 Jan 2016, Gary Kotton wrote: The commit https://github.com/openstack/neutron/commit/5d53dfb8d64186- b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that make use of the method _get_tenant_id_for_create Just out of curiosity, is it not standard practice that a plugin shouldn't use a private method? -- Chris Dent (�s°□°)�s�喋擤ォ�http://anticdent.org/ freenode: cdent tw: @anticdent__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
I have posted https://review.openstack.org/265315 to try and help the decomposed plugins have a breather. In addition to this this may also break the aaS. Thanks Gary From: Gary Kotton mailto:gkot...@vmware.com>> Reply-To: OpenStack List mailto:openstack-dev@lists.openstack.org>> Date: Friday, January 8, 2016 at 4:59 PM To: OpenStack List mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [Neutron] Heads up for decomposed plugin break Hi, The commit https://github.com/openstack/neutron/commit/5d53dfb8d64186b5b1d2f356fbff8f222e15d1b2<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_neutron_commit_5d53dfb8d64186b5b1d2f356fbff8f222e15d1b2&d=BQMFAw&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=lhciomgWgbznB97GytIalu9q4e2QQCGW8gDD0DImX88&s=aPhc2O7ECTHt8VWFWvXPAR0Mrt4UuAKaZBKj-ZPKhBY&e=> may break the decomposed plugins that make use of the method _get_tenant_id_for_create It would have been nice if there was a deprecation warning. Options: 1. Decomposed plugins fix this 2. Revert the patch and find a solution that does not break the plugins If we do go for #1 then we can start to stop enforcing the usage of the deprecation warnings... Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break
Gary, Thanks for sending the email about the breakage. +1 to the deprecation warning. Fawad Khaliq On Fri, Jan 8, 2016 at 7:59 PM, Gary Kotton wrote: > Hi, > The commit > https://github.com/openstack/neutron/commit/5d53dfb8d64186b5b1d2f356fbff8f222e15d1b2 > may > break the decomposed plugins that make use of the method > _get_tenant_id_for_create > > It would have been nice if there was a deprecation warning. > > Options: > >1. Decomposed plugins fix this >2. Revert the patch and find a solution that does not break the plugins > > If we do go for #1 then we can start to stop enforcing the usage of the > deprecation warnings… > > Thanks > Gary > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Heads up for decomposed plugin break
Hi, The commit https://github.com/openstack/neutron/commit/5d53dfb8d64186b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that make use of the method _get_tenant_id_for_create It would have been nice if there was a deprecation warning. Options: 1. Decomposed plugins fix this 2. Revert the patch and find a solution that does not break the plugins If we do go for #1 then we can start to stop enforcing the usage of the deprecation warnings... Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
