#openstack-meeting-alt: Marconi

Meeting summary

1. Review last week's actions (kgriffs1, 19:05:37)
   1. kgriffs to kick the tires on Pecan (kgriffs1, 19:05:50)
   2. http://github.com/racker/falcon (kgriffs1, 19:12:50)
   
   
2. Review the g1 milestone (kgriffs1, 19:17:18)
   1. https://launchpad.net/marconi/+milestone/grizzly-1 (kgriffs1, 19:18:08)
   2. Set up Marconi wiki, repo, Launchpad, etc. (kgriffs1, 19:18:35)
   3. Define v1.0 functional and non-functional requirements (kgriffs1, 19:19:15)
   4. http://wiki.openstack.org/marconi/specs/grizzly (kgriffs1, 19:20:09)
   5. Define v1.0 API (kgriffs1, 19:21:47)
   6. Create a skeleton implementation and test suite (kgriffs1, 19:23:48)
   7. ACTION: kgriffs1 to move coding to g2 (kgriffs1, 19:25:47)
   
   
3. Decide whether to support tags or some other fanout mechanism, or just stick with N-queue approach (for v1.0 at least) (kgriffs1, 19:27:02)
   1. AGREED: Have concrete queues (kgriffs1, 19:30:25)
   2. AGREED: No tags or fanout for v1 (kgriffs1, 19:34:50)
   
   
4. Consider splitting the API into two namespaces, one for work queuing and one for eventing (kgriffs1, 19:36:37)
   1. Pro: Allows for different scaling architectures, storage backends, etc. (kgriffs1, 19:37:34)
   2. Pro: Simplifies semantics for the two major use cases (kgriffs1, 19:37:42)
   3. Con: Remove affordances - clients won't be able to mix/match semantics (we would be effectively removing features) (kgriffs1, 19:38:11)
   4. http://wiki.openstack.org/marconi/specs/api/v1 (kgriffs1, 19:43:30)
   5. http://wiki.openstack.org/marconi/specs/api/v1 (kgriffs1, 19:52:40)
   6. AGREED: use per-message lock/receipt IDs or just message IDs directly (kgriffs1, 20:16:35)
   7. ACTION: kgriffs1 to update API spec to remove tags, add concrete queues (kgriffs1, 20:21:58)
   8. AGREED: Start some discussion threads on the mailing list (kgriffs1, 20:25:22)
   9. ACTION: everyone think about locking semantics (kgriffs1, 20:26:25)
   10. ACTION: everyone think about / discuss the implications of a unified queue type/namespace and come up with a recommendation for next mtg. (kgriffs1, 20:27:00)

Action items

1. kgriffs1 to move coding to g2
2. kgriffs1 to update API spec to remove tags, add concrete queues
3. everyone think about locking semantics
4. everyone think about / discuss the implications of a unified queue type/namespace and come up with a recommendation for next mtg.

Action items, by person

1. kgriffs1
   1. kgriffs1 to move coding to g2
   2. kgriffs1 to update API spec to remove tags, add concrete queues
2. UNASSIGNED
   1. everyone think about locking semantics
   2. everyone think about / discuss the implications of a unified queue type/namespace and come up with a recommendation for next mtg.

People present (lines said)

1. kgriffs1 (118)
2. treeder (66)
3. openstack (3)
4. edsrzf (2)