Open Stack

----- Mail original -----
> De: "Thierry Carrez" <thierry at openstack.org>
> À: openstack-sigs at lists.openstack.org
> Envoyé: Lundi 31 Juillet 2017 12:44:28
> Objet: Re: [Openstack-sigs] [meta] Initial working groups to convert to	SIGs
> 
> lebre.adrien at free.fr wrote:
> >> De: "Thierry Carrez" <thierry at openstack.org>
> >> On the downstream side, a lot of the working groups would likely
> >> benefit
> >> from being turned into SIGs. As long as their focus is not purely
> >> operational, and they are willing to go beyond expressing gaps and
> >> requirements and tackle implementation, the SIG format is a lot
> >> more
> >> adapted and would facilitate gathering development resources and
> >> coordinating efforts. The most obvious targets are the use-case
> >> oriented
> >> groups: Scientific WG, Telco/NFV WG, Massively-distributed/Edge
> >> clouds
> >> WG, Public Clouds WG, Large Deployments WG. LCOO could also be
> >> turned
> >> into a SIG, given that they are already tackling implementation
> >> and
> >> pooling resources -- although they would likely need to have a
> >> more
> >> defined scope and/or merge with the Large deployments WG for
> >> clarity.
> > 
> > After spending a few cycles through these different WGs (in
> > addition to the FEMDC that I'm co-chairing, I have been trying to
> > follow the actions performed in the Telco/NFV WG and Large
> > deployment Team), I'm not sure whether each of them should be
> > turned into a specific SIG.
> > The main issue we are all facing is the number of contributors who
> > can allocate sufficient amount of time to make things progressing.
> > Because of such issue, there is for instance an on-going
> > discussion between LCOO folks and Curtis (chair of the Telco/NFV
> > in CC) to integrate NFV/Telco discussions under the umbrella of
> > the LCOO WG (If I'm correct this is the second try for the
> > Telco/NFV WG and despite the relevance of such a WG, contributors
> > still did not come :().
> > 
> > More generally, I think there is a lot of overlapping challenges
> > between WGs. According to what I understood from the SIG proposal,
> > it would probably make sense to try to identify those overlapping
> > challenges and create SIGs accordingly (NFV use-cases involved
> > generally several sites/DCs which leads to the need of operating
> > distributed cloud infrastructures, Deploying/operating a large
> > cloud systems require mechanisms/features that scale well, those
> > mechanisms can be suited also for FEMDC infrastructures and
> > reciprocally...).
> I totally agree that a transition to SIGs gives us the opportunity to
> refactor those groups to avoid overlap and fragmentation, and we
> should
> take it. I like that the LCOO is focused on associating development
> resources to specific goals (making it very much SIG-like in its
> composition and resulting efficiency) but in terms of problem space
> it
> is trying to address, it seems to overlap both with the Telco/NFV
> group
> and the Large Deployments group, creating fragmentation in the
> resources
> associated to each.
> 
> Personally I think we should have one SIG around Telco/NFV issues
> (ideally with a LCOO-like approach to pooling development resources
> to
> actually implement its priorities), one SIG around Large
> Deployments/Scaling, one SIG around Edge/distributed clouds, and one
> SIG
> around Public clouds -- because those all represent slightly
> different
> problem spaces, and different actors that could be interested in
> pooling
> their dev resources.

While I can see issues that are public cloud specifics, I'm still wondering what are challenges that can be addressed in a possible ``large scale/deployment'' SIG that will not be common/useful for the Fog/Edge one (and similarly for the Telcos/NFVs vs FEMDC).

Without means to detect overlapping between on-going activities it is difficult to favour collaborations.
One way to make progress toward such a goal could consist in requesting the issues/challenges, a particular SIG would like to address before creating it officially? 
Not just coarse-grained ideas but a clear and well identified roadmap. 
According to this roadmap, the ''meta'' SIG would be able to forward the request to one SIG that already exists (and by such a way, to favour the consolidation of development resources). what do you think? 
The other issue is probably also related to the number of SIG you expect: the more SIGs the harder it will be to identify overlapping. 


best,
ad_rien_

PS: we have been trying  to address this issue of identifying collaboration opportunities between WGs at the UC level. We agreed to schedule a cross WG chair meeting once a month. The first try was two weeks ago. While only three WGs were represented, the discussion have been fruitful from my viewpoint. 
> 
> --
> Thierry Carrez (ttx)
> 
> _______________________________________________
> Openstack-sigs mailing list
> Openstack-sigs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>