Hello, everyone: I am writing this email to ask you if you have had time to look into it. I would highly appreciate your feedback and comments.
Thanks and Regards, Amit ________________________________ Von: Amit Mondal <ad...@amitinside.com> Gesendet: Samstag, 7. März 2020 11:02 Uhr An: Carsten Ziegeler <cziege...@apache.org>; dev@felix.apache.org <dev@felix.apache.org> Betreff: AW: AW: [DISCUSS] Project Contribution to Apache Felix Hi Carsten, Thank you for your feedback. The project I worked on, leverages Configuration Admin and Metatype specifications to manage user-specified flags. It also does provide a utility service API to allow introspection of the feature flags available in the runtime. I have also provided a bundle in this project to present a basic example of using feature flags. Since it leverages only the OSGi APIs, the primary benefit of this approach is that developers can use feature flags without having any dependency on any external APIs. That is, consumers can make the feature flags available in the runtime by providing Metatype XML files. Therefore, it doesn't need any additional dependency at all. If the extender bundle is available in the runtime, the available Metatypes will be processed, and the extender will identify the available flags. The management agents will then be able to control them from outside. The idea is to make it API agnostic and loosely coupled completely. It enables consumers to specify or provide their feature flags without implementing or using any external APIs. The feature flags functionality should only work as soon as the extender gets installed in the runtime — the similar approach we use for the DS, Configurator or Metatype specifications. Users can provide XML files (for DS and Metatype) or JSON files (for Configurator), but they will only be processed as soon as the extenders are used in the runtime. I hope this clarifies some of your queries. Should you require any further information, I would be glad to provide. Thanks and Regards, Amit ________________________________ Von: Carsten Ziegeler <cziege...@apache.org> Gesendet: Samstag, 7. März 2020 10:05 An: dev@felix.apache.org <dev@felix.apache.org> Betreff: Re: AW: [DISCUSS] Project Contribution to Apache Felix Hi Amit, thanks for starting the discussion. I think, there is no question about having support for toggles. Is a little bit unclear to me what in your project is the relation to OSGi? Is there any integration with toggles and lets say the OSGi framework? If you could elaborate on this, that would be great. Regards Carsten On 06.03.2020 15:29, Amit Mondal wrote: > Hi Thomas, > > Thanks for your quick feedback. The spec you mentioned is similar to this > project [1], Peter worked on. This addresses the problem with the start > levels - non-dynamism. Many developers start trying to control the bundle > start level when they run in timing dependencies. Since, in OSGi, we always > support dynamic behaviour, such a solution to use start level is not > encouraged. The Condition Service (as specified in RFC 242) addresses a > similar problem. On the other hand, feature flags addresses high-level > enablement/disablement of a flag, allowing teams to modify system behaviour > without changing code. This can help the team in making more informed > decisions about a feature, shortening the release cycle, performing A/B > testing, and empowering people other than engineers allowing them to control > releases, among others. > > This also enables you to have a very well established feature flag life-cycle > management, ensuring platforms remain stable over different feature flags > combinations and the testing complexity that grows harder and harder with > each new flag. > > I would really like to further discuss if there exists any scope to > collaborate on an implementation for such feature flags integration. > > Thanks and Regards, > Amit > > [1] - > https://github.com/aQute-os/biz.aQute.osgi.util/tree/master/biz.aQute.osgi.conditionaltarget > ________________________________ > Von: Thomas Watson <tjw...@gmail.com> > Gesendet: Freitag, 6. März 2020 14:52 > An: dev@felix.apache.org <dev@felix.apache.org> > Betreff: Re: [DISCUSS] Project Contribution to Apache Felix > > Hi Amit, > > This sounds like it is trying to solve a similar problem that an OSGi R8 > spec proposal call "Conditions" is trying to address with RFC 242 [1]. It > would be good to understand how the two approaches differ. If they are > solving similar issues then perhaps it would be better to collaborate on an > implementation of the proposed condition factory in Felix. The Condition > specification is going to impact the SCR implementation also, so the Felix > project will need to react to the Condition specification regardless. > > Tom > > [1] > https://github.com/osgi/design/blob/master/rfcs/rfc0242/rfc-0242-Condition-Service.pdf > > > On Fri, Mar 6, 2020 at 7:25 AM Amit Mondal <ad...@amitinside.com> wrote: > >> Hello, everyone: >> >> I am writing this email to propose a project I did work on earlier. The >> project introduces support of feature flags for the OSGi environment. >> Probably many of you already know about feature flags or feature toggles. I >> would like to further elaborate a bit for those who are not familiar with >> it. >> >> It turns out that when many people hear the term feature flags, they >> fixate on the word - flag and are thinking of something much older - other >> flags in software engineering. They are referring to a compile-time flag or >> a server configuration flag or maybe a server configuration file. While >> those are indeed flags, what they all have in common is that they are >> global. What I mean by that is they impact every user passing through that >> piece of software. >> >> But when I say feature flags, sometimes called feature toggles or >> ops-toggles, I’m talking about a very different thing. I’m referring to >> making a dynamic decision in my code - live. I’m deciding which way I’m >> going to send a user, without having to push new code and without having to >> change a config file. It’s not static, like those other examples of flags. >> It’s a user-by-user, session-by-session decision. >> >> The key benefit of using feature flags is that they decouple development >> from app releases. This means two things: >> >> * features can be merged before they are fully implemented >> * fully implemented features can remain hidden until you are ready to >> release them >> >> First and foremost, feature flags help developers because incomplete >> features can be merged! This allows to split a feature into many small >> increments and merge those branches one by one. >> >> Secondly, feature flags also help with releasing. In the old days, an app >> release could get blocked when finding a last-minute issue on a new >> feature. Thanks to feature flags, this can no longer happen! If a feature >> isn’t fully ready, it can just be temporarily disabled. Even more, when a >> feature is ready to ship, you no longer have to do a big bang roll out to >> all users. Instead, you can gradually roll out and make a data-driven >> decision on to roll out further or maybe even rollback! That dramatically >> de-risks rolling out new features. >> >> Finally, improvements to new features can be built side by the side of the >> old feature and using A/B tests you can then decide which feature should >> remain. This allows optimising user engagement in your app. >> >> I believe this was sufficient to portray the idea behind feature flags. I >> have worked on a prototype version [1] of the feature flags that leverages >> pure OSGi specifications. Being an Eclipse committer, I see several >> benefits of making such a project flourish under the supervision of the >> developers working on Felix. As Felix community primarily focuses on OSGi, >> this project would avail benefits from further development, maintenance and >> adoption. >> >> Currently, the project is licensed under the Apache 2.0 software license, >> but it still uses my top-level domain in the bundles. If you think the >> project would be valuable, I would love to make the bundle names compatible >> with the Felix naming conventions. >> >> I would really appreciate your opinion regarding this proposal for the >> contribution. >> >> >> Thanks and Regards, >> Amit >> >> >> [1] - https://github.com/amitjoy/feature-flags-for-osgi >> > -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
