18:00:48 <heckj> #startmeeting keystone
18:00:48 <openstack> Meeting started Tue Feb  5 18:00:48 2013 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:48 <dolphm> yay!
18:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:51 <henrynash> and is!
18:00:52 <openstack> The meeting name has been set to 'keystone'
18:00:57 <heckj> Whassup dolph?
18:01:14 <dolphm> heckj: not much, belatd welcome back
18:01:16 <dolphm> belated*
18:01:27 <heckj> heh - closer to surface now - it's not dark anymore :-)
18:01:29 <joesavak> bleated?
18:01:41 <heckj> dolphm: missed out on last week's keystone meeting
18:02:09 <ayoung> #link http://wiki.openstack.org/Meetings/KeystoneMeeting
18:02:15 <heckj> Okay - looking over the agenda
18:02:31 <ayoung> I see we haven;t updated since last week
18:02:40 <heckj> BTW: I've got to keep things short on my side today - will get heavily distracted in about 30 minutes as I'm trying to run two meetings at once
18:03:17 <heckj> #topic Hot, Burning Issues of Love?
18:03:21 <topol> I have friends who play online poker and play 10 tables simultaneously. You can handle 2 meetings
18:03:41 <ayoung> topol, they play with their money, not with mine
18:03:52 <heckj> anything in the frying pan this week?
18:03:58 <heckj> critical reviews pending, etc?
18:04:08 <ayoung> gyee's work on V3 Token is probably most critical
18:04:13 <henrynash> heckj: so we need the auth review done
18:04:20 <henrynash> ayoung: +1
18:04:20 <gyee> you guys OK with the spec now?
18:04:37 <henrynash> gyee: you saw my comment on the unstopped token bit…..
18:04:51 <ayoung> henrynash, can you link
18:05:24 <gyee> henrynash, I am still uncomfortable with the concept of private namespace
18:05:35 <joesavak> +1 gyee
18:05:40 <gyee> still get wrap my head around on how does it work in conjunction with public namespaces?
18:05:45 <heckj> dolphm: I think most of the holdout last week was related to commentary related to multifactor and token structures, which I think mostly got resolved with a general agreement to leave it open and assert extra keys should be ignored. This jive with you?
18:05:47 <gyee> still can't
18:05:52 <henrynash> https://review.openstack.org/#/c/20524/15/openstack-identity-api/src/markdown/identity-api-v3.md
18:05:56 <dolphm> seeing the impact of private namespaces on openstackclient makes me sad
18:06:03 <ayoung> heckj, it jives with me
18:06:16 <henrynash> dolphm: ?
18:06:24 <stevemar> me too
18:06:28 <gyee> I think we need more impact on the private namespace
18:06:33 <gyee> impact study
18:06:51 <ayoung> can private namespaces be implemented later, or do they need to be designed in up front>
18:06:52 <ayoung> ?
18:06:52 <gyee> I still think we either going to have namspace for all or nothing
18:07:03 <henrynash> gyee: I guess my concerns is we had this debate, approved the blueprint
18:07:05 <dolphm> heckj: sure
18:07:34 <gyee> I am OK with namespace, just not *private* namespace
18:07:50 <dolphm> tbh, when i +2'd the spec, i didn't expect it to merge so fast -- i was just happy with the way it was written... i probably should have +1'd
18:07:53 <henrynash> gyee: there is very little code change that that would cause…..but of course it would be a hard on/off
18:08:06 <dolphm> if it's a feature we can't fully deliver in the next 10 days, we need to cut it from the spec, and put it back for v3.1
18:08:14 <heckj> gyee or henrynash: can one of you summarize how namespace is impacting the spec and the choice that needs to be made there?
18:08:20 <henrynash> dolphm:: we can definitely deliver it
18:08:43 <henrynash> heckj:  There are two spec changes:
18:09:08 <gyee> I am half way there with the auth impl
18:09:13 <henrynash> 1) Specifiy domain in auth when usernaem is specified
18:09:24 <gyee> tooks 2 days, at this way, I should have a wip review in the next 2 days :)
18:09:33 <dolphm> discussion on impact to openstackclient: https://review.openstack.org/#/c/20854/4/openstackclient/identity/v3/credential.py
18:10:11 <henrynash> …as well as domain alongside for project scope/default  to ensure these are unique….all in auth or scoping
18:11:40 <henrynash> dolphm: do you think there is an issue there  in terms of adding the filtering?
18:11:55 <gyee> the idea that we have to retrieve the user's domain in order to figure out the namespace is not very performance friendly
18:12:09 <dolphm> henrynash: adding ?domain_id= to GET /users and GET /projects?
18:12:20 <henrynash> dolphm: yes
18:12:25 <dolphm> henrynash: not at all
18:13:03 <henrynash> gyee: sure. but we do this how often?
18:14:07 <gyee> henrynash, can you update the doc on how does private domain work in conjunction with public domain?
18:14:26 <henrynash> gyee: you mean 'default' domain?
18:14:54 <gyee> not just default
18:15:32 <henrynash> gyee: not quite with you….what do you mean by public domain?  Any domain, not private?
18:15:34 <gyee> say I have user jdoe in default/public domain, and I want to create a user jdoe in a private domain XYZ
18:15:41 <joesavak> so, private domain = private namespace, allows usernames to be unique for that domain instead system wide. If not used, then users get a default (public) domain and domain isn't required for authN?
18:15:42 <gyee> how does that work?
18:16:04 <henrynash> joesavak: yes
18:16:04 <gyee> and how does it impact other OS services?
18:16:32 <joesavak> i like the flexibility
18:16:57 <dolphm> gyee: dashboard is the (only?) impact i'm aware of -- users in a privately namespaced domain can't login
18:17:08 <henrynash> gyee: so the only real potential is swift, and looking at the with auth code, there might actually be no changes (still being checked - if there are they are minor)
18:17:19 <henrynash> swift containers seem fine
18:17:50 <henrynash> swift ACL has legacy code that checks tenantID as well as useranme, so that *might* can no changes….
18:17:54 <joesavak> dashboard will need to do something like <domainid>.horizon.com and send in domain id with the user/pass for authN if configured in the OS deployment
18:18:07 <henrynash> joesavak: yes
18:18:15 <dwchadwick> can anyone give the rationale for why user names and project names can be locally defined in a domain but role names cannot be. Seems illogical to me
18:19:05 <henrynash> dwchadwick: it is a artefact that today the role names are shared identifiers between all services and keystone
18:19:06 <dolphm> dwchadwick: we need to have domain-specific policy first
18:19:10 <ayoung> dwchadwick, as of now, policy is specificied at a service level,  so private roles would be meaningless
18:20:10 <joesavak> we need policies tied to explicit capabilities to enable private roles.
18:20:48 <dwchadwick> but if you have service wide policy, how can that work with domain specific user names and not with domain specific role names
18:21:01 <heckj> gyee: reading through this, there's some impact on other services for a private domain concept with V3 auth impl (not suprising), and the argument against so far that I've caught is that it's not performant, and we'll need to be clear about expectations for interop when using and not using domains. Does that summarize your concerns?
18:21:05 <henrynash> gyee: I understand the desire to have  a hard switch on namespace….but since there wold be very little code change that this saves, I think the flexibility we get from the current spec, outweighs any gain
18:21:21 <dolphm> dwchadwick: policy files have no concern for user names
18:21:42 <gyee> heckj, that sounds right
18:21:47 <heckj> dwchadwick: let's keep this to one topic at a time please - fine to bring that up later, but let's sort out the current spec disagreement
18:21:53 <ayoung> policy does not care about user names.  Policy as it is currently makes decisions based on roles and tenants.
18:22:18 <henrynash> heck, gyee: I'm not sure about the performant bit…this is for auth when we need to do the look up, not  each token check?
18:22:19 <gyee> later when we give it a full go on namespace, then what's the advantage of private domain?
18:22:22 <dolphm> henrynash: it's the client-side code impact that seems much larger
18:22:32 <dwchadwick> but tenants (now projects) can be domain specific
18:23:01 <ayoung> can someone please define (or link to a definition of) a private namespace?
18:23:34 <gyee> problem with private domain, is that from now on, given a name, I have to do a looking on the domain
18:23:44 <gyee> lookup
18:23:50 <heckj> joesavak relayed this earlier, which I thought covered it: so, private domain = private namespace, allows usernames to be unique for that domain instead system wide. If not used, then users get a default (public) domain and domain isn't required for authN?
18:23:50 <henrynash> ayoung: so the spec is probably the best: https://review.openstack.org/#/c/18805/
18:23:56 <dolphm> ayoung: you approved the review lol
18:23:59 <dwchadwick> unless the domain name is always provided, or in its absence you can assume default
18:24:13 <dwchadwick> then all names can be local to the domain
18:24:29 <henrynash> heckj: yep, it's really that simple":  names are private to that domain or they are not
18:24:48 <ayoung> dolphm, yeah, but I think that it might mean differently from I origianlly interpreted it
18:24:52 <gyee> its not just default domain
18:25:08 <gyee> say if I have 3 public domains and 1 private domain
18:25:27 <ayoung> #link https://docs.google.com/document/d/1c6Tvr_zRMOP2mJCQN9lrfJjxGaXAExXiFlwMDvmXbl4/edit
18:25:29 <gyee> name is globally unique across all the public domains
18:25:38 <henrynash> gyee: so today, names are global across all domains
18:25:39 <gyee> this is confusing just to describe it
18:26:05 <dolphm> i'm lost on how the default domain has any impact on public/private namespacing?
18:26:23 <dwchadwick> Its not confusing if you get a nice description written up somewhere
18:26:43 <gyee> dolphm, for a given name, I don't know if its globally unique till I lookup its domain
18:26:44 <henrynash> gyee: that stays true expect for and names that are in a domain that was created with the "private" flag set….in which cases those names are in their own private name sapce
18:26:47 <joesavak> think of public domain as a single default domain (only one can exist) and it is basically the absence of a private domain
18:26:48 <henrynash> gyee: well, that's how it is today!
18:27:09 <ayoung> OK...so a "private" namespace is a namespace.  THe private does not imply privacy concerns, but rather a way to divide uniqueness between two realms, so usernames and tenant names can be reused, correct?
18:27:12 <dolphm> 1) user names share a single namespace across all publicly namespaced domains, 2) project names share a single namespace across all publicly namespaced domains, 3) user names have their own namespace within a privately namespaced domain, 4) project names have their own namespace within a privately namespaced domain
18:27:19 <heckj> henrynash, gyee: I'm missing the distinction between public and private domains - hven't seen an identifier to assert which it is. I've been under the impression that if there *is* a domain at all, it's a "private" domain in the curren conversation. Is there a disinction there I'm missing
18:27:43 <dolphm> ayoung: yes
18:28:15 <dwchadwick> when you create a domain there is a public/private flag
18:28:26 <dolphm> ayoung: meaning that a username or project name without a domain for context *may* be ambiguous, but you're forced to check for it in the public namespace because you don't know which private namespace to look in
18:28:28 <heckj> dwchadwick: ah, thank you - missed that.
18:28:29 <henrynash> heckj: on domain create, you can specify pivate_user_names and/or private_project _names true/false
18:28:49 <henrynash> heckj: default is false - i.e the current situation
18:29:05 <dwchadwick> and you should also be able to specify public/private role names as well ;-)
18:29:22 <henrynash> dwchadwick: another battle, not this one :-)
18:29:41 <Haneef> Can't we simply make names scoped to domain?
18:29:44 <heckj> heh, just can't keep a good academic down, can you
18:29:47 <stevemar> dwchadwick: i agree
18:30:14 <dwchadwick> its all part of the same battle. Having a clean model that is consistent and understandable rather than adhoc
18:30:25 <gyee> what battle? :)
18:30:37 <gyee> see how confusing this thing is?
18:30:45 <dwchadwick> the battle over the v3 API ;-)
18:30:46 <dolphm> dwchadwick: unfortunately we don't start with a blank slate for every release
18:31:14 <gyee> we either going to have namspace or we don't, much easier to understand
18:31:14 <joesavak> haneef - i think the way henrynash did it allows for an easier transition from v2 to v3. As discussed earlier there are ripple effects when domainId is required for authN in addition to user/pass. If v3 impl provided an easy way to transition from user-unique across all domains to user-unique to a domain it will help adoption
18:31:21 <heckj> henrynash, gyee - frankly, the distinction seems needlessly complex and simply a means of enabling a break in the uniqeness rules that we currently are living under. I think (maybe this is what gyee was arguing) that we would be better making usernames specific/unique to domains from the very start - revising what we're doing today
18:31:24 <dwchadwick> but adding more spaghetti to the plate makes it more difficult to untangle in the long run
18:31:38 <gyee> heckj, amen brother!
18:32:09 <gyee> I am NOT against namespace, I am against *private* namespace
18:32:15 <heckj> so as a compromise here, let me suggest the following:
18:32:32 <dwchadwick> gyee - what is the difference?
18:32:41 <heckj> we change our asserting that user names need to be globally unique, and instead only enforce uniqueness to a domain
18:32:50 <heckj> we remove the concept of public vs. priviate domains altogether
18:32:52 <dwchadwick> all namespaces are private until make global
18:33:02 <ayoung> dwchadwick, yes
18:33:08 <Haneef> heckj , totally agree. Don't need to write so many pages in document to explain private/public  domain in docs. Simply make it domain scope
18:33:12 <ayoung> I agree "all namespaces are private until make global"
18:33:20 <ayoung> but...you should be able to run that backwards
18:33:25 <heckj> we make additional implementation notes in the spec asserting that there is a concept of a default domain, and if a domain isn't specified in auth, that auth is assume to go against the default domain
18:33:31 <dolphm> ayoung: "backwards"?
18:33:49 <ayoung> it should be possible to split a global namespace into multiple private ones down the road
18:33:58 <ayoung> if the pool is globally unique to start
18:34:05 <dolphm> heckj: you can't make a private namespace public -- there will be collisions with the existing public namespace
18:34:07 <joesavak> default domain will help v3 adoption
18:34:12 <ayoung> you should be able to split that into multiple pools of names where the  names start to overlap
18:34:42 <ayoung> there should be a default domain.  THat is the domain for all users.  THe problem is on how to split it up after wards
18:34:50 <ayoung> if you l;ook at the DNS syustem, they are split on dots
18:35:04 <ayoung> ldap splits on the whole cn=<value>, comma
18:35:38 <ayoung> and so if some people are doing username with email addresses, and you start splitting on domain name, now people that were in the same domain are split into different
18:36:12 <ayoung> ayoung@redhat.com would be partitioned into a different domain than admiyo@yahoo.com, even though they are both MY email addresses.  This is the process we need to keep in mind
18:36:13 <henrynash> heckj:  so I am am absolutely fine with this approach…and indeed I started there! The thing we are really saying is that the use of domains will really be for enterprises that want to have their own namespace and won't accept restrictions of clashing with others
18:36:19 <ayoung> So...we start with Folsom
18:36:26 <dwchadwick> the concept is simple. You take your own private name and prefix or suffix with your name (i.e. name of parent) to turn it into a global name
18:36:33 <ayoung> and the V2 API.  And we specify how things will grow into the V3 API
18:36:35 <Haneef> to support v2, can't we create a predefined v2 domain and move all the users to it.
18:36:52 <joesavak> Haneef, +1
18:36:54 <henrynash> we have the v2 thing coverered
18:36:58 <gyee> heckj, I am fine with your proposal
18:37:04 <gyee> have namespace applicable to all
18:37:17 <ayoung> Lets call it DOM0 just to confuse the Xen guys!
18:37:25 <dolphm> Haneef: we already did that
18:37:30 <henrynash> when you upgrade from F->G, all users and projects end up in the default domain and v2 and v3 clients will find them fine
18:37:40 <joesavak> sweet
18:38:14 <Haneef> So we don't even need to worry about default domain, for v2 users, it is v2 domain, and v3 , they are going to create a new domain or use existing one
18:38:33 <ayoung> dwchadwick, "the concept is simple. You take your own private name and prefix or suffix with your name (i.e. name of parent) to turn it into a global name"  that leads to things liike Kerberos tickets:  ayoung@example.com@EXAMPLE.COM
18:38:50 <ayoung> BNotice the double @ incase I didn't make it clear enough
18:39:23 <psedlak> with current proposal - user in private namespace will never be able to access diferent domains/project meanwhile user in global name space can get this acces and that could be problem in just private namespaces (possible name-clash) - right?
18:39:24 <gyee> ayoung, that looks like my email@EMAIL
18:39:32 <dwchadwick> yes exactly. As the world grows and domains merge then you need to add another level to the name
18:39:32 <henrynash> haneef: better than that, domain is optional in v3, so if the cloud provider want to run in "folsom" mode, the just never specify a domain on any entity and it all ends up in one big default domain with folsom semantcis
18:39:51 <ayoung> Since we have not ruled out any characters in usernames, we can't specify a means to concatinate  username and domain in a singled string.
18:40:24 <gyee> ayoung, email is unique across the world
18:40:26 <dwchadwick> I suggested you make it a config parameter that each OpenStack installation can decide
18:40:30 <ayoung> henrynash, so, is there fundamentally and difference between saying "we have multiple domains" and "we have multiple namespaces?"
18:40:41 <dwchadwick> In this way you cater for Chinese, Korean, Japanese etc
18:41:01 <dolphm> ayoung: +1 to straight up concatenation is impossible
18:41:10 <ayoung> gyee, yes, but we are not currently splitting domains on email addresses.  If we do that,. we end up with one domain per unique email address in the system....sub optimal
18:41:22 <henrynash> ayoung: if we take the approach suggest here, then no every domain is its own namespace
18:41:39 <ayoung> henrynash, and I think that is the right approach
18:42:07 <ayoung> so lets drop the term "private" from discussing namespaces.  What we should say is something like this:
18:42:16 <ayoung> 1.  IN folsom, there is one domain and one namespace
18:42:34 <ayoung> 2  Grizzly there will, by default, also be one domain and one namespace
18:42:44 <ayoung> 3.  If you want to enable an additional domain, you can do so
18:43:01 <ayoung> 4.  this domain will have a separate namespace from the existing domain.
18:43:10 <henrynash> ayoung: +1
18:43:11 <dwchadwick> 4. But you have to specify the domain name always
18:43:15 <ayoung> I think this maps to how people will want to use it.
18:43:20 <topol> ayoung +1
18:43:28 <ayoung> dwchadwick, there's the rub, as the bard said
18:43:35 <gyee> ayoung, +1
18:43:40 <ayoung> so that should be up to the deployment to decide
18:43:55 <ayoung> if you have multiple namespaces,  you can chose either:
18:44:06 <ayoung> 1.  if they leave off the domain ID, they get the default or
18:44:17 <ayoung> 2. if you leave off the domain id you get an error
18:44:24 <ayoung> We have gone with 1
18:44:28 <henrynash> ayoung: …they get the domain the token is scoped to….
18:44:35 <ayoung> as it allows the V2 api to work unchanged
18:44:43 <ayoung> henrynash, right
18:44:54 <ayoung> but you have to start the process somewhere
18:45:24 <ayoung> so if I just pass in userid and password to get a token, and not domain ID, we are saying that is checked against the default domain to keep V2 working
18:45:52 <gyee> I like that
18:45:52 <dwchadwick> no 4. But you have to specify the domain name always when you want to use the non-default domain
18:46:00 <henrynash> ayoung: v2 client yes
18:46:03 <ayoung> But, for V3,  we can specify that the domain Id is always passed, or we can specify it is up to the deployment whether it is required or not
18:46:15 <joesavak> up to deployment, please
18:46:27 <ayoung> dwchadwick, yes, you  have to specify the domain name always when you want to use the non-default domain.
18:46:41 <dwchadwick> that works
18:47:00 <ayoung> gyee, henrynash do you guys feel like we have a workable solution?
18:47:02 <dwchadwick> So this issue is not up to the deployment
18:47:17 <gyee> ayoung, sounds good to me!
18:47:34 <ayoung> dwchadwick, the deployment gets to say whether default domains are in effect, or whether you always have to specify
18:47:37 <henrynash> gyee: The key is that this is a hard: every domain has its own namespace
18:47:48 <dwchadwick> ayoung  yes
18:47:58 <henrynash> I'm fine with that…the rest is details we can work through outside this meeting
18:48:05 <ayoung> dwchadwick, said another way, the deployment controls the rule "what to do if domain ID is missing"
18:48:12 <ayoung> schweet
18:48:33 <dwchadwick> ayoung : no, the deployment cannot control that
18:48:35 <gyee> henrynash, hard to implement or hard to understand? :)
18:48:47 <henrynash> gyee: hard as in fixed!
18:48:48 <dwchadwick> It cannot say domain name is missing and it is private namespace
18:49:06 <ayoung> dwchadwick, I thought we agreed to stop using the word private
18:49:11 <ayoung> but yes, I am not saying that
18:49:14 <dwchadwick> as recipient then wont know what name it is meant to be
18:49:14 <ayoung> it can say
18:49:29 <ayoung> if no domain id, use a default domain of "EXAMPLE_COM"
18:49:38 <dwchadwick> agreed
18:49:44 <ayoung> or it can say
18:49:55 <ayoung> if no domain id, raise an exception
18:49:57 <dwchadwick> but it cannot same if domain is missing, guess which domain it is
18:51:06 <ayoung> dwchadwick, true....although we are specifying that in certain cases, a missing domain ID would mean "carry over the domain id used in a previous transaction with this same user"
18:51:15 <henrynash> heck, young: Ok, sign me up to update the api spec to reflect this
18:51:27 <ayoung> so it has to be specified at some point in the chain.
18:51:55 <ayoung> #action henrynash updates spec to reflect current design of domain namespacing
18:52:17 <gyee> can you guys approve the current token API spec first?
18:52:34 <topol> gyee: whats the review url
18:52:37 <henrynash> gyee: valid point
18:52:39 <dwaite> I'm still a little unclear on domains and namespaces
18:52:57 <gyee> https://review.openstack.org/#/c/20524/
18:53:00 <topol> gyee: you earned a +1 from me today
18:53:12 <gyee> topol, thanks
18:53:13 <henrynash> gyee: you'll need to change the wordings to remove private namespaces etc.
18:53:21 <ayoung> gyee you have your approval https://review.openstack.org/#/c/20524/
18:53:34 <gyee> grasseyass amigo!
18:53:45 <henrynash> gyee: however, it won't change what you pass, just the text description
18:53:53 <dwaite> is a domain a namespace?
18:54:01 <ayoung> heh, I already hit approve.  Should I stop that?
18:54:04 <gyee> dwaite, yes
18:54:05 <henrynash> dwaite: it is now
18:54:06 <dwaite> ok
18:54:08 <dwaite> yay
18:54:37 <gyee> henrynash, you can do the wording update after the merge
18:54:44 <henrynash> gyee: +2
18:54:49 <gyee> w00t!
18:54:52 <dolphm> ayoung: did you review the final result or just hit approve?
18:55:13 <ayoung> dolphm, hit approve. there were +2s from two core
18:55:31 <ayoung> I can stop it
18:55:50 <dolphm> ayoung: please read hugely impactful changes before you sign off on them :(
18:56:01 <gyee> what's the holdup?
18:56:04 <heckj> reading back really quick - I very much want a fixed suggested solution for waht happens when no domain is specified.
18:56:12 <heckj> ayoung - good with your proposal entirely
18:56:22 <heckj> but it can't be deployment specific, or we'll fuck interoperability
18:57:05 <heckj> I'm fine with someone choosing to do it another way, but we need (as OpenStack) to have an opinion on the solution and publish it to allow for interop
18:57:07 <ayoung> dolphm, sorry...I just saw that there was the requisite number.  We can continue to update the spec, though....I think that it is ok for this to be its own commit
18:57:27 <ayoung> not a bad idea to break big reviews down into smaller ones, as we have seen
18:57:35 <gyee> right, and henrynash is going to change the wording on namespace
18:57:39 <stevemar> +1
18:57:51 <ayoung> wow, that merged fast
18:58:05 <dolphm> docs have very little build process
18:58:06 <gyee> henrynash, she's all yours :)
18:58:18 <dolphm> / gating
18:58:23 <henrynash> gyee: I"ll treat her gently...
18:58:57 <ayoung> dolphm, actually, now that I look at it, I had read that earlier.
18:59:28 <ayoung> I was fine by it.  It can always be clearer, but I think we are on the right track
18:59:58 <heckj> Well, there goes that meeting.
19:00:18 <ayoung> dolphm, since I assume heckj is split-brained right now, you want to move on to the next topic, or just call it here
19:00:22 <henrynash> heckj: hey, but agreed stuff!
19:00:36 <ayoung> heckj, ah.  we done?
19:00:41 <heckj> we're out of time, so we'll need to wrap for today
19:00:44 <heckj> #endmeeting