Re: [openstack-dev] [heat] Rolling Upgrades

[Michał Dulko]

On 10/21/2016 11:57 PM, Zane Bitter wrote:
> On 21/10/16 08:37, Michał Dulko wrote:
>>> > Finally, a note about Oslo versioned objects: they don't really help
>>> > us. They work great for nova where there is just nova-conductor
>>> > reading and writing to the DB, but we have multiple heat-engines
>>> doing
>>> > that that need to be restarted in a rolling manner. See the
>>> references
>>> > below for greater detail.
>> They do help in case you're changing RPC arguments *content*. In
>> particular they make it easier to modify schema of dict-like structures
>> sent over RPC.
>
> This is technically true, but there's a much simpler solution to that
> which we already have: just don't change the content in
> non-backward-compatible ways (i.e. you can add stuff but not
> change/rename/remove stuff).
>
> We have to do that anyway, because this is effectively our user
> interface, so if we didn't we'd break clients. For that reason, we're
> already much more strict about this than required to avoid this
> problem in the RPC layer.

Sure, it's about compatibility, so if nothing ever changes, then you're
fine.

>
> As Crag said, the problem we do have is when we add flags/arguments to
> a message, how can we ensure that older versions of the engine still
> interpret it correctly.

In Cinder we're assuming you cannot send a message containing some new
flags/arguments if the environment is running services in various
versions. It's better to fail fast and possibly with a message to the
user, than to do something he haven't asked for.

Thanks,
Michal


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [chef] draft logo & sneak peek

[Samuel Cassiba]

Ohai Chefs,

Here is the draft of our project logo. As you may remember, we requested a 
kangaroo some time ago to resemble the Xzibit meme-like way of how we deploy 
OpenStack, and this is the draft of that decision. I have enclosed the original 
message, which includes a link for feedback.

Since neither myself nor the other cores will be at the PTG, we’ll have to work 
out some way to get the final product distributed if interested.

Have a great Summit!

Best,
Samuel Cassiba
Project Team Lead, OpenStack Chef

> Begin forwarded message:
> 
> From: Heidi Joy Tretheway 
> Subject: Your draft logo & sneak peek
> Date: October 21, 2016 at 10:12:54 PDT
> To: Samuel Cassiba 
> 
> Hi,
> 
> We're excited to show you the draft version of your project logo, attached. 
> We want to give you and your team a chance to see the mascot illustrations 
> before we make them official, so we decided to make Barcelona the draft 
> target, with final logos ready by the Project Team Gathering in Atlanta in 
> February. 
> 
> Our illustrators worked as fast as possible to draft nearly 60 logos, and 
> we're thrilled to see how they work as a family. Here's a 50-second "sneak 
> peek" at how they came together: https://youtu.be/JmMTCWyY8Y4 
> 
> 
> We welcome you to share this logo with your team and discuss it in Barcelona. 
> We're very happy to take feedback on it if we've missed the mark. The style 
> of the logos is consistent across projects, and we did our best to 
> incorporate any special requests, such as an element of an animal that is 
> especially important, or a reference to an old logo.
> 
> We ask that you don't start using this logo now since it's a draft. Here's 
> what you can expect for the final product:
> A horizontal version of the logo, including your mascot, project name and the 
> words "An OpenStack Community project"
> A square(ish) version of the logo, including all of the above
> A mascot-only version of the logo
> Stickers for all project teams distributed at the PTG
> One piece of swag that incorporates all project mascots, such as a deck of 
> playing cards, distributed at the PTG
> All digital files will be available through the website
> 
> We know this is a busy time for you, so to take some of the burden of 
> coordinating feedback off you, we made a feedback form: 
> http://tinyurl.com/OSmascot   You are also 
> welcome to reach out to Heidi Joy directly with questions or concerns. Please 
> provide feedback by Friday, Nov. 11, so that we can request revisions from 
> the illustrators if needed. Or, if this logo looks great, just reply to this 
> email and you don't need to take any further action.
> 
> Thank you!
> Heidi Joy Tretheway - project lead
> Todd Morey - creative lead
> 
> P.S. Here's an email that you can copy/paste to send to your team (remember 
> to attach your logo from my email):
> 
> Hi team, 
> I just received a draft version of our project logo, using the mascot we 
> selected together. A final version (and some cool swag) will be ready for us 
> before the Project Team Gathering in February. Before they make our logo 
> final, they want to be sure we're happy with our mascot. 
> 
> We can discuss any concerns in Barcelona and you can also provide direct 
> feedback to the designers: http://tinyurl.com/OSmascot 
>   Logo feedback is due Friday, Nov. 11. To get a 
> sense of how ours stacks up to others, check out this sneak preview of 
> several dozen draft logos from our community: https://youtu.be/JmMTCWyY8Y4 
> 
> 
>   
> Heidi Joy Tretheway
> Senior Marketing Manager, OpenStack Foundation
> 503 816 9769  | Skype: heidi.tretheway 
> 
>     
>  
> 
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [telemetry][ceilometer]when the rabbitmq queue isfull of the message. ceilometer-collector is killed.

[gordon chung]

glad you found the solution. :)

On 24/10/16 01:52 AM, 张盛平 wrote:
> Hello everyone, I think I have found something related. sorry for troubling.
>
>  https://bugs.launchpad.net/ceilometer/+bug/1551667
>
>
>

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] Team meeting this week cancelled

[Rabi Mishra]

Hi All,

I'm cancelling our IRC meeting this week, as many of us are attending the
Summit. We would have our meeting next week as scheduled.

-- 
Regards,
Rabi Misra
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Magnum] Magnum Sessions for Barcelona Summit Attendees

[Adrian Otto]

Team,

For those of you attending the Barcelona summit this week, please add the 
following sessions to your calendar, in addition to the Containers track:

https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Magnum%3A

If there are any additional topics you would like to cover with the team, 
please add them to our Friday afternoon meetup:

https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17216

Thanks,

Adrian Otto
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Project name DB length

[Adrian Turjak]

On 21/10/16 04:30, Adam Young wrote:
>
> No. keep them short.  We are working toward a scheme where you can
> nest the names like this"
>
>
> parent/child1/child2
>
>
> But if you make them too long, that becomes a disaster.  There is a
> strict option in the config file that prevents you from making names
> with non-URL safe characters.  Set that option.

Nested names is the exact reason I want 64+ char project names. I
apologies for the long in email in advance, but let me give you the
context for this.

I do remember a series of specs that were meant to work towards your
suggestion but they all seemed to have been abandoned.

This is the review/spec series that I remember reading through:
https://review.openstack.org/#/c/310048/ --abandoned
https://review.openstack.org/#/c/318605/ --abandoned
https://review.openstack.org/#/c/332940/

The latter of which still doesn't really solve the problem in a useful
way. I was looking forward to project names being unique only in the
parent scope. I can understand why that isn't possible, because people
still use project names rather than ids (a bad practice), and because
without a full path a name doesn't make sense. Are there any other specs
around this topic I've missed?

I'm trying to make single domain HMT work via a service that will
enforce the full project hierarchy and url safety in the name. Much like
was proposed here: https://review.openstack.org/#/c/318605

We are running  a public cloud and while we would love to transition to
giving each client a domain, we aren't able to do that yet, and it will
complicate matters a hell of a lot (especially for customer login,
domain/username/password).

With emails as our usernames we get around the username constraint in a
single domain easily enough, and a management service which allows for
per project user management for clients to invite their own users once
given access. So the only problem we have is no HMT support right now
and project name uniqueness. Also no groups, as groups make no sense
outside of having your own domain (although I may have ideas around this
limitation anyway).

The project name uniqueness per domain still stings though because even
given a full domain a client can't do this:

MyCompanyName (as domain) > CompanyDepartment1 > Project1 > development
MyCompanyName (as domain) > CompanyDepartment1 > Project1 > production
MyCompanyName (as domain) > CompanyDepartment1 > Project2 > development
MyCompanyName (as domain) > CompanyDepartment1 > Project2 > production
MyCompanyName (as domain) > CompanyDepartment2 > Project1 > development
MyCompanyName (as domain) > CompanyDepartment2 > Project1 > production

Having 'CompanyDepartment_' as a subdomain would help, but only a little.

Making those full paths would work, but would mean longer names:

MyCompanyName (as domain) > CompanyDepartment1
MyCompanyName (as domain) > CompanyDepartment1/Project1
MyCompanyName (as domain) > CompanyDepartment1/Project1/development - 39
chars, so not to bad, still room to go deeper
MyCompanyName (as domain) > CompanyDepartment1/Project1/production

In single domain:
default (as domain) >
MyCompanyName/CompanyDepartment1/Project1/development - 53 chars,
getting close...

64 characters still gives most people enough to work with, but does
impose a limit I'd rather not inflict on customers. Even 100 would be
better. While I could simply edit the code and migrate our own
deployment I would prefer to make the change upstream and backport in
the knowledge we won't be carrying it forever.

Although... if there is a better solution to this, I'd take it, but from
what I've been reading true HMT has mostly been pushed aside with the
suggestion to just give everyone their own domain (which still has the
project name constraint, and isn't an option for us right now).

I just want to get useful HMT working for our cloud and I think I can
get it mostly there through our management tasks service (a proxy
service that works with keystone on a user's behalf and allows us more
control), and the current features keystone supports (project parents,
inherited roles). The only real barrier I can see is people reaching the
character limit.

Hopefully that explains why I'd prefer longer project names than 64
char, but if you can give me an alternative I'd take it.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][zaqar][telemetry] Subscribing to events

[Zane Bitter]

On 22/10/16 10:38, Thomas Herve wrote:

Hi all,

One of my long time goal since I started contributing to OpenStack is
to try to remove polling where I can. With Zaqar WebSocket support, we
now have a transport available for users to connect to, and where we
can push notifications. We already leveraged that in Heat [1], so that
you can manipulate a stack and you'll be notified when its status
changes.

Still, not everyone uses Heat, and under the hood it still polls for
you. We should be able to use the various notifications that projects
publish to push similar events. Ceilometer already consumes those
notifications and try to make them somewhat consumable [2].

The missing piece is something that bridges Ceilometer and Zaqar. I
wrote a small service [3] which provide a simple API, so that you can
say "Subscribe to those events and send them to this queue". The data
flow looks like this:

Service (Nova, Neutron) -> Notification -> Ceilometer -> Bridge ->
Zaqar -> User.

This way, you'll get a Zaqar message per event, with some filtering
done by the bridge service. It's far from being ideal, as the
notification format is a endless topic of conversation, but I hope
that if we start using it things will move further. I also hope I can
get some feedback on the approach.


Could you document what makes this different from 
http://docs.openstack.org/developer/aodh/event-alarm.html? (I can think 
of some ways, but it's not clear to me whether a separate service is the 
right thing or if the existing Aodh event alarms can be modified to do 
what we want.)



One question is whether we want to skip the subscription phase, and
simply makes all those events available to users at a known place (for
example, all events in the Zaqar queue events-queue, or maybe all Nova
events in the compute-events-queue). That pushes filtering to the
user, but it also simplifies the bootstrap phase.

Anyway, I wanted to send this before the summit so that people
interested can come talk to me.

Thanks,




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][VMT][Security] Glance coresec reorg

[Mikhail Fedosin]

Agree :) +1 for both of them!

Best,
Mike

On Mon, Oct 24, 2016 at 6:31 PM, Michael Xin  wrote:

> +1 for both.
>
> yours,
> Michael
>
> On Fri, Oct 21, 2016 at 3:07 AM, Flavio Percoco  wrote:
>
>> On 20/10/16 12:33 -0700, Steve Lewis wrote:
>>
>>> I'm not voicing as a core here, but in the course of several cycles I
>>> have
>>> seen Erno and Ian each providing the care and insight needed by this role
>>> and trust them to do the job well.
>>>
>>>
>> +1k to the above!
>>
>> Thank you both for stepping up for this critical task.
>> Flavio
>>
>>
>>
>>> On Wed, Oct 19, 2016 at 3:50 PM, Jeremy Stanley 
>>> wrote:
>>>
>>> On 2016-10-18 22:22:28 + (+), Brian Rosmaita wrote:
 > Thus, the main point of this email is to propose Ian Cordasco and Erno
 > Kuvaja as new members of the Glance coresec team.  They've both been
 > Glance cores for several cycles, have a broad knowledge of the
 software
 > and team, contribute high-quality reviews, and are conversant with
 good
 > security practices.
 [...]

 Sounds good to me. From a VMT perspective, I'm just happy to see
 Glance keeping active participants with available bandwidth looking
 at prospective vulnerability reports so we can continue to churn
 through them faster and make them public sooner. Thanks for keeping
 the wheels turning!
 --
 Jeremy Stanley

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.op
 enstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



>>>
>>> --
>>> SteveL
>>>
>>
>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][octavia][tacker][designate][manila][sahara][magnum][infra] servicevm working group meetup

[Adam Harwell]

I'll be there.

On Mon, Oct 24, 2016, 20:29 Doug Wiegley 
wrote:

>
> On Oct 24, 2016, at 8:23 PM, Doug Wiegley 
> wrote:
>
> As part of a requirements mailing list thread [1], the idea of a servicevm
> working group, or a common framework for reference openstack service VMs,
> came up. It's too late to get onto the official schedule, but unofficially,
> let's meet here:
>
> When: Tuesday, 1:30pm-2:10pm
> Where: CCIB P1 Room 128
>
> If this is too short notice, then we can retry on Friday.
>
> Thanks,
> doug
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105861.html
>
>
> And an etherpad:
>
> https://etherpad.openstack.org/p/ocata-summit-servicevm
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][octavia][tacker][designate][manila][sahara][magnum][infra] servicevm working group meetup

[Doug Wiegley]

> On Oct 24, 2016, at 8:23 PM, Doug Wiegley  
> wrote:
> 
> As part of a requirements mailing list thread [1], the idea of a servicevm 
> working group, or a common framework for reference openstack service VMs, 
> came up. It's too late to get onto the official schedule, but unofficially, 
> let's meet here:
> 
> When: Tuesday, 1:30pm-2:10pm
> Where: CCIB P1 Room 128
> 
> If this is too short notice, then we can retry on Friday.
> 
> Thanks,
> doug
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105861.html
> 

And an etherpad:

https://etherpad.openstack.org/p/ocata-summit-servicevm 



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [trove][octavia][tacker][designate][manila][sahara][magnum][infra] servicevm working group meetup

[Doug Wiegley]

As part of a requirements mailing list thread [1], the idea of a servicevm 
working group, or a common framework for reference openstack service VMs, came 
up. It's too late to get onto the official schedule, but unofficially, let's 
meet here:

When: Tuesday, 1:30pm-2:10pm
Where: CCIB P1 Room 128

If this is too short notice, then we can retry on Friday.

Thanks,
doug

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-October/105861.html



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][VMT][Security] Glance coresec reorg

[Michael Xin]

+1 for both.

yours,
Michael

On Fri, Oct 21, 2016 at 3:07 AM, Flavio Percoco  wrote:

> On 20/10/16 12:33 -0700, Steve Lewis wrote:
>
>> I'm not voicing as a core here, but in the course of several cycles I have
>> seen Erno and Ian each providing the care and insight needed by this role
>> and trust them to do the job well.
>>
>>
> +1k to the above!
>
> Thank you both for stepping up for this critical task.
> Flavio
>
>
>
>> On Wed, Oct 19, 2016 at 3:50 PM, Jeremy Stanley 
>> wrote:
>>
>> On 2016-10-18 22:22:28 + (+), Brian Rosmaita wrote:
>>> > Thus, the main point of this email is to propose Ian Cordasco and Erno
>>> > Kuvaja as new members of the Glance coresec team.  They've both been
>>> > Glance cores for several cycles, have a broad knowledge of the software
>>> > and team, contribute high-quality reviews, and are conversant with good
>>> > security practices.
>>> [...]
>>>
>>> Sounds good to me. From a VMT perspective, I'm just happy to see
>>> Glance keeping active participants with available bandwidth looking
>>> at prospective vulnerability reports so we can continue to churn
>>> through them faster and make them public sooner. Thanks for keeping
>>> the wheels turning!
>>> --
>>> Jeremy Stanley
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>
>> --
>> SteveL
>>
>
> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle]design summit sessions and no IRC meeting this week.

[joehuang]

Hello, team,

The OpenStack design summit will be held this week, so no IRC meeting this 
week. You can find venue, time and session topics for the design summit 
sessions here:

https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Tricircle%3A

https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Tricircle

If you are not able to attend the sessions in Barcelona F2F, you can also find 
the etherpad link through the link mentioned above and join the discussion via 
etherpad.

Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [classifier] At the Summit: Common Classifier + OVS Flow Management

[Duarte Cardoso, Igor]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Romance Standard Time
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Duarte Cardoso, Igor":MAILTO:igor.duarte.card...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=OpenStack 
 Development Mailing List (not for usage questions):MAILTO:openstack-dev@li
 sts.openstack.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Miguel Ang
 el Ajo Pelayo:MAILTO:majop...@redhat.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ihar Hrac
 hyshka':MAILTO:ihrac...@redhat.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Vikram Ch
 oudhary':MAILTO:vikram.choudh...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Sean M. C
 ollins':MAILTO:s...@coreitpro.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Haim Dani
 el':MAILTO:hdan...@redhat.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Mathieu R
 ohon':MAILTO:mathieu.ro...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Shaughness
 y, David":MAILTO:david.shaughne...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Eichberger
 , German":MAILTO:german.eichber...@hpe.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Cathy Zhan
 g:MAILTO:cathy.h.zh...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Henry Four
 ie:MAILTO:louis.fou...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Armando M.
 :MAILTO:arma...@gmail.com
DESCRIPTION;LANGUAGE=en-US:Hi again\,\n\nI’m setting the meeting for Thur
 sday 12:30pm\, at the Hilton (P0 - Ballroom Foyer).\nLet’s gather togeth
 er and talk about these 2 efforts.\n\n
 _\nFrom: Duarte Cardoso\, Igor [mailto:igor.duarte.cardoso@intel.c
 om]\nSent: Thursday\, October 20\, 2016 3:08 PM\nTo: openstack-dev@lists.o
 penstack.org\; Miguel Angel Ajo 
 Pelayo >\; 'Ihar Hrachyshk
 a' >\; 'Vikram Choudhary' 
 >\; 'Sean 
 M. Collins' >\; 'Haim Daniel
 ' >\; 'Mathieu Rohon' >\; Shaughnessy\, David 
 >\; Eichbe
 rger\, German 
 >\; Cathy Zhang 
 >\; Henry Fourie >
 \; Armando M. >\nSubject: [ope
 nstack-dev] [neutron] [classifier] At the Summit: Common Classifier + OVS 
 Flow Management\n\n\nHi\,\n\nTwo etherpads were created on the last meetin
 g as placeholders to what can be discussed at the summit regarding the com
 mon classification framework/classifier and the OVS flow manager:\nhttps:/
 /etherpad.openstack.org/p/neutron-common-classification-framework-barcelon
 a\nhttps://etherpad.openstack.org/p/neutron-ovs-flow-management-barcelona\
 nFeel free to add topics to the pads.\n\nHow/where would you like to meet 
 at the summit to discuss future work on these 2 efforts?\nI’m okay meeti
 ng during lunch time from Tuesday to Friday\, or even during Monday\, or a
 t the contributors meet-up on Friday.\nThoughts?\n\nBest regards\,\nIgor.\
 n\n
SUMMARY;LANGUAGE=en-US:[neutron] [classifier] At the Summit: Common Classif
 ier + OVS Flow Management
DTSTART;TZID=Romance Standard Time:20161027T123000
DTEND;TZID=Romance Standard Time:20161027T14
UID:04008200E00074C5B7101A82E0089082FD080D2ED201000
 01000F91FB92F8F6B4F4B80025D1CCB7EDEBD
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20161024T134401Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:Hilton (P0 - Ballroom Foyer)
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:1981327328
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] [networking-sfc][devstack][mitaka] Chain doesn't work

[Alioune]

Hi all,

I'm trying to implement service chain in OpenStack using networking-sfc
(stable/mitaka) and OVS 2.5.90


The following is the architecture I used :

SRC DST
  ||
  == br-int 
 |
   SF1
SF1: 55.55.55.3
SRC: 55.55.55.4
DST: 55.55.55.5

I can create port-pairs, port-pair-group, classifier and chain with these
commands:

neutron flow-classifier-create  --ethertype IPv4  --source-ip-prefix
55.55.55.4/32  --logical-source-port 0009034f-4c39-4cbf-be7d-fcf82dad024c
--protocol icmp  FC1
neutron port-pair-create --ingress=p1 --egress=p1 PP1
neutron port-pair-group-create --port-pair PP1 PG1
neutron port-chain-create --port-pair-group PG1 --flow-classifier FC1 PC1

I could ping from SRC to DST before setting the chain, but after the chain
creating ping doesn't work.

ICMP echo request packets arrive to SF1 port but it doesn't send back the
packets in order to allow them to get their destination DST (see output
below).

The Opendaylight/SFC project uses NSH aware service function (SF) that send
back packets to the chains after analyzing them, I would like to know :

- How networking-sfc configures SF to send back packets to the chain as
seem in some of your presentation ?
- What's wrong in my configurations (see commands and ovs-ofctl output
below) ? I've followed the main steps described in your wiki page.

Best Regards,


vagrant@vagrant-ubuntu-trusty-64:~$ neutron port-list
+--+--+---+--+
| id   | name | mac_address   |
fixed_ips
|
+--+--+---+--+
| 0009034f-4c39-4cbf-be7d-fcf82dad024c |  | fa:16:3e:dd:16:f7 |
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
"55.55.55.4"}|
| 082e896d-5982-458c-96e7-0dd372d3d7d9 | p1   | fa:16:3e:90:b4:67 |
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
"55.55.55.3"}|
| 2ad109e4-42a8-4554-b884-a32344e91036 |  | fa:16:3e:74:9a:fa |
{"subnet_id": "3cf6eb27-7258-4252-8f3d-b6f9d27c948b", "ip_address":
"192.168.105.2"} |
| 51f055c0-ff4d-47f4-9328-9a0d7ca204f3 |  | fa:16:3e:da:f9:93 |
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
"55.55.55.1"}|
| 656ad901-2bc0-407a-a581-da955ecf3b59 |  | fa:16:3e:7f:44:01 |
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
"55.55.55.2"}|
| b1d14a4f-cde6-4c44-b42e-0f0466dba32a |  | fa:16:3e:a6:c6:35 |
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
"55.55.55.5"}|
+--+--+---+--+

vagrant@vagrant-ubuntu-trusty-64:~$ ifconfig |grep 082e896d
qbr082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
qvb082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
qvo082e896d-59 Link encap:Ethernet  HWaddr 7e:1a:7b:7d:09:df
tap082e896d-59 Link encap:Ethernet  HWaddr fe:16:3e:90:b4:67

vagrant@vagrant-ubuntu-trusty-64:~$ sudo tcpdump -i tap082e896d-59 icmp
tcpdump: WARNING: tap082e896d-59: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap082e896d-59, link-type EN10MB (Ethernet), capture size
65535 bytes
10:51:10.229674 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 61, length 64
10:51:11.230318 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 62, length 64
10:51:12.233451 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 63, length 64
10:51:13.234496 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 64, length 64
10:51:14.235583 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 65, length 64
10:51:15.236585 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 66, length 64
10:51:16.237568 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 67, length 64
10:51:17.238974 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 68, length 64
10:51:18.244244 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 69, length 64
10:51:19.245758 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 70, length 64
10:51:20.246521 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 71, length 64



vagrant@vagrant-ubuntu-trusty-64:~/openstack_networking/simple-sf$ sudo
ovs-ofctl dump-flows br-int -O OpenFlow13

2016-10-24T11:28:43Z|1|ofp_actions|INFO|OFPAT_SET_MPLS_TTL is
deprecated in OpenFlow13 (use Set-Field)
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0xbbf3cb977f3738c7, duration=2418.957s, table=0, n_packets=2297,
n_bytes=225106, 

[openstack-dev] [release] git-upstream 0.12.0 release

[Darragh Bailey - mailing lists]

Pleased to announce the 0.12.0 release of git-upstream.


With source available at:

http://git.openstack.org/cgit/openstack/git-upstream

Please report any issues through launchpad:

https://bugs.launchpad.net/git-upstream


git-upstream is an open source Python application that can be used to
keep in sync with upstream open source projects, mainly OpenStack.

For more info on what git-upstream is for:

https://pypi.python.org/pypi/git-upstream


Full changelog available from:

_https://git.openstack.org/cgit/openstack/git-upstream/tree/ChangeLog_


For more details see below.

Changes in git-upstream 0.11.0..0.12.0
--

d50f0a3 Changelog for 0.12.0 Release
7dd634a Fix help subcommand
5c0a4a7 Remove compatibility hacks causing issues with newer GitPython
691ae78 Check valid import branch argument value
0e30d38 Report import branch name used by default
f243bd6 Use tag for import branch naming when given
be781cc Support tags for input args
5f4038e Allow SHA1 as reference for inputs
7897e35 Use python for pre/post scripts
47092a9 Fix finish merge to ensure correct contents
54d4876 Always have rebase perform finish
a24debc Ensure correct mode of git-rebase executed
d8bb479 Ensure parent options retained for exec'ed finish
9e077c5 Support old GitPython transform_kwargs signature
79b31d9 Refactor test to allow additional
3b5e241 Fix access for pre-script dict member
b7dc443 Update .gitignore with .eggs path for setuptools
7a135a1 Enable default GIT_PYTHON_TRACE for tests
26c4274 Consolidate to a single separator character
10e8f92 Example in USAGE.md should reference .gitreview
c195b69 Fix broken interactive mode to be usable
307637d Record upstream branch in import merge commit
e231483 Handle all local changes landed upstream
8ab6ccc Detect cherry-picked changes without Change-Id
a05425f Use a recent pbr
f37890b Add tool to recreate git repo from test scenarios
90bf42d Detect when nothing to import
343c3e7 Merge multiple unrelated additional branches
62def85 Support for python 3
0037786 Show rebase help during interactive import
45a617a Simplify USAGE.md example by using a local remote
eaaeae8 Fix / simplify the example patch in USAGE.md
54c40a7 Minor change to the USAGE.md
69ed25e Handle missing merge during initial import
1810d1e Include parent commits in git graph
5687a7b Match name and result of is_detached() method
81ad238 Install coverage and fix command line to call
246439b Refactor import command tests to use scenarios
af6f690 Fix a tiny typo in USAGE
30f6bf2 Update package author/maintainer details
754db13 Consolidate note reference and header constants
4a55a31 Consolidate BadName exception compatibility
9640363 Keep modifications to GitPython objects in single module
fb05151 Support test specific scripts to modify test areas
677c17a Ensure end of arguments marked clearly


Diffstat (except docs and test files)
-

 .gitignore |   2 +
 ChangeLog  |  50 +++
 USAGE.md   |  49 +++
 git_upstream/__init__.py   |   3 +
 git_upstream/commands/__init__.py  |   2 +-
 git_upstream/commands/help.py  |  12 +-
 git_upstream/commands/import.py|  98 +++--
 git_upstream/lib/__init__.py   |  18 +++
 git_upstream/lib/drop.py   |  20 +--
 git_upstream/lib/importupstream.py | 173 --
 git_upstream/lib/note.py   |   5 -
 git_upstream/lib/pygitcompat.py| 100 ++---
 git_upstream/lib/rebaseeditor.py   | 194 +
 git_upstream/lib/searchers.py  | 142 ++
 git_upstream/lib/strategies.py |  26 +++-
 git_upstream/lib/supersede.py  |  22 +--
 git_upstream/lib/utils.py  |   5 +-
 git_upstream/log.py|   9 +-
 git_upstream/main.py   |  22 ++-
 git_upstream/rebase_editor.py  |  44 +++---
 git_upstream/resources/todo_epilogue_1_7_5.txt |  18 +++
 git_upstream/resources/todo_epilogue_2_6_0.txt |  19 +++
 requirements.txt   |  11 +-
 setup.cfg  |   9 +-
 test-requirements.txt  |   3 +-
 tox.ini|   9 +-
 26 files changed, 660 insertions(+), 405 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 9401cff..e93d264 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,4 +1,9 @@
-pbr>=0.5.21,<1.0
-
 argcomplete
-GitPython>=0.3.2.RC1,!=0.3.2
+# GitPython 1.0.1 required by openstack global-requirements
+# python>=3 should work with >=0.3.4
+# python<3 should work with >=0.3.2.RC1,!=0.3.2

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Henry Fourie]

+1


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Rolling Upgrades

[Grasza, Grzegorz]

> From: Crag Wolfe [mailto:cwo...@redhat.com]
> 
> On 10/20/2016 09:30 PM, Rabi Mishra wrote:
> > Thanks Crag on starting the thread. Few comments inline.
> >
...
> >
> > For RPC changes, we don't have a great solution right now (looking
> > specifically at heat/engine/service.py). If we add a field, an older
> > running heat-engine will break if it receives a request from a newer
> > running heat-engine. For a relevant example, consider adding the
> > "root_id" as an argument (
> > https://review.openstack.org/#/c/354621/13/heat/engine/service.py
> > 
> ).
> >
> > Looking for the simplest solution -- if we introduce a mandatory
> > "future_args" arg (a dict) now to all rpc methods (perhaps provide a
> > decorator to do so), then we could follow this pattern post-Ocata:
> >
> > legacy release: accepts the future_args param (but does nothing with
> > it).
> > release+1: accept the new parameter with a default of None,
> >pass the value of the new parameter in future_args.
> > release+2: accept the new parameter, pass the value of the new
> parameter
> >in its proper placeholder, no longer in future_args.
> >
> > This is something similar to the one is being used by neutron for the
> > agents, i.e consistently capturing those new/unknown arguments with
> > keyword arguments and ignoring them on agent side; and by not
> > enforcing newer RPC entry point versions on server side. However,
> > this makes the rpc api less strict and not ideal.
> >
> 
> I'm not sure what the definition of ideal is here. But, full disclaimer is 
> that I've
> thought about RPC a lot less than the DB side. :-)
> 
> FWIW, we might as well be explicit in stating that we only expect two minor
> versions to be running at once (during a rolling upgrade). That is a simpler
> problem than having to support N minor versions.
> 

For heat, RPC compatibility actually isn't that complicated, because you can 
run multiple heat versions with different AMQP virtual hosts, so they 
physically cannot talk to each other.

You begin the rolling upgrade by starting new instances of heat engine with a 
new virtual host, then upgrade all API nodes (connected with a new virtual 
host). When all jobs on the old part of the cluster are done, you can stop old 
heat engine instances.

/ Greg


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [magnum]What version of coreos should I use for stable/mitaka?

[Rikimaru Honjo]

Hello,

I'm using magnum which is stable/mitaka.
And, I failed to create a bay by the following bug.
(I chose coreos as OS, and kubernetes as COE.)

https://bugs.launchpad.net/magnum/+bug/1605554

But I'd like to use still stable/mitaka.
What version of coreos should I use?

Best regards,
--
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntts.co.jp


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] bug deputy report

[John Schwarz]

On Mon, Oct 24, 2016 at 7:39 AM, Das, Anindita  wrote:
> 1.   https://bugs.launchpad.net/neutron/+bug/1635554 - Delete Router /
> race condition
>

I've triaged this bug and assigned it to myself. I'll make sure this
either gets solved or gets the proper attention.

-- 
John Schwarz,
Senior Software Engineer,
Red Hat.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] OpenStack Summit Barcelona: Heat Meetup (evening)

[Rico Lin]

Hola amigos
Let's settle down for a Tuesday meetup
8:00pm at Ten's Tapas Restaurant [1]
Welcome to join us and have fun.

[1]
Ten's Tapas Restaurant Barcelona

Carrer del Rec, 79, 08003 Barcelona
933 19 22 22

https://g.co/kgs/7u7qvG

2016年10月20日 下午2:40，"Rabi Mishra" 寫道：

> Thanks Rico for taking the initiative. Appreciate it. I'm fine for any
> location on any evening other than Monday.
>
> On Thu, Oct 20, 2016 at 8:58 AM, Rico Lin  wrote:
>
>> Hi everyone,
>>
>> We're planning to have an evening Heat contributors meetup in Barcelona
>> Summit.
>> We would like every contributor, ops, users join us and have fun.
>> We need to decide which day of that week would be most suited for all of
>> us. If you would like to attend, please put your name and possible days at:
>> http://doodle.com/poll/dyy6tdnawchnddvy
>>
>> As for location, feel free to suggest any.
>> I would suggest `Bambu Beach Bar`[1], drink and tapas which nearby venue,
>> or `Cervecería Catalana`[2] and Tapas 24 [3] which a little far from the
>> venue. All nice and relax places(Not like the evening place from the last
>> summit I promise!!). Most importantly, all place served beers and drinks(
>> This is very essential if we want to attract our Steve!!).
>>
>>
>> [1] https://www.tripadvisor.com.tw/Restaurant_Review-g187497
>> -d4355271-Reviews-Bambu_Beach_Bar-Barcelona_Catalonia.htm
>> [2] https://www.tripadvisor.com.tw/Restaurant_Review-g187497
>> -d782944-Reviews-Cerveceria_Catalana-Barcelona_Catalonia.html
>> [3] https://www.tripadvisor.com.tw/Restaurant_Review-g187497
>> -d1314895-Reviews-Tapas_24-Barcelona_Catalonia.html
>>
>> --
>> May The Force of OpenStack Be With You,
>>
>> *Rico Lin*irc: ricolin
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Regards,
> Rabi Misra
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [band] OpenStack Summit - Barcelona - musicians please raise your hands

[Neil Jerram]

  Hi Amrith,Is the band still on? I will assume yes, but look forward to more details!     Neil From: Amrith KumarSent: Monday, 19 September 2016 19:56To: OpenStack Development Mailing List (not for usage questions)Reply To: OpenStack Development Mailing List (not for usage questions)Subject: Re: [openstack-dev] [band] OpenStack Summit - Barcelona - musicians please raise your hands







Thanks Neil, sounds like we’ll have a couple of others (who’ve replied privately and not to the ML) bringing instruments as
 well. I have heard so far from:
 
Three guitars
One flute/sax
 
Thanks,
 
-amrith
 



From: Neil
 Jerram [mailto:n...@tigera.io] 
Sent: Monday, September 19, 2016 2:36 PM
To: OpenStack Development Mailing List (not for usage questions) 
Subject: Re: [openstack-dev] [band] OpenStack Summit - Barcelona - musicians please raise your hands


 


I will be happy to bring my clarinet.

 Neil

 


On Sat, Sep 17, 2016 at 7:37 PM Colette Alexander  wrote:


On Sat, Sep 17, 2016 at 1:35 PM, Amrith Kumar  wrote:
> So, would y'all musicians who plan to bring your gear to Barcelona please start a little thread here on the ML and let's get a band going?

I would totally bring my gear if my cello didn't need its own plane seat!

If someone in Spain has a cello though, I will totally play.

-colette/gothicmindfood

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev








__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [mistral] No team meeting - 10/24/2016

[Renat Akhmerov]

Hi,

Since it’s the Summit time again we don’t have a team meeting today. See you in 
Barcelona soon!

Renat Akhmerov
@Nokia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [charms] draft logo design

[James Page]

Hi Charmers

I've received a draft version of our project logo, using the mascot we
selected together. A final version (and some cool swag) will be ready for
us before the Project Team Gathering in February. Before they make our logo
final, they want to be sure we're happy with our mascot.

We can discuss any concerns in Barcelona and you can also provide direct
feedback to the designers:
  http://tinyurl.com/OSmascot

Logo feedback is due Friday, Nov. 11. To get a sense of how ours stacks up
to others, check out this sneak preview of several dozen draft logos from
our community:
  https://youtu.be/JmMTCWyY8Y4

Cheers

James
[image: Charms.jpeg]
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [charms] summit schedule + pads

[James Page]

Hi Charmers

The Ocata Design Summit is upon us; we have fishbowl sessions on Wednesday
afternoon, and workrooms first thing in Friday morning:


https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Charms

I've created pads for the fishbowl sessions:

  https://etherpad.openstack.org/p/BCN-charms-fb-2
  https://etherpad.openstack.org/p/BCN-charms-fb-1

We'll use these to guide the discussion and document outcomes for each of
the topics we need to discuss.

I expect to use the workroom time to spike on some of the topics discussed
on Wednesday.

All contributors are welcome to participate; I expect that a few developers
associated with SDN and Storage integrations are here this week - this is a
great opportunity to catchup with the rest of the OpenStack charms team to
find out about plans for the next development cycle so please come along!

Look forward to seeing you all this week.

Cheers

James
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev