21:00:44 <dims> #startmeeting crossproject
21:00:45 <openstack> Meeting started Tue Sep  1 21:00:44 2015 UTC and is due to finish in 60 minutes.  The chair is dims. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:48 <openstack> The meeting name has been set to 'crossproject'
21:00:52 <dims> courtesy ping for david-lyle flaper87 dims dtroyer johnthetubaguy rakhmerov
21:00:52 <dims> courtesy ping for smelikyan morganfainberg adrian_otto bswartz slagle
21:00:52 <dims> courtesy ping for adrian_otto mestery kiall jeblair thinrichs j^2 stevebaker
21:00:54 <dims> courtesy ping for mtreinish Daisy Piet notmyname ttx isviridov gordc SlickNik
21:00:56 <dims> courtesy ping for cloudnull loquacities thingee hyakuhei redrobot dirk TravT
21:00:58 <dims> courtesy ping for vipul lifeless annegentle SergeyLukjanov devananda boris-42 nikhil_k
21:00:59 <david-lyle> o/
21:01:00 <dims> courtesy ping for barrett and shamail elmiko etoews jaypipes (See Topics in agenda!)
21:01:01 <stevebaker> \o
21:01:05 <docaedo> o/
21:01:07 <jeblair> dims: i have a thing to say!
21:01:07 <dims> #link Agenda: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
21:01:08 <EmilienM> o/
21:01:09 <notmyname> here
21:01:18 <Piet> Here!
21:01:19 <dims> jeblair: go ahead
21:01:21 <j^2> Hi!
21:01:22 <philipw> Here
21:01:24 <vipul> o/
21:01:31 <lifeless> o/
21:01:32 <jeblair> #link stackforge move scheduled for october 17: http://lists.openstack.org/pipermail/openstack-dev/2015-August/073071.html
21:01:35 <edleafe> o/
21:01:35 <jroll> \o
21:01:45 <barrett1> o?
21:01:47 <jeblair> just wanted to get the message out there ^
21:01:47 <mtreinish> o/
21:01:48 <barrett1> o/
21:01:50 <dims> thanks jeblair for the announcement
21:01:55 <Rockyg> o/
21:02:04 <elmiko> o/
21:02:08 <dims> #topic review past actions
21:02:20 <dims> we had a couple of things left over
21:02:21 <Rockyg> jeblair, ++
21:02:23 <dims> #info Meeting Chairs still needed for October 13
21:02:23 <dims> #info ttx to create a summit session about crossproject discussion & meetings
21:02:29 <dims> Anyone up for Oct 13?
21:02:33 <ttx> I'll push that when we start working on it
21:02:38 <dims> thanks ttx
21:02:46 <dims> going once
21:02:54 <ttx> so no point in tracking that week after week :)
21:02:56 <EmilienM> dims: I can
21:02:58 <gordc> o/
21:03:02 <dims> EmilienM: nice thanks
21:03:07 <EmilienM> no gordc !!
21:03:09 <dims> ttx ack, will stop tracking that
21:03:10 <EmilienM> :P
21:03:14 <dims> #topic Team announcements (horizontal, vertical, diagonal)
21:03:19 <ttx> On the release management front...
21:03:24 <ttx> We are on liberty-3 week, where we'll tag .0b3 versions for cycle-with-milestones projects
21:03:26 <EmilienM> gordc: you can do it this time, please I think I'm traveling
21:03:28 <gordc> EmilienM: naw you can have it.
21:03:35 <ttx> For those projects that marks the start of a feature-frozen period while they work toward their first release candidate
21:03:39 <gordc> i was actually just raising hand for meeting
21:03:44 * gordc reads backlog
21:03:46 <ttx> When the flow of bugfixes starts to slow down we can create the release branch (stable/liberty) and unfreeze master
21:03:51 <ttx> That usually takes a couple of weeks
21:04:05 <ttx> This week we'll also tag the last "liberty" versions for libraries, so that we can cut stable branches there early next week
21:04:23 <ttx> So if you have, say, python-${PROJECT}client updates or features that need to go in liberty, you probably want to get them released ASAP
21:04:31 <dims> ttx, i need to merge g-r updates for some oslo libs
21:04:39 <ttx> We'll soft-freeze requirements starting end of week, and until all release branches are cut
21:04:45 <ttx> (we branch openstack/requirements last)
21:04:47 <ttx> Questions on that ?
21:05:06 <jroll> ironic (finally) made a 4.0.0 release this past week, we're fast following with a 4.1.0 to clear up some issues and will have an announcement then. 4.2.0 will be stable/liberty. planning on more frequent releases in M :)
21:05:09 <nikhil_k> TravT: ^
21:05:23 <nikhil_k> (about py-glanceclient)
21:05:24 <fungi> with clarkb's cross-test jobs for master requirements in place, we should presumably continue as usual approving constraints updates correct?
21:05:25 <dims> thanks jroll
21:05:32 <TravT> nikhil_k, thx
21:05:46 <fungi> just not approving updates to global-requirements.txt
21:05:47 <EmilienM> puppet team have midcycle starting tomorrow
21:05:50 <ttx> fungi: we should apply extra care. That's why I said softfreeze
21:05:55 <fungi> got it
21:05:59 <EmilienM> #link puppet openstack midcycle: https://etherpad.openstack.org/p/puppet-liberty-mid-cycle
21:06:07 <ttx> fungi: adding new deps still puts pressure on downstream packagers
21:06:15 <lifeless> dims: but not caps
21:06:16 <ttx> so we want to slow down progressively there too
21:06:27 <dims> lifeless: ack
21:06:28 <lifeless> ttx: dims: dhellmann: just to make sure we're on the same page: we're not capping liberty
21:06:38 <ttx> lifeless: right
21:06:44 <dims> lifeless: we use the upper-constraints, ack
21:06:46 <dhellmann> lifeless: ++
21:06:51 <lifeless> we'll use constraints to hold devstack and unit tests in line. cool
21:06:52 <EmilienM> ok it's not a midcycle, it's a sprint :-)
21:06:59 <ttx> I think dims just wants the requirements to propagate
21:07:11 <dhellmann> right, we should make sure all of our mins are up to date
21:07:11 <dims> ttx: yes
21:07:20 <fungi> and allow upper-constraints to continue getting updated, on the assumption that testing should catch serious issues with them
21:07:40 <dhellmann> lifeless: how far away are we from having constraints for unit test jobs?
21:07:50 <ttx> lifeless: I like how the netaddr  issue last week perfectly illustrates the need to cover unit tests with constraints as well.
21:07:51 <lifeless> dhellmann: the nova patches are just waiting +2A
21:07:57 <lifeless> https://review.openstack.org/#/c/207262/
21:08:02 <lifeless> https://review.openstack.org/#/c/205931/
21:08:40 <dhellmann> is that the first project to use them?
21:08:57 <fungi> also there was some interest expressed in the netaddr thread for neutron being a guinea pig on this
21:09:48 <dims> fungi: looks easy for someone to duplicate those 2 reviews for neutron
21:09:52 <lifeless> fungi: sure, I'm positive we can adda  patch for neutron in just a few minutes
21:09:55 <fungi> (though it's still not going to help grenade issues where a new dep release blows up kilo)
21:10:01 <dims> right
21:10:22 <lifeless> fungi: it will help
21:10:27 <lifeless> fungi: less places to stop the fire
21:10:35 <lifeless> fungi: it won't eliminate
21:10:56 <dims> #action dims to ping some nova cores about https://review.openstack.org/#/c/205931/
21:11:09 <dims> any other announcements?
21:11:16 <dims> going once
21:11:19 <dims> switching
21:11:21 <lifeless> we're going to want a version of that patch in all tres
21:11:22 <dims> #topic Product Work Group: User Stories Update/Checkpoint
21:11:22 <dims> This topic was raised by barrett and shamail
21:11:24 <lifeless> in lberty
21:11:40 <dims> barrett1: Shamail: ping
21:11:42 <dims> lifeless: ack
21:11:44 <barrett1> Hi Carol Barrett
21:11:52 <Shamail> hi
21:12:05 <barrett1> Thanks for the time on the agenda
21:12:16 <dims> very welcome, floor is yours
21:12:40 <barrett1> We wanted to give you an update on the user story work from the team
21:12:48 <barrett1> You can find our repo here: http://specs.openstack.org/openstack/openstack-user-stories
21:12:58 <dims> #link http://specs.openstack.org/openstack/openstack-user-stories
21:13:06 <barrett1> You may find the generated specs page for easier consumption of user stories going forward; Click on any title in the Draft Section. This page will be updated further to contain more information/data over time.
21:13:07 <Shamail> dims: thanks
21:13:52 <barrett1> We had a long list of stories and reviewed them to consolidate like-kind and then prioritize
21:14:09 <barrett1> Here's the list of current user stories, prioritized:
21:14:32 <barrett1> Rolling Upgrades: Building upon the work done in Kilo & Liberty
21:14:44 <barrett1> Headroom & Capacity Management (including quotas): Focus on the management of capacity so that resource exhaustion is minimized.
21:15:01 <barrett1> Life Cycle Managment (DB, VM, Storage): The usage examples in this user story focus on the creation, management and clean-up (ex. VM becomes orphaned, storage created but never attached, etc)
21:15:16 <barrett1> On Boarding Legacy Applications: Support for basic on-boarding of legacy apps. We expect many of these capabilities to benefit cloud apps too.
21:15:27 <Shamail> It is probably also worth mentioning that the Product WG is working on a method to priori
21:15:35 <barrett1> OpenStack Service Separation: Enable OpenStack services to use different libary versions, while running simultaneously
21:15:49 <barrett1> OpenStack simplifiled API: Address the by product of shift from Nova Networking to Neutron of a number of simple use cases require the user to issue a relatively large number of API calls to Nova, Neutron, and possibly other services.
21:16:06 <barrett1> Role Based Access: Hierarchical permissions to support Enterprise IT requirements.
21:16:33 <barrett1> Encrypted Storage: Ability for a workload to require encyrpted storage for its execution and boot from encrypted storage too
21:16:40 <barrett1> That's the end of the list
21:16:46 <gordc> barrett1: are these tagged by projects they affect?
21:16:47 <dims> barrett1: i was half expecting a list of projects for each of those items so we can get feedback from cores/ptl Or are you doing that already (feedback from projects)?
21:17:04 <dims> gordc: ha, same question :)
21:17:13 <barrett1> gordonc: the next step is gaps analysis which will create this.
21:17:28 <gordc> dims: :)
21:17:48 <clarkb> service separation is already possible with virtualenvs and other packaging tools, not sure what openstack needs to do
21:17:58 <gordc> barrett1: cool cool. yeah it seems most of them affect nova... /me says thanks.
21:18:06 <kfox1111> barrett1: I'm working on the nova instance user spec, and it kind of seems like it might fit in the user-stories...
21:18:16 <barrett1> clarkb: thanks will pass this along to the team behind this one.
21:18:17 <Rockyg> prod wg is putting cpls in place to help get the info needed from projects
21:18:30 <Shamail> Sorry... What I was trying to say: It is probably also worth mentioning that the Product WG is working on a method to prioritize user stories via gerrit but we wanted to share our prioritized list with the cross project team during the pilot to ensure the user stories that we selected would align with this team for now.
21:18:48 <Shamail> This feedback is highly valuable to the team.
21:19:01 <Shamail> Thanks.
21:19:12 <Rockyg> Shamail, ++
21:19:39 <barrett1> Kfox1111: Which use story do you think is closest fit? I'll connect you with the team.
21:19:44 <ttx> barrett1: thos generally sound like private cloud / enterprise use cases more than massive public cloud use cases. Is that on purpose ?
21:20:08 <Rockyg> clarkb, Yeah, some of these projects might just be docs and focused testing of docs and capabilities
21:20:15 <kfox1111> barrett1: its kind of its own story. https://review.openstack.org/#/c/186617/
21:20:19 <barrett1> ttx: They are a mix of Enterprise, Telco and CSPs
21:20:30 <Shamail> barrett1: ++
21:20:32 <barrett1> There's a lot of cross over for these basic things
21:20:41 <ttx> barrett1: ack
21:21:01 <ttx> agree that rolling upgrades is just good for everyone
21:21:02 <jroll> ttx: I'd bet that private cloud folks are just the majority of users and/or users with large feature requests, though I see a few that apply to rackspace for inastance
21:21:04 <dims> barrett1: Shamail: I've seen a lot of Pets related blueprints/reviews rejected by some projects. what's the plan for evangelization? why would it be different this time?
21:21:07 <kfox1111> Probably lifecycle or lagacy Apps.
21:21:11 <Rockyg> ttx, also, most of these apply to publice clouds for scaling needs
21:21:19 <barrett1> kfox1111: Will look it over. We also have a backlog of stories to be written
21:21:25 <Shamail> ttx: I'm glad that you mentioned that.  Geoff and Rockyg are working to start a CSP (public cloud) user group since one does not formally exist yet.
21:21:27 <jroll> ttx: upgrades, capacity management, simple API
21:21:28 <kfox1111> barrett1: Thanks.
21:21:43 <ttx> Shamail: great!
21:22:16 <barrett1> What do you all think of the priority of these stories? Based upon the limited info I gave....
21:22:53 <jroll> barrett1: IMO they're all good things to do
21:22:58 <Shamail> dims: I think one of the differences would be to include developers as a part of the gap analysis process and also working with our teams to make sure that we have people willing to execute versus just "suggest" and leaving the teams trying to prioritize with existing resources
21:23:05 <barrett1> jroll: +1
21:23:25 <jroll> idk about priority, that's going to vary wildly by person I think :)
21:23:37 <dims> Shamail: some of them is not a matter of resources, but philosophy (Pets specifically)
21:23:39 <ttx> barrett1: some of them need to be individually implemented (think: rolling upgrades) while some others can be driven from a central location (think: containerized deployment -> Kolla)
21:23:42 <Shamail> jroll: +1... The simple API resonates will with me :)
21:23:44 <kfox1111> with my op hat on, quotas and rolling updates are our biggest needs.
21:23:51 <ttx> barrett1: the latter will probalby happen faster
21:23:54 <jroll> rolling upgrades as #1 is a huge +1 from me though, I've been doing rolling upgrades downstream with ironic and it makes life so awesome
21:24:18 <Shamail> dims: +1, I want to have the conversation because I do agree that philosophy plays a role in prior rejections as well.
21:24:22 <dims> y that one is a no brainer in my book
21:24:29 <barrett1> ttx: We took a preliminary swag at which projects were inolved in each user story. All of them involved several...if not all.
21:24:33 <dims> (rolling upgrades)
21:24:36 <dims> thanks Shamail
21:25:05 <barrett1> ttx: We've heard that where the PWG can add value is in cross-project and cross-release, so we prioritied those user stories higher
21:25:06 <docaedo> I wonder if the story about "service separation and different library versions" is really about rolling upgrades? less so different library versions, more different service versions?
21:25:43 <Rockyg> I think they are certainly related
21:25:58 <kfox1111> docaedo: yeah. thats a good way of putting it.
21:26:03 <ttx> barrett1: FWIW I'm pushing for some refactoring in summit conference tracks that would explicitly make room for a "upstream dev" track where presenting those would directly reach developers and pass a message
21:26:15 <gordc> barrett1: for the items that cover all projects, how do we avoid the 'one size fits all' approach... ie it seems like rolling upgrades solutions are being copy/pasted everywhere but not necessarily optimised for each project.
21:26:17 <dims> ttx: +1
21:26:20 <Shamail> So does the list of prioritized user stories (out of the many user stories that were mentioned) make sense?  We wanted to ensure that we didn't relegate anything that this team feels is important to the back-burner during our pilot.
21:26:23 <ttx> currently we have no good forum for a formal presentation of those
21:26:29 <barrett1> docaedo: I think you're probably right - more about upgrades. If Kolla is used then it's easy, if not....
21:26:43 <kfox1111> though I guess they are slightly different in one way. Rolling upgrades may need service seperation, but we may want to run different versioned services for long periods of time, outside of a rolling upgrade.
21:26:53 <Shamail> ttx: ++
21:27:17 <jroll> right, I think "not deploying identical versions of each service" is a useful thing (I know it is, we do it)
21:27:20 <Rockyg> kfox1111, ++
21:27:46 <Shamail> We want to be respective of time and make sure that we reach a list of next steps while allowing time for other items in today's agenda.
21:27:49 <barrett1> docaedo: Sorry, VersionedObjects will address the service issues. Service/Library separation is about system library dependencies
21:28:20 <jroll> ok, I think service separation is a solved problem with virtualenvs etc like clarkb said
21:28:25 <docaedo> barrett1: yep, version all the things is the answer to making different service versions work happily (easing the upgrade story)
21:28:28 <jroll> anyway, this looks like a great start IMO
21:28:30 <Rockyg> and gordc, yeah.  Rolling upgrades need to fit each project.  Some may work the same, but....Horizon encompasses all projects so it will be harder
21:28:32 <barrett1> ttx +1; will keep a eye out for this
21:29:01 <barrett1> jroll +1
21:29:34 <dims> barrett1: Shamail: call it time on this topic?
21:29:40 <gordc> Rockyg: agreed. i guess the concern i had was it seems right now it's not really optimised to fit the projects design... they're just a generic solution that may work (but not optimally)
21:29:41 <Rockyg> ttx, when you have more solid info/design, come to a prod_wg meeting to discuss...
21:29:56 <barrett1> Dims: Want to cover next steps if we have time
21:29:59 <dims> sure
21:30:16 <barrett1> High-level of next steps: User Stories updated with MC comments and posted in Report, User story team creation, gap analysis complete for pre-design summit project discussions, CPLs starting to join team meetings, etc.
21:30:30 <barrett1> A timeline view will be posted on our wiki by next week
21:30:39 <dims> barrett1: link please
21:31:04 <Shamail> We would like to share the link for the time-line with this team.  Can we use the ML to share?
21:31:14 <Shamail> It has not been created yet.
21:31:17 <dims> Shamail: +1
21:31:23 <Shamail> Thanks.
21:31:33 <Shamail> We will update the team as soon as possible.
21:31:39 <Rockyg> product team wiki page: https://wiki.openstack.org/wiki/ProductTeam
21:31:46 <barrett1> Any next steps related to cross-project team that you want us to include?
21:31:50 <dims> Thanks Rockyg
21:31:54 <Rockyg> the link will be there...
21:32:09 <Shamail> Rockyg: thanks!  Good point.
21:32:59 <dims> ok switching to another topic
21:33:05 <dims> #topic API WG recommendations - Heads up
21:33:06 <dims> This topic was raised to highlight these guidelines for the Cross Project Liaisons - courtesy of  elmiko, etoews, jaypipes
21:33:14 <Shamail> I think we can move on with the action that we will share the link and people will let us know if they disagree with the current "prioritized" user story list.
21:33:15 <dims> #link https://review.openstack.org/#/c/190743/ - Add description of pagination parameters
21:33:15 <dims> #link https://review.openstack.org/#/c/215683/ - Require "OpenStack-" in headers
21:33:15 <dims> #link https://review.openstack.org/#/c/208264/ - Add the condition for using a project term
21:33:15 <barrett1> Ok - Sounds like are priorities are OK for now, we'll send out the timeline link later this week and keep an eye out for more news from ttx/
21:33:17 <dims> #link https://review.openstack.org/#/c/185288/ - Added note about caching of responses when using https
21:33:19 <dims> #link https://review.openstack.org/#/c/183456/ - Add section describing 501 common mistake
21:33:45 <dims> #action shamail barrett1 to share the link and people will let us know if they disagree with the current "prioritized" user story list.
21:33:55 <dims> thanks Shamail barrett1
21:33:59 <Rockyg> Uh, do we need a cross project session to see what, if any dependencies exist between projects to accomplish rolling upgrades for each?  Generate a state table or some such?
21:34:04 <Shamail> Thanks everyone.
21:34:19 <barrett1> Thanks all!
21:34:21 <Rockyg> Oops.  Got that in late.
21:34:45 <dims> Rockyg: ttx mentioned some time at summit for this
21:34:49 <barrett1> RockyG: Let's talk in team meeting and come with a proposal
21:34:56 <dims> barrett1: ++
21:35:07 <dims> jaypipes: elmiko: etoews: ping
21:35:10 <Shamail> barrett1: ++
21:35:32 <elmiko> dims: thanks for posting the links
21:35:32 <Rockyg> Yup.
21:35:45 <dims> elmiko: any commentary to go along with the links? :)
21:35:48 <elmiko> not much to discuss, some of these have been reworked and are up again
21:35:56 <elmiko> a few are new
21:36:18 <elmiko> i think the most controversial might be the header naming
21:36:25 <elmiko> or at least, it was
21:36:55 <dims> elmiko: so brickbats and kudos on the reviews?
21:37:07 <elmiko> oh, and the 501 seems to be a hot topic ;)
21:37:13 <bknudson> get ready to start using OpenStack-Identity-Token rather than X-Auth-Token
21:37:14 <elmiko> lol, something like that dims
21:37:29 <dims> :)
21:37:39 <notmyname> surely we wouldn't break the client ecosystem like that ;-)
21:37:56 * dims whispers micro versions
21:37:58 <elmiko> i think bknudson is having some fun ;)
21:38:17 <edleafe> elmiko: hehehe
21:38:36 <elmiko> dims: we do have a microversion spec underway , but its still being worked on
21:39:01 <dims> elmiko: ah thanks
21:39:31 <dims> any other feedback to elmiko?
21:39:31 <elmiko> for the curious , https://review.openstack.org/187112
21:39:39 <elmiko> nope, that's all from me
21:39:52 <dims> ah thanks
21:40:03 <dims> ok, let's open it up
21:40:04 <dims> #topic Open discussion
21:40:13 <tpatil> Request everyone to please review 'Return request ID to caller' specs
21:40:22 <tpatil> #link: https://review.openstack.org/#/c/156508
21:40:24 <notmyname> missed it earlier.. Swift 2.4.0 was released today
21:40:26 <notmyname> #link http://lists.openstack.org/pipermail/openstack-announce/2015-September/000575.html
21:40:30 <dims> tpatil: thanks
21:40:33 <kfox1111> ok. so, back on the nova instance user topic...
21:40:38 <kfox1111> #link https://review.openstack.org/#/c/186617/
21:40:41 <dims> notmyname: sweet
21:40:47 <kfox1111> Its sounding like it needs to be moved to a cross project spec?
21:40:57 <tpatil> dims: Thanks
21:41:16 <kfox1111> we're also finding it hard to pin down which parts of the functionality belong to which project.
21:41:25 <kfox1111> Any suggestions for making progress?
21:41:38 <dims> kfox1111: reading
21:41:42 <kfox1111> Thx.
21:42:14 <philipw> dims: at the mid-cycle kencjohn_ voluntered me (with permission :-) ) for the swift cpl...  just wanted to say hi!
21:42:24 <Shamail> Will this team have a design summit session in Tokyo?
21:42:32 <dims> philipw: ah nice, welcome
21:42:39 <philipw> thnx
21:43:05 <notmyname> philipw: I look forward to talking with you. please let me know if you have any questions. also, feel free to lurk in #openstack-swift
21:43:13 <jroll> Shamail: yes
21:43:20 <jroll> (iirc)
21:43:29 <philipw> notmyname: excellent, likewise
21:43:32 <dims> kfox1111: i'd rope in a couple of keystone cores to that nova spec and ask what they think
21:43:39 <Rockyg> jroll, you mean cross project -- yes
21:43:57 <Rockyg> Shamail, I'll report at the prod wg with links
21:44:07 <Shamail> thanks jroll: I look forward to meeting a lot of you in-person!
21:44:12 <kfox1111> dims: the keystone and barbican ptl's are on board.
21:44:14 <Shamail> Thanks Rockyg
21:44:16 <dims> kfox1111: some of this could be in a middlware, may be some oslo work
21:44:53 <Rockyg> kfox1111, this sounds a lot like the beginnings of user API for various needs cross project
21:45:12 <kfox1111> yeah. its very cross project. :/
21:45:24 <kfox1111> magnum's talking about implementing an alternative right now, sicne it doesnt' exist. :/
21:45:28 <kfox1111> and they need something quickly.
21:45:59 <dims> kfox1111: i don't see them commenting on the review
21:46:01 <Rockyg> This will also be crucial for nested tenants
21:46:06 <kfox1111> sahara, trove and heat all do similar other things now, but don't share any implementation. :/
21:46:20 <dims> kfox1111: +1 to start a cross project spec and an email thread then
21:46:33 <kfox1111> k.
21:46:36 <Shamail> dims: ++
21:47:37 <Rockyg> kfox1111, on the ml thread, put *all* applicable projects and API
21:47:53 <kfox1111> I think thats basically everyone?
21:47:58 <elmiko> kfox1111: i've been following the instance user spec and really need to comment. we are also going to discuss it a little at the security mid-cycle
21:48:09 <Rockyg> Yeah, so just "ALL" should do ;-)
21:48:14 <kfox1111> k.
21:48:34 <Rockyg> but still, API as I bet that's what this comes down to -  user apis
21:48:56 <kfox1111> elmiko: cool.
21:49:15 <kfox1111> would be nice to reserve some time at the Tokyo summit for it too.
21:49:21 <Shamail> I would try to get DefCore support too since this topic will impact their work too.
21:49:31 <kfox1111> Its really affecting a large number of projects by not having it.
21:49:41 <elmiko> kfox1111: +1
21:49:48 <kfox1111> app-catalog too.
21:50:02 <kfox1111> its really hard to write secure, generic apps for the catalog without it. :/
21:50:15 <kfox1111> DefCore, good idea.
21:51:04 <Rockyg> Added the spec as is to xproject etherpad for summit
21:51:14 <kfox1111> perfect. thanks.
21:51:25 <dims> kfox1111: looks like you have some fans now :)
21:51:41 <kfox1111> thanks. :)
21:52:00 <dims> Does anyone else have any other topics to discuss?
21:52:16 <dims> going once
21:52:26 <dims> going twice
21:52:30 <dims> Thanks a ton everyone
21:52:32 <EmilienM> thanks dims!
21:52:39 <edleafe> thanks dims!
21:52:42 <dims> EmilienM: thanks for your guidance!
21:52:43 <Rockyg> Thanks!
21:52:49 <dims> #endmeeting