14:00:18 #startmeeting neutron lbaas 14:00:19 Meeting started Thu Aug 21 14:00:18 2014 UTC and is due to finish in 60 minutes. The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:22 The meeting name has been set to 'neutron_lbaas' 14:00:29 mornin' 14:00:38 Morning 14:00:41 morning 14:00:47 #chair jorgem 14:00:48 Current chairs: dougwig jorgem 14:00:54 #topic Documentation for V2 needs to be postponed and V1 re-instated 14:01:10 hello 14:01:11 #link http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html 14:01:27 since v2 is going into incubator, v1 docs need to be put back in 14:01:42 so, where do the incubator docs live? 14:01:46 is going to incubation final? 14:01:50 hey dougwig, do you want to run the agenda today? I'm guessing the meeting started right before I joined? 14:01:51 who do we contact, or file a bug, or? 14:02:00 xgerman: that is something to be determined, we need more details o nthat 14:02:09 jorgem: i set you as an extra chair, so you can take over if you want. 14:02:15 Min talked about a doc chnage 14:02:16 xgerman: definitely should get min to save that doc work somewhere though 14:02:17 but np either way 14:02:32 who wants the action item to follow this up? 14:02:32 https://review.openstack.org/#/c/107603/ 14:02:33 dougwig: I'll let you take a stab at it today ;) 14:03:14 xgerman: im not sure if she needs to file a bug or a new review for this 14:03:30 guys. is moving to incubation final? 14:03:33 #action dougwig follow-up on doc reversion 14:03:46 samuelbercovici: i'd say its a 99.999% certainty 14:03:54 samuelbercovici: blogan: +1 14:03:54 samuelbercovici: let's transition to that... 14:03:55 dougwig, why would we reverse - we can just say in incubation? 14:04:20 xgerman: because unless we hear differently, v1 is still going to be supported in juno. 14:04:30 #topic Update on incubator 14:04:51 xgerman: from what I have read about the incubation, is that the docs shouldn't change until graduation, either way, v1 docs still need to be there 14:05:04 mestery: are you around for a quick incubator update? 14:05:25 ok, I only read about experimental things being in horizon 14:05:27 or markmcclain 14:05:30 why should it move to incubation? is there anyone who prefer this over waiting on review queue until we get into trunk? 14:05:52 samuelbercovici: no one preferred it, it's just what is happening with neutron 14:06:01 sameulbercovici: kind of a new policy for new extensions 14:06:16 blogan: but lbaas is not a new extension 14:06:17 samuelbercovici: it's been made clear that we're not far enough along with v2 for Juno. 14:06:29 samuelbercovici: v2 technically is 14:06:58 dougwig: then I think it is better to remain on review queue for Kilo than get moved to incubation 14:07:20 i don't think we're going to be given that choice. nor is gbp. we're still waiting final word. 14:07:31 sameulbercovici: we argued the points for a while now, and I think we've all accepted its going to happen. Other features/extensions that are actually more mature than v2 are also going into the incubator 14:07:36 * TrevorV late but here, sorry 14:07:48 lbaas is different than gbp. I think that the api is in consensus 14:08:16 samuelbercovici +1 14:08:32 samuelbercovici: You'll get no argument from me on that, but I don't think we're going to change the minds of the core devs on this. 14:09:06 samuelbercovici: we're just saying, the debate has been had, we have no choice 14:09:18 As I've ranted about extensively in other places, I think this is a political thing, and LBaaS has become a pawn in the battle. 14:09:40 Well, LBaaS v2, I mean. 14:09:47 but we shall move forward now, and not look to the past, right? right? 14:09:53 Right. 14:10:08 samuelbercovici: if you check out last week's minutes for this meeting, kyle and mark joined and spoke at length about the incubator. i don't think us not doing it was on the table. 14:10:31 mestery_: ping 14:10:32 samuelbercovici: yeah, they were soliciting comments and arguments last week, until the end of the meeting when they said the patch was about to go in to do it, and I asked if the decision had already been made, and they said yes >_> 14:10:34 Speak of the devil! 14:10:49 specifically mestery_ said yes. welcome mestery_ :) 14:11:00 he's been pinging in and out of IRC since i woke up. not sure if he's still at linuxcon. 14:11:00 that's probably an auto rejoin 14:11:14 Oh, haha! 14:11:16 anywho, back to the docs 14:11:19 also mestery announced the incubator officially at liunuxcon 14:11:19 yeah :( 14:11:30 dougwig: already did so. 14:11:46 What is the fate of V1. There were talks about moving V1 as well to incubation? 14:11:54 (where can we find last week's minutes?) 14:12:06 * mestery is lurking while at Linuxcon in Chicago at the moment. 14:12:13 #link http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/ 14:12:19 xgerman: do you think Min can follow up on at least getting V1 docs re-instated and at least getting V2 marked as preview/experiemental/incubated? 14:12:20 so the incubation is going to be the dump bin for any code whic is not core? 14:12:28 Oh he is here! Sorry to have implied you were the devil earlier. ;) 14:12:35 bloga, yes, I can ask her 14:12:49 xgerman: okay thanks, because v1 docs really do need to remain 14:13:00 nah, everybody should use v2 14:13:12 samuelbercovici: it's not supposed to be. we have been assured it is not. 14:13:29 samuelbercovici: despite what dougwig says, I'm pretty sure you're right :P 14:13:36 Yeah, the hope is that that doesn't happen with incubator. 14:13:41 xgerman: lol 14:13:43 but we'll see 14:13:45 vjay5: v1 will probably remain in tree, but no official word on it so that could change 14:13:48 dougwig: we were also assured at the begginning that we can start the api all over and it will be fine..... 14:13:51 I'm trying to be optimistic, folks! 14:14:14 (Though I'm not sure I can achieve blogan levels of optimism.) 14:14:23 blogan / vjay5: I'd actually like to see v1 pulled out of tree, if we're going to be stuck in incubator with v2 14:14:25 I thought I was pesismistic, then I met sbalukoff 14:14:28 but that may be a lost cause argument 14:14:32 sbalukoff: its called denial and large quantities of alcholol! 14:14:34 +s 14:14:38 samuelbercovici: yes, we were. and that's what has most of us a tad bit unsettled (or a lot unsettled.) 14:14:55 alcholol is the type of alcohol that makes you laugh 14:15:02 rm_work: i'm very against pulling v1 out of tree, until it has something to replace it. 14:15:03 blogan: So that's what I've been doing wrong! I need to take up drinking. 14:15:07 we cant pull out v1, we have some customers who have deployed our solution 14:15:22 it has been there for 2 releases now 14:15:28 vjay5: i think that actually is the reason to keep it in tree 14:15:28 brb 14:15:39 dougwig: if v1 is out of tree, it makes the argument for splitting off easier :P 14:15:41 blogan +1 14:15:45 dougwig is right that pulling v1 out of tree screws over users and vendors with v1 deployments / drivers 14:15:50 so back to the criteria of selecting code into incubation, and I beg pardon for acting the lawyer here. Is there a reason why an API which is in concensus can't be done on trunk but must pass via incubation? 14:15:59 but also there is supposedly "no reason projects from the incubator can't be deployed easily along with neutron" 14:16:01 rm_work: can't screw over the customers because of a political maneuver 14:16:12 rm_work: that's what I thought 14:16:15 I would totally settle for v1 being officially deprecated in Juno. Not sure how feasible that is. 14:16:23 yeah, but they keep assuring us things are deployable to prod from incubator directly 14:16:23 so 14:16:41 rm_work I just read an e-mail where the packagers revolted and said no to the incubator 14:16:42 samuelbercovici: you'll have to take that up with mestery and markmcclain 14:16:53 blogan: ok 14:16:55 samuelbercovici: the decision of where things start/mature is in the hands of the neutron cores. 14:16:58 xgerman: well, ok then >_< 14:17:01 xgerman: Really? Was this public somewhere? 14:17:05 blogan: +1 14:17:12 xgerman: So we are back to no incubator then? 14:17:17 if that's the case, I am back to having some problems with the incubator plan again 14:17:18 xgerman: geesh 14:17:24 * mestery is catching up on emails now. 14:17:24 The funny thing is, I had spoken to packages (not Ihar) and they said the incubator could be packaged 14:17:24 So need to clarify that. 14:17:35 mestery: Please do! 14:17:39 sbalukoff, theres an email thread where this is being dicussed 14:17:52 yeah, having incubator packaged was one of the concessions that made it somewhat bearable as a solution 14:17:52 link? 14:17:54 mestery: too many rumors swirling around, we need official details on this ASAP, rumors tend to kill any momentum 14:18:08 +1 14:18:16 dougwig: I am working in this community for the last ~3 years. to me incubation is a place out of focus. why would any core who has his hands full, spend time to llok at code in incubation? this is beyond my understanding 14:18:29 blogan: ++ 14:18:35 samuelbercovici: i think that is one of the main fears, yes 14:18:39 blogan: +1 14:18:46 though they said we'd get some of our own additional reviewers in incubation 14:19:00 rm_work: they said they were thinking about it, it wont happen in the beginning 14:19:07 rm_work: That's still not defined very well though 14:19:08 :/ 14:19:11 samuelbercovici: i'm really not the right person to be asking. the theory is that the review requirements will be different, and more iterative. but i can't speak for the cores. 14:19:20 so that may not happen either? really? :/ 14:19:57 rm_work: additional reviewers means less chance of graduation. if i had to guess, they want to see how it's going to work, and add reviewers if necessary. but that's just a guess. 14:20:19 is this incubation, already in place? 14:20:29 samuelbercovici: no 14:20:30 samuelbercovici: Nope 14:20:48 I thought markmcclain said the patches were going in last week? 14:21:02 guess that didn 14:21:04 *didn't happen 14:21:05 rm_work: Hasn't landed yet, from what I understand. 14:21:16 hah, what a surprise, a review is delayed :P 14:21:21 guess it even happens to the PTL 14:21:23 so until we get more information, rehashing all of this is really just a waste of time 14:21:36 blogan: +1 14:21:42 last i heard, the code for the incubator was, "waiting on a few items." not sure if that was code items, or review feedback. 14:21:44 blogan +1 14:21:55 also we aleways have the mailing list 14:21:55 +1, but i didn't want to cut anyone off. 14:21:59 ok, to move on to next topic? 14:22:23 #topic LBaaS v2 Client Code 14:22:56 #link https://review.openstack.org/#/c/111475/ 14:22:58 The current implementation of the v2 client code lets in some confusion vs the v1 client code 14:23:36 how so? 14:23:37 #link https://review.openstack.org/#/c/111475/ 14:23:39 A comment regarding this issue was made by Yair (not here today) and dougwig also -1 until we talked about it... time we talk about it I think 14:24:07 the whole 'lb-pool-create' vs 'lbaas-pool-create', etc is very confusing to first-timers and people who aren't up to speed 14:24:26 ah, right. yair was very opposed to have v1 and v2 available at the same time, with slightly different command names. 14:24:34 while it is okay to provide both v1 and v2 client APIs, I think there should be a stronger separation there 14:24:44 So, I would vote to deprecate all the v1-specific commands when v2 is available. 14:24:55 But, I think we were told at the mid-cycle hack-a-thon this wasn't an option. 14:25:06 That we needed to have both available at the same time. 14:25:07 yair's argument was to now allow both extensions to be present at the same time. 14:25:14 /now/not/ 14:25:15 sbalukoff, wouldn't this be right after v2 reached graduation? 14:25:35 prepending commands to ease confusion between versions? 14:25:45 jschwarz: Keep in mind this code was written and this direction set before such a concept as "graduation" existed. 14:26:04 we must all adapt to changes in the project, it seems ;-) 14:26:34 yair's point was that "neutron lb" and "neutron lbaas" were sufficiently similar so as to likely cause users to make mistakes. 14:26:39 So what do we see as the 'right way' of doing this? 14:26:42 whoa, grammar fail. 14:26:45 Or rather, what would the core devs see? 14:26:53 yeah and that is a good point, and something we should address 14:27:02 (after all we couldn't version) 14:27:06 and I'd be fine with saying v1 and v2 cannot be active at teh same time 14:27:14 blogan: +1, and why i dropped a supporting -1. 14:27:34 I heard a suggestion of a configuration option specifically allowing v1 or v2, but not both 14:27:38 blogan: +1 14:27:44 sort of like "ENABLE_LBAAS_V2 = True/False" 14:27:57 does anyone feel strongly that they should both be allowed at the same time, outside of dev environments? 14:27:57 You heard it here folks: My -1's have actually been "supportive" 14:27:58 ;) 14:28:18 it was discussed at hack-a-thon that v1 and v2 cannot be active at same time 14:28:35 Again, I can't fault Craig's code here because he implemented this this way based on direction from the core devs. 14:28:43 the reason was to allow olad code that was using v1 to move to v2 by having both apis with a shim 14:28:48 But I think he'd also be in favor of disabling v1 when v2 is in use and visa versa. 14:28:48 vivek-ebay: i don't remember that all, but my memory from the hackathon has all but faded 14:28:50 not sure if we still want to do so 14:28:50 No fault for Craig's code intended 14:29:07 samuelbercovici: no point in dong a shim now 14:29:15 blogan +1 14:29:23 blogan +1 14:29:24 blogan: +1 14:29:55 did yair say, what he would consider acceptable? 14:29:56 so would the best way to do it for the client to say that all calls go through lb? 14:30:05 as in lb-pool-create works for both v1 and v2? 14:30:14 samuelbercovici, we did not have a length discussion about this, I'm afraid 14:30:19 (this would imply that the client would have some way to discover which version the server is running) 14:30:28 the request from the tempest folks was that the interfaces be the same but different for v1 vs v2. 14:30:38 as in, in favor of 'neutron lb' for both. 14:30:44 "the same but different" 14:30:49 blogan: this would be really probalmatic with "old" scripts 14:30:57 I still prefere different naming 14:30:58 Excellent specification there. ;) 14:31:15 would "neutron lb" vs "neutron lbv2" be a better option? 14:31:15 sbalukoff: i'm not the best one to argue that point, since i don't agree with that facet of the objection 14:31:24 there could be different naming, but then I would suggest specifically enabling either one but not both 14:31:35 dougwig: Aah, sorry-- I thought that was a direct quote 14:31:40 neutron lbv2-create-pool looks horrible. :) 14:31:42 so if I created a pool in v1, I wouldn't be able to try to add a member to that pool in v2 14:31:51 no 14:32:06 no mixing of APIs 14:32:33 also the db migration makes it diffiuclt without shim 14:32:47 jschwarz: you wouldn't be able to add a v2 member to a v1 member currently, it'd say member id not found 14:32:51 yairs point is that if you run one set of commands, and then the other, you get an non-intuitive error (he's right). i'm not sure that it necessarily follows that the commands must be the same, just that both not be present. 14:33:08 blogan, I know, but it wouldn't prevent confusing for the users 14:33:18 s/confusing/confusion/g 14:33:25 jschwarz: i know, and i agree it'll be confusing to users 14:33:39 the best would be to take if with him on IRC and then maybe on ML 14:34:08 samuelbercovici: "old" scripts would only have a problem if v2 used the same lb prefix, and if v2 was enabled on the server right? 14:34:27 blogan: to me the current naming is fine 14:34:47 blogan: lb vs. lbaas is fine to me 14:34:54 samuelbercovici: +1 14:35:10 does anyone here today feel strongly that the api endpoints and cli commands should match v1 where they overlap? because if not, we're arguing with a phantom. 14:35:13 sameulbercovici: is it fine even when they're both enabled together? 14:35:24 and I think we all are fine with this. so the discussion should be taken with yair to see how to address his concern 14:35:30 +1 14:35:38 +1 14:35:39 I agree with Yair 14:36:06 i'm going to move on, unless there's part of this we haven't discussed... 14:36:18 jschwarz: can you start a ML thread about it? 14:36:31 blogan, sure, either me or Yair on sunday 14:36:37 jschwarz: hopefully Yair will come into as well 14:36:43 +1 14:36:45 #action jschwarz Discuss v1/v2 api naming issue on ML 14:36:53 #topic What is LBaaS v1 in Juno? 14:37:08 vjay: you added this didn't you? 14:37:11 whoever added this agenda item, the floor is yours. 14:37:13 yes 14:37:15 vjay5 14:37:17 i added this 14:37:38 i wanted to make sure V1 is sure to be in the main tree 14:37:50 vjay5: i'd say that is a probability, but not a certainty 14:38:00 vjay5: we won't know until we get more details 14:38:11 i have not heard even a single hint from the cores that it won't be. 14:38:15 Yep. Similar discussion to earlier. 14:38:29 yeah, again, they have told us that even incubator will be packaged for production -- so, it shouldn't matter -- but either way we need more details to really discuss this 14:38:45 so these discussions are core only? or is it somewhere public for people to particpate 14:38:49 there are pople using v1, you can't take it away without a replacement 14:39:17 yes, i think v1 is un-touched 14:39:19 dougwig: i heard at some point it was something that they "were exploring" 14:39:19 vjay5 / samuelbercovici: right, so either it will be in core, or it will be packaged in incubator -- one of the two 14:39:28 samuelbercovici: If incubator is pursued as intended with good faith, moving v1 there isn't "taking it away" 14:39:30 per se. 14:39:35 sbalukoff +1 14:39:42 +1 14:39:51 but again, I think this is a fruitless discussion until we get more details. 14:40:00 +1000 14:40:04 [09:38:26] yeah, again, they have told us that even incubator will be packaged for production -- so, it shouldn't matter -- but either way we need more details to really discuss this 14:40:08 That is if the packagers get on board and decide to actually package the incubator? 14:40:27 sbalukoff: I don't agree. status in thigs in incubation and packaging them is not same as core 14:40:29 well, there always is github 14:40:43 xgerman: and stackforge! 14:40:56 ok, we're devolving into another incubator rant without info. 14:40:58 :) 14:41:05 yes 14:41:07 either way we need more details to really discuss this 14:41:11 vjay5: have we answered your question with enough uncertainty? 14:41:12 indeed 14:41:19 how are these details and info communicated? 14:41:19 lol 14:41:20 dougwig you are syaing it likes a bad thing :-) 14:41:21 samuelbercovici: Given my level of skepticism on this, I'm sure you probably know I agree with you. ;) 14:41:55 vjay5: I'm assuming it will be announced on the ML, but even that is unclear 14:41:56 ok, moving on... 14:42:08 ok..lets move to next topic then 14:42:08 #topic Is Juno open for fixing v1 bugs? 14:42:10 Yes please! 14:42:19 I added this as well 14:42:29 Doesn't this depend on our previous discussion? 14:42:39 i've seen v1 reviews and cores commenting on them, so i'm inferring the answer here is 'yes'. 14:42:43 vjay5: Very good question. I have no idea. 14:42:44 Thus, we should wait until more info is available? 14:42:59 jorgem: yep. 14:43:03 +1 14:43:06 i know eugene has done some bug fixes for v1, but I htink they were mroe stability bug fixes for neutron 14:43:17 we were not submitting V1 small enahancements and bugs on the driver because we were intending to move V1. 14:43:18 but i'd say that with fpf today, if you have a v1 fix, submit it. 14:43:24 s/v1/v2 14:43:34 so there is not last date yet right? 14:43:39 s/not/no 14:43:47 file a bug and upload the fix 14:43:50 there probably is but we don't know 14:43:58 no restriction like august 21 for bugs i suppose? 14:44:14 this is actually probably another casualty of the incubator, is that since we were focused on v2, v1 bug fixes were overlooked, and now it doesn't look so good 14:44:15 i'd submit your v1 fixes, not wait. worst case, it gets ignored. 14:44:19 vjay5: It would be a really good idea to get those submitted today. 14:44:28 ok. thanks! 14:44:38 #topic Open discussion 14:44:44 i gotta go 14:44:49 Seeya! 14:44:52 adios 14:44:56 bye 14:45:03 anyone have anything else, or we'll break early ? 14:45:16 I got nothin' 14:45:20 same 14:45:26 0 14:45:27 dougwig: we could rant about incubation for another 15 min? 14:45:30 does anyone knows of a missing critical featur that is still required to get v2 core into juno? 14:45:33 HAHA 14:45:45 I have a question 14:45:45 I mean, since we have the time... 14:46:05 samuelbercovici: well, we are running up against the clock on TLS... but I don't know if we required that in Juno V2 14:46:20 samuelbercovici: no tempest tests, no horizon, the ref driver doesn't have an agent, so can only run on one box, general unproven stability. 14:46:30 I am preparing to discuss with Kyle, and as far as I know we have everyting required (API, Tests, CLI, driver and reference implementation) 14:46:31 I feel like incubation is the start of Skynet 14:46:37 am i missing something? 14:46:46 lol 14:46:50 Heh! 14:46:52 samuelbercovici: well, TLS is still totally missing components 14:47:01 I am talking core v2 14:47:03 vivek-ebay: What is your question? 14:47:12 Suppose user created a LB with few members in a pool. 14:47:16 I prefer to have this in Juno and complete the rest for Kilo if possible 14:47:23 samuelbercovici: ok, so TLS isn't req for core v2 14:47:25 ? 14:47:26 samuelbercovici: tests and the ref driver not being able to scale. 14:47:28 members are supposedly instance member IPs 14:47:48 I think that we can get pass with unscalalble ref driver 14:47:57 samuelbercovici: but by all means, have the conversation. we'll cross our fingers for you. 14:48:06 what avout tempest, I thought it was worked on? 14:48:07 There some missing container communication for the TLS ref impl 14:48:19 when tenant/user removes instance from nova...will LB continue to have that member within the pool ? 14:48:22 samuelbercovici: minimal api tests. not in detail, and no scenarios. 14:48:26 Ive submitted the review for it, but without Barbicans work complete it wont do anything 14:48:29 vivek-ebay: Yes. 14:48:42 since member IPs are not strictly tied to nova instances. 14:48:49 samuelbercovici: momentum/work stopped about 2-3 weeks ago, when the incubator came into play. 14:48:54 later some other tenant can get the same IP, and cause unexpected behavior 14:49:28 we should somehow enforce removal of member if instance is being removed. 14:49:35 vivek-ebay: So if the other tenant is on a different internal network, that shouldn't happen. 14:49:38 vivek-ebay: members don't have to be instances. 14:49:57 yeah I have about 1300 lines of barbican code still waiting for review -- and more to write on the neutron-lbaas side to get barbican up and working 14:49:57 in our case, tenants shares networks 14:49:59 But it could if the IP being referenced is accessible from the first tenant's network (eg. the IP being referenced is "public" in some way) 14:50:32 safer would be to add something to the member indicating if it was a nova instance, so the cleanup wouldn't need to infer anything. 14:50:48 dougwig: I agree. but we can still make at least with core v2. It is a question of seeing what is missing to get this done and focus on it! 14:51:00 vivek-ebay: Then, yes the problem you describe exists, but forcing removing of a member is problematic since they don't correspond 1:1 with instances. 14:51:33 we have written a notification handler to handle such cases 14:51:55 handler listens for instance deletion notification and calls lbaas api to remove member from existing pool. 14:52:11 samuelbercovici: I think our window for that has essentially closed while we were waiting on core reviewer feedback on the core changes three weeks ago. :/ 14:52:12 but was thinking if this can be generically addressed. will be a common problem. 14:53:06 vivek-ebay: You'd need to have some way to know that the lbaas member actually corresponds with the nova instance. Is IP address enough to know that? 14:53:36 no, we modified schema to also contain instance uuid 14:53:42 vivek-ebay: In other environments, it's not necessarily a problem because tenants don't share back-end networks. 14:53:49 vivek-ebay: aah! 14:54:14 vivek-ebay: Is that attribute required? 14:54:32 for us yes, but should be optional in general 14:54:43 I don't think we can force lbaas members to correspond with nova instances. That would break some users' configurations. 14:54:59 vivek-ebay: So, that's not a bad idea. 14:55:10 correct..we want it to be independent 14:55:16 Make it an optional attribute of the member, and then the code can auto-clean stuff with your notifier. 14:56:37 heh. i said that at 8:50 sbalukoff 14:56:52 :) 14:57:07 dougwig: Why use one statement to get to the point when I can use 10? ;) 14:57:08 :) 14:57:53 heh. 14:57:56 2 minutes. 14:57:59 ok, time to wrap up i guess 14:58:13 yeah, i guess my team just... took off to our sprint planning meeting >_> 14:58:19 I guess they thought we were done :P 14:58:36 Well, we're done now! 14:58:40 i'd suggest moving the member discussion to the ML 14:58:40 later all! 14:58:46 \o 14:58:50 bye 14:58:50 bye 14:58:53 Seeya! 14:58:53 bye all 14:58:54 #endmeeting