Re: [openstack-dev] Vancouver Design Summit format changes
(X-posted to -operators.) Any thoughts on how the ops track spaces would be requested, since there is not a real ‘operators project’, PTL, etc.? I assume this would come from the operators group as a whole, so probably something we should put on the agenda at the ops meet up in March. (I’ve added it to the etherpad.) Mike On 1/9/15, 2:50 PM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, The OpenStack Foundation staff is considering a number of changes to the Design Summit format for Vancouver, changes on which we'd very much like to hear your feedback. The problems we are trying to solve are the following: - Accommodate the needs of more OpenStack projects - Reduce separation and perceived differences between the Ops Summit and the Design/Dev Summit - Create calm and less-crowded spaces for teams to gather and get more work done While some sessions benefit from large exposure, loads of feedback and large rooms, some others are just workgroup-oriented work sessions that benefit from smaller rooms, less exposure and more whiteboards. Smaller rooms are also cheaper space-wise, so they allow us to scale more easily to a higher number of OpenStack projects. My proposal is the following. Each project team would have a track at the Design Summit. Ops feedback is in my opinion part of the design of OpenStack, so the Ops Summit would become a track within the forward-looking Design Summit. Tracks may use two separate types of sessions: * Fishbowl sessions Those sessions are for open discussions where a lot of participation and feedback is desirable. Those would happen in large rooms (100 to 300 people, organized in fishbowl style with a projector). Those would have catchy titles and appear on the general Design Summit schedule. We would have space for 6 or 7 of those in parallel during the first 3 days of the Design Summit (we would not run them on Friday, to reproduce the successful Friday format we had in Paris). * Working sessions Those sessions are for a smaller group of contributors to get specific work done or prioritized. Those would happen in smaller rooms (20 to 40 people, organized in boardroom style with loads of whiteboards). Those would have a blanket title (like infra team working session) and redirect to an etherpad for more precise and current content, which should limit out-of-team participation. Those would replace project pods. We would have space for 10 to 12 of those in parallel for the first 3 days, and 18 to 20 of those in parallel on the Friday (by reusing fishbowl rooms). Each project track would request some mix of sessions (We'd like 4 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on Friday) and the TC would arbitrate how to allocate the limited resources. Agenda for the fishbowl sessions would need to be published in advance, but agenda for the working sessions could be decided dynamically from an etherpad agenda. By making larger use of smaller spaces, we expect that setup to let us accommodate the needs of more projects. By merging the two separate Ops Summit and Design Summit events, it should make the Ops feedback an integral part of the Design process rather than a second-class citizen. By creating separate working session rooms, we hope to evolve the pod concept into something where it's easier for teams to get work done (less noise, more whiteboards, clearer agenda). What do you think ? Could that work ? If not, do you have alternate suggestions ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Hierarchical Multitenancy
+1 to Nova support for this getting in to Kilo. We have a similar use case. I’d really like to doll out quota on a department level, and let individual departments manage sub projects and quotas on their own. I agree that HMT has limited value without Nova support. Thanks! Mike From: Tim Bell tim.b...@cern.chmailto:tim.b...@cern.ch Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, December 23, 2014 at 11:01 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Hierarchical Multitenancy Joe, Thanks… there seems to be good agreement on the spec and the matching implementation is well advanced with BARC so the risk is not too high. Launching HMT with quota in Nova in the same release cycle would also provide a more complete end user experience. For CERN, this functionality is very interesting as it allows the central cloud providers to delegate the allocation of quotas to the LHC experiments. Thus, from a central perspective, we are able to allocate N thousand cores to an experiment and delegate their resource co-ordinator to prioritise the work within the experiment. Currently, we have many manual helpdesk tickets with significant latency to adjust the quotas. Tim From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: 23 December 2014 17:35 To: OpenStack Development Mailing List Subject: Re: [openstack-dev] Hierarchical Multitenancy On Dec 23, 2014 12:26 AM, Tim Bell tim.b...@cern.chmailto:tim.b...@cern.ch wrote: It would be great if we can get approval for the Hierachical Quota handling in Nova too (https://review.openstack.org/#/c/129420/). Nova's spec deadline has passed, but I think this is a good candidate for an exception. We will announce the process for asking for a formal spec exception shortly after new years. Tim From: Morgan Fainberg [mailto:morgan.fainb...@gmail.commailto:morgan.fainb...@gmail.com] Sent: 23 December 2014 01:22 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Hierarchical Multitenancy Hi Raildo, Thanks for putting this post together. I really appreciate all the work you guys have done (and continue to do) to get the Hierarchical Mulittenancy code into Keystone. It’s great to have the base implementation merged into Keystone for the K1 milestone. I look forward to seeing the rest of the development land during the rest of this cycle and what the other OpenStack projects build around the HMT functionality. Cheers, Morgan On Dec 22, 2014, at 1:49 PM, Raildo Mascena rail...@gmail.commailto:rail...@gmail.com wrote: Hello folks, My team and I developed the Hierarchical Multitenancy concept for Keystone in Kilo-1 but What is Hierarchical Multitenancy? What have we implemented? What are the next steps for kilo? To answers these questions, I created a blog post http://raildo.me/hierarchical-multitenancy-in-openstack/ Any question, I'm available. -- Raildo Mascena Software Engineer. Bachelor of Computer Science. Distributed Systems Laboratory Federal University of Campina Grande Campina Grande, PB - Brazil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Pod-area meetup to discuss proposal to allow HV-based network selection
We have some folks interested in this, but want to see the Rackspace Neutron scaling talk (starting now.) Will head down after it. From: Manish Godara mani...@yahoo-inc.commailto:mani...@yahoo-inc.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 2:14 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] Pod-area meetup to discuss proposal to allow HV-based network selection Hey folks, I have met several folks at the summit who have come up with their own solutions for large clouds to allow network scaling. Several of the solutions seem to be based on network selection given certain constraints. I would like to discuss some use-cases and some solutions. We could meet at 3:30/Thu (today) in the pod area, if interested. Thanks, manish ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [barbican] any barbican devs at summit?
Would be interested in syncing up to hear about your experiences with this. Anybody at the summit this week that'd be willing to chat for a few minutes? Email works to reach out to me, or I'm on IRC (mdorman) sporadically this week. Thanks, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
