Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
On 02/02/2018 11:56 AM, Lance Bragstad wrote: > I apologize for using the "baremetal/VM" name, but I wanted to get an > etherpad rolling sooner rather than later [0], since we're likely going > to have to decide on a new name in person. I ported the initial ideas > Colleen mentioned when she started this thread, added links to previous > etherpads from Boston and Denver, and ported some topics from the Boston > etherpads. > > Please feel free to add ideas to the list or elaborate on existing ones. > Next week we'll start working through them and figure out what we want > to accomplish for the session. Once we have an official room for the > discussion, I'll add the etherpad to the list in the wiki. Based on some discussions in #openstack-dev this morning [0], I took a stab at working out a rough schedule for Monday and Tuesday [1]. Let me know if you notice conflicts or want to re-propose a session/topic. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-02-05.log.html#t2018-02-05T15:45:57 [1] https://etherpad.openstack.org/p/baremetal-vm-rocky-ptg > > [0] https://etherpad.openstack.org/p/baremetal-vm-rocky-ptg > > > On 02/02/2018 11:10 AM, Zane Bitter wrote: >> On 30/01/18 10:33, Colleen Murphy wrote: >>> At the last PTG we had some time on Monday and Tuesday for >>> cross-project discussions related to baremetal and VM management. We >>> don't currently have that on the schedule for this PTG. There is still >>> some free time available that we can ask for[1]. Should we try to >>> schedule some time for this? >> +1, I would definitely attend this too. >> >> - ZB >> >>> From a keystone perspective, some things we'd like to talk about with >>> the BM/VM teams are: >>> >>> - Unified limits[2]: we now have a basic REST API for registering >>> limits in keystone. Next steps are building out libraries that can >>> consume this API and calculate quota usage and limit allocation, and >>> developing models for quotas in project hierarchies. Input from other >>> projects is essential here. >>> - RBAC: we've introduced "system scope"[3] to fix the admin-ness >>> problem, and we'd like to guide other projects through the migration. >>> - Application credentials[4]: this main part of this work is largely >>> done, next steps are implementing better access control for it, which >>> is largely just a keystone team problem but we could also use this >>> time for feedback on the implementation so far >>> >>> There's likely some non-keystone-related things that might be at home >>> in a dedicated BM/VM room too. Do we want to have a dedicated day or >>> two for these projects? Or perhaps not dedicated days, but >>> planned-in-advance meeting time? Or should we wait and schedule it >>> ad-hoc if we feel like we need it? >>> >>> Colleen >>> >>> [1] >>> https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true >>> [2] >>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html >>> [3] >>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html >>> [4] >>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html >>> >>> __ >>> >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> __ >> >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
I apologize for using the "baremetal/VM" name, but I wanted to get an etherpad rolling sooner rather than later [0], since we're likely going to have to decide on a new name in person. I ported the initial ideas Colleen mentioned when she started this thread, added links to previous etherpads from Boston and Denver, and ported some topics from the Boston etherpads. Please feel free to add ideas to the list or elaborate on existing ones. Next week we'll start working through them and figure out what we want to accomplish for the session. Once we have an official room for the discussion, I'll add the etherpad to the list in the wiki. [0] https://etherpad.openstack.org/p/baremetal-vm-rocky-ptg On 02/02/2018 11:10 AM, Zane Bitter wrote: > On 30/01/18 10:33, Colleen Murphy wrote: >> At the last PTG we had some time on Monday and Tuesday for >> cross-project discussions related to baremetal and VM management. We >> don't currently have that on the schedule for this PTG. There is still >> some free time available that we can ask for[1]. Should we try to >> schedule some time for this? > > +1, I would definitely attend this too. > > - ZB > >> From a keystone perspective, some things we'd like to talk about with >> the BM/VM teams are: >> >> - Unified limits[2]: we now have a basic REST API for registering >> limits in keystone. Next steps are building out libraries that can >> consume this API and calculate quota usage and limit allocation, and >> developing models for quotas in project hierarchies. Input from other >> projects is essential here. >> - RBAC: we've introduced "system scope"[3] to fix the admin-ness >> problem, and we'd like to guide other projects through the migration. >> - Application credentials[4]: this main part of this work is largely >> done, next steps are implementing better access control for it, which >> is largely just a keystone team problem but we could also use this >> time for feedback on the implementation so far >> >> There's likely some non-keystone-related things that might be at home >> in a dedicated BM/VM room too. Do we want to have a dedicated day or >> two for these projects? Or perhaps not dedicated days, but >> planned-in-advance meeting time? Or should we wait and schedule it >> ad-hoc if we feel like we need it? >> >> Colleen >> >> [1] >> https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true >> [2] >> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html >> [3] >> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html >> [4] >> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html >> >> __ >> >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
On 30/01/18 10:33, Colleen Murphy wrote: At the last PTG we had some time on Monday and Tuesday for cross-project discussions related to baremetal and VM management. We don't currently have that on the schedule for this PTG. There is still some free time available that we can ask for[1]. Should we try to schedule some time for this? +1, I would definitely attend this too. - ZB From a keystone perspective, some things we'd like to talk about with the BM/VM teams are: - Unified limits[2]: we now have a basic REST API for registering limits in keystone. Next steps are building out libraries that can consume this API and calculate quota usage and limit allocation, and developing models for quotas in project hierarchies. Input from other projects is essential here. - RBAC: we've introduced "system scope"[3] to fix the admin-ness problem, and we'd like to guide other projects through the migration. - Application credentials[4]: this main part of this work is largely done, next steps are implementing better access control for it, which is largely just a keystone team problem but we could also use this time for feedback on the implementation so far There's likely some non-keystone-related things that might be at home in a dedicated BM/VM room too. Do we want to have a dedicated day or two for these projects? Or perhaps not dedicated days, but planned-in-advance meeting time? Or should we wait and schedule it ad-hoc if we feel like we need it? Colleen [1] https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true [2] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html [3] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html [4] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
> > Fair point. When the "VM/baremetal workgroup" was originally formed, > the goal was more about building clouds with both types of resources, > making them behave similarly from a user perspective, etc. Somehow > we got into talking applications and these other topics came up, which > seemed more interesting/pressing to fix. :) > > Maybe "cross-project identity integration" or something is a better name? Cloud-Native Application IMO is one of the ways to see the flow for both VM/Baremetal. But It's true if we can have more specific goal coss project to make sure we're marching to that goal (which `VM/baremetal workgroup` formed for) will be even better. Instead of modifying the name, I do prefer if we can spend some time to trace current flow and come out with specific targets for teams to work on in rocky to allow building both types of resources and feel like same flow to user, and which of cause includes what keystone already started. So other than topics Collen mentioned above (and I think they all great), we should focus working on what topics we can comes out from here (I think that's why Collen start this ML). Ideas? -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
On Wed, Jan 31, 2018 at 12:22 PM, Dmitry Tantsur wrote: > On 01/31/2018 06:15 PM, Matt Riedemann wrote: > >> On 1/30/2018 9:33 AM, Colleen Murphy wrote: >> >>> At the last PTG we had some time on Monday and Tuesday for >>> cross-project discussions related to baremetal and VM management. We >>> don't currently have that on the schedule for this PTG. There is still >>> some free time available that we can ask for[1]. Should we try to >>> schedule some time for this? >>> >>> From a keystone perspective, some things we'd like to talk about with >>> the BM/VM teams are: >>> >>> - Unified limits[2]: we now have a basic REST API for registering >>> limits in keystone. Next steps are building out libraries that can >>> consume this API and calculate quota usage and limit allocation, and >>> developing models for quotas in project hierarchies. Input from other >>> projects is essential here. >>> - RBAC: we've introduced "system scope"[3] to fix the admin-ness >>> problem, and we'd like to guide other projects through the migration. >>> - Application credentials[4]: this main part of this work is largely >>> done, next steps are implementing better access control for it, which >>> is largely just a keystone team problem but we could also use this >>> time for feedback on the implementation so far >>> >>> There's likely some non-keystone-related things that might be at home >>> in a dedicated BM/VM room too. Do we want to have a dedicated day or >>> two for these projects? Or perhaps not dedicated days, but >>> planned-in-advance meeting time? Or should we wait and schedule it >>> ad-hoc if we feel like we need it? >>> >>> Colleen >>> >>> [1] https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rI >>> zlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25Kji >>> uRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true >>> [2] http://specs.openstack.org/openstack/keystone-specs/specs/ >>> keystone/queens/limits-api.html >>> [3] http://specs.openstack.org/openstack/keystone-specs/specs/ >>> keystone/queens/system-scope.html >>> [4] http://specs.openstack.org/openstack/keystone-specs/specs/ >>> keystone/queens/application-credentials.html >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> These all seem like good topics for big cross-project issues. >> >> I've never liked the "BM/VM" platform naming thing, it seems to imply >> that the only things one needs to care about for these discussions is if >> they work on or use nova and ironic, and that's generally not the case. >> > > ++ can we please rename it? I think people (myself included) will expect > specifically something related to bare metal instances co-existing with > virtual ones (e.g. scheduling or networking concerns). Which is also a > great topic, but it does not seem to be present on the list. Fair point. When the "VM/baremetal workgroup" was originally formed, the goal was more about building clouds with both types of resources, making them behave similarly from a user perspective, etc. Somehow we got into talking applications and these other topics came up, which seemed more interesting/pressing to fix. :) Maybe "cross-project identity integration" or something is a better name? // jim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
On Wed, Jan 31, 2018 at 6:46 PM, Graham Hayes wrote: > On 31/01/18 17:22, Dmitry Tantsur wrote: >> On 01/31/2018 06:15 PM, Matt Riedemann wrote: >>> On 1/30/2018 9:33 AM, Colleen Murphy wrote: [snip] >>> >>> These all seem like good topics for big cross-project issues. >>> >>> I've never liked the "BM/VM" platform naming thing, it seems to imply >>> that the only things one needs to care about for these discussions is >>> if they work on or use nova and ironic, and that's generally not the >>> case. >> >> ++ can we please rename it? I think people (myself included) will expect >> specifically something related to bare metal instances co-existing with >> virtual ones (e.g. scheduling or networking concerns). Which is also a >> great topic, but it does not seem to be present on the list. >> > > Yeah - both of these topic apply to all projects. If we could do > scheduled time for both of these, and then separate time for Ironic / > Nova issues it would be good. > >>> >>> So if you do have a session about this really cross-project >>> platform-specific stuff, can we at least not call it "BM/VM"? Plus, >>> "BM" always makes me think of something I'd rather not see in a room >>> with other people. >>> ++ Sorry, I didn't mean to be exclusive. These topics do apply to most projects, and it did feel awkward writing that email with keystone goals in mind when keystone is in neither category. Colleen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
On 31/01/18 17:22, Dmitry Tantsur wrote: > On 01/31/2018 06:15 PM, Matt Riedemann wrote: >> On 1/30/2018 9:33 AM, Colleen Murphy wrote: >>> At the last PTG we had some time on Monday and Tuesday for >>> cross-project discussions related to baremetal and VM management. We >>> don't currently have that on the schedule for this PTG. There is still >>> some free time available that we can ask for[1]. Should we try to >>> schedule some time for this? >>> >>> From a keystone perspective, some things we'd like to talk about with >>> the BM/VM teams are: >>> >>> - Unified limits[2]: we now have a basic REST API for registering >>> limits in keystone. Next steps are building out libraries that can >>> consume this API and calculate quota usage and limit allocation, and >>> developing models for quotas in project hierarchies. Input from other >>> projects is essential here. >>> - RBAC: we've introduced "system scope"[3] to fix the admin-ness >>> problem, and we'd like to guide other projects through the migration. >>> - Application credentials[4]: this main part of this work is largely >>> done, next steps are implementing better access control for it, which >>> is largely just a keystone team problem but we could also use this >>> time for feedback on the implementation so far >>> >>> There's likely some non-keystone-related things that might be at home >>> in a dedicated BM/VM room too. Do we want to have a dedicated day or >>> two for these projects? Or perhaps not dedicated days, but >>> planned-in-advance meeting time? Or should we wait and schedule it >>> ad-hoc if we feel like we need it? >>> >>> Colleen >>> >>> [1] >>> https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true >>> >>> [2] >>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html >>> >>> [3] >>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html >>> >>> [4] >>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html >>> >>> >>> __ >>> >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> These all seem like good topics for big cross-project issues. >> >> I've never liked the "BM/VM" platform naming thing, it seems to imply >> that the only things one needs to care about for these discussions is >> if they work on or use nova and ironic, and that's generally not the >> case. > > ++ can we please rename it? I think people (myself included) will expect > specifically something related to bare metal instances co-existing with > virtual ones (e.g. scheduling or networking concerns). Which is also a > great topic, but it does not seem to be present on the list. > Yeah - both of these topic apply to all projects. If we could do scheduled time for both of these, and then separate time for Ironic / Nova issues it would be good. >> >> So if you do have a session about this really cross-project >> platform-specific stuff, can we at least not call it "BM/VM"? Plus, >> "BM" always makes me think of something I'd rather not see in a room >> with other people. >> > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
On 01/31/2018 06:15 PM, Matt Riedemann wrote: On 1/30/2018 9:33 AM, Colleen Murphy wrote: At the last PTG we had some time on Monday and Tuesday for cross-project discussions related to baremetal and VM management. We don't currently have that on the schedule for this PTG. There is still some free time available that we can ask for[1]. Should we try to schedule some time for this? From a keystone perspective, some things we'd like to talk about with the BM/VM teams are: - Unified limits[2]: we now have a basic REST API for registering limits in keystone. Next steps are building out libraries that can consume this API and calculate quota usage and limit allocation, and developing models for quotas in project hierarchies. Input from other projects is essential here. - RBAC: we've introduced "system scope"[3] to fix the admin-ness problem, and we'd like to guide other projects through the migration. - Application credentials[4]: this main part of this work is largely done, next steps are implementing better access control for it, which is largely just a keystone team problem but we could also use this time for feedback on the implementation so far There's likely some non-keystone-related things that might be at home in a dedicated BM/VM room too. Do we want to have a dedicated day or two for these projects? Or perhaps not dedicated days, but planned-in-advance meeting time? Or should we wait and schedule it ad-hoc if we feel like we need it? Colleen [1] https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true [2] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html [3] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html [4] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev These all seem like good topics for big cross-project issues. I've never liked the "BM/VM" platform naming thing, it seems to imply that the only things one needs to care about for these discussions is if they work on or use nova and ironic, and that's generally not the case. ++ can we please rename it? I think people (myself included) will expect specifically something related to bare metal instances co-existing with virtual ones (e.g. scheduling or networking concerns). Which is also a great topic, but it does not seem to be present on the list. So if you do have a session about this really cross-project platform-specific stuff, can we at least not call it "BM/VM"? Plus, "BM" always makes me think of something I'd rather not see in a room with other people. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
On 1/30/2018 9:33 AM, Colleen Murphy wrote: At the last PTG we had some time on Monday and Tuesday for cross-project discussions related to baremetal and VM management. We don't currently have that on the schedule for this PTG. There is still some free time available that we can ask for[1]. Should we try to schedule some time for this? From a keystone perspective, some things we'd like to talk about with the BM/VM teams are: - Unified limits[2]: we now have a basic REST API for registering limits in keystone. Next steps are building out libraries that can consume this API and calculate quota usage and limit allocation, and developing models for quotas in project hierarchies. Input from other projects is essential here. - RBAC: we've introduced "system scope"[3] to fix the admin-ness problem, and we'd like to guide other projects through the migration. - Application credentials[4]: this main part of this work is largely done, next steps are implementing better access control for it, which is largely just a keystone team problem but we could also use this time for feedback on the implementation so far There's likely some non-keystone-related things that might be at home in a dedicated BM/VM room too. Do we want to have a dedicated day or two for these projects? Or perhaps not dedicated days, but planned-in-advance meeting time? Or should we wait and schedule it ad-hoc if we feel like we need it? Colleen [1] https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true [2] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html [3] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html [4] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev These all seem like good topics for big cross-project issues. I've never liked the "BM/VM" platform naming thing, it seems to imply that the only things one needs to care about for these discussions is if they work on or use nova and ironic, and that's generally not the case. So if you do have a session about this really cross-project platform-specific stuff, can we at least not call it "BM/VM"? Plus, "BM" always makes me think of something I'd rather not see in a room with other people. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
On 01/30/2018 09:33 AM, Colleen Murphy wrote: > At the last PTG we had some time on Monday and Tuesday for > cross-project discussions related to baremetal and VM management. We > don't currently have that on the schedule for this PTG. There is still > some free time available that we can ask for[1]. Should we try to > schedule some time for this? > > From a keystone perspective, some things we'd like to talk about with > the BM/VM teams are: > > - Unified limits[2]: we now have a basic REST API for registering > limits in keystone. Next steps are building out libraries that can > consume this API and calculate quota usage and limit allocation, and > developing models for quotas in project hierarchies. Input from other > projects is essential here. > - RBAC: we've introduced "system scope"[3] to fix the admin-ness > problem, and we'd like to guide other projects through the migration. > - Application credentials[4]: this main part of this work is largely > done, next steps are implementing better access control for it, which > is largely just a keystone team problem but we could also use this > time for feedback on the implementation so far So, I'm probably biased, but a huge +1 for me. I think the last baremetal/vm session in Denver was really productive and led to most of what we accomplished this release. Who else do we need to get involved in order to get this scheduled? Do we need some more projects to show up (e.g. cinder, nova, neutron)? Tacking on the RBAC stuff, it would be cool to sit down with others and talk about basic roles [0], since we have everything to make that possible. I suppose we could start collecting topics in an etherpad and elaborating on them there. [0] https://review.openstack.org/#/c/523973/ > There's likely some non-keystone-related things that might be at home > in a dedicated BM/VM room too. Do we want to have a dedicated day or > two for these projects? Or perhaps not dedicated days, but > planned-in-advance meeting time? Or should we wait and schedule it > ad-hoc if we feel like we need it? > > Colleen > > [1] > https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true > [2] > http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html > [3] > http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html > [4] > http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
+1 to Jim, I'm specifically interested in app creds and RBAC as I'd like to find a way to pass some of API access creds to the ironic deploy ramdisk, and it seems one of those could help. Let's discuss :) Cheers, On Tue, Jan 30, 2018 at 6:03 PM, Jim Rollenhagen wrote: > On Tue, Jan 30, 2018 at 10:33 AM, Colleen Murphy > wrote: > >> At the last PTG we had some time on Monday and Tuesday for >> cross-project discussions related to baremetal and VM management. We >> don't currently have that on the schedule for this PTG. There is still >> some free time available that we can ask for[1]. Should we try to >> schedule some time for this? >> > > I'd attend for the topics you list below, FWIW. > > >> >> From a keystone perspective, some things we'd like to talk about with >> the BM/VM teams are: >> >> - Unified limits[2]: we now have a basic REST API for registering >> limits in keystone. Next steps are building out libraries that can >> consume this API and calculate quota usage and limit allocation, and >> developing models for quotas in project hierarchies. Input from other >> projects is essential here. >> - RBAC: we've introduced "system scope"[3] to fix the admin-ness >> problem, and we'd like to guide other projects through the migration. >> - Application credentials[4]: this main part of this work is largely >> done, next steps are implementing better access control for it, which >> is largely just a keystone team problem but we could also use this >> time for feedback on the implementation so far >> >> There's likely some non-keystone-related things that might be at home >> in a dedicated BM/VM room too. Do we want to have a dedicated day or >> two for these projects? Or perhaps not dedicated days, but >> planned-in-advance meeting time? Or should we wait and schedule it >> ad-hoc if we feel like we need it? >> > > There's always plenty to discuss between nova and ironic, but we usually > just schedule those topics somewhat ad-hoc. Never opposed to some > dedicated time if folks will show up, though. :) > > // jim > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
On Tue, Jan 30, 2018 at 10:33 AM, Colleen Murphy wrote: > At the last PTG we had some time on Monday and Tuesday for > cross-project discussions related to baremetal and VM management. We > don't currently have that on the schedule for this PTG. There is still > some free time available that we can ask for[1]. Should we try to > schedule some time for this? > I'd attend for the topics you list below, FWIW. > > From a keystone perspective, some things we'd like to talk about with > the BM/VM teams are: > > - Unified limits[2]: we now have a basic REST API for registering > limits in keystone. Next steps are building out libraries that can > consume this API and calculate quota usage and limit allocation, and > developing models for quotas in project hierarchies. Input from other > projects is essential here. > - RBAC: we've introduced "system scope"[3] to fix the admin-ness > problem, and we'd like to guide other projects through the migration. > - Application credentials[4]: this main part of this work is largely > done, next steps are implementing better access control for it, which > is largely just a keystone team problem but we could also use this > time for feedback on the implementation so far > > There's likely some non-keystone-related things that might be at home > in a dedicated BM/VM room too. Do we want to have a dedicated day or > two for these projects? Or perhaps not dedicated days, but > planned-in-advance meeting time? Or should we wait and schedule it > ad-hoc if we feel like we need it? > There's always plenty to discuss between nova and ironic, but we usually just schedule those topics somewhat ad-hoc. Never opposed to some dedicated time if folks will show up, though. :) // jim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?
At the last PTG we had some time on Monday and Tuesday for cross-project discussions related to baremetal and VM management. We don't currently have that on the schedule for this PTG. There is still some free time available that we can ask for[1]. Should we try to schedule some time for this? From a keystone perspective, some things we'd like to talk about with the BM/VM teams are: - Unified limits[2]: we now have a basic REST API for registering limits in keystone. Next steps are building out libraries that can consume this API and calculate quota usage and limit allocation, and developing models for quotas in project hierarchies. Input from other projects is essential here. - RBAC: we've introduced "system scope"[3] to fix the admin-ness problem, and we'd like to guide other projects through the migration. - Application credentials[4]: this main part of this work is largely done, next steps are implementing better access control for it, which is largely just a keystone team problem but we could also use this time for feedback on the implementation so far There's likely some non-keystone-related things that might be at home in a dedicated BM/VM room too. Do we want to have a dedicated day or two for these projects? Or perhaps not dedicated days, but planned-in-advance meeting time? Or should we wait and schedule it ad-hoc if we feel like we need it? Colleen [1] https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true [2] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html [3] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html [4] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
