22:00:02 <adrian_otto> #startmeeting Solum Team Meeting
22:00:03 <openstack> Meeting started Tue May 27 22:00:02 2014 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:06 <openstack> The meeting name has been set to 'solum_team_meeting'
22:00:09 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-05-27_2200_UTC Our Agenda
22:00:16 <adrian_otto> #topic Roll Call
22:00:18 <paulmo> Paul Montgomery
22:00:21 <adrian_otto> Adrian Otto
22:00:47 <asalkeld> o/
22:00:47 <tomblank1> tom blankenship
22:01:12 <james_li> James Li
22:01:25 <ravips> Ravi
22:01:39 <muralia> murali
22:01:57 <julienvey> Julien Vey
22:01:57 <devkulkarni> Devdatta
22:02:29 <adrian_otto> for those of us in the USA, I hope you had a meaningful Memorial Day holiday yesterday.
22:02:59 <adrian_otto> welcome everyone
22:03:14 <adrian_otto> if you have not recorded your attendance yet, feel free to chime in at any time.
22:03:17 <adrian_otto> #topic Announcements
22:03:51 <adrian_otto> I do not have any announcements prepared. Do any team members have any announcements they would like to make?
22:04:08 <asalkeld> no, not really
22:04:09 <paulmo> Just a request to help keep this up to date: https://wiki.openstack.org/wiki/Solum/ExternalDependencies
22:04:22 <adrian_otto> paulmo: thanks!
22:04:27 <devkulkarni> no
22:04:33 <adrian_otto> ok, next agenda item
22:04:37 <adrian_otto> #topic Ratify Election Rules
22:04:45 <adrian_otto> #link https://wiki.openstack.org/wiki/Solum/Elections Proposed Election Rules
22:05:03 <adrian_otto> Please take a moment to review this, which was based on your feedback from last week's meeting
22:05:32 <devkulkarni> What is fullform of ATC?
22:05:39 <paulmo> +1 dev, was about to ask
22:05:46 <adrian_otto> I will be seeking any feedback you may have to amend it prior to moving for a #agreed by unanimous consent.
22:05:53 <adrian_otto> ATC = Active Technical Contributor
22:06:03 <asalkeld> you have code in tree?
22:06:23 <adrian_otto> means that you contributed code in the prior release, or the one before that, yes
22:07:08 <devkulkarni> election result date is missing (I think we had talked about it as well)
22:07:28 <asalkeld> seems like the normal procedure
22:07:37 <devkulkarni> thanks adrian_otto for the clarification
22:07:46 <adrian_otto> ok, I added a new #1 and pushed the rest down
22:07:50 <adrian_otto> so reload to see taht
22:08:23 <adrian_otto> I should clarify the 6-month release cycles
22:08:25 <paulmo> "previous two release cycles" = 1 year?  That seems to not jive with #2
22:08:35 <devkulkarni> just a minor tweak .. "who has made a contribution to Solum in one of the two previous release cycles" ?
22:08:53 <adrian_otto> reload again
22:09:24 <adrian_otto> and just updated #2 accordingly
22:09:32 <paulmo> 1's timeframe doesn't match with 2 and 3 if I read it correctly
22:09:45 <devkulkarni> okay, that clarifies that the contribution could be in any one of the previous two release cycles
22:10:07 <asalkeld> isn't there a generic openstack one we can link to?
22:10:10 <adrian_otto> paulmo: ok thx. #3 corrected.
22:10:17 <paulmo> Is anyone qualified?  There haven't been 2 full cycles right?
22:10:25 <adrian_otto> asalkeld: no, because they use a more sophisticated process
22:10:33 <asalkeld> I see
22:10:47 <adrian_otto> paulmo, yes, you just need one contribution.
22:10:56 <adrian_otto> so all current contributors qualify by these rules
22:11:31 <adrian_otto> ok, any other feedback on the rules?
22:11:41 <asalkeld> looks ok to me
22:11:42 <paulmo> Ah, ok,… perhaps 1 should be clarified with "who has made a contribution _at any time_ in the previous..."
22:11:44 <devkulkarni> lgtm
22:12:08 <tomblank1> paulmo: yes, i think that would clarify what you were asking about..
22:12:22 <tomblank1> otherwise, looks good and we should go with it...
22:12:34 <adrian_otto> paulmo: how about: An ATC is an Active Technical Contributor, defined as any individual who has made a contribution to Solum within the previous two 6-month release cycles.
22:12:55 <paulmo> Yes, sounds good to me.
22:12:59 <adrian_otto> ok, tx
22:13:03 <tomblank1> adrian_otto: +1
22:13:10 <adrian_otto> ok, updated.
22:13:14 <adrian_otto> Review just to be sure.
22:13:32 <adrian_otto> any objections to adopting these rules by unanimous consent?
22:13:38 <devkulkarni> no
22:13:42 <paulmo> no objection
22:13:43 <ravips> no
22:13:45 <tomblank1> no objection
22:13:46 <asalkeld> no
22:13:51 <paulczar> do it!
22:13:55 <muralia> nope
22:13:57 <adrian_otto> ok, hearing no objections:
22:14:04 <peoplemerge> I'm here, trying to triage multiple meetings
22:14:15 <datsun180b> no objections
22:14:19 <adrian_otto> #agreed We have approved the following election rules: https://wiki.openstack.org/wiki/Solum/Elections
22:14:23 <adrian_otto> thanks everyone
22:14:52 <adrian_otto> now, if at any time anyoen feels there is a problem with the rules, I ask that you bring those concerns here before editing the page.
22:14:58 <adrian_otto> so that we can address them as a team.
22:15:23 <adrian_otto> ok, let's advance to our next order of business
22:15:26 <adrian_otto> #topic Review Action Items
22:15:33 <adrian_otto> drian_otto to file/update blueprints for Pipeline and Environments
22:15:35 <adrian_otto> +a
22:15:42 <adrian_otto> Status: COMPLETE.
22:15:50 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/pipeline Pipeline Blueprint
22:16:06 <adrian_otto> See also: Linked bug/task tickets (there are a few already, we may add more as needed)
22:16:14 <adrian_otto> link https://blueprints.launchpad.net/solum/+spec/environments Environments Blueprint
22:16:20 <adrian_otto> it also has linked task tickets
22:16:34 <adrian_otto> any remarks on these?
22:17:16 <asalkeld> as long as it is consistent with our gdoc I guess
22:17:16 <devkulkarni> About Environments..
22:17:32 <asalkeld> were we not going to call them "targets"
22:17:38 <adrian_otto> we can link the Gdoc to it too
22:17:38 <asalkeld> to avoid confusion
22:17:46 <devkulkarni> I know we have clearer understanding of pipelines, but I am not sure if we have similar about environments
22:18:10 <devkulkarni> yes, lets put the link of the gdoc in both the blueprints
22:18:22 <asalkeld> devkulkarni, well - we all know what's in them
22:18:24 <adrian_otto> anyone have that handy?
22:18:39 <asalkeld> https://docs.google.com/a/salkeld.id.au/document/d/1a0yjxKWbwnY7g9NZtYALEZdm1g8Uf4fixDZLAgRBZCU/edit#
22:18:47 <adrian_otto> asalkeld: tx!
22:19:08 <devkulkarni> asalkeld:
22:19:25 <asalkeld> yip
22:19:31 <devkulkarni> one of things that we were discussing at Atlanta was whether pipelines are same as environments
22:19:33 <adrian_otto> it is already linked
22:19:44 <devkulkarni> this was during our Thursday's discussion
22:19:48 <adrian_otto> to Pileplines
22:20:17 <adrian_otto> my understanding is that we maintained that a Pipeline is not an Environment
22:20:24 <devkulkarni> so thats what I meant when I said that there needs to be some more clarity
22:20:28 <asalkeld> devkulkarni, that is more credentials related
22:20:29 <devkulkarni> oh okay
22:20:48 <adrian_otto> A Pipeline is an imperative process through with Solum is expected to progress
22:20:53 <devkulkarni> we did agree to that I think
22:21:01 <asalkeld> so you *could* use a different pipeline instead of making different targets
22:21:17 <asalkeld> (as a different user)
22:21:27 <asalkeld> (if that made sense)
22:21:29 <adrian_otto> whereas an Environment is a place where we relate one or more assemblies in a shared context that may contain additional constraints or attributes.
22:22:13 <devkulkarni> okay.. does gdoc has discussion about environments as well?
22:22:21 <devkulkarni> (will read it) we can proceed..
22:22:22 <adrian_otto> asalkeld: yes, I recall that as an option.
22:22:23 <asalkeld> devkulkarni, not so much
22:22:57 <asalkeld> I struggle to see the real use cases (it's quite advanced functionality)
22:23:13 <devkulkarni> yeah.. pipelines are very clear..
22:23:15 <adrian_otto> ok, we can revisit Pipelines and Environments in our Open Discussion as needed
22:23:20 <devkulkarni> +1
22:23:31 <adrian_otto> if we end up not needing one of those blueprints, we can deal with that
22:23:40 <adrian_otto> next on our agenda is...
22:23:45 <adrian_otto> #topic Mistral Integration Discussion
22:23:49 <adrian_otto> devkulkarni: all yours
22:24:02 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/solum-mistral Superseded Blueprint
22:24:07 <devkulkarni> so lots of WIPs and blueprints have been created regarding this..
22:24:08 <adrian_otto> that was the BP you filed
22:24:16 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/pipeline Pipeline Blueprint
22:24:19 <adrian_otto> that is the new one
22:24:27 <adrian_otto> #link https://bugs.launchpad.net/solum/+bug/1322748 Initial Mistral Feature Task
22:24:36 <adrian_otto> and that is the individual work item assigned to you
22:24:37 <devkulkarni> I think asalkeld and datsun would have most to discuss about Mistral
22:24:48 <devkulkarni> I did an initial WIP of the workbook
22:24:55 <devkulkarni> just to kickstart discussions..
22:25:07 <asalkeld> well I am working to get plugins into mistral
22:25:20 <asalkeld> and julienvey is working on oauth
22:25:32 <asalkeld> we also need oauth in mistral
22:25:54 <adrian_otto> asalkeld: can you take a moment to share with us why Keystone is not the answer?
22:25:54 <devkulkarni> How are folks finding using mistral for Solum overall?
22:25:55 <asalkeld> and I have been fixing bugs/raising bugs
22:26:08 <asalkeld> adrian_otto, it is keystone
22:26:21 <asalkeld> (keystone now does oauth1)
22:26:31 <paulmo> A clarification of the authorization features needed and what is missing would really help me.
22:26:42 <adrian_otto> are we referring to "oauth" and "v3 Keystone trusts" as synonyms?
22:26:45 <asalkeld> and the tokens don't suffer from chained trust issue
22:27:02 <asalkeld> so we logically need "trusts"
22:27:18 <paulmo> Keystone server has trusts and OAuth1a already if I understand the pull requests correctly.
22:27:18 <asalkeld> but oauth tokens can be passed from service to service
22:27:19 * morganfainberg felt a disturbance in the force...^wirc network
22:27:43 <adrian_otto> hi morganfainberg
22:27:48 <asalkeld> trusts really don't like getting rescoped
22:28:04 <morganfainberg> adrian_otto, hi there.
22:28:12 <asalkeld> so won't work from solum -> mistral -> heat
22:28:46 <asalkeld> anyways there are bp's out for all 3 projects
22:28:59 <asalkeld> and people signed up for the work
22:29:02 <devkulkarni> my main concern here is, are we sure that Solum's fine-grained auth needs are completely satisfied by OAuth1.0
22:29:21 <devkulkarni> or would Keystone's Trusts would be the answer for us
22:29:35 <morganfainberg> asalkeld, so is there something we (as keystone) can do to help make keystone ... better and/or suit your needs if Trusts etc aren't sufficient?
22:29:38 <devkulkarni> notwithstanding that Keystone does not yet have chained trusts
22:30:04 <asalkeld> morganfainberg, we would need chained-trusts
22:30:30 <paulmo> Keystone has OAuth1a: https://review.openstack.org/#/c/29130/
22:30:33 <morganfainberg> asalkeld, a chained trust is a rescopable trust?
22:30:37 <asalkeld> but from speaking to heat team, they believe that oauth is the answer
22:30:53 <asalkeld> morganfainberg, I believe so
22:30:57 <devkulkarni> morganfainberg: are you asking, or are you saying they are one and the same?
22:30:59 * morganfainberg isn't clear on specifics of what a chained-trust would encompass
22:31:23 <asalkeld> morganfainberg, you would be able to create a trust token from a trust token
22:31:48 <morganfainberg> asalkeld, a different trust?
22:31:52 <asalkeld> yes
22:32:00 <adrian_otto> one of a lesser scope, right?
22:32:07 <morganfainberg> adrian_otto, i would hope so
22:32:10 <asalkeld> each service needs a trust_id
22:32:16 <asalkeld> (yes)
22:32:32 <asalkeld> solum is totally broken without this
22:32:47 <asalkeld> my suggestion is to just use keystone oauth
22:32:50 <morganfainberg> so you'd scope to X, which would have permission to scope to Y,Z,and Q
22:33:00 <morganfainberg> via trusts.
22:33:29 <asalkeld> morganfainberg, yip
22:33:45 <morganfainberg> asalkeld, if keystone oauth would be sufficient i think it would be better than trying to secure chained trusts like that.  i see so many security issues and edge cases with that kind of trust scoping
22:33:57 <asalkeld> agree
22:34:11 <asalkeld> tho' I am not an auth guru
22:34:38 <morganfainberg> asalkeld, it might... might be a security concern since oauth i don't think limits roles provided
22:34:43 <morganfainberg> in it's current implementation
22:35:03 <asalkeld> morganfainberg, I'll ask about it
22:35:28 <asalkeld> not sure what the heat team plan to do about that)
22:35:29 <morganfainberg> asalkeld, yeah please come over to -keystone channel after your meeting (or a little later this week) and we can hammer out the usecase clearly
22:35:38 <asalkeld> ok
22:35:42 <morganfainberg> asalkeld we might even be able to drag some heat folks in.
22:35:50 <morganfainberg> if they're around
22:35:52 <devkulkarni> asalkeld: please mention when you plan to meet with keystone folks
22:35:55 <asalkeld> maybe a ml discussion
22:36:06 <adrian_otto> asalkeld: would you feel comfortable taking an action item to follow up with the keystone team?
22:36:06 <devkulkarni> +1 to ml discussion as well
22:36:10 <morganfainberg> ML would be good too (better) to seed the convo at least
22:36:17 <asalkeld> adrian_otto, for sure
22:37:05 * morganfainberg goes back to lurking.
22:37:13 <devkulkarni> thanks morganfainberg
22:37:18 <adrian_otto> #action asalkeld follow up with keystone team by ML, and IRC (as needed) to explore options for multi-service trust tokens, OAuth, or chaining, and finding the right fit for Solum.
22:37:19 <paulmo> Good trusts and OAuth article: http://adam.younglogic.com/2013/03/trusts-and-oauth/
22:37:30 <morganfainberg> devkulkarni, of course!
22:37:49 <morganfainberg> we have some ideas on some composite token magic we want to implement but i'll look for the ML topic, the composite token might suit your needs as well.
22:37:53 <adrian_otto> ok, so our current topic is Mistral Inegration
22:38:01 <adrian_otto> Integration
22:38:02 <morganfainberg> anyway.. cheers and catch you all later
22:38:08 <adrian_otto> tx again morganfainberg
22:38:16 <tomblank1> thx morganfainberg:
22:38:31 <asalkeld> so re: mistral integration
22:38:48 <asalkeld> I think (besides auth) it will be in good shape soon
22:39:08 <asalkeld> there are some needed patches inflight
22:39:22 <devkulkarni> in mistral?
22:39:26 <adrian_otto> ok, does anyone have further concerns or remarks regarding Mistral Integration?
22:39:27 <asalkeld> yip
22:39:29 <devkulkarni> do we need any action from us?
22:39:49 <asalkeld> i think we should be involved in mistral
22:40:11 <adrian_otto> asalkeld: +1
22:40:26 <asalkeld> but we can start using it really soon
22:40:46 <asalkeld> (auth will stop us doing useful stuff tho')
22:40:50 <adrian_otto> so let's become a Mistral user as discussed in Atlanta, and see where that takes us
22:41:02 <devkulkarni> +1
22:41:08 <asalkeld> that is the most important issue right now
22:41:30 <adrian_otto> worst case we can persist account credentails in barbican, and individually auth to separate services as needed
22:41:43 <adrian_otto> and we can shed that for a more elegant solution once we find the right approach
22:41:56 <adrian_otto> my understanding is that Heat made the same first step, right?
22:42:12 <adrian_otto> but even worse, because it stored the account username and password in its own db
22:42:14 <asalkeld> yeah, but it's nasty
22:42:15 <devkulkarni> there was no barbican then :P
22:42:24 <adrian_otto> right
22:42:34 <adrian_otto> but sometimes progress requires a little nasty
22:42:50 <adrian_otto> so let's see if there is something we can do in limited scope with the auth facilities we already have
22:42:51 <paulczar> just use the admin user/tenant until oath is ready ?
22:43:07 <adrian_otto> paulczar: seems to me that would work for now
22:43:22 <julienvey> paulczar: simple but works fine for now, +1
22:43:23 <devkulkarni> not a bad option (although we have to deal with namespaces for stacks and such)
22:43:27 <asalkeld> paulczar, it's what to do when mistral is doing something on our part
22:43:33 <adrian_otto> except you would not want to allow end users to modify workflows
22:43:42 <adrian_otto> unless they treat Solum as a single tenant system
22:43:53 <asalkeld> so we would have to imbed user/pass into mistral tasks
22:43:56 <devkulkarni> we have discussed admin user/tenant option on and off..
22:44:54 <asalkeld> (maybe the target/environment can help)
22:45:29 <asalkeld> but when we get a git hook, we need to get a token - it would need to be based on user/password
22:46:16 <asalkeld> mmm - ok : I'll look at a plan "b"
22:46:21 <adrian_otto> user/password = barbican secret token
22:46:48 <adrian_otto> let's only go that route if it's clearly less work than adding missing capability to keystone
22:47:02 <julienvey> we should be able to come with oauth pretty soon, keystone doc about that is quite good
22:47:05 <asalkeld> maybe our target/env can have a barbican reference
22:47:10 <adrian_otto> or the new stuff for keystone is controversial to the extent it can't land soon
22:47:16 <devkulkarni> julienvey: do you have a link?
22:47:31 <julienvey> yes, 1s
22:47:34 <julienvey> https://github.com/openstack/keystone/blob/bab63bff9dc4fb94912f1e9b8a7bba8445f34fd5/doc/source/extensions/oauth1.rst
22:47:35 <asalkeld> adrian_otto, for oauth we don't need changes to keystone
22:47:37 <julienvey> https://review.openstack.org/#/c/80193/15/examples/scripts/exercise_v3_oauth.py
22:47:38 * paulmo is still not sure what is missing in KeyStone.  It has trusts, it has OAuth1a...
22:48:01 <julienvey> https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-oauth1-ext.md#create-request-token-post-os-oauth1request_token
22:48:01 <devkulkarni> paulmo: we need chained trusts. ks is missing that right now.
22:48:10 <devkulkarni> julienvey: thanks!
22:48:11 <adrian_otto> asalkeld: yes, we could have an "unauthenticated" Environment per tenant where there is a trust token scoped to a mistral workflow, right?
22:48:11 <asalkeld> I need to go take my boy to school...
22:48:37 <adrian_otto> tanks asalkeld
22:48:52 <adrian_otto> devkulkarni: we have a whole pile of discussion topics for today
22:48:55 <asalkeld> adrian_otto, trust tokens in their current form won't work
22:49:13 <devkulkarni> adrian_otto: we can take some of them and continue for others next week?
22:49:14 <adrian_otto> Language Packs, STI, Task Review
22:49:24 <devkulkarni> btw, the chained trust discussion is done
22:49:33 <adrian_otto> which are time sensitive, and which should we push?
22:49:46 <devkulkarni> time sensitive is custom lang pack
22:49:51 <adrian_otto> ok
22:50:02 <adrian_otto> #topic Custom Language Pack Discussion
22:50:07 <adrian_otto> go
22:50:10 <devkulkarni> I wanted to brain storm what is a custom lang pack and how would we go about implementing it..
22:50:30 <devkulkarni> noorul and I discussed some of it which is captured in an etherpad
22:50:42 <adrian_otto> I have a concept of this
22:50:43 <devkulkarni> https://etherpad.openstack.org/p/custom-language-packs
22:50:55 <adrian_otto> you register an app "type" by creating a language pack resource
22:51:12 <adrian_otto> and that type has a Git Repo associated with it
22:51:31 <julienvey> a LP is basically is a glance image
22:51:43 <adrian_otto> Solum will git clone that repo, and execute a well known script within it
22:51:50 <devkulkarni> yes, and a custom one is an image which has custom tools/libraries installed
22:52:05 <julienvey> so we miss only the builder to build the app with this LP ?
22:52:09 <adrian_otto> that should run in the context of the related glance image
22:52:25 <paulczar> is there a difference between an LP and a custom LP apart from who created and uploaded it ?
22:52:34 <adrian_otto> that way a service provider can externally maintain a custom LP
22:52:45 <adrian_otto> paulczar: I hope not.
22:52:46 <devkulkarni> paulczar: I don't think so..
22:52:54 <paulczar> good :)
22:53:32 <adrian_otto> devkulkarni: we might need to revisit this next week
22:53:39 <devkulkarni> okay.. I think this is a good discussion.. this is what I had in mind.. for want to time I suggest we continue next week
22:53:43 <adrian_otto> or plan to follow up between now and then
22:53:44 <devkulkarni> yep
22:53:54 <adrian_otto> what are you blocked on?
22:54:01 <devkulkarni> nothing specifically.
22:54:10 <paulczar> we should require two entrypoints in the image a ‘build’ and a ‘run’ …    probably need some way to specify if the build is ‘slug’ style or ‘whole image’ style
22:54:11 <adrian_otto> ok
22:54:12 <devkulkarni> just wanted to discuss what folks had in mind
22:54:25 <adrian_otto> #topic Open Discussion
22:54:35 <adrian_otto> I will move remaining topics to next week's agenda for us
22:54:36 <tomblank1> devkulkarni: we can always start up a ML discussion as well if needed before next week
22:55:10 <devkulkarni> sounds good adrian_otto
22:55:35 <devkulkarni> In 5 minutes, what do we need for this "	Nova docker driver improvements" :)
22:55:44 <adrian_otto> so an LP could either be an image that has a well known script inside of it that the instance executes
22:55:48 <devkulkarni> Its here: https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap
22:55:48 <datsun180b> devkulkarni: improve it
22:55:52 * datsun180b dusts off hands
22:55:52 <devkulkarni> ha ha
22:55:55 <adrian_otto> or an external repo with a well known script in it
22:57:17 <adrian_otto> nova-docker has weak Glance integration which must be addressed
22:57:27 <paulczar> devkulkarni: support for environment variables, a default set with the image +  a lightweight version of cloud-init that turns user-data into env variable to override
22:57:28 <adrian_otto> it needs a sensible multi-tenancy setup.
22:57:40 <adrian_otto> one way is to bypass the glance-registry and access glance directly
22:57:57 <adrian_otto> s/glance-registry/docker-registry service/
22:58:13 <paulczar> devkulkarni: ability to specify custom docker registry endpoint per image/user/tenant/whatever
22:58:25 <devkulkarni> is this all being done by the openstack-containers team? why is it on solum's roadmap as a list of deliverables?
22:59:07 <devkulkarni> thanks adrian_otto and paulczar for details
22:59:11 <adrian_otto> it can move from our roadmap when other teams commit to them as deliverables.
22:59:18 <adrian_otto> but until them, we see them as our concerns
22:59:27 <paulczar> devkulkarni: ability to register an empty image in glance which has enough details for nova-docker to go and fetch the image from provided registry
22:59:27 <devkulkarni> okay. makes sense.
22:59:28 <adrian_otto> ok, time has elapsed for our meeting
22:59:35 <adrian_otto> thanks everyone for attending
22:59:39 <tomblank1> and we (Solum team) may have to actually develop that code
22:59:46 <adrian_otto> tomblank1: yes
22:59:56 <adrian_otto> #endmeeting