From cdent+os at anticdent.org Thu Mar 1 14:34:50 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Thu, 1 Mar 2018 14:34:50 +0000 (GMT) Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG Message-ID: I'd like to announce a new Special Interest Group: The Cats and Sofas Special Interest Group (CS-SIG). As with all OpenStack SIGs, this group provides a locus for sharing and communication among members of the community having a shared interest. In this case, cats and sofas. The group will: * Have no IRC meetings, nor meetings of any kind. * Have no IRC channel. * Produce no code, documentation or material nor process anything sold, bought, or processed, or repair anything sold, bought, or processed. Instead the group will devote itself to securing access to the comfort of cats and sofas either during or after regular OpenStack events, including, but not limited to, the PTG and Summit. Such cats and sofas will provide succour in the face of extended social engagement, refreshing members of the SIG (and anyone else) who needs a little pick me up before returning to discussion, refreshed and ready. -- Chris Dent (⊙＿⊙') https://anticdent.org/ freenode: cdent tw: @anticdent From dtantsur at redhat.com Thu Mar 1 15:07:23 2018 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Thu, 1 Mar 2018 16:07:23 +0100 Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG In-Reply-To: References: Message-ID: <71d97854-1e83-ede7-71bb-679eaf38cd2d@redhat.com> Count me in! On 03/01/2018 03:34 PM, Chris Dent wrote: > > I'd like to announce a new Special Interest Group: The Cats and Sofas > Special Interest Group (CS-SIG). As with all OpenStack SIGs, this > group provides a locus for sharing and communication among members of > the community having a shared interest. In this case, cats and sofas. > > The group will: > > * Have no IRC meetings, nor meetings of any kind. > * Have no IRC channel. > * Produce no code, documentation or material nor process anything >   sold, bought, or processed, or repair anything sold, bought, or >   processed. > > Instead the group will devote itself to securing access to the comfort > of cats and sofas either during or after regular OpenStack events, > including, but not limited to, the PTG and Summit. > > Such cats and sofas will provide succour in the face of extended > social engagement, refreshing members of the SIG (and anyone else) who > needs a little pick me up before returning to discussion, refreshed > and ready. > > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > From Arkady.Kanevsky at dell.com Thu Mar 1 15:12:16 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Thu, 1 Mar 2018 15:12:16 +0000 Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG In-Reply-To: <71d97854-1e83-ede7-71bb-679eaf38cd2d@redhat.com> References: <71d97854-1e83-ede7-71bb-679eaf38cd2d@redhat.com> Message-ID: Are the dog people allowed? -----Original Message----- From: Dmitry Tantsur [mailto:dtantsur at redhat.com] Sent: Thursday, March 1, 2018 9:07 AM To: openstack-sigs at lists.openstack.org Subject: Re: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG Count me in! On 03/01/2018 03:34 PM, Chris Dent wrote: > > I'd like to announce a new Special Interest Group: The Cats and Sofas > Special Interest Group (CS-SIG). As with all OpenStack SIGs, this > group provides a locus for sharing and communication among members of > the community having a shared interest. In this case, cats and sofas. > > The group will: > > * Have no IRC meetings, nor meetings of any kind. > * Have no IRC channel. > * Produce no code, documentation or material nor process anything >   sold, bought, or processed, or repair anything sold, bought, or >   processed. > > Instead the group will devote itself to securing access to the comfort > of cats and sofas either during or after regular OpenStack events, > including, but not limited to, the PTG and Summit. > > Such cats and sofas will provide succour in the face of extended > social engagement, refreshing members of the SIG (and anyone else) who > needs a little pick me up before returning to discussion, refreshed > and ready. > > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > _______________________________________________ openstack-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From openstack at medberry.net Thu Mar 1 15:26:25 2018 From: openstack at medberry.net (David Medberry) Date: Thu, 1 Mar 2018 08:26:25 -0700 Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG In-Reply-To: References: Message-ID: Do we have to BYOAntihistamine or will they be provided? Love cats but they do induce non-stop sneezing and eye-watering.... On Thu, Mar 1, 2018 at 7:34 AM, Chris Dent wrote: > > I'd like to announce a new Special Interest Group: The Cats and Sofas > Special Interest Group (CS-SIG). As with all OpenStack SIGs, this > group provides a locus for sharing and communication among members of > the community having a shared interest. In this case, cats and sofas. > > The group will: > > * Have no IRC meetings, nor meetings of any kind. > * Have no IRC channel. > * Produce no code, documentation or material nor process anything > sold, bought, or processed, or repair anything sold, bought, or > processed. > > Instead the group will devote itself to securing access to the comfort > of cats and sofas either during or after regular OpenStack events, > including, but not limited to, the PTG and Summit. > > Such cats and sofas will provide succour in the face of extended > social engagement, refreshing members of the SIG (and anyone else) who > needs a little pick me up before returning to discussion, refreshed > and ready. > > -- > Chris Dent (⊙＿⊙') https://anticdent.org/ > freenode: cdent tw: @anticdent > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Thu Mar 1 15:55:18 2018 From: amy at demarco.com (Amy) Date: Thu, 1 Mar 2018 09:55:18 -0600 Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG In-Reply-To: References: <71d97854-1e83-ede7-71bb-679eaf38cd2d@redhat.com> Message-ID: <031DFC71-B5CE-4311-9FED-6F4E35429751@demarco.com> The dog and pony contingent would like to know if they are included or need their own SIG. Amy (spotz) > On Mar 1, 2018, at 9:12 AM, wrote: > > Are the dog people allowed? > > -----Original Message----- > From: Dmitry Tantsur [mailto:dtantsur at redhat.com] > Sent: Thursday, March 1, 2018 9:07 AM > To: openstack-sigs at lists.openstack.org > Subject: Re: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG > > Count me in! > >> On 03/01/2018 03:34 PM, Chris Dent wrote: >> >> I'd like to announce a new Special Interest Group: The Cats and Sofas >> Special Interest Group (CS-SIG). As with all OpenStack SIGs, this >> group provides a locus for sharing and communication among members of >> the community having a shared interest. In this case, cats and sofas. >> >> The group will: >> >> * Have no IRC meetings, nor meetings of any kind. >> * Have no IRC channel. >> * Produce no code, documentation or material nor process anything >> sold, bought, or processed, or repair anything sold, bought, or >> processed. >> >> Instead the group will devote itself to securing access to the comfort >> of cats and sofas either during or after regular OpenStack events, >> including, but not limited to, the PTG and Summit. >> >> Such cats and sofas will provide succour in the face of extended >> social engagement, refreshing members of the SIG (and anyone else) who >> needs a little pick me up before returning to discussion, refreshed >> and ready. >> >> >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From sean.mcginnis at gmail.com Thu Mar 1 16:02:44 2018 From: sean.mcginnis at gmail.com (Sean McGinnis) Date: Thu, 1 Mar 2018 10:02:44 -0600 Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG In-Reply-To: <031DFC71-B5CE-4311-9FED-6F4E35429751@demarco.com> References: <71d97854-1e83-ede7-71bb-679eaf38cd2d@redhat.com> <031DFC71-B5CE-4311-9FED-6F4E35429751@demarco.com> Message-ID: Are you calling OpenStack a dog and pony show?! :) Sorry spotz. On Thu, Mar 1, 2018 at 9:55 AM, Amy wrote: > The dog and pony contingent would like to know if they are included or > need their own SIG. > > Amy (spotz) > > > On Mar 1, 2018, at 9:12 AM, < > Arkady.Kanevsky at dell.com> wrote: > > > > Are the dog people allowed? > > > > -----Original Message----- > > From: Dmitry Tantsur [mailto:dtantsur at redhat.com] > > Sent: Thursday, March 1, 2018 9:07 AM > > To: openstack-sigs at lists.openstack.org > > Subject: Re: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG > > > > Count me in! > > > >> On 03/01/2018 03:34 PM, Chris Dent wrote: > >> > >> I'd like to announce a new Special Interest Group: The Cats and Sofas > >> Special Interest Group (CS-SIG). As with all OpenStack SIGs, this > >> group provides a locus for sharing and communication among members of > >> the community having a shared interest. In this case, cats and sofas. > >> > >> The group will: > >> > >> * Have no IRC meetings, nor meetings of any kind. > >> * Have no IRC channel. > >> * Produce no code, documentation or material nor process anything > >> sold, bought, or processed, or repair anything sold, bought, or > >> processed. > >> > >> Instead the group will devote itself to securing access to the comfort > >> of cats and sofas either during or after regular OpenStack events, > >> including, but not limited to, the PTG and Summit. > >> > >> Such cats and sofas will provide succour in the face of extended > >> social engagement, refreshing members of the SIG (and anyone else) who > >> needs a little pick me up before returning to discussion, refreshed > >> and ready. > >> > >> > >> > >> _______________________________________________ > >> openstack-sigs mailing list > >> openstack-sigs at lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > >> > > > > > > _______________________________________________ > > openstack-sigs mailing list > > openstack-sigs at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > _______________________________________________ > > openstack-sigs mailing list > > openstack-sigs at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Thu Mar 1 16:10:30 2018 From: amy at demarco.com (Amy Marrich) Date: Thu, 1 Mar 2018 10:10:30 -0600 Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG In-Reply-To: References: <71d97854-1e83-ede7-71bb-679eaf38cd2d@redhat.com> <031DFC71-B5CE-4311-9FED-6F4E35429751@demarco.com> Message-ID: Never! But if you prefer, the canines and equines still want to be included! Amy (spotz) On Thu, Mar 1, 2018 at 10:02 AM, Sean McGinnis wrote: > Are you calling OpenStack a dog and pony show?! > > :) > > Sorry spotz. > > On Thu, Mar 1, 2018 at 9:55 AM, Amy wrote: > >> The dog and pony contingent would like to know if they are included or >> need their own SIG. >> >> Amy (spotz) >> >> > On Mar 1, 2018, at 9:12 AM, < >> Arkady.Kanevsky at dell.com> wrote: >> > >> > Are the dog people allowed? >> > >> > -----Original Message----- >> > From: Dmitry Tantsur [mailto:dtantsur at redhat.com] >> > Sent: Thursday, March 1, 2018 9:07 AM >> > To: openstack-sigs at lists.openstack.org >> > Subject: Re: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG >> > >> > Count me in! >> > >> >> On 03/01/2018 03:34 PM, Chris Dent wrote: >> >> >> >> I'd like to announce a new Special Interest Group: The Cats and Sofas >> >> Special Interest Group (CS-SIG). As with all OpenStack SIGs, this >> >> group provides a locus for sharing and communication among members of >> >> the community having a shared interest. In this case, cats and sofas. >> >> >> >> The group will: >> >> >> >> * Have no IRC meetings, nor meetings of any kind. >> >> * Have no IRC channel. >> >> * Produce no code, documentation or material nor process anything >> >> sold, bought, or processed, or repair anything sold, bought, or >> >> processed. >> >> >> >> Instead the group will devote itself to securing access to the comfort >> >> of cats and sofas either during or after regular OpenStack events, >> >> including, but not limited to, the PTG and Summit. >> >> >> >> Such cats and sofas will provide succour in the face of extended >> >> social engagement, refreshing members of the SIG (and anyone else) who >> >> needs a little pick me up before returning to discussion, refreshed >> >> and ready. >> >> >> >> >> >> >> >> _______________________________________________ >> >> openstack-sigs mailing list >> >> openstack-sigs at lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> >> >> > >> > >> > _______________________________________________ >> > openstack-sigs mailing list >> > openstack-sigs at lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > _______________________________________________ >> > openstack-sigs mailing list >> > openstack-sigs at lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emccormick at cirrusseven.com Thu Mar 1 16:53:43 2018 From: emccormick at cirrusseven.com (Erik McCormick) Date: Thu, 1 Mar 2018 11:53:43 -0500 Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG In-Reply-To: References: <71d97854-1e83-ede7-71bb-679eaf38cd2d@redhat.com> <031DFC71-B5CE-4311-9FED-6F4E35429751@demarco.com> Message-ID: Imma bring this. On Mar 1, 2018 11:10 AM, "Amy Marrich" wrote: > Never! But if you prefer, the canines and equines still want to be > included! > > Amy (spotz) > > On Thu, Mar 1, 2018 at 10:02 AM, Sean McGinnis > wrote: > >> Are you calling OpenStack a dog and pony show?! >> >> :) >> >> Sorry spotz. >> >> On Thu, Mar 1, 2018 at 9:55 AM, Amy wrote: >> >>> The dog and pony contingent would like to know if they are included or >>> need their own SIG. >>> >>> Amy (spotz) >>> >>> > On Mar 1, 2018, at 9:12 AM, < >>> Arkady.Kanevsky at dell.com> wrote: >>> > >>> > Are the dog people allowed? >>> > >>> > -----Original Message----- >>> > From: Dmitry Tantsur [mailto:dtantsur at redhat.com] >>> > Sent: Thursday, March 1, 2018 9:07 AM >>> > To: openstack-sigs at lists.openstack.org >>> > Subject: Re: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG >>> > >>> > Count me in! >>> > >>> >> On 03/01/2018 03:34 PM, Chris Dent wrote: >>> >> >>> >> I'd like to announce a new Special Interest Group: The Cats and Sofas >>> >> Special Interest Group (CS-SIG). As with all OpenStack SIGs, this >>> >> group provides a locus for sharing and communication among members of >>> >> the community having a shared interest. In this case, cats and sofas. >>> >> >>> >> The group will: >>> >> >>> >> * Have no IRC meetings, nor meetings of any kind. >>> >> * Have no IRC channel. >>> >> * Produce no code, documentation or material nor process anything >>> >> sold, bought, or processed, or repair anything sold, bought, or >>> >> processed. >>> >> >>> >> Instead the group will devote itself to securing access to the comfort >>> >> of cats and sofas either during or after regular OpenStack events, >>> >> including, but not limited to, the PTG and Summit. >>> >> >>> >> Such cats and sofas will provide succour in the face of extended >>> >> social engagement, refreshing members of the SIG (and anyone else) who >>> >> needs a little pick me up before returning to discussion, refreshed >>> >> and ready. >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> openstack-sigs mailing list >>> >> openstack-sigs at lists.openstack.org >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >>> >> >>> > >>> > >>> > _______________________________________________ >>> > openstack-sigs mailing list >>> > openstack-sigs at lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >>> > _______________________________________________ >>> > openstack-sigs mailing list >>> > openstack-sigs at lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >>> >>> _______________________________________________ >>> openstack-sigs mailing list >>> openstack-sigs at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >>> >> >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> >> > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 180130-peacock-img_1561-ac-851p_fcac1e233b9065fc3a99fb2bc582520d.nbcnews-ux-2880-1000.jpg Type: image/jpeg Size: 86566 bytes Desc: not available URL: From rbergero at redhat.com Thu Mar 1 17:03:26 2018 From: rbergero at redhat.com (Robyn Bergeron) Date: Thu, 1 Mar 2018 10:03:26 -0700 Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG In-Reply-To: References: Message-ID: On Mar 1, 2018 2:35 PM, "Chris Dent" wrote: I'd like to announce a new Special Interest Group: The Cats and Sofas Special Interest Group (CS-SIG). As with all OpenStack SIGs, this group provides a locus for sharing and communication among members of the community having a shared interest. In this case, cats and sofas. The group will: * Have no IRC meetings, nor meetings of any kind. * Have no IRC channel. * Produce no code, documentation or material nor process anything sold, bought, or processed, or repair anything sold, bought, or processed. Instead the group will devote itself to securing access to the comfort of cats and sofas either during or after regular OpenStack events, including, but not limited to, the PTG and Summit. Such cats and sofas will provide succour in the face of extended social engagement, refreshing members of the SIG (and anyone else) who needs a little pick me up before returning to discussion, refreshed and ready. Hmm. Can the sofas be used for naps, or should we also have a Naps SIG? I think a community of practice around naptime at events aligns well, particular at actual events where folks need naps. Which is all events. :) I'd say more, but it would turn into a discussion about squirrels. :) -- Chris Dent (⊙＿⊙') https://anticdent.org/ freenode: cdent tw: @anticdent _______________________________________________ openstack-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs -------------- next part -------------- An HTML attachment was scrubbed... URL: From davanum at gmail.com Thu Mar 1 17:04:07 2018 From: davanum at gmail.com (Davanum Srinivas) Date: Thu, 1 Mar 2018 17:04:07 +0000 Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG In-Reply-To: References: Message-ID: Sign me up! On Thu, Mar 1, 2018 at 2:34 PM, Chris Dent wrote: > > I'd like to announce a new Special Interest Group: The Cats and Sofas > Special Interest Group (CS-SIG). As with all OpenStack SIGs, this > group provides a locus for sharing and communication among members of > the community having a shared interest. In this case, cats and sofas. > > The group will: > > * Have no IRC meetings, nor meetings of any kind. > * Have no IRC channel. > * Produce no code, documentation or material nor process anything > sold, bought, or processed, or repair anything sold, bought, or > processed. > > Instead the group will devote itself to securing access to the comfort > of cats and sofas either during or after regular OpenStack events, > including, but not limited to, the PTG and Summit. > > Such cats and sofas will provide succour in the face of extended > social engagement, refreshing members of the SIG (and anyone else) who > needs a little pick me up before returning to discussion, refreshed > and ready. > > -- > Chris Dent (⊙＿⊙') https://anticdent.org/ > freenode: cdent tw: @anticdent > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Davanum Srinivas :: https://twitter.com/dims From zhipengh512 at gmail.com Thu Mar 1 17:38:52 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Thu, 1 Mar 2018 17:38:52 +0000 Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG In-Reply-To: References: Message-ID: cyborg cheetah demands a voice to be heard ! :P https://yt3.ggpht.com/-c3YmkrYYVGU/AAAAAAAAAAI/AAAAAAAAAAA/03e6R9oh2O8/s288-mo-c-c0xffffffff-rj-k-no/photo.jpg On Thu, Mar 1, 2018 at 5:04 PM, Davanum Srinivas wrote: > Sign me up! > > On Thu, Mar 1, 2018 at 2:34 PM, Chris Dent wrote: > > > > I'd like to announce a new Special Interest Group: The Cats and Sofas > > Special Interest Group (CS-SIG). As with all OpenStack SIGs, this > > group provides a locus for sharing and communication among members of > > the community having a shared interest. In this case, cats and sofas. > > > > The group will: > > > > * Have no IRC meetings, nor meetings of any kind. > > * Have no IRC channel. > > * Produce no code, documentation or material nor process anything > > sold, bought, or processed, or repair anything sold, bought, or > > processed. > > > > Instead the group will devote itself to securing access to the comfort > > of cats and sofas either during or after regular OpenStack events, > > including, but not limited to, the PTG and Summit. > > > > Such cats and sofas will provide succour in the face of extended > > social engagement, refreshing members of the SIG (and anyone else) who > > needs a little pick me up before returning to discussion, refreshed > > and ready. > > > > -- > > Chris Dent (⊙＿⊙') https://anticdent.org/ > > freenode: cdent tw: @anticdent > > _______________________________________________ > > openstack-sigs mailing list > > openstack-sigs at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at ericsson.com Thu Mar 1 21:19:55 2018 From: balazs.gibizer at ericsson.com (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Thu, 1 Mar 2018 21:19:55 +0000 Subject: [Openstack-sigs] [meta] [announce] Cats and Sofas SIG In-Reply-To: References: Message-ID: <1519939195.1840.1@smtp.office365.com> On Thu, Mar 1, 2018 at 2:34 PM, Chris Dent wrote: > > I'd like to announce a new Special Interest Group: The Cats and Sofas > Special Interest Group (CS-SIG). As with all OpenStack SIGs, this > group provides a locus for sharing and communication among members of > the community having a shared interest. In this case, cats and sofas. > > The group will: > > * Have no IRC meetings, nor meetings of any kind. > * Have no IRC channel. > * Produce no code, documentation or material nor process anything > sold, bought, or processed, or repair anything sold, bought, or > processed. > > Instead the group will devote itself to securing access to the comfort > of cats and sofas either during or after regular OpenStack events, > including, but not limited to, the PTG and Summit. > > Such cats and sofas will provide succour in the face of extended > social engagement, refreshing members of the SIG (and anyone else) who > needs a little pick me up before returning to discussion, refreshed > and ready. I will definitely join this SIG. I suggest to support Bare Metal sofas only and make the cats happy by orchestrating the sofa place with Heat. Cheers, gibi > > -- > Chris Dent (⊙＿⊙') > https://anticdent.org/ > freenode: cdent tw: @anticdent > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From zhipengh512 at gmail.com Sat Mar 3 10:39:08 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Sat, 3 Mar 2018 10:39:08 +0000 Subject: [Openstack-sigs] [tc][ltm]Long Term Maintenance mode discussion Message-ID: Hi operators, users and public cloud providers, I would like to draw your attention to a discussion[0] happening now on the Technical Committee side about introducing a resolution on how to better provide long term maintenance for stable branches. As I understand this is a widely desired feature so please help reviewing the patch with your insight. For public cloud providers , if you have any questions we could discuss on #openstack-publiccloud and then Tobias or me could relay any concerns you might have but find it difficult to directly comment on the patch. Thanks :) [0]https://review.openstack.org/#/c/548916/ -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From colleen at gazlene.net Sun Mar 4 13:20:12 2018 From: colleen at gazlene.net (Colleen Murphy) Date: Sun, 04 Mar 2018 14:20:12 +0100 Subject: [Openstack-sigs] [product][meta] Disbanding the Product Working Group In-Reply-To: References: Message-ID: <1520169612.3902173.1290876496.491E2581@webmail.messagingengine.com> On Tue, Feb 27, 2018, at 5:15 PM, Shamail Tahir wrote: > Hi User Committee and Meta-SIG, > > PWG presented a proposal to disband the working group at the OpenStack > Foundation Board meeting yesterday and the board agreed with our assessment > and recommendation. This message is to formally request for the WG to be > wrapped up (since it is under UC governance) and also to share relevant > information with the Meta-SIG team... > > We believe that relatively recent changes in the OpenStack community > (within the last year) allow for objectives such as cross project > coordination/collaboration, WG/Project team collaboration, and building > multi-release directional guidance in a distributed manner across our > community. This means that most of the goals of the product working group > charter now have better avenues for delivery than within the group itself. > > The three major goals for the Product Working Group were: > > - Creating a community-generated multi-release roadmap > - Collect feedback and aggregate requirements from our user-base and the > various 'markets' where OpenStack clouds have been adopted > - Plan, prioritize, coordinate, and track implementation of development > proposals > > > Each of these goals is being pursued through various structures and > initiatives within the OpenStack community at this point: > > - The PWG roadmap sub-team was spun off from the Product Working Group > and is being led by Anne Bertucio from the OpenStack Foundation (this team > is looking for more volunteers, so please let Anne know if you are > interested!) > - The forum event allows for both individual teams and SIGs to discuss > requirements directly with stakeholders and users > - The advent of SIGs allows for greater collaboration between > developers, operators, users, and other stakeholders within the same group. > - Cross-project efforts that require collaboration between teams to > deliver a capability can be facilitated through the SIG construct and > things that we would like to see adopted across all projects can be > addressed via release goals. > > The development proposal workflow we created within the PWG, we believe, > could provide SIGs with a useful framework on how ideas can be taken from > concept to implementation in a repeatable manner. If the Meta-SIG is > interested in learning more about the workflow, the core members from the > PWG would be glad to join a meeting to discuss the workflow and help > transition it to the Meta-SIG. Please let us know! > > The core members of the Product Working Group would like to thank everyone > who contributed in this working group (including OpenStack Foundation > staff) and helped pave the way for a successful exit! It has been an > amazing journey over the last 3 years and we want to thank the OpenStack > community for working with us along the way and making this a rewarding > experience. > > Link to PWG Board presentation: > https://docs.google.com/presentation/d/17Z5vCfZDO3GO2DP4ckIqokSpVfLY1NQAo5dsuzxj-7A > > Thanks, > Product Working Group Core Team > (Arkady Kanevsky, Gerald Kunzmann, Rochelle Grober, Shamail Tahir, & Yih > Sun Leong) Thanks for this update and for everyone's hard work. A bit of a housekeeping inquiry: one of our PTG topics within the keystone team was reviewing and updating our liaisons for various working groups. Does the Product Working Group still need vertical team liaisons, or can this wiki entry be cleaned up? https://wiki.openstack.org/wiki/CrossProjectLiaisons#Product_Working_Group Thanks! Colleen From itzshamail at gmail.com Mon Mar 5 11:51:10 2018 From: itzshamail at gmail.com (Shamail Tahir) Date: Mon, 5 Mar 2018 06:51:10 -0500 Subject: [Openstack-sigs] [product][meta] Disbanding the Product Working Group In-Reply-To: <1520169612.3902173.1290876496.491E2581@webmail.messagingengine.com> References: <1520169612.3902173.1290876496.491E2581@webmail.messagingengine.com> Message-ID: Hi Colleen, > On Mar 4, 2018, at 8:20 AM, Colleen Murphy wrote: > > > >> On Tue, Feb 27, 2018, at 5:15 PM, Shamail Tahir wrote: >> Hi User Committee and Meta-SIG, >> >> PWG presented a proposal to disband the working group at the OpenStack >> Foundation Board meeting yesterday and the board agreed with our assessment >> and recommendation. This message is to formally request for the WG to be >> wrapped up (since it is under UC governance) and also to share relevant >> information with the Meta-SIG team... >> >> We believe that relatively recent changes in the OpenStack community >> (within the last year) allow for objectives such as cross project >> coordination/collaboration, WG/Project team collaboration, and building >> multi-release directional guidance in a distributed manner across our >> community. This means that most of the goals of the product working group >> charter now have better avenues for delivery than within the group itself. >> >> The three major goals for the Product Working Group were: >> >> - Creating a community-generated multi-release roadmap >> - Collect feedback and aggregate requirements from our user-base and the >> various 'markets' where OpenStack clouds have been adopted >> - Plan, prioritize, coordinate, and track implementation of development >> proposals >> >> >> Each of these goals is being pursued through various structures and >> initiatives within the OpenStack community at this point: >> >> - The PWG roadmap sub-team was spun off from the Product Working Group >> and is being led by Anne Bertucio from the OpenStack Foundation (this team >> is looking for more volunteers, so please let Anne know if you are >> interested!) >> - The forum event allows for both individual teams and SIGs to discuss >> requirements directly with stakeholders and users >> - The advent of SIGs allows for greater collaboration between >> developers, operators, users, and other stakeholders within the same group. >> - Cross-project efforts that require collaboration between teams to >> deliver a capability can be facilitated through the SIG construct and >> things that we would like to see adopted across all projects can be >> addressed via release goals. >> >> The development proposal workflow we created within the PWG, we believe, >> could provide SIGs with a useful framework on how ideas can be taken from >> concept to implementation in a repeatable manner. If the Meta-SIG is >> interested in learning more about the workflow, the core members from the >> PWG would be glad to join a meeting to discuss the workflow and help >> transition it to the Meta-SIG. Please let us know! >> >> The core members of the Product Working Group would like to thank everyone >> who contributed in this working group (including OpenStack Foundation >> staff) and helped pave the way for a successful exit! It has been an >> amazing journey over the last 3 years and we want to thank the OpenStack >> community for working with us along the way and making this a rewarding >> experience. >> >> Link to PWG Board presentation: >> https://docs.google.com/presentation/d/17Z5vCfZDO3GO2DP4ckIqokSpVfLY1NQAo5dsuzxj-7A >> >> Thanks, >> Product Working Group Core Team >> (Arkady Kanevsky, Gerald Kunzmann, Rochelle Grober, Shamail Tahir, & Yih >> Sun Leong) > > Thanks for this update and for everyone's hard work. > > A bit of a housekeeping inquiry: one of our PTG topics within the keystone team was reviewing and updating our liaisons for various working groups. Does the Product Working Group still need vertical team liaisons, or can this wiki entry be cleaned up? Thank you. They can be cleaned up. I’ll make the edit later today. > > https://wiki.openstack.org/wiki/CrossProjectLiaisons#Product_Working_Group > > Thanks! > > Colleen > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From lhinds at redhat.com Mon Mar 5 16:41:39 2018 From: lhinds at redhat.com (Luke Hinds) Date: Mon, 5 Mar 2018 16:41:39 +0000 Subject: [Openstack-sigs] [security] Security SIG Meeting Time Change Message-ID: Hi All, As agreed during the PTG, we will switch Thursdays meetings from 17:00 UTC, to 15:00 UTC. -- Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Mon Mar 5 20:00:19 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Mon, 05 Mar 2018 20:00:19 +0000 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions Message-ID: Hello Everyone :) It was wonderful to see and talk with so many of you last week! For those that couldn't attend our whole day of chats or those that couldn't attend at all, I thought I would put forth a summary of our discussions which were mostly noted in the etherpad[1] #Contributor Guide# - Walkthrough: We walked through every section of what exists and came up with a variety of improvements on what is there. Most of these items have been added to our StoryBoard project[2]. This came up again Tuesday in docs sessions and I have added those items to StoryBoard as well. - Google Analytics: It was discussed we should do something about getting the contributor portal[3] to appear higher in Google searches about onboarding. Not sure what all this entails. NEEDS AN OWNER IF ANYONE WANTS TO VOLUNTEER. #Mission Statement# We updated our mission statement[4]! It now states: To provide a place for new contributors to come for information and advice. This group will also analyze and document successful contribution models while seeking out and providing information to new members of the community. #Weekly Meeting# We discussed beginning a weekly meeting- optimized for APAC/Europe and settled on 800 UTC in #openstack-meeting on Wednesdays. Proposed here[5]. For now I added a section to our wiki for agenda organization[6]. The two main items we want to cover on a weekly basis are new contributor patches in gerrit and if anything has come up on ask.openstack.org about contributors so those will be standing agenda items. #Forum Session# We discussed proposing some forum sessions in order to get more involvement from operators. Currently, our activities focus on development activities and we would like to diversify. When this SIG was first proposed we wanted to have two chairs- one to represent developers and one to represent operators. We will propose a session or two when the call for forum proposals go out (should be today). #IRC Channels# We want to get rid of #openstack-101 and begin using #openstack-dev instead. The 101 channel isn't watched closely enough anymore and it makes more sense to move onboarding activities (like in OpenStack Upstream Institute) to a channel where there are people that can answer questions rather than asking those to move to a new channel. For those concerned about noise, OUI is run the weekend before the summit when most people are traveling to the Summit anyway. #Ongoing Onboarding Efforts# - GSOC: Unfortunately we didn't get accepted this year. We will try again next year. - Outreachy: Applications for the next round of interns are due March 22nd, 2018 [7]. Decisions will be made by April and then internships run May to August. - WoO Mentoring: The format of mentoring is changing from 1x1 to cohorts focused on a single goal. If you are interested in helping out, please contact me! I NEED HELP :) - Contributor guide: Please see the above section. - OpenStack Upstream Institute: It will be run, as usual, the weekend before the Summit in Vancouver. Depending on how much progress is made on the contributor guide, we will make use of it as opposed to slides like previous renditions. There have also been a number of OpenStack Days requesting we run it there as well. More details of those to come. #Project Liaisons# The list is filling out nicely, but we still need more coverage. If you know someone from a project not listed that might be willing to help, please reach out to them and get them added to our list [8]. I thiiiiiink that is just about everything. Hopefully I at least covered everything important :) Thanks Everyone! - Kendall Nelson (diablo_rojo) [1] PTG Etherpad https://etherpad.openstack.org/p/FC_SIG_Rocky_PTG [2] StoryBoard Tracker https://storyboard.openstack.org/#!/project/913 [3] Contributor Portal https://www.openstack.org/community/ [4] Mission Statement Update https://review.openstack.org/#/c/548054/ [5] Meeting Slot Proposal https://review.openstack.org/#/c/549849/ [6] Meeting Agenda https://wiki.openstack.org/wiki/First_Contact_SIG#Meeting_Agenda [7] Outreachy https://www.outreachy.org/apply/ [8] Project Liaisons https://wiki.openstack.org/wiki/First_Contact_SIG#Project_Liaisons -------------- next part -------------- An HTML attachment was scrubbed... URL: From thingee at gmail.com Mon Mar 5 23:15:38 2018 From: thingee at gmail.com (Mike Perez) Date: Mon, 5 Mar 2018 15:15:38 -0800 Subject: [Openstack-sigs] [forum] Brainstorming Topics for Vancouver 2018 Message-ID: <20180305231538.GF32596@gmail.com> Hi all, Welcome to the topic selection process for our Forum in Vancouver. Note that this is not a classic conference track with speakers and presentations. OpenStack community members (participants in development teams, SIGS, working groups, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is for the entire community to come together, to create a neutral space rather than having separate "ops" and "dev" days. Users should should aim to come with ideas for for the next release, gather feedback on the past version and have strategic discussions that go beyond just one release cycle. We aim to ensure the broadest coverage of topics that will allow for multiple parts of the community getting together to discuss key areas within our community/projects. There are two stages to the brainstorming: 1. Starting today, set up an etherpad with your team and start discussing ideas you'd like to talk about at the Forum and work out which ones to submit - just like you did prior to the design summit. 2. Then, in a couple of weeks, we will open up a more formal web-based tool for you to submit abstracts for the most popular sessions that came out of your brainstorming. Make an etherpad and add it to the list at: https://wiki.openstack.org/wiki/Forum/Vancouver2018 One key thing we'd like to see (as always?) is cross-project collaboration, and discussion between every area of the community. Try to see if there is an interested working group on the user side to add to your ideas. Examples of typical discussions that include multiple parts of the community getting together to discuss: * Strategic, whole-of-community discussions, to think about the big picture, including beyond just one release cycle and new technologies o eg Making OpenStack One Platform for containers/VMs/Bare Metal (Strategic session) the entire community congregates to share opinions on how to make OpenStack achieve its integration engine goal * Cross-project sessions, in a similar vein to what has happened at past design summits, but with increased emphasis on issues that are of relevant to all areas of the community o eg Rolling Upgrades at Scale (Cross-Project session) -- the Large Deployments Team collaborates with Nova, Cinder and Keystone to tackle issues that come up with rolling upgrades when there's a large number of machines. * Project-specific sessions, where developers can ask users specific questions about their experience, users can provide feedback from the last release and cross-community collaboration on the priorities and 'blue sky' ideas for the next release. o eg Neutron Pain Points (Project-Specific session) -- Co-organized by neutron developers and users. Neutron developers bring some specific questions they want answered, Neutron users bring feedback from the latest release and ideas about the future. Think about what kind of session ideas might end up as: Project-specific, cross-project or strategic/whole-of-community discussions. There'll be more slots for the latter two, so do try and think outside the box! This part of the process is where we gather broad community consensus - in theory the second part is just about fitting in as many of the good ideas into the schedule as we can. Further details about the forum can be found at: https://wiki.openstack.org/wiki/Forum -- Mike Perez (thingee) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From fungi at yuggoth.org Tue Mar 6 14:23:48 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 6 Mar 2018 14:23:48 +0000 Subject: [Openstack-sigs] [openstack-dev] [security] Security SIG Meeting Time Change In-Reply-To: References: Message-ID: <20180306142348.c4yc5nmclsalk2bk@yuggoth.org> On 2018-03-05 16:41:39 +0000 (+0000), Luke Hinds wrote: > As agreed during the PTG, we will switch Thursdays meetings from > 17:00 UTC, to 15:00 UTC. This conflicts with the third (and generally most active) weekly TC office hour, but I should hopefully be able to juggle participating in both. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From stig.openstack at telfer.org Tue Mar 6 20:23:48 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Tue, 6 Mar 2018 20:23:48 +0000 Subject: [Openstack-sigs] [scientific] IRC Meeting 2100UTC - PTG Roundup Message-ID: <175B8A91-0D57-4BC4-B021-C72348CABC7B@telfer.org> Hi All - We have a Scientific SIG IRC meeting today at 2100 UTC (about 30 minutes time). Everyone is welcome. Today we’d like to do a round-up of all the SIG activities and related goings-on at the PTG in Dublin. The agenda and meeting details are available here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_March_6th_2018 Cheers, Stig From chris at openstack.org Wed Mar 7 00:56:27 2018 From: chris at openstack.org (Chris Hoge) Date: Tue, 6 Mar 2018 16:56:27 -0800 Subject: [Openstack-sigs] SIG-K8s Meeting tomorrow at March 8 at 00:00 UTC / March 7 at 16:00 PST Message-ID: Please join us for the next K8s-SIG-OpenStack meeting, taking place tomorrow at March 8 at 00:00 UTC / March 7 at 16:00 PST. The agenda will include: * OpenStack PTG Wrap-up * External OpenStack Cloud Controller Manager migration to OpenStack community. * Cloud Provider Documentation. * Status of Load Balancers in OpenStack public clouds. Please add additional agenda items here: https://docs.google.com/document/d/15UwgLbEyZyXXxVtsThcSuPiJru4CuqU9p3ttZSfTaY4/edit?usp=sharing Zoom meeting room: https://zoom.us/j/417251241 Thanks, Chris From zhipengh512 at gmail.com Wed Mar 7 16:36:08 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Thu, 8 Mar 2018 00:36:08 +0800 Subject: [Openstack-sigs] [openstack-dev] [keystone] [oslo] new unified limit library In-Reply-To: <0C7BCB2F-BE9C-4B8B-8344-0DA03F16BA9A@cern.ch> References: <5AA005E0.7050808@windriver.com> <4a8db303-318d-c385-c350-ef25702d8b20@gmail.com> <60EC27CD-7F2F-4328-A09D-94CB92ED7988@cern.ch> <0C7BCB2F-BE9C-4B8B-8344-0DA03F16BA9A@cern.ch> Message-ID: This is certainly a feature will make Public Cloud providers very happy :) On Thu, Mar 8, 2018 at 12:33 AM, Tim Bell wrote: > Sorry, I remember more detail now... it was using the 'owner' of the VM as > part of the policy rather than quota. > > Is there a per-user/per-group quota in Nova? > > Tim > > -----Original Message----- > From: Tim Bell > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev at lists.openstack.org> > Date: Wednesday, 7 March 2018 at 17:29 > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev at lists.openstack.org> > Subject: Re: [openstack-dev] [keystone] [oslo] new unified limit library > > > There was discussion that Nova would deprecate the user quota feature > since it really didn't fit well with the 'projects own resources' approach > and was little used. At one point, some of the functionality stopped > working and was repaired. The use case we had identified goes away if you > have 2 level deep nested quotas (and we have now worked around it). > > Tim > -----Original Message----- > From: Lance Bragstad > Reply-To: "OpenStack Development Mailing List (not for usage > questions)" > Date: Wednesday, 7 March 2018 at 16:51 > To: "openstack-dev at lists.openstack.org" openstack.org> > Subject: Re: [openstack-dev] [keystone] [oslo] new unified limit > library > > > > On 03/07/2018 09:31 AM, Chris Friesen wrote: > > On 03/07/2018 08:58 AM, Lance Bragstad wrote: > >> Hi all, > >> > ] > > > > 1) Nova currently supports quotas for a user/group tuple that > can be > > stricter than the overall quotas for that group. As far as I > know no > > other project supports this. > ... > I think the initial implementation of a unified limit pattern is > targeting limits and quotas for things associated to projects. In > the > future, we can probably expand on the limit information in > keystone to > include user-specific limits, which would be great if nova wants > to move > away from handling that kind of stuff. > > > > Chris > > > > ____________________________________________________________ > ______________ > > > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > > OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bell at cern.ch Wed Mar 7 16:44:10 2018 From: Tim.Bell at cern.ch (Tim Bell) Date: Wed, 7 Mar 2018 16:44:10 +0000 Subject: [Openstack-sigs] [openstack-dev] [keystone] [oslo] new unified limit library In-Reply-To: References: <5AA005E0.7050808@windriver.com> <4a8db303-318d-c385-c350-ef25702d8b20@gmail.com> <60EC27CD-7F2F-4328-A09D-94CB92ED7988@cern.ch> <0C7BCB2F-BE9C-4B8B-8344-0DA03F16BA9A@cern.ch> Message-ID: I think nested quotas would give the same thing, i.e. you have a parent project for the group and child projects for the users. This would not need user/group quotas but continue with the ‘project owns resources’ approach. It can be generalised to other use cases like the value add partner or the research experiment working groups (http://openstack-in-production.blogspot.fr/2017/07/nested-quota-models.html) Tim From: Zhipeng Huang Reply-To: "openstack-sigs at lists.openstack.org" Date: Wednesday, 7 March 2018 at 17:37 To: "OpenStack Development Mailing List (not for usage questions)" , openstack-operators , "openstack-sigs at lists.openstack.org" Subject: Re: [Openstack-sigs] [openstack-dev] [keystone] [oslo] new unified limit library This is certainly a feature will make Public Cloud providers very happy :) On Thu, Mar 8, 2018 at 12:33 AM, Tim Bell > wrote: Sorry, I remember more detail now... it was using the 'owner' of the VM as part of the policy rather than quota. Is there a per-user/per-group quota in Nova? Tim -----Original Message----- From: Tim Bell > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Wednesday, 7 March 2018 at 17:29 To: "OpenStack Development Mailing List (not for usage questions)" > Subject: Re: [openstack-dev] [keystone] [oslo] new unified limit library There was discussion that Nova would deprecate the user quota feature since it really didn't fit well with the 'projects own resources' approach and was little used. At one point, some of the functionality stopped working and was repaired. The use case we had identified goes away if you have 2 level deep nested quotas (and we have now worked around it). Tim -----Original Message----- From: Lance Bragstad > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Wednesday, 7 March 2018 at 16:51 To: "openstack-dev at lists.openstack.org" > Subject: Re: [openstack-dev] [keystone] [oslo] new unified limit library On 03/07/2018 09:31 AM, Chris Friesen wrote: > On 03/07/2018 08:58 AM, Lance Bragstad wrote: >> Hi all, >> ] > > 1) Nova currently supports quotas for a user/group tuple that can be > stricter than the overall quotas for that group. As far as I know no > other project supports this. ... I think the initial implementation of a unified limit pattern is targeting limits and quotas for things associated to projects. In the future, we can probably expand on the limit information in keystone to include user-specific limits, which would be great if nova wants to move away from handling that kind of stuff. > > Chris > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.friesen at windriver.com Wed Mar 7 21:55:53 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Wed, 7 Mar 2018 15:55:53 -0600 Subject: [Openstack-sigs] [openstack-dev] [keystone] [oslo] new unified limit library In-Reply-To: References: <5AA005E0.7050808@windriver.com> <4a8db303-318d-c385-c350-ef25702d8b20@gmail.com> <60EC27CD-7F2F-4328-A09D-94CB92ED7988@cern.ch> <0C7BCB2F-BE9C-4B8B-8344-0DA03F16BA9A@cern.ch> Message-ID: <5AA05FE9.6050708@windriver.com> On 03/07/2018 10:44 AM, Tim Bell wrote: > I think nested quotas would give the same thing, i.e. you have a parent project > for the group and child projects for the users. This would not need user/group > quotas but continue with the ‘project owns resources’ approach. Agreed, I think that if we support nested quotas with a suitable depth of nesting it could be used to handle the existing nova user/project quotas. Chris From Tim.Bell at cern.ch Mon Mar 12 16:57:09 2018 From: Tim.Bell at cern.ch (Tim Bell) Date: Mon, 12 Mar 2018 16:57:09 +0000 Subject: [Openstack-sigs] [scientific] Burn in testing Message-ID: <9843CD42-1D91-48B9-8172-A5E6DCE7A125@cern.ch> FYI, Pre-stressing hardware before production has been a topic in some of the scientific SIG discussions. The CERN process is now described in http://openstack-in-production.blogspot.fr/2018/03/hardware-burn-in-in-cern-datacenter.html. The current implementation is not easily portable to other clouds but there is ongoing discussion with the Ironic team to see how this sort of approach can be integrated. Discussions have started now in openstack-dev for those who are interested. Tim From aspiers at suse.com Tue Mar 13 17:51:35 2018 From: aspiers at suse.com (Adam Spiers) Date: Tue, 13 Mar 2018 17:51:35 +0000 Subject: [Openstack-sigs] [self-healing][PTG][congress][monasca] etherpad for PTG session on self-healing In-Reply-To: References: <5cf370bf9248400ebbd471055e7cb78a@R01UKEXCASM126.r01.fujitsu.local> <20180223110736.krfrcdumeatpouka@pacific.linksys.moosehall> Message-ID: <20180313175135.7run2f3tnhjmt3k2@pacific.linksys.moosehall> Hi Nemat, Sorry for the slow reply, it's been busy with the PTG and the resulting backlog :-) Nematollah Bidokhti wrote: >Hi Adam, > >I divide the self-healing issues into two categories (maybe there are more): > >1- Known issues (these are the error codes that have been identified by individual projects) >2- Unknown issues (things that we find out based on real-time monitoring and anomaly detection) Yes, that's one reasonable way to divide them. >What will be the initial focus of self-healing Sig? The first, since the "self-" part of self-healing requires that we can automate action to address issues which need fixing, and that in turn requires a strong understanding of the issues. >The 2nd item is a lot more complicated and will take time to define >and implement. Absolutely. I see that as a much longer-term goal. > The 1st one is feasible and can be achieved in reasonable time. This > also depends on the type of issues. Exactly, we have to walk before we can run :-) >For example, networking issues could be difficult to monitor and recover. That's interesting that you picked networking issues as an example, since NIC failure is one of the first use cases which has already been tackled: https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral and I also mentioned this last night in a presentation to the London OpenStack Meetup: https://aspiers.github.io/openstack-meetup-london-march-2018-self-healing/#/use-case-1 But of course there are many different types of networking issues, and tackling them as a whole is much harder than tackling an individual failure case :-) Cheers, Adam From aspiers at suse.com Tue Mar 13 18:09:14 2018 From: aspiers at suse.com (Adam Spiers) Date: Tue, 13 Mar 2018 18:09:14 +0000 Subject: [Openstack-sigs] [self-healing] proposed talks for Vancouver In-Reply-To: <2044939227.3799861.1519468328849@mail.yahoo.com> References: <5cf370bf9248400ebbd471055e7cb78a@R01UKEXCASM126.r01.fujitsu.local> <2044939227.3799861.1519468328849@mail.yahoo.com> Message-ID: <20180313180914.kj442fxk2jsoz3ed@pacific.linksys.moosehall> Ifat Afek wrote: >Hi Adam, >Two other sesdion proposals for Vancouver that are related to self healing: > > >Proactive Root Cause Analysis with Vitrage, Kubernetes, Zabbix and Prometheus: > https://www.openstack.org/summit/vancouver-2018/vote-for-speakers/#/20964 > >Closing the loop: VNF end-to-end failure detection and auto healing: >https://www.openstack.org/summit/vancouver-2018/vote-for-speakers/#/20839 Thanks! I've added them to the wiki: https://wiki.openstack.org/wiki/Self-healing_SIG#Upcoming_events From Tim.Bell at cern.ch Tue Mar 13 19:35:25 2018 From: Tim.Bell at cern.ch (Tim Bell) Date: Tue, 13 Mar 2018 19:35:25 +0000 Subject: [Openstack-sigs] [User-committee] [Scientific] Unified limits and hierarchical project use cases Message-ID: Lance, Thanks for reaching out. BTW, we're not set on how hierarchical quotas should work but we were trying to write down a possible scenario. There was also quite a lot of interest from other labs so I'm adding the Scientific SIG to the thread. We also expanded a little on the approach in http://openstack-in-production.blogspot.fr/2017/07/nested-quota-models.html based on some discussions with Sean where he was looking for more detail. Tim -----Original Message----- From: Lance Bragstad Date: Tuesday, 13 March 2018 at 20:25 To: "user-committee at lists.openstack.org" Subject: [User-committee] Unified limits and hierarchical project use cases Hey all, Unified limits and hierarchical quotas was a big topic during the Rocky PTG. With the ground work laid in Queens, most of the discussions for Rocky focused on different enforcement models. For those who haven't been keeping up with the unified limits discussions, an enforcement model is an opinionated way of how a quota, or limit, should behave with respect to other parent, sibling, or child projects. It's possible to think of multiple ways in which enforcement can be done, and it's not that there is one right way and the rest are wrong, just a difference in how quotas might need to behave for different deployments. During the discussions at the PTG, everyone in the room agreed that we don't really understand how people are using hierarchical projects. This makes it tough to design a quota or limit enforcement model without understanding how people expect it to work. Tim Bell has taken some time to write down how he expects a quota system to work for CERN's use case [0], which we'll be working into a specification for an enforcement model [1]. We'd like to see if the User Committee can help us collect more information from users and operators about how they expect enforcement to be done. Do your deployments use hierarchical projects? How do you manage quota today? Do you have expectations about how quotas and limits work across related projects (e.g. setting quota on a parent project affects the children in X ways)? Depending on responses, it'd be nice to aggregate the results, kind of like what Tim provided, so that we can write a specification for them. Is there a way we can leverage the UC to collect this information? Thanks, Lance [0] http://lists.openstack.org/pipermail/openstack-dev/2017-February/111999.html [1] https://review.openstack.org/#/c/549766/ From john at johngarbutt.com Tue Mar 13 21:07:23 2018 From: john at johngarbutt.com (John Garbutt) Date: Tue, 13 Mar 2018 21:07:23 +0000 Subject: [Openstack-sigs] [User-committee] [Scientific] Unified limits and hierarchical project use cases In-Reply-To: References: Message-ID: On Tue, 13 Mar 2018 at 19:36, Tim Bell wrote: > Lance, > > Thanks for reaching out. BTW, we're not set on how hierarchical quotas > should work but we were trying to write down a possible scenario. There was > also quite a lot of interest from other labs so I'm adding the Scientific > SIG to the thread. > > We also expanded a little on the approach in > http://openstack-in-production.blogspot.fr/2017/07/nested-quota-models.html > based on some discussions with Sean where he was looking for more detail. > I had forgotton about that blog, thanks for reminding me. My current proposal is really going for something as simple as possible that unblocks a bunch of use cases in a way that we can discover what might need building next: https://review.openstack.org/#/c/549766/ It limits the hierarchy to two levels for coding (and operational) simplicity. I was thinking of the community / virtual organisation model (VOMS/EGI AAI), where the community gets an amount of quota. That community is then allowed one level of sub projects that can also use some resources from the pool of quota given to the whole community. Given you must count how many resources are owned by all projects in the tree, there is a strong argument towards keeping the tree as small as possible. I am particularly interested in the use cases that are really blocked with only two levels of hierarchy. Thanks, John -----Original Message----- > From: Lance Bragstad > Date: Tuesday, 13 March 2018 at 20:25 > To: "user-committee at lists.openstack.org" < > user-committee at lists.openstack.org> > Subject: [User-committee] Unified limits and hierarchical project use cases > > Hey all, > > Unified limits and hierarchical quotas was a big topic during the Rocky > PTG. With the ground work laid in Queens, most of the discussions for > Rocky focused on different enforcement models. > > For those who haven't been keeping up with the unified limits > discussions, an enforcement model is an opinionated way of how a quota, > or limit, should behave with respect to other parent, sibling, or child > projects. It's possible to think of multiple ways in which enforcement > can be done, and it's not that there is one right way and the rest are > wrong, just a difference in how quotas might need to behave for > different deployments. > > During the discussions at the PTG, everyone in the room agreed that we > don't really understand how people are using hierarchical projects. > This > makes it tough to design a quota or limit enforcement model without > understanding how people expect it to work. Tim Bell has taken some > time > to write down how he expects a quota system to work for CERN's use case > [0], which we'll be working into a specification for an enforcement > model [1]. > > We'd like to see if the User Committee can help us collect more > information from users and operators about how they expect enforcement > to be done. Do your deployments use hierarchical projects? How do you > manage quota today? Do you have expectations about how quotas and > limits > work across related projects (e.g. setting quota on a parent project > affects the children in X ways)? > > Depending on responses, it'd be nice to aggregate the results, kind of > like what Tim provided, so that we can write a specification for them. > > Is there a way we can leverage the UC to collect this information? > > Thanks, > > Lance > > [0] > > http://lists.openstack.org/pipermail/openstack-dev/2017-February/111999.html > [1] https://review.openstack.org/#/c/549766/ > > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bell at cern.ch Tue Mar 13 21:22:00 2018 From: Tim.Bell at cern.ch (Tim Bell) Date: Tue, 13 Mar 2018 21:22:00 +0000 Subject: [Openstack-sigs] [User-committee] [Scientific] Unified limits and hierarchical project use cases In-Reply-To: References: Message-ID: <22661168-FA4C-4572-BF54-F704E65191C9@cern.ch> John, Two levels would certainly solve the vast majority of our use cases (i.e. delegation to a VO/Experiment within an envelope). The CERN blog included the expansion to 3 in that there had been some concerns from potential implementers raised over the algorithms when the nesting went beyond 2. Replacing the per user use case and moving resource ownership to the project would also simplify code in other areas. Tim From: John Garbutt Date: Tuesday, 13 March 2018 at 22:08 To: "openstack-sigs at lists.openstack.org" Cc: "user-committee at lists.openstack.org" Subject: Re: [User-committee] [Openstack-sigs] [Scientific] Unified limits and hierarchical project use cases On Tue, 13 Mar 2018 at 19:36, Tim Bell > wrote: Lance, Thanks for reaching out. BTW, we're not set on how hierarchical quotas should work but we were trying to write down a possible scenario. There was also quite a lot of interest from other labs so I'm adding the Scientific SIG to the thread. We also expanded a little on the approach in http://openstack-in-production.blogspot.fr/2017/07/nested-quota-models.html based on some discussions with Sean where he was looking for more detail. I had forgotton about that blog, thanks for reminding me. My current proposal is really going for something as simple as possible that unblocks a bunch of use cases in a way that we can discover what might need building next: https://review.openstack.org/#/c/549766/ It limits the hierarchy to two levels for coding (and operational) simplicity. I was thinking of the community / virtual organisation model (VOMS/EGI AAI), where the community gets an amount of quota. That community is then allowed one level of sub projects that can also use some resources from the pool of quota given to the whole community. Given you must count how many resources are owned by all projects in the tree, there is a strong argument towards keeping the tree as small as possible. I am particularly interested in the use cases that are really blocked with only two levels of hierarchy. Thanks, John -----Original Message----- From: Lance Bragstad > Date: Tuesday, 13 March 2018 at 20:25 To: "user-committee at lists.openstack.org" > Subject: [User-committee] Unified limits and hierarchical project use cases Hey all, Unified limits and hierarchical quotas was a big topic during the Rocky PTG. With the ground work laid in Queens, most of the discussions for Rocky focused on different enforcement models. For those who haven't been keeping up with the unified limits discussions, an enforcement model is an opinionated way of how a quota, or limit, should behave with respect to other parent, sibling, or child projects. It's possible to think of multiple ways in which enforcement can be done, and it's not that there is one right way and the rest are wrong, just a difference in how quotas might need to behave for different deployments. During the discussions at the PTG, everyone in the room agreed that we don't really understand how people are using hierarchical projects. This makes it tough to design a quota or limit enforcement model without understanding how people expect it to work. Tim Bell has taken some time to write down how he expects a quota system to work for CERN's use case [0], which we'll be working into a specification for an enforcement model [1]. We'd like to see if the User Committee can help us collect more information from users and operators about how they expect enforcement to be done. Do your deployments use hierarchical projects? How do you manage quota today? Do you have expectations about how quotas and limits work across related projects (e.g. setting quota on a parent project affects the children in X ways)? Depending on responses, it'd be nice to aggregate the results, kind of like what Tim provided, so that we can write a specification for them. Is there a way we can leverage the UC to collect this information? Thanks, Lance [0] http://lists.openstack.org/pipermail/openstack-dev/2017-February/111999.html [1] https://review.openstack.org/#/c/549766/ _______________________________________________ openstack-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrhillsman at gmail.com Tue Mar 13 21:27:13 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Tue, 13 Mar 2018 16:27:13 -0500 Subject: [Openstack-sigs] [User-committee] [Scientific] Unified limits and hierarchical project use cases In-Reply-To: References: Message-ID: Hey Lance, Thanks for putting this on our radar. Personally I need to read Tim's blog and understand a bit more about what this is exactly. I do remember a thread last year that got a lot of responses of which hierarchical quotas[0] [0] http://lists.openstack.org/pipermail/openstack-operators/2017-January/012436.html On Tue, Mar 13, 2018 at 4:07 PM, John Garbutt wrote: > On Tue, 13 Mar 2018 at 19:36, Tim Bell wrote: > >> Lance, >> >> Thanks for reaching out. BTW, we're not set on how hierarchical quotas >> should work but we were trying to write down a possible scenario. There was >> also quite a lot of interest from other labs so I'm adding the Scientific >> SIG to the thread. >> >> We also expanded a little on the approach in http://openstack-in- >> production.blogspot.fr/2017/07/nested-quota-models.html based on some >> discussions with Sean where he was looking for more detail. >> > > I had forgotton about that blog, thanks for reminding me. > > My current proposal is really going for something as simple as possible > that unblocks a bunch of use cases in a way that we can discover what might > need building next: > https://review.openstack.org/#/c/549766/ > > It limits the hierarchy to two levels for coding (and operational) > simplicity. I was thinking of the community / virtual organisation model > (VOMS/EGI AAI), where the community gets an amount of quota. That community > is then allowed one level of sub projects that can also use some resources > from the pool of quota given to the whole community. Given you must count > how many resources are owned by all projects in the tree, there is a strong > argument towards keeping the tree as small as possible. > > I am particularly interested in the use cases that are really blocked with > only two levels of hierarchy. > > Thanks, > John > > -----Original Message----- >> From: Lance Bragstad >> Date: Tuesday, 13 March 2018 at 20:25 >> To: "user-committee at lists.openstack.org" > openstack.org> >> Subject: [User-committee] Unified limits and hierarchical project use >> cases >> >> Hey all, >> >> Unified limits and hierarchical quotas was a big topic during the >> Rocky >> PTG. With the ground work laid in Queens, most of the discussions for >> Rocky focused on different enforcement models. >> >> For those who haven't been keeping up with the unified limits >> discussions, an enforcement model is an opinionated way of how a >> quota, >> or limit, should behave with respect to other parent, sibling, or >> child >> projects. It's possible to think of multiple ways in which enforcement >> can be done, and it's not that there is one right way and the rest are >> wrong, just a difference in how quotas might need to behave for >> different deployments. >> >> During the discussions at the PTG, everyone in the room agreed that we >> don't really understand how people are using hierarchical projects. >> This >> makes it tough to design a quota or limit enforcement model without >> understanding how people expect it to work. Tim Bell has taken some >> time >> to write down how he expects a quota system to work for CERN's use >> case >> [0], which we'll be working into a specification for an enforcement >> model [1]. >> >> We'd like to see if the User Committee can help us collect more >> information from users and operators about how they expect enforcement >> to be done. Do your deployments use hierarchical projects? How do you >> manage quota today? Do you have expectations about how quotas and >> limits >> work across related projects (e.g. setting quota on a parent project >> affects the children in X ways)? >> >> Depending on responses, it'd be nice to aggregate the results, kind of >> like what Tim provided, so that we can write a specification for them. >> >> Is there a way we can leverage the UC to collect this information? >> >> Thanks, >> >> Lance >> >> [0] >> http://lists.openstack.org/pipermail/openstack-dev/2017- >> February/111999.html >> [1] https://review.openstack.org/#/c/549766/ >> >> >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > > _______________________________________________ > User-committee mailing list > User-committee at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee > > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martialmichel at datamachines.io Tue Mar 13 21:37:12 2018 From: martialmichel at datamachines.io (Martial Michel) Date: Tue, 13 Mar 2018 17:37:12 -0400 Subject: [Openstack-sigs] [Scientific] IRC Meeting March 14th 2018 1100 UTC in channel #openstack-meeting Message-ID: Hello, We will have our IRC meeting in the #openstack-meeting channel at 1100 UTC March 14th. Agenda is at: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_March_14th_2018 All are welcome. Looking forward to seeing you there -- Martial -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Tue Mar 13 22:29:59 2018 From: amy at demarco.com (Amy Marrich) Date: Tue, 13 Mar 2018 17:29:59 -0500 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: Message-ID: Just one comment on this section before I forget again: #IRC Channels# We want to get rid of #openstack-101 and begin using #openstack-dev instead. The 101 channel isn't watched closely enough anymore and it makes more sense to move onboarding activities (like in OpenStack Upstream Institute) to a channel where there are people that can answer questions rather than asking those to move to a new channel. For those concerned about noise, OUI is run the weekend before the summit when most people are traveling to the Summit anyway. I would recommend sending folks to #openstack vs #openstack-dev by default. Amy (spotz) On Mon, Mar 5, 2018 at 2:00 PM, Kendall Nelson wrote: > Hello Everyone :) > > It was wonderful to see and talk with so many of you last week! For those > that couldn't attend our whole day of chats or those that couldn't attend > at all, I thought I would put forth a summary of our discussions which were > mostly noted in the etherpad[1] > > #Contributor Guide# > > - Walkthrough: We walked through every section of what exists and came up > with a variety of improvements on what is there. Most of these items have > been added to our StoryBoard project[2]. This came up again Tuesday in docs > sessions and I have added those items to StoryBoard as well. > > - Google Analytics: It was discussed we should do something about getting > the contributor portal[3] to appear higher in Google searches about > onboarding. Not sure what all this entails. NEEDS AN OWNER IF ANYONE WANTS > TO VOLUNTEER. > > #Mission Statement# > > We updated our mission statement[4]! It now states: > > To provide a place for new contributors to come for information and > advice. This group will also analyze and document successful contribution > models while seeking out and providing information to new members of the > community. > > #Weekly Meeting# > > We discussed beginning a weekly meeting- optimized for APAC/Europe and > settled on 800 UTC in #openstack-meeting on Wednesdays. Proposed here[5]. > For now I added a section to our wiki for agenda organization[6]. The two > main items we want to cover on a weekly basis are new contributor patches > in gerrit and if anything has come up on ask.openstack.org about > contributors so those will be standing agenda items. > > #Forum Session# > > We discussed proposing some forum sessions in order to get more > involvement from operators. Currently, our activities focus on development > activities and we would like to diversify. When this SIG was first proposed > we wanted to have two chairs- one to represent developers and one to > represent operators. We will propose a session or two when the call for > forum proposals go out (should be today). > > #IRC Channels# > We want to get rid of #openstack-101 and begin using #openstack-dev > instead. The 101 channel isn't watched closely enough anymore and it makes > more sense to move onboarding activities (like in OpenStack Upstream > Institute) to a channel where there are people that can answer questions > rather than asking those to move to a new channel. For those concerned > about noise, OUI is run the weekend before the summit when most people are > traveling to the Summit anyway. > > #Ongoing Onboarding Efforts# > > - GSOC: Unfortunately we didn't get accepted this year. We will try again > next year. > > - Outreachy: Applications for the next round of interns are due March > 22nd, 2018 [7]. Decisions will be made by April and then internships run > May to August. > > - WoO Mentoring: The format of mentoring is changing from 1x1 to cohorts > focused on a single goal. If you are interested in helping out, please > contact me! I NEED HELP :) > > - Contributor guide: Please see the above section. > > - OpenStack Upstream Institute: It will be run, as usual, the weekend > before the Summit in Vancouver. Depending on how much progress is made on > the contributor guide, we will make use of it as opposed to slides like > previous renditions. There have also been a number of OpenStack Days > requesting we run it there as well. More details of those to come. > > #Project Liaisons# > > The list is filling out nicely, but we still need more coverage. If you > know someone from a project not listed that might be willing to help, > please reach out to them and get them added to our list [8]. > > I thiiiiiink that is just about everything. Hopefully I at least covered > everything important :) > > Thanks Everyone! > > - Kendall Nelson (diablo_rojo) > > [1] PTG Etherpad https://etherpad.openstack.org/p/FC_SIG_Rocky_PTG > [2] StoryBoard Tracker https://storyboard.openstack.org/#!/project/913 > [3] Contributor Portal https://www.openstack.org/community/ > [4] Mission Statement Update https://review.openstack.org/#/c/548054/ > [5] Meeting Slot Proposal https://review.openstack.org/#/c/549849/ > [6] Meeting Agenda https://wiki.openstack.org/wiki/First_Contact_SIG# > Meeting_Agenda > [7] Outreachy https://www.outreachy.org/apply/ > [8] Project Liaisons https://wiki.openstack.org/wiki/First_Contact_SIG# > Project_Liaisons > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Tue Mar 13 23:13:02 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 13 Mar 2018 23:13:02 +0000 Subject: [Openstack-sigs] [First Contact][SIG] Weekly Meeting Message-ID: Hello! [1] has been merged and we have an agenda [2] so we are full steam ahead for the upcoming meeting! Our inaugural First Contact SIG meeting will be in #openstack-meeting at 0800 UTC Wednesday! Hope to see you all in ~9 hours! -Kendall (diablo_rojo) [1]https://review.openstack.org/#/c/549849/ [2] https://wiki.openstack.org/wiki/First_Contact_SIG#Meeting_Agenda -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrhillsman at gmail.com Wed Mar 14 11:46:59 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Wed, 14 Mar 2018 06:46:59 -0500 Subject: [Openstack-sigs] [meta][governance] SIG Governance Proposal Message-ID: Hi everyone, As you all know we have been operating SIGs for some time now with a very loose governance model. We took this approach on purpose to give folks space and opportunity to decide what they believed constituted a SIG in hopes of learning how we can apply SIGs to our community needs. However at this point there is some confusion and concern regarding SIG governance, in particular the need to have a clear way to address issues before any conflict arises. As a temporary resolution the Meta SIG leads are proposing the following: If conflicts between SIGs or within the leadership of a given SIG cannot be solved at the SIG level, they should be brought to the SIG admins group for resolution. The SIG admins group is formed of a UC representative and a TC representative. In case the SIG admins disagree on the resolution of the conflict, the OpenStack Foundation Executive Director will be asked to break the tie. To be more clear, this is primarily to address concerns that cannot be or are not handled within the individual SIG. An example would be a SIG with only two leaders/chairs and an inability to settle something between the two resulting in the need for a third-party to assist in resolving; an email to the SIG ML with the topic [governance] is sufficient. Keep in mind this is just a first step towards us figuring out overall SIG governance and your input is needed. The initial SIG admins group is formed by Melvin Hillsman (UC representative) and Thierry Carrez (TC representative). The UC and TC are of course welcome to designate new representatives at any time. The SIG admins also approve changes to the https://governance.openstack.org/sigs/ website, including approving new SIGs. Kind regards, Thierry Carrez Melvin Hillsman -------------- next part -------------- An HTML attachment was scrubbed... URL: From aspiers at suse.com Wed Mar 14 15:49:31 2018 From: aspiers at suse.com (Adam Spiers) Date: Wed, 14 Mar 2018 15:49:31 +0000 Subject: [Openstack-sigs] [self-healing] Dublin PTG summary Message-ID: <20180314154931.nvxzrucxpibjot4q@pacific.linksys.moosehall> Hi all, Thanks to everyone who made it to the self-healing SIG session at the Dublin PTG! We had around 30 people in the end, some really productive conversations, and even a group photo! Although some people preferred to stay in the nice warm meeting room rather than risk the freezing temperatures of the "Beast from the East" ;-) https://www.dropbox.com/sh/dtei3ovfi7z74vo/AAB3g-QiXB-TBvvZMltPtpcUa/Self%20Healing%20SIG?dl=0&preview=DSC_4333.JPG You can see the notes from the session here: https://etherpad.openstack.org/p/self-healing-ptg-rocky but below is a summary of the highlights. Documentation of capabilities of existing projects ================================================== https://storyboard.openstack.org/#!/story/2001430 Prior to the PTG we started to collect information on all the existing integration points available between different projects: https://etherpad.openstack.org/p/self-healing-project-integrations I showed my initial attempts at visualisation the relationships, but we concluded that trying to visualise all integrations on a single graph is probably too hard to do in a useful way, so it probably makes more sense to visualise and document architectures use case by use case. Nevertheless, having a complete list of integration points should serve as a useful component in future documentation. Documentation repository ======================== We agreed to start documenting use cases and specs in our self-healing sig repository: https://git.openstack.org/cgit/openstack/self-healing-sig Formerly this repository was empty and only existed so that we could have StoryBoard project (this is currently a requirement due to the way that StoryBoard projects are set up in OpenStack), but we realised that it was a great place to collaborate on this information which will pretty much always span a few projects, but not as many as OpenStack's traditional cross-project initiatives do. As a result I have populated it using the -specs cookiecutter template, but still need to draft a template for use cases and tidy up the index: https://storyboard.openstack.org/#!/story/2001628 Discussions on various use cases ================================ Some people are already keen to start work on use cases immediately, which is great news. I don't remember all the details, but one example involved monitoring NICs on compute nodes, moving VMs away from any compute node seen to be in a sub-optimal state (IIRC an extension to Neutron's API might be needed to help with detecting this), and then potentially handing over to an operator for manual remediation after the automated self-healing phase. I touched on this briefly during the presentation I gave on the self-healing SIG to the London OpenStack Meetup on Monday night: https://aspiers.github.io/openstack-meetup-london-march-2018-self-healing/#/use-case-1 Stakeholders contact list ========================= One challenge we might face when working on self-healing use cases involving multiple projects is simply getting stuck with an issue relating to a specific project and not knowing the best person to ask for help. Of course it is always possible (and indeed advisable) to ask on IRC / mailing lists, but we decided that it would be helpful to know in advance the names of individuals in each project who have already declared an interest in self-healing and volunteered to help out. So I built this etherpad: https://etherpad.openstack.org/p/self-healing-contacts Please consider signing up to help answer questions relating to your area of expertise! Health-check API ================ https://storyboard.openstack.org/#!/story/2001439 Discussion with members of the API SIG on the new health-check API initiative: https://review.openstack.org/#/c/531456/ There seemed to be consensus that the API SIG would own driving of the implementation of the health-check API, whereas the self-healing SIG would own the subsequent work to determine and document the various use cases for effectively consuming the API. So the self-healing SIG would be the "customer" of the API SIG, which seems to make sense as a nice way of structuring the work organisationally. Automated testing ================= There was broad agreement that any implementations of self-healing use cases (including standard HA functionality) should have corresponding automated tests. OPNFV has already done a lot of good work in this area, and there were a few folks from the OPNFV world present, so hopefully the connections established will lead to collaboration and reuse of existing work in the future. Since the PTG we have had a few more people express a desire to join this initiative, which is great news: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128020.html https://etherpad.openstack.org/p/extreme-testing-contacts Operator feedback ================= It's *crucial* that we hear feedback from operators on their real-world experiences and opinions about how self-healing could help them, since ultimately making operators' lives easier is the primary goal of the SIG. Unfortunately there were no operators present in Dublin, but since then we have managed to collect some feedback from the Tokyo Ops Meetup and London OpenStack Meetup, and hopefully the Vancouver Forum will be an ideal opportunity to hear more. If you are an operator reading this, please don't be shy! Let us know what problems you would like to see the self-healing SIG focus on! On that note, I'll end with a final plea: Please join us! =============== All participation is very welcome, no matter how small. At this stage we're especially interested in hearing about people's experiences, opinions and ideas: - Are you already implementing any self-healing functionality in your OpenStack clouds? If so, how are you doing it, and what's working and not working? - What self-healing functionality do you miss and would like to see implemented in the future? You can find us on: - #openstack-self-healing on Freenode IRC - this openstack-sigs at lists.openstack.org mailing list (please use the [self-healing] tag) From Tim.Bell at cern.ch Wed Mar 14 17:33:15 2018 From: Tim.Bell at cern.ch (Tim Bell) Date: Wed, 14 Mar 2018 17:33:15 +0000 Subject: [Openstack-sigs] [self-healing] Dublin PTG summary In-Reply-To: <20180314154931.nvxzrucxpibjot4q@pacific.linksys.moosehall> References: <20180314154931.nvxzrucxpibjot4q@pacific.linksys.moosehall> Message-ID: <05C4C808-FD90-444E-8C94-38D426F48730@cern.ch> Adam, Happy to come along in Vancouver as soon as you have a slot. Thanks for all the work that's going into this SIG. Tim -----Original Message----- From: Adam Spiers Reply-To: "openstack-sigs at lists.openstack.org" Date: Wednesday, 14 March 2018 at 16:50 To: OpenStack SIGs list Subject: [Openstack-sigs] [self-healing] Dublin PTG summary Hi all, Thanks to everyone who made it to the self-healing SIG session at the Dublin PTG! We had around 30 people in the end, some really productive conversations, and even a group photo! Although some people preferred to stay in the nice warm meeting room rather than risk the freezing temperatures of the "Beast from the East" ;-) https://www.dropbox.com/sh/dtei3ovfi7z74vo/AAB3g-QiXB-TBvvZMltPtpcUa/Self%20Healing%20SIG?dl=0&preview=DSC_4333.JPG You can see the notes from the session here: https://etherpad.openstack.org/p/self-healing-ptg-rocky but below is a summary of the highlights. Documentation of capabilities of existing projects ================================================== https://storyboard.openstack.org/#!/story/2001430 Prior to the PTG we started to collect information on all the existing integration points available between different projects: https://etherpad.openstack.org/p/self-healing-project-integrations I showed my initial attempts at visualisation the relationships, but we concluded that trying to visualise all integrations on a single graph is probably too hard to do in a useful way, so it probably makes more sense to visualise and document architectures use case by use case. Nevertheless, having a complete list of integration points should serve as a useful component in future documentation. Documentation repository ======================== We agreed to start documenting use cases and specs in our self-healing sig repository: https://git.openstack.org/cgit/openstack/self-healing-sig Formerly this repository was empty and only existed so that we could have StoryBoard project (this is currently a requirement due to the way that StoryBoard projects are set up in OpenStack), but we realised that it was a great place to collaborate on this information which will pretty much always span a few projects, but not as many as OpenStack's traditional cross-project initiatives do. As a result I have populated it using the -specs cookiecutter template, but still need to draft a template for use cases and tidy up the index: https://storyboard.openstack.org/#!/story/2001628 Discussions on various use cases ================================ Some people are already keen to start work on use cases immediately, which is great news. I don't remember all the details, but one example involved monitoring NICs on compute nodes, moving VMs away from any compute node seen to be in a sub-optimal state (IIRC an extension to Neutron's API might be needed to help with detecting this), and then potentially handing over to an operator for manual remediation after the automated self-healing phase. I touched on this briefly during the presentation I gave on the self-healing SIG to the London OpenStack Meetup on Monday night: https://aspiers.github.io/openstack-meetup-london-march-2018-self-healing/#/use-case-1 Stakeholders contact list ========================= One challenge we might face when working on self-healing use cases involving multiple projects is simply getting stuck with an issue relating to a specific project and not knowing the best person to ask for help. Of course it is always possible (and indeed advisable) to ask on IRC / mailing lists, but we decided that it would be helpful to know in advance the names of individuals in each project who have already declared an interest in self-healing and volunteered to help out. So I built this etherpad: https://etherpad.openstack.org/p/self-healing-contacts Please consider signing up to help answer questions relating to your area of expertise! Health-check API ================ https://storyboard.openstack.org/#!/story/2001439 Discussion with members of the API SIG on the new health-check API initiative: https://review.openstack.org/#/c/531456/ There seemed to be consensus that the API SIG would own driving of the implementation of the health-check API, whereas the self-healing SIG would own the subsequent work to determine and document the various use cases for effectively consuming the API. So the self-healing SIG would be the "customer" of the API SIG, which seems to make sense as a nice way of structuring the work organisationally. Automated testing ================= There was broad agreement that any implementations of self-healing use cases (including standard HA functionality) should have corresponding automated tests. OPNFV has already done a lot of good work in this area, and there were a few folks from the OPNFV world present, so hopefully the connections established will lead to collaboration and reuse of existing work in the future. Since the PTG we have had a few more people express a desire to join this initiative, which is great news: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128020.html https://etherpad.openstack.org/p/extreme-testing-contacts Operator feedback ================= It's *crucial* that we hear feedback from operators on their real-world experiences and opinions about how self-healing could help them, since ultimately making operators' lives easier is the primary goal of the SIG. Unfortunately there were no operators present in Dublin, but since then we have managed to collect some feedback from the Tokyo Ops Meetup and London OpenStack Meetup, and hopefully the Vancouver Forum will be an ideal opportunity to hear more. If you are an operator reading this, please don't be shy! Let us know what problems you would like to see the self-healing SIG focus on! On that note, I'll end with a final plea: Please join us! =============== All participation is very welcome, no matter how small. At this stage we're especially interested in hearing about people's experiences, opinions and ideas: - Are you already implementing any self-healing functionality in your OpenStack clouds? If so, how are you doing it, and what's working and not working? - What self-healing functionality do you miss and would like to see implemented in the future? You can find us on: - #openstack-self-healing on Freenode IRC - this openstack-sigs at lists.openstack.org mailing list (please use the [self-healing] tag) _______________________________________________ openstack-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From lhinds at redhat.com Wed Mar 14 18:35:50 2018 From: lhinds at redhat.com (Luke Hinds) Date: Wed, 14 Mar 2018 18:35:50 +0000 Subject: [Openstack-sigs] [security] Tomorrow's meeting and LCOO Message-ID: Hello, Something has come up that determines I won't be able to attend the meeting tomorrow and more importantly chair it. However I would not want to be a bottleneck to good progress underway. If someone would like to step up and chair for just this meeting, the agenda is below: https://etherpad.openstack.org/p/security-agenda Also keep in mind, we now meet in #openstack-meeting at 15:00, instead of 17:00. If not, we will defer and meet the week after. Last point, someone called eeiden pinged me on IRC, but have since logged out. They LCOO has an interest in working with the security SIG, which is most welcome. If anyone knows eeiden, can you ask him / her to contact us on this list and we can get initial discussions going and hopefully bring them into the meeting too. Cheers, Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: From aspiers at suse.com Wed Mar 14 19:00:25 2018 From: aspiers at suse.com (Adam Spiers) Date: Wed, 14 Mar 2018 19:00:25 +0000 Subject: [Openstack-sigs] [self-healing] Vancouver Forum In-Reply-To: <05C4C808-FD90-444E-8C94-38D426F48730@cern.ch> References: <20180314154931.nvxzrucxpibjot4q@pacific.linksys.moosehall> <05C4C808-FD90-444E-8C94-38D426F48730@cern.ch> Message-ID: <20180314190025.bbcx4gzsaydqh2gb@pacific.linksys.moosehall> Thanks Tim! And thanks for the reminder - I've just created an etherpad for brainstorming topics for Vancouver: https://etherpad.openstack.org/p/YVR-self-healing-brainstorming Particularly keen to hear from operators who have interesting problems which could potentially be solved with self-healing approaches ... and I can't think of an OpenStack user with more interesting problems than CERN, hint hint ;-) Tim Bell wrote: >Adam, > >Happy to come along in Vancouver as soon as you have a slot. Thanks for all the work that's going into this SIG. > >Tim > >-----Original Message----- >From: Adam Spiers >Reply-To: "openstack-sigs at lists.openstack.org" >Date: Wednesday, 14 March 2018 at 16:50 >To: OpenStack SIGs list >Subject: [Openstack-sigs] [self-healing] Dublin PTG summary > > Hi all, > > Thanks to everyone who made it to the self-healing SIG session at the > Dublin PTG! We had around 30 people in the end, some really > productive conversations, and even a group photo! Although some > people preferred to stay in the nice warm meeting room rather than > risk the freezing temperatures of the "Beast from the East" ;-) > > https://www.dropbox.com/sh/dtei3ovfi7z74vo/AAB3g-QiXB-TBvvZMltPtpcUa/Self%20Healing%20SIG?dl=0&preview=DSC_4333.JPG > > You can see the notes from the session here: > > https://etherpad.openstack.org/p/self-healing-ptg-rocky > > but below is a summary of the highlights. > > Documentation of capabilities of existing projects > ================================================== > > https://storyboard.openstack.org/#!/story/2001430 > > Prior to the PTG we started to collect information on all the existing > integration points available between different projects: > > https://etherpad.openstack.org/p/self-healing-project-integrations > > I showed my initial attempts at visualisation the relationships, but we > concluded that trying to visualise all integrations on a single graph > is probably too hard to do in a useful way, so it probably makes more > sense to visualise and document architectures use case by use case. > Nevertheless, having a complete list of integration points should > serve as a useful component in future documentation. > > Documentation repository > ======================== > > We agreed to start documenting use cases and specs in our self-healing > sig repository: > > https://git.openstack.org/cgit/openstack/self-healing-sig > > Formerly this repository was empty and only existed so that we could > have StoryBoard project (this is currently a requirement due to the > way that StoryBoard projects are set up in OpenStack), but we realised > that it was a great place to collaborate on this information which > will pretty much always span a few projects, but not as many as > OpenStack's traditional cross-project initiatives do. > > As a result I have populated it using the -specs cookiecutter > template, but still need to draft a template for use cases and tidy up > the index: > > https://storyboard.openstack.org/#!/story/2001628 > > Discussions on various use cases > ================================ > > Some people are already keen to start work on use cases immediately, > which is great news. I don't remember all the details, but one > example involved monitoring NICs on compute nodes, moving VMs away > from any compute node seen to be in a sub-optimal state (IIRC an > extension to Neutron's API might be needed to help with detecting > this), and then potentially handing over to an operator for manual > remediation after the automated self-healing phase. > > I touched on this briefly during the presentation I gave on the > self-healing SIG to the London OpenStack Meetup on Monday night: > > https://aspiers.github.io/openstack-meetup-london-march-2018-self-healing/#/use-case-1 > > Stakeholders contact list > ========================= > > One challenge we might face when working on self-healing use cases > involving multiple projects is simply getting stuck with an issue > relating to a specific project and not knowing the best person to ask > for help. Of course it is always possible (and indeed advisable) to > ask on IRC / mailing lists, but we decided that it would be helpful to > know in advance the names of individuals in each project who have > already declared an interest in self-healing and volunteered to help > out. So I built this etherpad: > > https://etherpad.openstack.org/p/self-healing-contacts > > Please consider signing up to help answer questions relating to your > area of expertise! > > Health-check API > ================ > > https://storyboard.openstack.org/#!/story/2001439 > > Discussion with members of the API SIG on the new health-check API > initiative: > > https://review.openstack.org/#/c/531456/ > > There seemed to be consensus that the API SIG would own driving of the > implementation of the health-check API, whereas the self-healing SIG > would own the subsequent work to determine and document the various > use cases for effectively consuming the API. So the self-healing SIG > would be the "customer" of the API SIG, which seems to make sense as a > nice way of structuring the work organisationally. > > Automated testing > ================= > > There was broad agreement that any implementations of self-healing use > cases (including standard HA functionality) should have corresponding > automated tests. OPNFV has already done a lot of good work in this > area, and there were a few folks from the OPNFV world present, so > hopefully the connections established will lead to collaboration and > reuse of existing work in the future. > > Since the PTG we have had a few more people express a desire to join > this initiative, which is great news: > > http://lists.openstack.org/pipermail/openstack-dev/2018-March/128020.html > https://etherpad.openstack.org/p/extreme-testing-contacts > > Operator feedback > ================= > > It's *crucial* that we hear feedback from operators on their > real-world experiences and opinions about how self-healing could help > them, since ultimately making operators' lives easier is the primary > goal of the SIG. > > Unfortunately there were no operators present in Dublin, but since > then we have managed to collect some feedback from the Tokyo Ops > Meetup and London OpenStack Meetup, and hopefully the Vancouver Forum > will be an ideal opportunity to hear more. > > If you are an operator reading this, please don't be shy! Let us know > what problems you would like to see the self-healing SIG focus on! > > On that note, I'll end with a final plea: > > Please join us! > =============== > > All participation is very welcome, no matter how small. At this stage > we're especially interested in hearing about people's experiences, > opinions and ideas: > > - Are you already implementing any self-healing functionality in > your OpenStack clouds? If so, how are you doing it, and what's > working and not working? > > - What self-healing functionality do you miss and would like to > see implemented in the future? > > You can find us on: > > - #openstack-self-healing on Freenode IRC > > - this openstack-sigs at lists.openstack.org mailing list > (please use the [self-healing] tag) > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > >_______________________________________________ >openstack-sigs mailing list >openstack-sigs at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From mrhillsman at gmail.com Wed Mar 14 19:15:31 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Wed, 14 Mar 2018 14:15:31 -0500 Subject: [Openstack-sigs] [forum] We want your session ideas for the Vancouver Forum! Message-ID: Hey everyone, Please take time to put ideas for sessions at the forum in the TC and/or UC catch-all etherpads or any of the others that are appropriate: https://wiki.openstack.org/wiki/Forum/Vancouver2018 We really want to get as many session ideas as possible so that the committee has too many to choose from :) Here is an idea of the types of sessions to think about proposing: *Project-specific sessions* Where developers can ask users specific questions about their experience, users can provide feedback from the last release and cross-community collaboration on the priorities and 'blue sky' ideas for the next release can occur. *Strategic, whole-of-community discussions* To think about the big picture, including beyond just one release cycle and new technologies *Cross-project sessions* In a similar vein to what has happened at past design summits, but with increased emphasis on issues that are of relevant to all areas of the community If you have organized any events in the past year you probably have heard of or been in some sessions that are perfect for the Forum. -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhinds at redhat.com Wed Mar 14 21:56:33 2018 From: lhinds at redhat.com (Luke Hinds) Date: Wed, 14 Mar 2018 21:56:33 +0000 Subject: [Openstack-sigs] [security] Tomorrow's meeting and LCOO In-Reply-To: References: Message-ID: Sounds great, thanks Gage! I will try to catch up with you on Friday! On Wed, Mar 14, 2018 at 6:51 PM, Gage Hugo wrote: > Hey Luke, > > I can chair the meeting tomorrow if that works. > > I will also ping eeiden about getting some LCOO discussion going as well. > > On Wed, Mar 14, 2018 at 1:35 PM, Luke Hinds wrote: > >> Hello, >> >> Something has come up that determines I won't be able to attend the >> meeting tomorrow and more importantly chair it. >> >> However I would not want to be a bottleneck to good progress underway. >> >> If someone would like to step up and chair for just this meeting, the >> agenda is below: >> >> https://etherpad.openstack.org/p/security-agenda >> >> Also keep in mind, we now meet in #openstack-meeting at 15:00, instead of >> 17:00. >> >> If not, we will defer and meet the week after. >> >> Last point, someone called eeiden pinged me on IRC, but have since logged >> out. They LCOO has an interest in working with the security SIG, which is >> most welcome. If anyone knows eeiden, can you ask him / her to contact us >> on this list and we can get initial discussions going and hopefully bring >> them into the meeting too. >> >> Cheers, >> >> Luke >> > > -- Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Thu Mar 15 00:28:13 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Thu, 15 Mar 2018 00:28:13 +0000 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: Message-ID: We talked about this more during the meeting last night. Most people were pretty neutral on the topic. I personally feel like #openstack-dev is the ideal place to direct people once they get set up on irc and are interested in contributing, but maybe that is because my perception of the chats in #openstack isn't correct. Looking at the definition in the IRC channel list[1] and the channel topic[2] I feel like it more for support questions on running openstack? I dunno. I honestly didn't spend time in the channel really until I joined last night so maybe my perception just needs an update. I am all ears for your reasoning behind #openstack instead of #openstack-dev though too. Please enlighten me :) -Kendall (diablo_rojo) [1] https://wiki.openstack.org/wiki/IRC [2] Openstack Support Channel, Development in #openstack-dev | Wiki: http://wiki.openstack.org/ | Docs: http://docs.openstack.org/ | Answers: https://ask.openstack.org | Logs: http://eavesdrop.openstack.org/irclogs/ | Paste: http://paste.openstack.org/ On Tue, Mar 13, 2018 at 3:30 PM Amy Marrich wrote: > Just one comment on this section before I forget again: > #IRC Channels# > We want to get rid of #openstack-101 and begin using #openstack-dev > instead. The 101 channel isn't watched closely enough anymore and it makes > more sense to move onboarding activities (like in OpenStack Upstream > Institute) to a channel where there are people that can answer questions > rather than asking those to move to a new channel. For those concerned > about noise, OUI is run the weekend before the summit when most people are > traveling to the Summit anyway. > > I would recommend sending folks to #openstack vs #openstack-dev by default. > > Amy (spotz) > > On Mon, Mar 5, 2018 at 2:00 PM, Kendall Nelson > wrote: > >> Hello Everyone :) >> >> It was wonderful to see and talk with so many of you last week! For those >> that couldn't attend our whole day of chats or those that couldn't attend >> at all, I thought I would put forth a summary of our discussions which were >> mostly noted in the etherpad[1] >> >> #Contributor Guide# >> >> - Walkthrough: We walked through every section of what exists and came up >> with a variety of improvements on what is there. Most of these items have >> been added to our StoryBoard project[2]. This came up again Tuesday in docs >> sessions and I have added those items to StoryBoard as well. >> >> - Google Analytics: It was discussed we should do something about getting >> the contributor portal[3] to appear higher in Google searches about >> onboarding. Not sure what all this entails. NEEDS AN OWNER IF ANYONE WANTS >> TO VOLUNTEER. >> >> #Mission Statement# >> >> We updated our mission statement[4]! It now states: >> >> To provide a place for new contributors to come for information and >> advice. This group will also analyze and document successful contribution >> models while seeking out and providing information to new members of the >> community. >> >> #Weekly Meeting# >> >> We discussed beginning a weekly meeting- optimized for APAC/Europe and >> settled on 800 UTC in #openstack-meeting on Wednesdays. Proposed here[5]. >> For now I added a section to our wiki for agenda organization[6]. The two >> main items we want to cover on a weekly basis are new contributor patches >> in gerrit and if anything has come up on ask.openstack.org about >> contributors so those will be standing agenda items. >> >> #Forum Session# >> >> We discussed proposing some forum sessions in order to get more >> involvement from operators. Currently, our activities focus on development >> activities and we would like to diversify. When this SIG was first proposed >> we wanted to have two chairs- one to represent developers and one to >> represent operators. We will propose a session or two when the call for >> forum proposals go out (should be today). >> >> #IRC Channels# >> We want to get rid of #openstack-101 and begin using #openstack-dev >> instead. The 101 channel isn't watched closely enough anymore and it makes >> more sense to move onboarding activities (like in OpenStack Upstream >> Institute) to a channel where there are people that can answer questions >> rather than asking those to move to a new channel. For those concerned >> about noise, OUI is run the weekend before the summit when most people are >> traveling to the Summit anyway. >> >> #Ongoing Onboarding Efforts# >> >> - GSOC: Unfortunately we didn't get accepted this year. We will try again >> next year. >> >> - Outreachy: Applications for the next round of interns are due March >> 22nd, 2018 [7]. Decisions will be made by April and then internships run >> May to August. >> >> - WoO Mentoring: The format of mentoring is changing from 1x1 to cohorts >> focused on a single goal. If you are interested in helping out, please >> contact me! I NEED HELP :) >> >> - Contributor guide: Please see the above section. >> >> - OpenStack Upstream Institute: It will be run, as usual, the weekend >> before the Summit in Vancouver. Depending on how much progress is made on >> the contributor guide, we will make use of it as opposed to slides like >> previous renditions. There have also been a number of OpenStack Days >> requesting we run it there as well. More details of those to come. >> >> #Project Liaisons# >> >> The list is filling out nicely, but we still need more coverage. If you >> know someone from a project not listed that might be willing to help, >> please reach out to them and get them added to our list [8]. >> >> I thiiiiiink that is just about everything. Hopefully I at least covered >> everything important :) >> >> Thanks Everyone! >> >> - Kendall Nelson (diablo_rojo) >> >> [1] PTG Etherpad https://etherpad.openstack.org/p/FC_SIG_Rocky_PTG >> [2] StoryBoard Tracker https://storyboard.openstack.org/#!/project/913 >> [3] Contributor Portal https://www.openstack.org/community/ >> [4] Mission Statement Update https://review.openstack.org/#/c/548054/ >> [5] Meeting Slot Proposal https://review.openstack.org/#/c/549849/ >> [6] Meeting Agenda >> https://wiki.openstack.org/wiki/First_Contact_SIG#Meeting_Agenda >> [7] Outreachy https://www.outreachy.org/apply/ >> [8] Project Liaisons >> https://wiki.openstack.org/wiki/First_Contact_SIG#Project_Liaisons >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> >> > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengh512 at gmail.com Thu Mar 15 00:37:35 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Thu, 15 Mar 2018 08:37:35 +0800 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: Message-ID: Hi folks, Sorry was not be able to make it to the First Contact SIG discussions in Dublin. The only suggestion I have is to have as many project as possible to have a dedicated FC SIG wiki page for localize onboarding support. For example like what we do in Cyborg: https://wiki.openstack.org/wiki/Cyborg/FirstContact I've captured all the discussions of the China Dev Group via a Chinese streaming site and also put the wiki link in the wechat group description, so that new developer know where to go to for a localize support. For communciation tools, per irc I agree converge to #openstack-dev is better than maintaining some independent channels. But also from my experience video conf in native lang is more effective. On Thu, Mar 15, 2018 at 8:28 AM, Kendall Nelson wrote: > We talked about this more during the meeting last night. Most people were > pretty neutral on the topic. > > I personally feel like #openstack-dev is the ideal place to direct people > once they get set up on irc and are interested in contributing, but maybe > that is because my perception of the chats in #openstack isn't correct. > Looking at the definition in the IRC channel list[1] and the channel > topic[2] I feel like it more for support questions on running openstack? I > dunno. I honestly didn't spend time in the channel really until I joined > last night so maybe my perception just needs an update. I am all ears for > your reasoning behind #openstack instead of #openstack-dev though too. > Please enlighten me :) > > -Kendall (diablo_rojo) > > [1] https://wiki.openstack.org/wiki/IRC > [2] Openstack Support Channel, Development in #openstack-dev | Wiki: > http://wiki.openstack.org/ | Docs: http://docs.openstack.org/ | Answers: > https://ask.openstack.org | Logs: http://eavesdrop.openstack.org/irclogs/ > | Paste: http://paste.openstack.org/ > > > On Tue, Mar 13, 2018 at 3:30 PM Amy Marrich wrote: > >> Just one comment on this section before I forget again: >> #IRC Channels# >> We want to get rid of #openstack-101 and begin using #openstack-dev >> instead. The 101 channel isn't watched closely enough anymore and it makes >> more sense to move onboarding activities (like in OpenStack Upstream >> Institute) to a channel where there are people that can answer questions >> rather than asking those to move to a new channel. For those concerned >> about noise, OUI is run the weekend before the summit when most people are >> traveling to the Summit anyway. >> >> I would recommend sending folks to #openstack vs #openstack-dev by >> default. >> >> Amy (spotz) >> >> On Mon, Mar 5, 2018 at 2:00 PM, Kendall Nelson >> wrote: >> >>> Hello Everyone :) >>> >>> It was wonderful to see and talk with so many of you last week! For >>> those that couldn't attend our whole day of chats or those that couldn't >>> attend at all, I thought I would put forth a summary of our discussions >>> which were mostly noted in the etherpad[1] >>> >>> #Contributor Guide# >>> >>> - Walkthrough: We walked through every section of what exists and came >>> up with a variety of improvements on what is there. Most of these items >>> have been added to our StoryBoard project[2]. This came up again Tuesday in >>> docs sessions and I have added those items to StoryBoard as well. >>> >>> - Google Analytics: It was discussed we should do something about >>> getting the contributor portal[3] to appear higher in Google searches about >>> onboarding. Not sure what all this entails. NEEDS AN OWNER IF ANYONE WANTS >>> TO VOLUNTEER. >>> >>> #Mission Statement# >>> >>> We updated our mission statement[4]! It now states: >>> >>> To provide a place for new contributors to come for information and >>> advice. This group will also analyze and document successful contribution >>> models while seeking out and providing information to new members of the >>> community. >>> >>> #Weekly Meeting# >>> >>> We discussed beginning a weekly meeting- optimized for APAC/Europe and >>> settled on 800 UTC in #openstack-meeting on Wednesdays. Proposed here[5]. >>> For now I added a section to our wiki for agenda organization[6]. The two >>> main items we want to cover on a weekly basis are new contributor patches >>> in gerrit and if anything has come up on ask.openstack.org about >>> contributors so those will be standing agenda items. >>> >>> #Forum Session# >>> >>> We discussed proposing some forum sessions in order to get more >>> involvement from operators. Currently, our activities focus on development >>> activities and we would like to diversify. When this SIG was first proposed >>> we wanted to have two chairs- one to represent developers and one to >>> represent operators. We will propose a session or two when the call for >>> forum proposals go out (should be today). >>> >>> #IRC Channels# >>> We want to get rid of #openstack-101 and begin using #openstack-dev >>> instead. The 101 channel isn't watched closely enough anymore and it makes >>> more sense to move onboarding activities (like in OpenStack Upstream >>> Institute) to a channel where there are people that can answer questions >>> rather than asking those to move to a new channel. For those concerned >>> about noise, OUI is run the weekend before the summit when most people are >>> traveling to the Summit anyway. >>> >>> #Ongoing Onboarding Efforts# >>> >>> - GSOC: Unfortunately we didn't get accepted this year. We will try >>> again next year. >>> >>> - Outreachy: Applications for the next round of interns are due March >>> 22nd, 2018 [7]. Decisions will be made by April and then internships run >>> May to August. >>> >>> - WoO Mentoring: The format of mentoring is changing from 1x1 to cohorts >>> focused on a single goal. If you are interested in helping out, please >>> contact me! I NEED HELP :) >>> >>> - Contributor guide: Please see the above section. >>> >>> - OpenStack Upstream Institute: It will be run, as usual, the weekend >>> before the Summit in Vancouver. Depending on how much progress is made on >>> the contributor guide, we will make use of it as opposed to slides like >>> previous renditions. There have also been a number of OpenStack Days >>> requesting we run it there as well. More details of those to come. >>> >>> #Project Liaisons# >>> >>> The list is filling out nicely, but we still need more coverage. If you >>> know someone from a project not listed that might be willing to help, >>> please reach out to them and get them added to our list [8]. >>> >>> I thiiiiiink that is just about everything. Hopefully I at least covered >>> everything important :) >>> >>> Thanks Everyone! >>> >>> - Kendall Nelson (diablo_rojo) >>> >>> [1] PTG Etherpad https://etherpad.openstack.org/p/FC_SIG_Rocky_PTG >>> [2] StoryBoard Tracker https://storyboard.openstack.org/#!/project/913 >>> [3] Contributor Portal https://www.openstack.org/community/ >>> [4] Mission Statement Update https://review.openstack.org/#/c/548054/ >>> [5] Meeting Slot Proposal https://review.openstack.org/#/c/549849/ >>> [6] Meeting Agenda https://wiki.openstack.org/wiki/First_Contact_SIG# >>> Meeting_Agenda >>> [7] Outreachy https://www.outreachy.org/apply/ >>> [8] Project Liaisons https://wiki.openstack.org/wiki/First_Contact_SIG# >>> Project_Liaisons >>> >>> _______________________________________________ >>> openstack-sigs mailing list >>> openstack-sigs at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >>> >>> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From gagehugo at gmail.com Wed Mar 14 18:51:45 2018 From: gagehugo at gmail.com (Gage Hugo) Date: Wed, 14 Mar 2018 13:51:45 -0500 Subject: [Openstack-sigs] [security] Tomorrow's meeting and LCOO In-Reply-To: References: Message-ID: Hey Luke, I can chair the meeting tomorrow if that works. I will also ping eeiden about getting some LCOO discussion going as well. On Wed, Mar 14, 2018 at 1:35 PM, Luke Hinds wrote: > Hello, > > Something has come up that determines I won't be able to attend the > meeting tomorrow and more importantly chair it. > > However I would not want to be a bottleneck to good progress underway. > > If someone would like to step up and chair for just this meeting, the > agenda is below: > > https://etherpad.openstack.org/p/security-agenda > > Also keep in mind, we now meet in #openstack-meeting at 15:00, instead of > 17:00. > > If not, we will defer and meet the week after. > > Last point, someone called eeiden pinged me on IRC, but have since logged > out. They LCOO has an interest in working with the security SIG, which is > most welcome. If anyone knows eeiden, can you ask him / her to contact us > on this list and we can get initial discussions going and hopefully bring > them into the meeting too. > > Cheers, > > Luke > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Mar 15 12:45:02 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 15 Mar 2018 12:45:02 +0000 Subject: [Openstack-sigs] [security] Tomorrow's meeting and LCOO In-Reply-To: References: Message-ID: <20180315124502.askhhq2nwnor5j3h@yuggoth.org> On 2018-03-14 13:51:45 -0500 (-0500), Gage Hugo wrote: > I can chair the meeting tomorrow if that works. [...] Thanks! I plan to try to pay some attention during the meeting, but couldn't volunteer to chair since the new scheduled time is the same as what is usually our busiest TC office hour slot of the week. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From fungi at yuggoth.org Thu Mar 15 12:58:40 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 15 Mar 2018 12:58:40 +0000 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: Message-ID: <20180315125840.fobitsay23wps2tb@yuggoth.org> On 2018-03-15 08:37:35 +0800 (+0800), Zhipeng Huang wrote: [...] > For communciation tools, per irc I agree converge to #openstack-dev is > better than maintaining some independent channels. But also from my > experience video conf in native lang is more effective. [...] Any ideas on whether we should suggest that people who are finding English challenging try to reach out on one of our language-specific mailing lists for a language in which they are more fluent (and then perhaps arrange there for a video conference with another contributor who can help them if that's more convenient)? -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From cdent+os at anticdent.org Thu Mar 15 17:30:16 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Thu, 15 Mar 2018 17:30:16 +0000 (GMT) Subject: [Openstack-sigs] [all][api] POST /api-sig/news Message-ID: Greetings OpenStack community, A rousing good time at the API-SIG meeting today. We opened with some discussion on what might be missing from the Methods [7] section of the HTTP guidelines. At the PTG we had discussed that perhaps we needed more info on which methods were appropriate when. It turns that what we probably need is better discoverability, so we're going to work on that but at the same time do a general review of that entire page. We then talked about microversions a bit (because it wouldn't be an API-SIG without them). There's an in-progress history of microversions document (linked below) that we need to decide if we'll revive. If you have a strong opinion, let us know. And finally we explored the options for how or if Neutron can cleanly resolve the handling of invalid query parameters. This was raised a while back in an email thread [8]. It's generally a good idea not to break existing client code, but what if that client code is itself broken? The next step will be to make the choice configurable. Neutron doesn't support microversions so "throw another microversion at it" won't work. As always if you're interested in helping out, in addition to coming to the meetings, there's also: * The list of bugs [5] indicates several missing or incomplete guidelines. * The existing guidelines [2] always need refreshing to account for changes over time. If you find something that's not quite right, submit a patch [6] to fix it. * Have you done something for which you think guidance would have made things easier but couldn't find any? Submit a patch and help others [6]. # Newly Published Guidelines None this week. # API Guidelines Proposed for Freeze Guidelines that are ready for wider review by the whole community. None this week. # Guidelines Currently Under Review [3] * Add guidance on needing cache-control headers https://review.openstack.org/550468 * Add guideline on exposing microversions in SDKs https://review.openstack.org/#/c/532814/ * Add API-schema guide (still being defined) https://review.openstack.org/#/c/524467/ * A (shrinking) suite of several documents about doing version and service discovery Start at https://review.openstack.org/#/c/459405/ * WIP: microversion architecture archival doc (very early; not yet ready for review) https://review.openstack.org/444892 # Highlighting your API impacting issues If you seek further review and insight from the API SIG about APIs that you are developing or changing, please address your concerns in an email to the OpenStack developer mailing list[1] with the tag "[api]" in the subject. In your email, you should include any relevant reviews, links, and comments to help guide the discussion of the specific challenge you are facing. To learn more about the API SIG mission and the work we do, see our wiki page [4] and guidelines [2]. Thanks for reading and see you next week! # References [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [2] http://specs.openstack.org/openstack/api-wg/ [3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z [4] https://wiki.openstack.org/wiki/API_SIG [5] https://bugs.launchpad.net/openstack-api-wg [6] https://git.openstack.org/cgit/openstack/api-wg [7] http://specs.openstack.org/openstack/api-wg/guidelines/http.html#http-methods [8] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128023.html Meeting Agenda https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda Past Meeting Records http://eavesdrop.openstack.org/meetings/api_sig/ Open Bugs https://bugs.launchpad.net/openstack-api-wg -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From zhipengh512 at gmail.com Fri Mar 16 04:07:35 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Fri, 16 Mar 2018 12:07:35 +0800 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: <20180315125840.fobitsay23wps2tb@yuggoth.org> References: <20180315125840.fobitsay23wps2tb@yuggoth.org> Message-ID: Hi Jeremy, I think non-eng mailing-list will not be utilized as we intent it to, the same thing happens with non-eng irc channel as well. I would suggest just pick a tool that people in the specific area enjoys using, for example wechat in China, Line/Slack in Japan, etc. On Thu, Mar 15, 2018 at 8:58 PM, Jeremy Stanley wrote: > On 2018-03-15 08:37:35 +0800 (+0800), Zhipeng Huang wrote: > [...] > > For communciation tools, per irc I agree converge to #openstack-dev is > > better than maintaining some independent channels. But also from my > > experience video conf in native lang is more effective. > [...] > > Any ideas on whether we should suggest that people who are finding > English challenging try to reach out on one of our language-specific > mailing lists for a language in which they are more fluent (and then > perhaps arrange there for a video conference with another > contributor who can help them if that's more convenient)? > -- > Jeremy Stanley > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdent+os at anticdent.org Fri Mar 16 08:55:45 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Fri, 16 Mar 2018 08:55:45 +0000 (GMT) Subject: [Openstack-sigs] [openstack-dev] [all][api] POST /api-sig/news In-Reply-To: <72f7b0cd-dca7-d4b0-8236-8222ac755f0a@redhat.com> References: <72f7b0cd-dca7-d4b0-8236-8222ac755f0a@redhat.com> Message-ID: Meta: When responding to lists, please do not cc individuals, just repond to the list. Thanks, response within. On Fri, 16 Mar 2018, Gilles Dubreuil wrote: > In order to continue and progress on the API Schema guideline [1] as > mentioned in [2] to make APIs more machine-discoverable and also discussed > during [3]. > > Unfortunately until a new or either a second meeting time slot has been > allocated,  inconveniently for everyone, have to be done by emails. I'm sorry that the meeting time is excluding you and others, but our efforts to have either a second meeting or to change the time have met with limited response (except from you). In any case, the meeting are designed to be checkpoints where we resolve stuck questions and checkpoint where we are on things. It is better that most of the work be done in emails and on reviews as that's the most inclusive, and is less dependent on time-related variables. So moving the discussion about schemas here is the right thing and the fact that it hasn't happened (until now) is the reason for what appears to be a rather lukewarm reception from the people writing the API-SIG newsletter: if there's no traffic on either the gerrit review or here in email then there's no evidence of demand. You're asserting here that there is; that's great. > Of course new features have to be decided (voted) by the community but how > does that work when there are not enough people voting in? > It seems unfair to decide not to move forward and ignore the request because > the others people interested are not participating at this level. In a world of limited resources we can't impose work on people. The SIG is designed to be a place where people can come to make progress on API-related issues. If people don't show up, progress can't be made. Showing up doesn't have to mean show up at an IRC meeting. In fact I very much hope that it never means that. Instead it means writing things (like your email message) and seeking out collaborators to push your idea(s) forward. > It's very important  to consider the fact "I" am representing more than just > myself but an Openstack integration team, whose members are supporting me, > and our work impacts others teams involved in their open source product > consuming OpenStack. I'm sorry if I haven't made this more clear from the > beginning, I guess I'm still learning on the particiaption process. So from > now on, I'm going to use "us" instead. Can some of those "us" show up on the mailing list, the gerrit reviews, and prototype work that Graham has done? > Also from discussions with other developers from AT&T (OpenStack summit in > Sydney) and SAP (Misty project) who are already using automation to consume > APIs, this is really needed. Them too. > I've also mentioned the now known fact that no SDK has full time resources to > maintain it (which was the initial trigger for us) more automation is the > only sustainable way to continue the journey. > > Finally how can we dare say no to more automation? Unless of course, only > artisan work done by real hipster is allowed ;) Nobody is saying no to automation (as far as I'm aware). Some people (e.g., me, but not just me) are saying "unless there's an active community to do this work and actively publish about it and the related use cases that drive it it's impossible to make it a priority". Some other people (also me, but not just me) are also saying "schematizing API client generation is not my favorite thing" but that's just a personal opinion and essentially meaningless because yet other people are saying "I love API schema!". What's missing, though, is continuous enagement on producing children of that love. >> Furthermore, API-Schema will be problematic for services that use > microversions. If you have some insight or opinions on this, please add your > comments to that review. > > I understand microversion standardization (OpenAPI) has not happened yet or > if it ever does but that shouldn't preclude making progress. Of course, but who are you expecting to make that progress? The API-SIGs statement of "not something we're likely to pursue as a part of guidance" is about apparent unavailability of interested people. If that changes then the guidance situation probably changes too. But not writing guiadance is different from provide a place to talk about it. That's what a SIG is for. Think of it as a room with coffee and snacks where it is safe to talk about anything related to APIs. And that room exists in email just as much as it does in IRC and at the PTG. Ideally it exists _most_ in email. > So summarize and clarify, we are talking about SDK being able to build their > interface to Openstack APIs in an automated way but statically from API > Schema generated by every project. Such API Schema is already built in memory > during API reference documentation generation and could be saved in JSON > format (for instance) (see [5]). What do you see as the current roadblocks preventing this work from continuing to make progress? -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From fungi at yuggoth.org Fri Mar 16 13:29:13 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 16 Mar 2018 13:29:13 +0000 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: <20180315125840.fobitsay23wps2tb@yuggoth.org> Message-ID: <20180316132912.dhnjsfllzdzbrezh@yuggoth.org> On 2018-03-16 12:07:35 +0800 (+0800), Zhipeng Huang wrote: > I think non-eng mailing-list will not be utilized as we intent it > to, the same thing happens with non-eng irc channel as well. I > would suggest just pick a tool that people in the specific area > enjoys using, for example wechat in China, Line/Slack in Japan, > etc. [...] It would be unfortunate to recommend closed/proprietary services to new contributors, as that sets a very negative first impression of our community's priorities. However, I suppose any opportunity to communicate is an opportunity to help introduce them to free and open alternatives to those commercial walled gardens. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From aspiers at suse.com Fri Mar 16 16:56:47 2018 From: aspiers at suse.com (Adam Spiers) Date: Fri, 16 Mar 2018 16:56:47 +0000 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] online communication software In-Reply-To: <20180316132912.dhnjsfllzdzbrezh@yuggoth.org> References: <20180315125840.fobitsay23wps2tb@yuggoth.org> <20180316132912.dhnjsfllzdzbrezh@yuggoth.org> Message-ID: <20180316165647.sfhoqhf57zykuhml@pacific.linksys.moosehall> Jeremy Stanley wrote: >On 2018-03-16 12:07:35 +0800 (+0800), Zhipeng Huang wrote: >> I think non-eng mailing-list will not be utilized as we intent it >> to, the same thing happens with non-eng irc channel as well. I >> would suggest just pick a tool that people in the specific area >> enjoys using, for example wechat in China, Line/Slack in Japan, >> etc. >[...] > >It would be unfortunate to recommend closed/proprietary services to >new contributors, as that sets a very negative first impression of >our community's priorities. However, I suppose any opportunity to >communicate is an opportunity to help introduce them to free and >open alternatives to those commercial walled gardens. Agreed (strongly) on both points. Excuse my ignorance, but what's the adoption of IRC like in Asia? Are there any barriers to use in China? I'd also be curious to hear the community's thoughts on Matrix: https://matrix.org/ To me it seems like a very exciting contender for "IRC 2.0" - bringing all the shiny new Slack-like features that many people enjoy these days, without sacrificing any freedom or openness, thanks to its Apache 2.0 licensing and decentralised federated architecture. And it even has a built-in bridge with Freenode, which I find extremely useful during summits and PTGs, because then I get IRC-bouncer-like functionality synchronised between my phone and laptop, so I never miss a message even if I drop off the conference wifi for a while. From zhipengh512 at gmail.com Sat Mar 17 01:09:01 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Sat, 17 Mar 2018 09:09:01 +0800 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] online communication software In-Reply-To: <20180316165647.sfhoqhf57zykuhml@pacific.linksys.moosehall> References: <20180315125840.fobitsay23wps2tb@yuggoth.org> <20180316132912.dhnjsfllzdzbrezh@yuggoth.org> <20180316165647.sfhoqhf57zykuhml@pacific.linksys.moosehall> Message-ID: I think we have to think it outside the box of typical western developer habit and towards to a question like "how generally people communicate ?" As far as I know people in APAC region likes to do voice and video a lot. IRC has a learning curve for APAC devs, believe it or not, which demands an awesome speed of understanding the intertwining english based convos as well as to be able type as fast as they could themselves. I don't think whether the software is an open source one is a major concern. The major concern is if the people in that particular region, loves to use that. On Sat, Mar 17, 2018 at 12:56 AM, Adam Spiers wrote: > Jeremy Stanley wrote: > >> On 2018-03-16 12:07:35 +0800 (+0800), Zhipeng Huang wrote: >> >>> I think non-eng mailing-list will not be utilized as we intent it >>> to, the same thing happens with non-eng irc channel as well. I >>> would suggest just pick a tool that people in the specific area >>> enjoys using, for example wechat in China, Line/Slack in Japan, >>> etc. >>> >> [...] >> >> It would be unfortunate to recommend closed/proprietary services to >> new contributors, as that sets a very negative first impression of >> our community's priorities. However, I suppose any opportunity to >> communicate is an opportunity to help introduce them to free and >> open alternatives to those commercial walled gardens. >> > > Agreed (strongly) on both points. > > Excuse my ignorance, but what's the adoption of IRC like in Asia? > Are there any barriers to use in China? > > I'd also be curious to hear the community's thoughts on Matrix: > > https://matrix.org/ > > To me it seems like a very exciting contender for "IRC 2.0" - bringing > all the shiny new Slack-like features that many people enjoy these > days, without sacrificing any freedom or openness, thanks to its > Apache 2.0 licensing and decentralised federated architecture. > > And it even has a built-in bridge with Freenode, which I find > extremely useful during summits and PTGs, because then I get > IRC-bouncer-like functionality synchronised between my phone and > laptop, so I never miss a message even if I drop off the conference > wifi for a while. > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From amotoki at gmail.com Sun Mar 18 09:31:15 2018 From: amotoki at gmail.com (Akihiro Motoki) Date: Sun, 18 Mar 2018 18:31:15 +0900 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: <20180315125840.fobitsay23wps2tb@yuggoth.org> Message-ID: I don't think Howard's point necessarily applies to the case of Japan. As Japanese community, we don't encourage to use non-IRC tools for OpenStack developers. Our local version of the upstream institute (training) uses a specific IRC channel for example. Our mailing lists of Japan users group (using google groups from historical reason :p) is open to any topics including development, operators, setup and so on. On the other hand, we use other tools: a Slack room for Japan operators community and a gitter room for Japanese translators. There are several reasons. One big reason is Slack is a popular communication tool. Another reason (which I think is more important) is such tools support offline notification. These tools allows us to track discussions while they are offline. A standard IRC does not provide such feature. Users need to set up other tools like IRC bouncer or use other IRC-based service (like IRCcloud). OpenStack infra provides logs of our IRC channels, but it is not handy to use multiple medias for a single discussion. When I prepared a gitter room for Japanese translators, I compared several tools from various points (unlimited logs, unlimited number of members, openness and so on) and decided to use Gitter in this case. Although it might not be ideal, it is useful and convenient for non-developers. In my understanding, the first contact SIG is mainly for developers, so my above point does not necessarily apply, but I think it is one of important points to support offline communication. Thanks, Akihiro 2018-03-16 13:07 GMT+09:00 Zhipeng Huang : > Hi Jeremy, > > I think non-eng mailing-list will not be utilized as we intent it to, the > same thing happens with non-eng irc channel as well. I would suggest just > pick a tool that people in the specific area enjoys using, for example > wechat in China, Line/Slack in Japan, etc. > > On Thu, Mar 15, 2018 at 8:58 PM, Jeremy Stanley wrote: >> >> On 2018-03-15 08:37:35 +0800 (+0800), Zhipeng Huang wrote: >> [...] >> > For communciation tools, per irc I agree converge to #openstack-dev is >> > better than maintaining some independent channels. But also from my >> > experience video conf in native lang is more effective. >> [...] >> >> Any ideas on whether we should suggest that people who are finding >> English challenging try to reach out on one of our language-specific >> mailing lists for a language in which they are more fluent (and then >> perhaps arrange there for a video conference with another >> contributor who can help them if that's more convenient)? >> -- >> Jeremy Stanley >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > > > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Product Line > Huawei Technologies Co,. Ltd > Email: huangzhipeng at huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipengh at uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > From zhipengh512 at gmail.com Sun Mar 18 13:27:24 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Sun, 18 Mar 2018 21:27:24 +0800 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: <20180315125840.fobitsay23wps2tb@yuggoth.org> Message-ID: Yes I've also noticed the slack usage in Japan dev community :) I guess my case is mostly my observation from China. In any case , I think the point is every community in a certain region should use the best tool they see fit, without a mandate on certain method. For the FC SIG itself, a irc channel should work with all the liaisons. @Akihiro BTW there are a lot of IRC bouncers you could use for the offline discussion capture :) On Sun, Mar 18, 2018 at 5:31 PM, Akihiro Motoki wrote: > I don't think Howard's point necessarily applies to the case of Japan. > > As Japanese community, we don't encourage to use non-IRC tools for > OpenStack developers. > Our local version of the upstream institute (training) uses a specific > IRC channel for example. > Our mailing lists of Japan users group (using google groups from > historical reason :p) is open to any topics including development, > operators, setup and so on. > > On the other hand, we use other tools: a Slack room for Japan > operators community and a gitter room for Japanese translators. > There are several reasons. One big reason is Slack is a popular > communication tool. > Another reason (which I think is more important) is such tools support > offline notification. These tools allows us to track discussions while > they are offline. > A standard IRC does not provide such feature. Users need to set up > other tools like IRC bouncer or use other IRC-based service (like > IRCcloud). > OpenStack infra provides logs of our IRC channels, but it is not handy > to use multiple medias for a single discussion. > When I prepared a gitter room for Japanese translators, I compared > several tools from various points (unlimited logs, unlimited number of > members, openness and so on) and decided to use Gitter in this case. > Although it might not be ideal, it is useful and convenient for > non-developers. > > In my understanding, the first contact SIG is mainly for developers, > so my above point does not necessarily apply, but I think it is one of > important points to support offline communication. > > Thanks, > Akihiro > > > 2018-03-16 13:07 GMT+09:00 Zhipeng Huang : > > Hi Jeremy, > > > > I think non-eng mailing-list will not be utilized as we intent it to, the > > same thing happens with non-eng irc channel as well. I would suggest just > > pick a tool that people in the specific area enjoys using, for example > > wechat in China, Line/Slack in Japan, etc. > > > > On Thu, Mar 15, 2018 at 8:58 PM, Jeremy Stanley > wrote: > >> > >> On 2018-03-15 08:37:35 +0800 (+0800), Zhipeng Huang wrote: > >> [...] > >> > For communciation tools, per irc I agree converge to #openstack-dev > is > >> > better than maintaining some independent channels. But also from my > >> > experience video conf in native lang is more effective. > >> [...] > >> > >> Any ideas on whether we should suggest that people who are finding > >> English challenging try to reach out on one of our language-specific > >> mailing lists for a language in which they are more fluent (and then > >> perhaps arrange there for a video conference with another > >> contributor who can help them if that's more convenient)? > >> -- > >> Jeremy Stanley > >> > >> _______________________________________________ > >> openstack-sigs mailing list > >> openstack-sigs at lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > >> > > > > > > > > -- > > Zhipeng (Howard) Huang > > > > Standard Engineer > > IT Standard & Patent/IT Product Line > > Huawei Technologies Co,. Ltd > > Email: huangzhipeng at huawei.com > > Office: Huawei Industrial Base, Longgang, Shenzhen > > > > (Previous) > > Research Assistant > > Mobile Ad-Hoc Network Lab, Calit2 > > University of California, Irvine > > Email: zhipengh at uci.edu > > Office: Calit2 Building Room 2402 > > > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > > > > _______________________________________________ > > openstack-sigs mailing list > > openstack-sigs at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From amotoki at gmail.com Sun Mar 18 14:02:28 2018 From: amotoki at gmail.com (Akihiro Motoki) Date: Sun, 18 Mar 2018 23:02:28 +0900 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: <20180315125840.fobitsay23wps2tb@yuggoth.org> Message-ID: 2018-03-18 22:27 GMT+09:00 Zhipeng Huang : > Yes I've also noticed the slack usage in Japan dev community :) I guess my > case is mostly my observation from China. Perhaps I am not aware of that in Japan, although I believe I know most (at least many) of OpenStack contributors from Japan. > In any case , I think the point is every community in a certain region > should use the best tool they see fit, without a mandate on certain method. > For the FC SIG itself, a irc channel should work with all the liaisons. > > @Akihiro BTW there are a lot of IRC bouncers you could use for the offline > discussion capture :) My point is not IRC bouncer itself. My point is we need to set up IRC bouncer in addition to IRC itself if we track discussions offline with a single tool. Do you have any advise to solve this problem? > > On Sun, Mar 18, 2018 at 5:31 PM, Akihiro Motoki wrote: >> >> I don't think Howard's point necessarily applies to the case of Japan. >> >> As Japanese community, we don't encourage to use non-IRC tools for >> OpenStack developers. >> Our local version of the upstream institute (training) uses a specific >> IRC channel for example. >> Our mailing lists of Japan users group (using google groups from >> historical reason :p) is open to any topics including development, >> operators, setup and so on. >> >> On the other hand, we use other tools: a Slack room for Japan >> operators community and a gitter room for Japanese translators. >> There are several reasons. One big reason is Slack is a popular >> communication tool. >> Another reason (which I think is more important) is such tools support >> offline notification. These tools allows us to track discussions while >> they are offline. >> A standard IRC does not provide such feature. Users need to set up >> other tools like IRC bouncer or use other IRC-based service (like >> IRCcloud). >> OpenStack infra provides logs of our IRC channels, but it is not handy >> to use multiple medias for a single discussion. >> When I prepared a gitter room for Japanese translators, I compared >> several tools from various points (unlimited logs, unlimited number of >> members, openness and so on) and decided to use Gitter in this case. >> Although it might not be ideal, it is useful and convenient for >> non-developers. >> >> In my understanding, the first contact SIG is mainly for developers, >> so my above point does not necessarily apply, but I think it is one of >> important points to support offline communication. >> >> Thanks, >> Akihiro >> >> >> 2018-03-16 13:07 GMT+09:00 Zhipeng Huang : >> > Hi Jeremy, >> > >> > I think non-eng mailing-list will not be utilized as we intent it to, >> > the >> > same thing happens with non-eng irc channel as well. I would suggest >> > just >> > pick a tool that people in the specific area enjoys using, for example >> > wechat in China, Line/Slack in Japan, etc. >> > >> > On Thu, Mar 15, 2018 at 8:58 PM, Jeremy Stanley >> > wrote: >> >> >> >> On 2018-03-15 08:37:35 +0800 (+0800), Zhipeng Huang wrote: >> >> [...] >> >> > For communciation tools, per irc I agree converge to #openstack-dev >> >> > is >> >> > better than maintaining some independent channels. But also from my >> >> > experience video conf in native lang is more effective. >> >> [...] >> >> >> >> Any ideas on whether we should suggest that people who are finding >> >> English challenging try to reach out on one of our language-specific >> >> mailing lists for a language in which they are more fluent (and then >> >> perhaps arrange there for a video conference with another >> >> contributor who can help them if that's more convenient)? >> >> -- >> >> Jeremy Stanley >> >> >> >> _______________________________________________ >> >> openstack-sigs mailing list >> >> openstack-sigs at lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> >> >> > >> > >> > >> > -- >> > Zhipeng (Howard) Huang >> > >> > Standard Engineer >> > IT Standard & Patent/IT Product Line >> > Huawei Technologies Co,. Ltd >> > Email: huangzhipeng at huawei.com >> > Office: Huawei Industrial Base, Longgang, Shenzhen >> > >> > (Previous) >> > Research Assistant >> > Mobile Ad-Hoc Network Lab, Calit2 >> > University of California, Irvine >> > Email: zhipengh at uci.edu >> > Office: Calit2 Building Room 2402 >> > >> > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado >> > >> > _______________________________________________ >> > openstack-sigs mailing list >> > openstack-sigs at lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > > > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Product Line > Huawei Technologies Co,. Ltd > Email: huangzhipeng at huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipengh at uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > From thierry at openstack.org Mon Mar 19 10:26:09 2018 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 19 Mar 2018 11:26:09 +0100 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: <20180315125840.fobitsay23wps2tb@yuggoth.org> Message-ID: Akihiro Motoki wrote: > 2018-03-18 22:27 GMT+09:00 Zhipeng Huang : >> @Akihiro BTW there are a lot of IRC bouncers you could use for the offline >> discussion capture :) > > My point is not IRC bouncer itself. > My point is we need to set up IRC bouncer in addition to IRC itself if > we track discussions offline with a single tool. > Do you have any advise to solve this problem? We had some talks about running some bouncer service in the past, but that did not anywhere yet. In particular we talked about running a multi-users The Lounge instance: https://thelounge.chat/ -- Thierry Carrez (ttx) From aspiers at suse.com Mon Mar 19 10:58:50 2018 From: aspiers at suse.com (Adam Spiers) Date: Mon, 19 Mar 2018 10:58:50 +0000 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: <20180315125840.fobitsay23wps2tb@yuggoth.org> Message-ID: <20180319105850.d3e3ijx6ocft5nc5@pacific.linksys.moosehall> Akihiro Motoki wrote: >2018-03-18 22:27 GMT+09:00 Zhipeng Huang : >> @Akihiro BTW there are a lot of IRC bouncers you could use for the offline >> discussion capture :) > >My point is not IRC bouncer itself. >My point is we need to set up IRC bouncer in addition to IRC itself if >we track discussions offline with a single tool. No you don't - see below. >Do you have any advise to solve this problem? I gave advice on exactly this elsewhere in this thread; just use Matrix's Freenode IRC bridge: http://lists.openstack.org/pipermail/openstack-sigs/2018-March/000332.html More details: https://jon.sprig.gs/blog/post/497 https://opensource.com/article/17/5/introducing-riot-IRC From colleen at gazlene.net Mon Mar 19 11:20:05 2018 From: colleen at gazlene.net (Colleen Murphy) Date: Mon, 19 Mar 2018 12:20:05 +0100 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: <20180319105850.d3e3ijx6ocft5nc5@pacific.linksys.moosehall> References: <20180315125840.fobitsay23wps2tb@yuggoth.org> <20180319105850.d3e3ijx6ocft5nc5@pacific.linksys.moosehall> Message-ID: <1521458405.959087.1308042272.64C05DDF@webmail.messagingengine.com> This discussion has gone completely off topic. The question from Jeremy was about easing language barriers: On Thu, Mar 15, 2018, at 1:58 PM, Jeremy Stanley wrote: > Any ideas on whether we should suggest that people who are finding > English challenging try to reach out on one of our language-specific > mailing lists for a language in which they are more fluent (and then > perhaps arrange there for a video conference with another > contributor who can help them if that's more convenient)? The difficulty in setting up an IRC bouncer and whether it is even a good idea to encourage or require IRC persistence for OpenStack contributors is a completely orthogonal problem, it is absolutely not culturally or language specific. What is culturally specific is where existing OpenStack communities already congregate. I've been told there is a vibrant OpenStack community on WeChat in China. But the Chinese mailing list is very low traffic[1]. So it would seem to me that sending newcomers into a black hole of a mailing list would be very discouraging, but encouraging their participation on a platform where they could actually find answers in their language could be beneficial to them. Colleen [1] http://lists.openstack.org/pipermail/openstack-zh/ From zhipengh512 at gmail.com Mon Mar 19 11:35:17 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Mon, 19 Mar 2018 11:35:17 +0000 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: <1521458405.959087.1308042272.64C05DDF@webmail.messagingengine.com> References: <20180315125840.fobitsay23wps2tb@yuggoth.org> <20180319105850.d3e3ijx6ocft5nc5@pacific.linksys.moosehall> <1521458405.959087.1308042272.64C05DDF@webmail.messagingengine.com> Message-ID: +1 Colleen On Mon, Mar 19, 2018, 7:20 PM Colleen Murphy wrote: > This discussion has gone completely off topic. The question from Jeremy > was about easing language barriers: > > On Thu, Mar 15, 2018, at 1:58 PM, Jeremy Stanley wrote: > > > Any ideas on whether we should suggest that people who are finding > > English challenging try to reach out on one of our language-specific > > mailing lists for a language in which they are more fluent (and then > > perhaps arrange there for a video conference with another > > contributor who can help them if that's more convenient)? > > The difficulty in setting up an IRC bouncer and whether it is even a good > idea to encourage or require IRC persistence for OpenStack contributors is > a completely orthogonal problem, it is absolutely not culturally or > language specific. > > What is culturally specific is where existing OpenStack communities > already congregate. I've been told there is a vibrant OpenStack community > on WeChat in China. But the Chinese mailing list is very low traffic[1]. So > it would seem to me that sending newcomers into a black hole of a mailing > list would be very discouraging, but encouraging their participation on a > platform where they could actually find answers in their language could be > beneficial to them. > > Colleen > > [1] http://lists.openstack.org/pipermail/openstack-zh/ > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aspiers at suse.com Mon Mar 19 13:06:49 2018 From: aspiers at suse.com (Adam Spiers) Date: Mon, 19 Mar 2018 13:06:49 +0000 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: <1521458405.959087.1308042272.64C05DDF@webmail.messagingengine.com> References: <20180315125840.fobitsay23wps2tb@yuggoth.org> <20180319105850.d3e3ijx6ocft5nc5@pacific.linksys.moosehall> <1521458405.959087.1308042272.64C05DDF@webmail.messagingengine.com> Message-ID: <20180319130649.xc37kygs3j4efmb4@pacific.linksys.moosehall> Colleen Murphy wrote: >This discussion has gone completely off topic. The question from >Jeremy was about easing language barriers: > >On Thu, Mar 15, 2018, at 1:58 PM, Jeremy Stanley wrote: > >> Any ideas on whether we should suggest that people who are finding >> English challenging try to reach out on one of our language-specific >> mailing lists for a language in which they are more fluent (and then >> perhaps arrange there for a video conference with another >> contributor who can help them if that's more convenient)? > >The difficulty in setting up an IRC bouncer and whether it is even a >good idea to encourage or require IRC persistence for OpenStack >contributors is a completely orthogonal problem, it is absolutely not >culturally or language specific. Agreed. That said, I think the discussions about IRC bouncers / persistence, Matrix etc. are worthwhile tangents, and my conscience is mostly clean from starting one sub-thread in that direction, because I changed the Subject: header accordingly ;-) (Only "mostly" and not "totally" because it's getting off-topic for this -sigs list ...) From adriant at catalyst.net.nz Mon Mar 19 20:37:55 2018 From: adriant at catalyst.net.nz (Adrian Turjak) Date: Tue, 20 Mar 2018 09:37:55 +1300 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: <20180315125840.fobitsay23wps2tb@yuggoth.org> Message-ID: ++ on The Lounge. It's nice and pretty much turns IRC into a wannabe Slack-like. We use it internally for Catalyst Cloud, and the biggest issue with it (doesn't import logs on service restart) will be fixed on the next version it looks like. On 19/03/18 23:26, Thierry Carrez wrote: > Akihiro Motoki wrote: >> 2018-03-18 22:27 GMT+09:00 Zhipeng Huang : >>> @Akihiro BTW there are a lot of IRC bouncers you could use for the offline >>> discussion capture :) >> My point is not IRC bouncer itself. >> My point is we need to set up IRC bouncer in addition to IRC itself if >> we track discussions offline with a single tool. >> Do you have any advise to solve this problem? > We had some talks about running some bouncer service in the past, but > that did not anywhere yet. In particular we talked about running a > multi-users The Lounge instance: > > https://thelounge.chat/ > From msm at redhat.com Mon Mar 19 21:26:31 2018 From: msm at redhat.com (Michael McCune) Date: Mon, 19 Mar 2018 17:26:31 -0400 Subject: [Openstack-sigs] [openstack-dev] [all][api] POST /api-sig/news In-Reply-To: References: <72f7b0cd-dca7-d4b0-8236-8222ac755f0a@redhat.com> Message-ID: On Fri, Mar 16, 2018 at 4:55 AM, Chris Dent wrote: > > >> So summarize and clarify, we are talking about SDK being able to build >> their interface to Openstack APIs in an automated way but statically from >> API Schema generated by every project. Such API Schema is already built in >> memory during API reference documentation generation and could be saved in >> JSON format (for instance) (see [5]). >> > > What do you see as the current roadblocks preventing this work from > continuing to make progress? > > > Gilles, i'm very curious about how we can help as well. i am keenly interested in the api-schema work that is happening and i am coming up to speed with the work that Graham has done, and which previously existed, on os-api-ref. although i don't have a *ton* of spare free time, i would like to help as much as i can. thanks for bringing this up again, peace o/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Mon Mar 19 22:49:25 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 19 Mar 2018 22:49:25 +0000 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: References: <20180315125840.fobitsay23wps2tb@yuggoth.org> Message-ID: <20180319224925.6iamtklsnbe6i2ju@yuggoth.org> On 2018-03-20 09:37:55 +1300 (+1300), Adrian Turjak wrote: > ++ on The Lounge. It's nice and pretty much turns IRC into a wannabe > Slack-like. > > We use it internally for Catalyst Cloud, and the biggest issue with it > (doesn't import logs on service restart) will be fixed on the next > version it looks like. [...] Someone may, in that case, be interested in resurrecting https://review.openstack.org/319506 (Infra spec for hosting an instance of it). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From kennelson11 at gmail.com Tue Mar 20 06:38:16 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 20 Mar 2018 06:38:16 +0000 Subject: [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions In-Reply-To: <1521458405.959087.1308042272.64C05DDF@webmail.messagingengine.com> References: <20180315125840.fobitsay23wps2tb@yuggoth.org> <20180319105850.d3e3ijx6ocft5nc5@pacific.linksys.moosehall> <1521458405.959087.1308042272.64C05DDF@webmail.messagingengine.com> Message-ID: +1 I obviously would like to see everyone in the community using IRC, but I realize it's not the most conducive to other languages and that in many parts of the world that are other options that are the norm. If we can document these other options so as to be able to direct new comers to them as an alternative/precursor to IRC while noting that the majority of the development community uses IRC... I think I'd be okay with that. Hopefully as the new contributors get traction in the community and learn the software they would switch to using IRC more as time went on. -Kendall (diablo_rojo) On Mon, 19 Mar 2018, 4:20 am Colleen Murphy, wrote: > This discussion has gone completely off topic. The question from Jeremy > was about easing language barriers: > > On Thu, Mar 15, 2018, at 1:58 PM, Jeremy Stanley wrote: > > > Any ideas on whether we should suggest that people who are finding > > English challenging try to reach out on one of our language-specific > > mailing lists for a language in which they are more fluent (and then > > perhaps arrange there for a video conference with another > > contributor who can help them if that's more convenient)? > > The difficulty in setting up an IRC bouncer and whether it is even a good > idea to encourage or require IRC persistence for OpenStack contributors is > a completely orthogonal problem, it is absolutely not culturally or > language specific. > > What is culturally specific is where existing OpenStack communities > already congregate. I've been told there is a vibrant OpenStack community > on WeChat in China. But the Chinese mailing list is very low traffic[1]. So > it would seem to me that sending newcomers into a black hole of a mailing > list would be very discouraging, but encouraging their participation on a > platform where they could actually find answers in their language could be > beneficial to them. > > Colleen > > [1] http://lists.openstack.org/pipermail/openstack-zh/ > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blair.bethwaite at gmail.com Tue Mar 20 14:26:05 2018 From: blair.bethwaite at gmail.com (Blair Bethwaite) Date: Wed, 21 Mar 2018 01:26:05 +1100 Subject: [Openstack-sigs] [scientific] IRC meeting 2100UTC Message-ID: Hi all, Reminder there's a Scientific SIG meeting coming up in about 6.5 hours. All comers welcome. (https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_March_20th_2018) ==== IRC Meeting March 20th 2018 ==== 2018-03-20 2100 UTC in channel #openstack-meeting # Forum brainstorming (https://etherpad.openstack.org/p/YVR18-scientific-sig-brainstorming) # Discussion regarding state of GPU passthrough and interest in collaborating to resolve security issues # AOB -- Cheers, ~Blairo From kennelson11 at gmail.com Tue Mar 20 21:50:02 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 20 Mar 2018 21:50:02 +0000 Subject: [Openstack-sigs] [First Contact] [SIG] Meeting Today! Message-ID: Hello! Another meeting tonight late/tomorrow depending on where in the world you live :) 0800 UTC Wednesday. Here is the agenda if you have anything to add [1]. Or if you want to add your name to the ping list it is there as well! See you all soon! -Kendall (diablo_rojo) [1] https://wiki.openstack.org/wiki/First_Contact_SIG#Meeting_Agenda -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrhillsman at gmail.com Wed Mar 21 15:45:39 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Wed, 21 Mar 2018 10:45:39 -0500 Subject: [Openstack-sigs] [forum] We want your session ideas for the Vancouver Forum! Message-ID: Hey everyone, Please take time to put ideas for sessions at the forum in the TC and/or UC catch-all etherpads or any of the others that are appropriate: https://wiki.openstack.org/wiki/Forum/Vancouver2018 We really want to get as many session ideas as possible so that the committee has too many to choose from :) Here is an idea of the types of sessions to think about proposing: *Project-specific sessions* Where developers can ask users specific questions about their experience, users can provide feedback from the last release and cross-community collaboration on the priorities and 'blue sky' ideas for the next release can occur. *Strategic, whole-of-community discussions* To think about the big picture, including beyond just one release cycle and new technologies *Cross-project sessions* In a similar vein to what has happened at past design summits, but with increased emphasis on issues that are of relevant to all areas of the community If you have organized any events in the past year you probably have heard of or been in some sessions that are perfect for the Forum. -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Wed Mar 21 23:22:16 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Wed, 21 Mar 2018 23:22:16 +0000 Subject: [Openstack-sigs] [First Contact] [SIG] Forum Brainstorming Message-ID: Hello Everyone! A little late to the brainstorm party, but I created the etherpad for ideas for topics for the First Contact SIG at the Forum[1]. I also added it to the wiki list of brainstorming etherpads. In addition, its on our agenda for discussion again in next week's meeting. Please add your ideas! -Kendall (diablo_rojo) [1] https://etherpad.openstack.org/p/FC_SIG_Rocky_Forum -------------- next part -------------- An HTML attachment was scrubbed... URL: From msm at redhat.com Thu Mar 22 17:14:37 2018 From: msm at redhat.com (Michael McCune) Date: Thu, 22 Mar 2018 13:14:37 -0400 Subject: [Openstack-sigs] [all][api] POST /api-sig/news Message-ID: Greetings OpenStack community, Another jovial meeting of the API-SIG was convened today. We began with a few housekeeping notes and then moved into a discussion of the api-ref work and how we might continue to assist Graham Hayes with the os-api-ref changes[7] that will output a machine-readable format for the API schemas. The group generally agrees that the SIG should continue to assist in moving these changes forward, there are concerns about the inclusion of microversions and how best to capture these, but for the time being the SIG will engage with the review and the parties interested in seeing this work through to completion. We then talked about the new reviews which have been added recently to the queue. The SIG has decided to freeze the proposed guidance[8] on exposing microversions in SDKs created by Dmitry Tantsur. There is also a review[9] from Ed Leafe to split up the current HTTP guidance document into separate documents to help improve the readability and presence of this material, this should be ready for freeze soon. Lastly, we discussed a new bug[10] concerning how services should be referenced in error messages. The current guidance specifies that a service name should be used and the proposed bug by Chris Dent is that the service type should be used instead. Chris has also created a review[11] to address this but the SIG would like more opinions on this change and how it might impact consuming the error messages. As always if you're interested in helping out, in addition to coming to the meetings, there's also: * The list of bugs [5] indicates several missing or incomplete guidelines. * The existing guidelines [2] always need refreshing to account for changes over time. If you find something that's not quite right, submit a patch [6] to fix it. * Have you done something for which you think guidance would have made things easier but couldn't find any? Submit a patch and help others [6]. # Newly Published Guidelines None this week. # API Guidelines Proposed for Freeze Guidelines that are ready for wider review by the whole community. * Add guideline on exposing microversions in SDKs https://review.openstack.org/#/c/532814 # Guidelines Currently Under Review [3] * Break up the HTTP guideline into smaller documents https://review.openstack.org/#/c/554234/ * Add guidance on needing cache-control headers https://review.openstack.org/550468 * Add API-schema guide (still being defined) https://review.openstack.org/#/c/524467/ * A (shrinking) suite of several documents about doing version and service discovery Start at https://review.openstack.org/#/c/459405/ * WIP: microversion architecture archival doc (very early; not yet ready for review) https://review.openstack.org/444892 # Highlighting your API impacting issues If you seek further review and insight from the API SIG about APIs that you are developing or changing, please address your concerns in an email to the OpenStack developer mailing list[1] with the tag "[api]" in the subject. In your email, you should include any relevant reviews, links, and comments to help guide the discussion of the specific challenge you are facing. To learn more about the API SIG mission and the work we do, see our wiki page [4] and guidelines [2]. Thanks for reading and see you next week! # References [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [2] http://specs.openstack.org/openstack/api-wg/ [3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z [4] https://wiki.openstack.org/wiki/API_SIG [5] https://bugs.launchpad.net/openstack-api-wg [6] https://git.openstack.org/cgit/openstack/api-wg [7] https://review.openstack.org/#/c/528801/ [8] https://review.openstack.org/#/c/532814/ [9] https://review.openstack.org/#/c/554234/ [10] https://bugs.launchpad.net/openstack-api-wg/+bug/1756464 [11] https://review.openstack.org/#/c/554921/ Meeting Agenda https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda Past Meeting Records http://eavesdrop.openstack.org/meetings/api_sig/ Open Bugs https://bugs.launchpad.net/openstack-api-wg -------------- next part -------------- An HTML attachment was scrubbed... URL: From stig.openstack at telfer.org Tue Mar 27 22:36:09 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Tue, 27 Mar 2018 23:36:09 +0100 Subject: [Openstack-sigs] [scientific] IRC Meeting, Wednesday 1100UTC: Cyborg and Forum Message-ID: Hi all - We have a Scientific SIG meeting on Wednesday at 1100 UTC. This week’s agenda is at: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_March_28th_2018 We’ll be hearing from Zhipeng Huang about the Cyborg project for managing hardware acceleration resources, and discussing forum topics to propose for the Vancouver summit. Everyone is welcome. Cheers, Stig -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdent+os at anticdent.org Thu Mar 29 17:39:05 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Thu, 29 Mar 2018 18:39:05 +0100 (BST) Subject: [Openstack-sigs] [all][api] POST /api-sig/news Message-ID: Greetings OpenStack community, Chaotic but fun API-SIG meeting today. elmiko has done some review of the long-in-progress microversion history doc [7] and reports that it is worth finishing and publishing as a historical document explaining why microversions exist. Having greater context on the why of microversions should help them feel like less of an imposition. We then discussed what sort of things, if any, the API-SIG should try to talk about during the Forum in Vancouver. edleafe will seek out some SDK-related people to see if we can share some time together. If you're reading this and you have some ideas, please respond and tell us. Then the long lost mordred returned from the land of zuul to discuss some ambiguities in how services, code and configuration use the concept of version. I have to admit that my eyes glazed over (with tears) for a moment through here, but the outcome was that the best thing to do is not surprise the users or make them do extra work. This will be encoded in a followup to the merging guidance on SDKs. elmiko had another report on research he was doing: He thinks he may have figured out a way to deal with microversions in OpenAPI documents. I don't want to oversell this yet, but if it works this could be combined with the pending experiments to make structured data out of existing api-ref documents [8] to auto-generate OpenAPI schema from documentation. Then we looked at some pending guidelines (see below). One that stood out as potentialy controversial is the use of service name or service type in errors document [9]. As always if you're interested in helping out, in addition to coming to the meetings, there's also: * The list of bugs [5] indicates several missing or incomplete guidelines. * The existing guidelines [2] always need refreshing to account for changes over time. If you find something that's not quite right, submit a patch [6] to fix it. * Have you done something for which you think guidance would have made things easier but couldn't find any? Submit a patch and help others [6]. # Newly Published Guidelines * Add guideline on exposing microversions in SDKs https://review.openstack.org/#/c/532814 # API Guidelines Proposed for Freeze Guidelines that are ready for wider review by the whole community. None this week. # Guidelines Currently Under Review [3] * Break up the HTTP guideline into smaller documents https://review.openstack.org/#/c/554234/ * Add guidance on needing cache-control headers https://review.openstack.org/550468 * Update the errors guidance to use service-type for code https://review.openstack.org/#/c/554921/ * Update parameter names in microversion sdk spec https://review.openstack.org/#/c/557773/ * Add API-schema guide (still being defined) https://review.openstack.org/#/c/524467/ * A (shrinking) suite of several documents about doing version and service discovery Start at https://review.openstack.org/#/c/459405/ * WIP: microversion architecture archival doc (very early; not yet ready for review) https://review.openstack.org/444892 # Highlighting your API impacting issues If you seek further review and insight from the API SIG about APIs that you are developing or changing, please address your concerns in an email to the OpenStack developer mailing list[1] with the tag "[api]" in the subject. In your email, you should include any relevant reviews, links, and comments to help guide the discussion of the specific challenge you are facing. To learn more about the API SIG mission and the work we do, see our wiki page [4] and guidelines [2]. Thanks for reading and see you next week! # References [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [2] http://specs.openstack.org/openstack/api-wg/ [3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z [4] https://wiki.openstack.org/wiki/API_SIG [5] https://bugs.launchpad.net/openstack-api-wg [6] https://git.openstack.org/cgit/openstack/api-wg [7] https://review.openstack.org/444892 [8] https://review.openstack.org/#/c/528801/ [9] https://review.openstack.org/#/c/554921/ Meeting Agenda https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda Past Meeting Records http://eavesdrop.openstack.org/meetings/api_sig/ Open Bugs https://bugs.launchpad.net/openstack-api-wg -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From ed at leafe.com Thu Mar 29 21:46:12 2018 From: ed at leafe.com (Ed Leafe) Date: Thu, 29 Mar 2018 16:46:12 -0500 Subject: [Openstack-sigs] [api-sig] Any interest in a meetup at the Vancouver Forum? Message-ID: <429C1B99-4BD5-4608-95B5-D83BB5085958@leafe.com> Many people from the API-SIG will be attending, so we were hoping to get together with people from the SDK community to discuss ways in which we can help each other. The main reason for forming a SIG was to break down the barriers between API upstream developers and downstream API consumers, so this seems like a good time to do just that. -- Ed Leafe From joe at topjian.net Thu Mar 29 21:56:26 2018 From: joe at topjian.net (Joe Topjian) Date: Thu, 29 Mar 2018 15:56:26 -0600 Subject: [Openstack-sigs] [api-sig] Any interest in a meetup at the Vancouver Forum? In-Reply-To: <429C1B99-4BD5-4608-95B5-D83BB5085958@leafe.com> References: <429C1B99-4BD5-4608-95B5-D83BB5085958@leafe.com> Message-ID: I'll be attending the summit/forum in Vancouver. I'm happy to attend any SDK/API-related sessions or other kinds of meetups. On Thu, Mar 29, 2018 at 3:46 PM, Ed Leafe wrote: > Many people from the API-SIG will be attending, so we were hoping to get > together with people from the SDK community to discuss ways in which we can > help each other. The main reason for forming a SIG was to break down the > barriers between API upstream developers and downstream API consumers, so > this seems like a good time to do just that. > > -- Ed Leafe > > > > > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -------------- next part -------------- An HTML attachment was scrubbed... URL: