<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div>Thanks for the summary, Tim. Very productive summit!</div><div><br></div><div>I’ve added more notes and a diagram to the HA ether pad. Is that the best way to continue the discussion?</div><div>https://etherpad.openstack.org/p/newton-congress-availability</div><div><br></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Tim Hinrichs <<a href="mailto:tim@styra.com">tim@styra.com</a>><br><span style="font-weight:bold">Reply-To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Date: </span> Tuesday, May 3, 2016 at 11:37 AM<br><span style="font-weight:bold">To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Subject: </span> [openstack-dev] [Congress] Austin recap<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div dir="ltr"><span id="docs-internal-guid-4547ff8c-77e6-0e9b-36b0-841d2a5d26d9"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">Hi all,</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">Here’s a quick summary of the Congress activities in Austin. Everyone should feel free to chime in with corrections and things I missed.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">1. Talks</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">Masahito gave a talk on applying Congress for fault recovery in the context of NFV.</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href="https://www.openstack.org/summit/austin-2016/summit-schedule/events/7199" style="text-decoration:none"><span style="font-size:14.6667px;font-family:Arial;color:rgb(17,85,204);text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">https://www.openstack.org/summit/austin-2016/summit-schedule/events/7199</span></a></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">Fabio gave a talk on applying Congress + Monasca to enforce application-level SLAs.</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href="https://www.openstack.org/summit/austin-2016/summit-schedule/events/7363" style="text-decoration:none"><span style="font-size:14.6667px;font-family:Arial;color:rgb(17,85,204);text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">https://www.openstack.org/summit/austin-2016/summit-schedule/events/7363</span></a></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">2. Integrations</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">We had discussions, both within the Congress Integrations fishbowl session, and outside of that session on potential integrations with other OpenStack projects. Here's a quick overview.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">- Monasca (fabiog). The proposed integration: Monasca pushes data to Congress using the push driver to let Congress know about the alarms Monasca configured. Can use multiple alarms using a single table. Eventually we talked about having Congress analyze the policy to configure the alarms that Monasca uses, completing the loop.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">- Watcher (acabot). Watcher aims to optimize the placement of VMs by pulling data from Ceilometer/Monasca and Nova (including affinity/anti-affinity info), computing necessary migrations for whichever strategy is configured, and migrates the VMs. Want to use Congress as a source of policies that they take into account when computing the necessary migrations.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">- Nova scheduler. There’s interest in policy-enabling the Nova scheduler, and then integrating that with Congress in the context of delegation, both to give Congress the ability to pull in the scheduling policy and to push the scheduling policy.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">- Mistral. The use case for this integration is to help people create an HA solution for VMs. So have Congress monitor VMs, identify when they have failed, and kick off a Mistral workflow to resurrect them.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">- Vintrage. Vintrage does root-cause-analysis. It provides a graph-based model for the structure of the datacenter (switches attached to hypervisors, servers attached to hypervisors, etc.) and a templating language for defining how to create new alarms from existing alarms. The action item that we left is that the Vintrage team will initiate a mailing list thread where we discuss which Vintrage data might be valuable for Congress policies.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">3. Working sessions</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">- The new distributed architecture is nearing completion. There seems to be 1 blocker for having the basic functionality ready to test: at boot, Congress doesn’t properly spin up datasources that have already been configured in the database. As an experiment to see how close we were to completion, we started up the Congress server with just the API and policy engine and saw the basics actually working! When we added the datasources, we found a bug where the API was assuming the datasources could be referenced by UUID, when in fact they can only be referenced by Name on the message-bus. So while there’s still quite a bit to do, we’re getting close to having all the basics working.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">- We made progress on the high-availability and high-throughput design. This is still very much open to design and discussion, so continuing the design on the mailing list would be great. Here are the highlights.</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap"> o Policy engine: split into (i) active-active for queries to deal with high-throughput (ii) active-passive for action-execution (requiring leader-election, etc.). Policy CRUD modifies DB; undecided whether API also informs all policy-engines, or whether they all sync from the DB.</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap"> o Pull datasources: no obvious need for replication, since they restart really fast and will just re-pull the latest data anyhow</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap"> o Push datasources: Need HA for ensuring the pusher can always push, e.g. the pusher drops the message onto oslo-messaging. Still up for debate is whether we also need HA for storing the data since there is no way to ask for it after a restart; one suggestion is that every datasource must allow us to ask for the state. HT does not require replication, since syncing the state between several instances would be required and would be less performant than a single instance. </span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap"> o API (didn’t really discuss this, so here’s my take). No obvious need for replication for HT, since if the API is a bottleneck, the backend will be an even bigger bottleneck. For HA, could do active-active since the API is just a front-end to the message bus + database, though we would need to look into locking now that there is no GIL. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">It was great seeing everyone in Austin!</span></p><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap">Tim</span></span><br><div><span><span style="font-size:14.6667px;font-family:Arial;color:rgb(33,33,33);vertical-align:baseline;white-space:pre-wrap"><br></span></span></div></div>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</blockquote></span></body></html>