#openstack-meeting: swift（2015-08-19）

1. 1. https://wiki.openstack.org/wiki/Meetings/Swift (notmyname, 21:02:41)
   
   
2. hackathon summary (notmyname, 21:02:54) 

    #link https://wiki.openstack.org/wiki/Meetings/Swift

   
   
3. releases (notmyname, 21:32:15)
   1. https://bugs.launchpad.net/swift shows 5 critical ones. (zaitcev, 21:35:19)

       so I want to do a release next week

       it will be 2.4

       so here's a "rule" I'd like to try to follow: if there is any open bug that is marked as critical, it blocks a release

       so if you're looking at a swift bug in launchpad.....rather, "when" you're looking at swift bugs in launchpad, if there's something that must be in the next release, it should be marked critical

       https://bugs.launchpad.net/swift shows 5 critical ones

   
   
4. keystone related patches (notmyname, 21:37:41)
   1. http://paste.openstack.org/show/421542/ (notmyname, 21:37:46)

       yeah, I would like to introduce keystone related patches in swift to get atention from you :-)

       i also try to make vagrant-swift-all-in-one with keystone

   
   
5. open discussion (notmyname, 21:45:33)

    I'm at the openstack ops meetup right now. there's love for swift here. "it just works." "it's very stable" "I don't have to worry about it". etc

   EC Optimizations 

    I think if we had more time at the hackathon, we might have gotten to a discussion regarding small file optimizations for EC.

    Specifically, whether we'd want to go forward with a dual-policy for EC policy for small vs. large objects.

    It probably goes deeper than just "if an object in the EC policy is < certain size, store it via replication".

    the other thing was if a customer sets EC policy, we could reject uploads < some size