[openstack-dev] [nova] Would be possible to modify metadata when instance is in rescued state?

[Pawel Suder]

Hello,


I would like to raise a topic regarding possibilities when metadata could be 
modified on instance.


We noticed that instance metadata could be modified only when vm_state is set 
to following values:

  *   active
  *   paused
  *   suspended
  *   stopped

Found:

https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3916-L3920
https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3905-L3908

>From time to time it is needed to have instance in rescued state.

Scenario: VM is rescued and special metadata attributes need to be set to allow 
cloud-init to act specifically for rescue mode. Metadata data should be 
available only during rescue mode.

Question: what kind of impact could be observed when checks for instance state 
will be modified for methods:

update_instance_metadata
delete_instance_metadata

Thank you,

Cheers,
Pawel
__
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] [nova] Would be possible to modify metadata when instance is in rescued state?

[Michael Still]

This sort of question comes up every six months or so it seems.

The issue is that for config drive users we don't have a way of rebuilding
all of the config drive (for example, the root password is gone). That's
probably an issue for rescue because its presumably one of the things you
might reset.

I'm not opposed to exploring options, but I think we need someone to come
up with a proposal which addresses previous concerns. I'd recommend a quick
search of the mailing list archives for previous discussions.

Hope this helps,
Michael




On Tue, May 9, 2017 at 5:04 PM, Pawel Suder 
wrote:

> Hello,
>
>
> I would like to raise a topic regarding possibilities when metadata could
> be modified on instance.
>
>
> We noticed that instance metadata could be modified only when vm_state is
> set to following values:
>
>
>- active
>- paused
>- suspended
>- stopped
>
> Found:
>
> https://github.com/openstack/nova/blob/master/nova/compute/
> api.py#L3916-L3920
> https://github.com/openstack/nova/blob/master/nova/compute/
> api.py#L3905-L3908
>
> From time to time it is needed to have instance in rescued state.
>
> Scenario: VM is rescued and special metadata attributes need to be set to
> allow cloud-init to act specifically for rescue mode. Metadata data should
> be available only during rescue mode.
>
> Question: what kind of impact could be observed when checks for instance
> state will be modified for methods:
>
> update_instance_metadata
> delete_instance_metadata
>
> Thank you,
>
> Cheers,
> Pawel
>
>
> __
> 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
>
>


-- 
Rackspace Australia
__
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][QoS] No QoS meeting this week

[Sławomir Kapłoński]

Hello,

As many of people are probably on summit we will cancel this week QoS meeting.
Next meeting will be at 23.05.2017.

Pozdrawiam / Best regards
Sławek Kapłoński
sla...@kaplonski.pl


__
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] [tripleo] Validations before upgrades and updates

[mathieu bultel]

On 05/08/2017 01:45 PM, Marios Andreou wrote:
> Hi folks, after some discussion locally with colleagues about
> improving the upgrades experience, one of the items that came up was
> pre-upgrade and update validations. I took an AI to look at the
> current status of tripleo-validations [0] and posted a simple WIP [1]
> intended to be run before an undercloud update/upgrade and which just
> checks service status. It was pointed out by shardy that for such
> checks it is better to instead continue to use the per-service
>  manifests where possible like [2] for example where we check status
> before N..O major upgrade. There may still be some undercloud specific
> validations that we can land into the tripleo-validations repo
> (thinking about things like the neutron networks/ports, validating the
> current nova nodes state etc?).
Yes, I think a bunch of validation: db states, services states, network
connectivity (external, internal)
>
> So do folks have any thoughts about this subject - for example the
> kinds of things we should be checking - Steve said he had some reviews
> in progress for collecting the overcloud ansible puppet/docker config
> into an ansible playbook that the operator can invoke for upgrade of
> the 'manual' nodes (for example compute in the N..O workflow) - the
> point being that we can add more per-service ansible validation tasks
> into the service manifests for execution when the play is run by the
> operator - but I'll let Steve point at and talk about those. 
>
I have a WIP review about that [1], but i need to revisit it a bit, to
add a part into the mistral workflow (Im also writing a POC to create a
mistral workbook for major upgrade and validate minor/major upgrade
before starting [2], I have a third one in progress, not pushed yet, to
implement the major upgrade option in the cli):

[1] https://review.openstack.org/444224
[2] https://review.openstack.org/#/c/462961


> cheers, marios
>
> [0] https://github.com/openstack/tripleo-validations 
> [1] https://review.openstack.org/#/c/462918/
> [2]  
> https://github.com/openstack/tripleo-heat-templates/blob/stable/ocata/puppet/services/neutron-api.yaml#L197
>  
>
>
> __
> 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] [tripleo] DPDK Containerization

[Saravanan KR]

Hello,

We are analyzing the work items needed to containerize DPDK. There is
a work in progress in the kolla image repo for adding DPDK support
[1]. By default, the kolla image will NOT have DPDK support, but only
when enabled at build time. This is because for ubuntu the openvswitch
package is different for DPDK enabled openvswitch. In case of rhel
family, the openvswitch package is only one which has both regular and
DPDK enabled openvswitch. DPDK can be enabled at run time. We can
maintain this run time enabling of DPDK for the containers too. So the
openvswitch containers will have DPDK packages installed, but disabled
by default. Puppet configuration will enable it, if needed.

In order to achieve it, we need to add a template override file for
DPDK based on kolla review [1]. This override should be applicable to
all the openvswitch container images. It can be achieved by adding a
property in overcloud_containers.yaml list to provide specific
template override files, like:

  container_images:
  - imagename: tripleoupstream/centos-binary-aodh-api:latest
  - imagename: tripleoupstream/centos-binary-openvswitch-db-server:latest
overrides:
  - openvswitch-dpdk-override.j2

Let me know if this is something workable. I know we have to modify
the image builder logic, but let me know if the direction is correct.

Another important item to look is that DPDK is enabled by
puppet-vswitch [2] by invoking the ovs-vsctl command. As I remember
the discussions around creating conf files out of puppet execution,
copying to host and mounting to the actual container is the approach
we are using. I am still figuring out to see how ovs-vsctl command can
be invoked using this model.

Containerization of openvswitch is looked up as separate effort by
another team, which will be the base requirement for the DPDK to work.
But openvswitch container need to be started before running the
"NetworkDeployment" which will run the os-net-config. This brings
another requirement of how to containerize os-net-config. It is tricky
as it is not associated with any puppet/service, it has to brought up
individually/separately, with the dependency of openvswitch. I am
still getting familiar with the blocks around this.

I will be updating the analysis and the progress, any suggestions or
directions is more than welcome.

Regards,
Saravanan KR

[1] https://review.openstack.org/#/c/342354/
[2] 
https://github.com/openstack/puppet-vswitch/blob/master/manifests/dpdk.pp#L113

__
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] - are you attending the Boston summit?

[Hirofumi Ichihara]

Hi Miguel,

Unfortunately I already have a plan to attend another party. Please give
another attendee my seat.

Thanks,
Hirofumi

2017-05-08 18:18 GMT-04:00 Miguel Lavalle :

> Dear Neutrinos,
>
> I am working with Legal Sea Foods on a reservation for 30 people,
> Wednesday at 7pm. I am assuming the 30 people who registered in the
> etherpad will attend (https://etherpad.openstack.
> org/p/neutron-boston-summit-attendees). If your name is in the etherpad
> and you DON'T plan to attend, please let me know.
>
> Legal Sea Foods has several locations close to the convention center. I
> will send an update with the slected location as soon as I can finalize the
> the details with them. Please keep an eye on your inbox
>
> Cheers
>
> Miguel
>
> On Mon, May 8, 2017 at 7:57 AM, Kevin Benton  wrote:
>
>> Let's plan for a social Wednesday night. I'll update this with a location
>> once we find a place.
>>
>> On May 8, 2017 08:50, "MCCASLAND, TREVOR"  wrote:
>>
>>> Looking forward to it! RSVP? +1
>>>
>>>
>>>
>>> *From:* Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
>>> *Sent:* Saturday, May 06, 2017 12:31 AM
>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>> openstack-dev@lists.openstack.org>
>>> *Subject:* Re: [openstack-dev] [neutron] - are you attending the Boston
>>> summit?
>>>
>>>
>>>
>>> Hey Neutron Folks,
>>>
>>>
>>>
>>> Following our past tradition, we should have Neutron dinner while we are
>>> all in Boston.
>>>
>>> Miguel has few places in mind. I would propose that we nominate him as
>>> the dinner organizer lieutenant.
>>>
>>>
>>>
>>> Miguel, I hope you will take us to some cool place.
>>>
>>>
>>>
>>> Thanks
>>>
>>> -Sukhdev
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Apr 20, 2017 at 4:31 PM, Kevin Benton  wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> If you are a Neutron developer attending the Boston summit, please add
>>> your name to the etherpad here so we can plan a Neutron social and easily
>>> coordinate in person meetings: https://etherpad.ope
>>> nstack.org/p/neutron-boston-summit-attendees
>>> 
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Kevin Benton
>>>
>>>
>>> 
>>> __
>>> 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
>>> 
>>>
>>>
>>>
>>> 
>>> __
>>> 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
>>>
>>>
>> 
>> __
>> 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

[openstack-dev] [I18n] (Special) Summit hack-room & IRC meeting in this week with Skype

[Ian Y. Choi]

Hello all,

First of all, I really really feel that Boston Summit welcomes translators!
Thanks to lots of kind support from upstream contributors, users,
operators, and also Foundation staff,
I think I18n team is able to have so many I18n sessions during this Summit.

I have asked translators whether they would come to Boston Summit or not
via i18n mailing list
several times but it seems that a few active translators finally have come
to Boston Summit [1].

Now, I would like to propose a hack-room for I18n team
on on Thursday 9:00 AM - 10:30 AM at Hynes, MR 108 (I have signed into [2]).
I think the time would be the best for I18n team since Thursday 9:00 AM -
10:00 AM is the same as I18n IRC meeting time slot [3].

So, for physical Summit attendees:
 - Please attend to I18n hack room on Thursday 9:00 AM - 10:30 AM at Hynes,
MR 108.
 - If someone wants to more know I18n and translation or have questions on
translation,
   please ping me via IRC. My IRC nickname is "ianychoi".

And for I18n translators (+ Zanata development team members) who are unable
to physically attend to the Summit:
- Please come to IRC meeting [3].
- Also I strongly encourage to also join a voice meeting via Skype Business.
  I have made a link for the Meeting:
https://meet.lync.com/ychoi/ianychoi/3HVZ0CY1 .
  Please join in the meeting if you would like to see I18n people in the
Summit :)
- Timezone information is also available at: [4]

Also, I welcome upstream contributors, users, operators, and even
Summit-101 members who would like to know how I18n team is dealing with
translation.

I am now proposing the following topics, but topics may be subject to
change:

 - (Greeting)
 - Sharing how Summit is going with I18n
 - Report of recent Zanata production server error
 - User survey translation status
 - Discussion on I18n team PTG participation
 - Feedback from I18n contributors: PTG, Summit, Design Summit, Forum
 - Action items


With many thanks,

/Ian

[1] https://etherpad.openstack.org/p/i18n-boston-summit-activities
[2] https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms
[3]
https://wiki.openstack.org/wiki/Meetings/I18nTeamMeeting#Agenda_for_next_meeting
[4]
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017&month=5&day=11&hour=13&min=0&sec=0&p1=43&p2=47&p3=33&p4=235&p5=108&p6=166
__
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] [OpenStack-I18n] [I18n] (Special) Summit hack-room & IRC meeting in this week with Skype

[Will Zhou]

Hi Ian, thanks for the kind arrangement. The time slot suits me and I will
remotely attend the meeting:)

On Tue, May 9, 2017 at 7:22 PM Ian Y. Choi  wrote:

> Hello all,
>
> First of all, I really really feel that Boston Summit welcomes translators!
> Thanks to lots of kind support from upstream contributors, users,
> operators, and also Foundation staff,
> I think I18n team is able to have so many I18n sessions during this Summit.
>
> I have asked translators whether they would come to Boston Summit or not
> via i18n mailing list
> several times but it seems that a few active translators finally have come
> to Boston Summit [1].
>
> Now, I would like to propose a hack-room for I18n team
> on on Thursday 9:00 AM - 10:30 AM at Hynes, MR 108 (I have signed into
> [2]).
> I think the time would be the best for I18n team since Thursday 9:00 AM -
> 10:00 AM is the same as I18n IRC meeting time slot [3].
>
> So, for physical Summit attendees:
>  - Please attend to I18n hack room on Thursday 9:00 AM - 10:30 AM at
> Hynes, MR 108.
>  - If someone wants to more know I18n and translation or have questions on
> translation,
>please ping me via IRC. My IRC nickname is "ianychoi".
>
> And for I18n translators (+ Zanata development team members) who are
> unable to physically attend to the Summit:
> - Please come to IRC meeting [3].
> - Also I strongly encourage to also join a voice meeting via Skype
> Business.
>   I have made a link for the Meeting:
> https://meet.lync.com/ychoi/ianychoi/3HVZ0CY1 .
>   Please join in the meeting if you would like to see I18n people in the
> Summit :)
> - Timezone information is also available at: [4]
>
> Also, I welcome upstream contributors, users, operators, and even
> Summit-101 members who would like to know how I18n team is dealing with
> translation.
>
> I am now proposing the following topics, but topics may be subject to
> change:
>
>  - (Greeting)
>  - Sharing how Summit is going with I18n
>  - Report of recent Zanata production server error
>  - User survey translation status
>  - Discussion on I18n team PTG participation
>  - Feedback from I18n contributors: PTG, Summit, Design Summit, Forum
>  - Action items
>
>
> With many thanks,
>
> /Ian
>
> [1] https://etherpad.openstack.org/p/i18n-boston-summit-activities
> [2] https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms
> [3]
> https://wiki.openstack.org/wiki/Meetings/I18nTeamMeeting#Agenda_for_next_meeting
> [4]
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017&month=5&day=11&hour=13&min=0&sec=0&p1=43&p2=47&p3=33&p4=235&p5=108&p6=166
> ___
> OpenStack-I18n mailing list
> openstack-i...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>
-- 

-
​
周正喜
Mobile: 13701280947
​WeChat: 472174291
__
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] [murano] IRC Meeting cancelled on May 9

[MONTEIRO, FELIPE C]

Hi all,

Due to the Summit this week, the Murano meeting this week is cancelled and will 
commence again next Tuesday, May 16.

Felipe

__
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] [Openstack-operators] [scientific] Lightning talks on Scientific OpenStack

[Blair Bethwaite]

Morning all -

Apologies for the shotgun email. But looks like we still have one or
two spots available for lightening talks if anyone has work they want
to share and/or discuss:

https://etherpad.openstack.org/p/Scientific-WG-Boston-Lightning

Best regards,

On 28 April 2017 at 06:19, George Mihaiescu  wrote:
> Thanks Stig,
>
> I added a presentation to the schedule.
>
>
> Cheers,
> George
>
>
>
> On Thu, Apr 27, 2017 at 3:49 PM, Stig Telfer 
> wrote:
>>
>> Hi George -
>>
>> Sorry for the slow response.  The consensus was for 8 minutes maximum.
>> That should be plenty for a lightning talk, and enables us to fit one more
>> in.
>>
>> Best wishes,
>> Stig
>>
>>
>> > On 27 Apr 2017, at 20:29, George Mihaiescu  wrote:
>> >
>> > Hi Stig, it will be 10 minutes sessions like in Barcelona?
>> >
>> > Thanks,
>> > George
>> >
>> >> On Apr 26, 2017, at 03:31, Stig Telfer 
>> >> wrote:
>> >>
>> >> Hi All -
>> >>
>> >> We have planned a session of lightning talks at the Boston summit to
>> >> discuss topics specific for OpenStack and research computing applications.
>> >> This was a great success at Barcelona and generated some stimulating
>> >> discussion.  We are also hoping for a small prize for the best talk of the
>> >> session!
>> >>
>> >> This is the event:
>> >>
>> >> https://www.openstack.org/summit/boston-2017/summit-schedule/events/18676
>> >>
>> >> If you’d like to propose a talk, please add a title and your name here:
>> >> https://etherpad.openstack.org/p/Scientific-WG-boston
>> >>
>> >> Everyone is welcome.
>> >>
>> >> Cheers,
>> >> Stig
>> >>
>> >>
>> >> ___
>> >> OpenStack-operators mailing list
>> >> openstack-operat...@lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Cheers,
~Blairo

__
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] KVM Forum 2017: Call For Participation

[Daniel P. Berrange]

KVM Forum 2017: Call For Participation
October 25-27, 2017 - Hilton Prague - Prague, Czech Republic

(All submissions must be received before midnight June 15, 2017)
=

KVM Forum is an annual event that presents a rare opportunity
for developers and users to meet, discuss the state of Linux
virtualization technology, and plan for the challenges ahead. 
We invite you to lead part of the discussion by submitting a speaking
proposal for KVM Forum 2017.

At this highly technical conference, developers driving innovation
in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can
meet users who depend on KVM as part of their offerings, or to
power their data centers and clouds.

KVM Forum will include sessions on the state of the KVM
virtualization stack, planning for the future, and many
opportunities for attendees to collaborate. As we celebrate ten years
of KVM development in the Linux kernel, KVM continues to be a
critical part of the FOSS cloud infrastructure.

This year, KVM Forum is joining Open Source Summit in Prague, 
Czech Republic. Selected talks from KVM Forum will be presented on
Wednesday October 25 to the full audience of the Open Source Summit.
Also, attendees of KVM Forum will have access to all of the talks from
Open Source Summit on Wednesday.

http://events.linuxfoundation.org/cfp

Suggested topics:
* Scaling, latency optimizations, performance tuning, real-time guests
* Hardening and security
* New features
* Testing

KVM and the Linux kernel:
* Nested virtualization
* Resource management (CPU, I/O, memory) and scheduling
* VFIO: IOMMU, SR-IOV, virtual GPU, etc.
* Networking: Open vSwitch, XDP, etc.
* virtio and vhost
* Architecture ports and new processor features

QEMU:
* Management interfaces: QOM and QMP
* New devices, new boards, new architectures
* Graphics, desktop virtualization and virtual GPU
* New storage features
* High availability, live migration and fault tolerance
* Emulation and TCG
* Firmware: ACPI, UEFI, coreboot, U-Boot, etc.

Management and infrastructure
* Managing KVM: Libvirt, OpenStack, oVirt, etc.
* Storage: Ceph, Gluster, SPDK, etc.r
* Network Function Virtualization: DPDK, OPNFV, OVN, etc.
* Provisioning


===
SUBMITTING YOUR PROPOSAL
===
Abstracts due: June 15, 2017

Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes. Also include the proposal
type -- one of:
- technical talk
- end-user talk

Submit your proposal here:
http://events.linuxfoundation.org/cfp
Please only use the categories "presentation" and "panel discussion"

You will receive a notification whether or not your presentation proposal
was accepted by August 10, 2017.

Speakers will receive a complimentary pass for the event. In the instance
that case your submission has multiple presenters, only the primary speaker for 
a
proposal will receive a complimentary event pass. For panel discussions, all
panelists will receive a complimentary event pass.

TECHNICAL TALKS

A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, focus on
work that needs to be done, difficulties that haven't yet been solved,
and on decisions that other developers should be aware of. Summarizing
recent developments is okay but it should not be more than a small
portion of the overall talk.

END-USER TALKS

One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.

If you are using KVM in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user talk. As an end user, this is a
unique opportunity to get your input to developers.

HANDS-ON / BOF SESSIONS

We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups.

These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at

  http://www.linux-kvm.org/page/KVM_Forum_2017_BOF

Let people you think who might be interested know about your BOF, and encourage
them to add their names to the wiki page as well. Please try to
add your ideas to the list before KVM Forum starts.


PANEL DISCUSSIONS

If you are proposing a panel discussion, please make sure that you list
all of your potential panelists in your the abstract. We will request full
biographies if a panel is accepted.


===
HOTEL / TRAVEL
===

This year's event will take place at the Hilton Prague.
For information on discounted room rates for conference attendees
and on other hotels close to the conferen

[openstack-dev] [scientific] Scientific-WG sessions in Boston

[Blair Bethwaite]

Hey all,

Hopefully you've all noticed this by now, the timing of the WG
sessions (lightening talks, meeting, BoF) has changed a little since
first published. I've just updated the etherpad to reflect that now:

https://etherpad.openstack.org/p/Scientific-WG-boston
Tues 11:15am - 11:55am - Scientific Working Group - Lightning Talks
Tues 3:40pm - 4:20pm - Scientific Working Group - Meeting
Weds 2:40pm - 3:20pm - Scientific OpenStack - BoF

Please jump on the etherpad and contribute to the agenda in order to
help us shape our focus for the next cycle.

Looking forward to seeing you today!

-- 
Cheers,
~Blairo

__
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] Odp.: [nova] Would be possible to modify metadata when instance is in rescued state?

[Pawel Suder]

Hello Michael,


I did a quick grep over archive with mails from openstack-dev list. It seems 
that topic about rescue mode was raised in August last year. I did not find 
anything directly related to metadata.


Understand that changing user metadata (with command `nova meta {uuid} set 
key=value`) when VM is in rescue mode, could cause some issues.

Cheers,
Pawel


Od: Michael Still mailto:mi...@stillhq.com>>
Temat: Odp: [openstack-dev] [nova] Would be possible to modify metadata when 
instance is in rescued state?
Data: 9 maja 2017 09:09:31 CEST
Do: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Odpowiedź-do: "OpenStack Development Mailing List \(not for usage questions\)" 
mailto:openstack-dev@lists.openstack.org>>

This sort of question comes up every six months or so it seems.

The issue is that for config drive users we don't have a way of rebuilding all 
of the config drive (for example, the root password is gone). That's probably 
an issue for rescue because its presumably one of the things you might reset.

I'm not opposed to exploring options, but I think we need someone to come up 
with a proposal which addresses previous concerns. I'd recommend a quick search 
of the mailing list archives for previous discussions.

Hope this helps,
Michael


On Tue, May 9, 2017 at 5:04 PM, Pawel Suder 
mailto:pawel.su...@corp.ovh.com>> wrote:

Hello,


I would like to raise a topic regarding possibilities when metadata could be 
modified on instance.


We noticed that instance metadata could be modified only when vm_state is set 
to following values:


  *   active
  *   paused
  *   suspended
  *   stopped

Found:

https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3916-L3920
https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3905-L3908

>From time to time it is needed to have instance in rescued state.

Scenario: VM is rescued and special metadata attributes need to be set to allow 
cloud-init to act specifically for rescue mode. Metadata data should be 
available only during rescue mode.

Question: what kind of impact could be observed when checks for instance state 
will be modified for methods:

update_instance_metadata
delete_instance_metadata

Thank you,

Cheers,
Pawel


__
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] [Ceilometer]

[simona marinova]

Hello,


I am working on an Openstack Newton platform and I am currently trying to 
implement the Telemetry services, Ceilometer and Aodh.

I installed and configured Aodh with MySQL first and it worked. Afterwards, I 
installed Ceilometer following the latest update which includes MongoDB, unlike 
the previous version with Gnocchi.


Ceilometer now works, but only the commands which do not include Aodh give the 
correct output, for example "ceilometer meter-list", "ceilometer resource-list" 
etc.


 The Alarming service doesn't work at this point. For example the command 
"ceilometer alarm-list" gives the error:


HTTPConnectionPool(host='controller', port=8042): Max retries exceeded with 
url: /v2/alarms (Caused by 
NewConnectionError(': Failed to establish a new connection: [Errno 111] 
Connection refused',))

Now my biggest concern is that the Alarming service database (MySQL-based) and 
the Data collection service database (MongoDB) are not communicating properly. 
Is it possible for the Aodh to access the data from MongoDB?

Additionally aodh-dbsync gives error, because it cannot detect the module 
gnocchiclient. There aren't gnocchi modules involved in this version.

What kind of configuration needs to be done in order for Telemetry and Alarming 
to work properly?

Best regards,
Simona



__
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] [Ironic] Stepping down from core

[Lucas Alvares Gomes]

Hi all,

This is a difficult email to send. As some of you might already know,
lately I've been focusing on the OVS/OVN (and related) projects and I
don't have much time left to dedicate on reviewing patches in Ironic,
at least for now.

My biggest priority for this cycle was to create a basic Redfish
driver and now that the patches are merged and a -nv job is running in
the gate I feel like it would be a good time to step down from the
core team. If needed, I could still help out as core reviewer on some
small projects which I'm very familiar with such as Sushy and
VirtualBMC, those doesn't take much time and the review queue is
usually short.

Also, this is not a good-bye email, I'm still very interested in
Ironic and I will continue to follow the project closely as well as be
around in the #openstack-ironic IRC channel at all times (-:

So, thanks for everything everyone, it's been great to work with you
all for all these years!!!

Cheers,
Lucas

__
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] [all] Project On-Boarding Info Collection

[Matt Riedemann]

On 5/8/2017 2:57 PM, Kendall Nelson wrote:

Hello!

If you are running a project onboarding session and have
etherpads/slides/ etc you are using to educate new contributors  please
send them to me! I am collecting all the resources you are sharing into
a single place for people that weren't able to attend sessions.

Thanks!

Kendall (diablo_rojo)


__
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



The nova onboarding etherpad is linked from the wiki page:

https://wiki.openstack.org/wiki/Forum/Boston2017

--

Thanks,

Matt

__
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] [tripleo][ui] another i18n proposal for heat templates 'description' help strings

[Florian Fuchs]

On Mon, May 8, 2017 at 10:20 AM, Peng Wu  wrote:
> Hi Julie,
>
>   I generated one example javascript file containing the translatable
> strings.
>   URL: https://pwu.fedorapeople.org/openstack-i18n/tripleo/tripleo-heat
> -templates.js
>
>   And the code to generate the above file is in:
>   https://pwu.fedorapeople.org/openstack-i18n/tripleo/
>
>   The generated file need to be copied to tripleo-ui project, and
> translate as other javascript files.
>
>   Please review it, thanks!

Thanks for the update Peng! A few comments:

1. A minor thing: The file is missing the import for the
defineMessages function, so that would have to be added here.
2. The UI looks up messages by their object key, not the message id
(random examples: [1]). The current naming would make that quite hard
(description1, description2, descriptionN, ...). Ideally the key would
be created using some reproducible conventions. For instance, the UI
stores EnvironmentGroups by their title, Environments by their file
path and Parameters by their name. If the message keys would reflect
this structure, the UI could look up the objects dynamically, based on
the naming conventions.

Two more things I noticed:

I count roughly 3400 occurrences of the word "description" in current
tripleo-heat-templates. I'm not sure we need them all (your current
example file only lists about 600, which would still be an acceptable
number I guess), but if we do, we should probably think about some
dynamic way to load messages in the UI and not put them all into one
huge file.

We need to handle cases where translatable t-h-t strings don't have a
corresponding message object in the generated js file. That's probably
not a big thing, but something we have to take care of.

[1] 
https://github.com/openstack/tripleo-ui/blob/master/src/js/components/deployment/DeploymentDetail.js#L106
 
https://github.com/openstack/tripleo-ui/blob/master/src/js/components/deployment/DeploymentDetail.js#L59

__
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] [qa] [patrole] Patrole py35 non-voting gate and 0.1.0 Patrole release

[MONTEIRO, FELIPE C]

Hi folks,

We've pushed up 2 patches for Patrole: one is a version 0.1.0 release for Pike 
[0] and the other is a py35 gate [1] as per the Pike QA Goals [2].

Regarding [0], the version is 0.1.0 since the library is not fully stable. 
Because a lot of APIs are slated to be deprecated (or already are deprecated), 
however, we think it's important to have a Patrole tag before we have to remove 
tests due to deprecations and removals of deprecated APIs. Regarding [1], we 
basically followed what Tempest does: Have one Patrole py35 gate that is used 
alongside the other Patrole voting gates.

Please let me know if this looks OK.

[0] https://review.openstack.org/#/c/463578/
[1] https://review.openstack.org/#/c/463583/
[2] https://etherpad.openstack.org/p/pike-qa-goals-py35

Felipe

__
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] [Ironic] Stepping down from core

[John Villalovos]

No!!!

Thanks for everything Lucas. Always a pleasure working with you and thanks
for all your help. Especially when I first joined Ironic.

Good luck for the future!

John

On Tue, May 9, 2017 at 7:15 AM, Lucas Alvares Gomes 
wrote:

> Hi all,
>
> This is a difficult email to send. As some of you might already know,
> lately I've been focusing on the OVS/OVN (and related) projects and I
> don't have much time left to dedicate on reviewing patches in Ironic,
> at least for now.
>
> My biggest priority for this cycle was to create a basic Redfish
> driver and now that the patches are merged and a -nv job is running in
> the gate I feel like it would be a good time to step down from the
> core team. If needed, I could still help out as core reviewer on some
> small projects which I'm very familiar with such as Sushy and
> VirtualBMC, those doesn't take much time and the review queue is
> usually short.
>
> Also, this is not a good-bye email, I'm still very interested in
> Ironic and I will continue to follow the project closely as well as be
> around in the #openstack-ironic IRC channel at all times (-:
>
> So, thanks for everything everyone, it's been great to work with you
> all for all these years!!!
>
> Cheers,
> Lucas
>
> __
> 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] [tc] [all] OpenStack moving both too fast and too slow at the same time

[Duncan Thomas]

On 5 May 2017 at 23:45, Chris Friesen  wrote:
> On 05/05/2017 02:04 PM, John Griffith wrote:
>> I'd love some detail on this.  What falls over?

> It's been a while since I looked at it, but the main issue was that with LIO
> as the iSCSI server there is no automatic traffic shaping/QoS between
> guests, or between guests and the host.  (There's no iSCSI server process to
> assign to a cgroup, for example.)
>
> The throttling in IOPS/Bps is better than nothing, but doesn't really help
> when you don't necessarily know what your total IOPS/bandwidth actually is
> or how many volumes could get created.
>
> So you have one or more guests that are hammering on the disk as fast as
> they can, combined with disks on the cinder server that maybe aren't as fast
> as they should be, and it ended up slowing down all the other guests.  And
> if the host is using the same physical disks for things like glance
> downloads or image conversion, then a badly-behaved guest can cause
> performance issues on the host as well due to IO congestion.  And if they
> fill up the host caches they can even affect writes to other unrelated
> devices.
>
> So yes, it wasn't the ideal hardware for the purpose, and there are some
> tuning knobs, but in an ideal world we'd be able to reserve some
> amount/percentage of bandwidth/IOPs for the host and have the rest shared
> equally between all active iSCSI sessions (or unequally via a share
> allocation if desired).

So that's a complaint that it can't do magic with underspecced,
overloaded hardware, plus a request for fair-share I/O or network
scheduling? The latter is maybe something cinder could look at, though
we're limited by the available technologies - array vendors tend to
keep such things proprietary. Note that it is trivial to overload many
SAN too, both the data path and the control path.

__
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] [all] Project On-Boarding Info Collection

[Alexander Chadin]

OpenStack Watcher

https://youtu.be/FJttohkf0sM

https://docs.google.com/presentation/d/1TYdBBd7jEmLlC0kgsh10LfIaRS1pNmmPE-L_2hXQK6Q

Best regards
_
Alexander Chadin
OpenStack Developer
Servionica LTD
a.cha...@servionica.ru
+7 (916) 693-58-81

On 9 May 2017, at 10:18, Matt Riedemann 
mailto:mriede...@gmail.com>> wrote:

On 5/8/2017 2:57 PM, Kendall Nelson wrote:
Hello!

If you are running a project onboarding session and have
etherpads/slides/ etc you are using to educate new contributors  please
send them to me! I am collecting all the resources you are sharing into
a single place for people that weren't able to attend sessions.

Thanks!

Kendall (diablo_rojo)


__
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


The nova onboarding etherpad is linked from the wiki page:

https://wiki.openstack.org/wiki/Forum/Boston2017

--

Thanks,

Matt

__
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] [vitrage] [nova] VM Heartbeat / Healthcheck Monitoring

[Waines, Greg]

I am looking for guidance on where to propose some “VM Heartbeat / Health-check 
Monitoring” functionality that I would like to contribute to openstack.

Briefly, “VM Heartbeat / Health-check Monitoring”

· is optionally enabled thru a Nova flavor extra-spec,

· is a service that runs on an OpenStack Compute Node,

· it sends periodic Heartbeat / Health-check Challenge Requests to a VM
over a virtio-serial-device setup between the Compute Node and the VM thru QEMU,

· on loss of heartbeat or a failed health check status will result in 
fault event, against the VM, being
reported to Vitrage thru its data-source API.

Where should I contribute this functionality ?

· put it ALL in Vitrage ... both the monitoring and the data-source 
reporting ?

· put the monitoring in Nova, and just the data source reporting in 
Vitrage ?

· other ?

Greg.





p.s. other info ...

Benefits of “VM Heartbeat / Health-check Monitoring”


· monitors health of OS and Applications INSIDE the VM

oi.e. even just a simple Ack of the Heartbeat would validate that the OS is 
running, IO mechanisms (sockets, etc)
are working and processes are getting scheduled

· health-check status reporting can trigger and report on either 
high-level or detailed application-specific audits within the VM,


· the simple virtio-serial-device interface thru QEMU is UP very early 
in VM life cycle and is virtually always up

oi.e. its available for reporting issues virtually all the time,

o   ... compared to reporting issues over Tenant Network to a remote 
VNFManager which relies on Ethernet and IP Networking within the VM itself and 
then any provider network and adjacent routers around the compute nodes ...


· uses a simple “Line-Delimited JSON” Format over virtio serial device 
( http://www.linux-kvm.org/page/Virtio-serial_API )

osimple to implement protocol inside VM, in pretty much any language

o( although would provide reference implementation )


· provides more thorough instance monitoring than libvirt’s emulated 
hardware watchdog ( https://libvirt.org/formatdomain.html#elementsWatchdog )
__
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] [tc] [all] OpenStack moving both too fast and too slow at the same time

[Joshua Harlow]

Matt Riedemann wrote:

On 5/8/2017 1:10 PM, Octave J. Orgeron wrote:

I do agree that scalability and high-availability are definitely issues
for OpenStack when you dig deeper into the sub-components. There is a
lot of re-inventing of the wheel when you look at how distributed
services are implemented inside of OpenStack and deficiencies. For some
services you have a scheduler that can scale-out, but the conductor or
worker process doesn't. A good example is cinder, where cinder-volume
doesn't scale-out in a distributed manner and doesn't have a good
mechanism for recovering when an instance fails. All across the services
you see different methods for coordinating requests and tasks such as
rabbitmq, redis, memcached, tooz, mysql, etc. So for an operator, you
have to sift through those choices and configure the per-requisite
infrastructure. This is a good example of a problem that should be
solved with a single architecturally sound solution that all services
can standardize on.


There was an architecture workgroup specifically designed to understand
past architectural decisions in OpenStack, and what the differences are
in the projects, and how to address some of those issues, but from lack
of participation the group dissolved shortly after the Barcelona summit.
This is, again, another example of if you want to make these kinds of
massive changes, it's going to take massive involvement and leadership.


I agree on the 'massive changes, it's going to take massive involvement 
and leadership.' though I am not sure how such changes and involvement 
actually happens; especially nowadays where companies which such 
leadership are moving on to something else (k8s, mesos, or other...)


So knowing that what are the options to actually make some kind of 
change occur? IMHO it must be driven by PTLs (yes I know they are always 
busy, to bad, so sad, lol). I'd like all the PTLs to get together and 
restart the arch-wg and make it a *requirement* that PTLs actually show 
up (and participate) in that group/meeting vs it just being a bunch of 
senior(ish) folks, such as myself, that showed up. Then if PTLs do not 
show up, I would start to say that the next time around they are running 
for PTL said lack of participation in the wider openstack vision should 
be known and potentially cause them to get kicked out (voted out?) of 
being a PTL in the future.




The problem in a lot of those cases comes down to development being
detached from the actual use cases customers and operators are going to
use in the real world. Having a distributed control plane with multiple
instances of the api, scheduler, coordinator, and other processes is
typically not testable without a larger hardware setup. When you get to
large scale deployments, you need an active/active setup for the control
plane. It's definitely not something you could develop for or test
against on a single laptop with devstack. Especially, if you want to use
more than a handful of the OpenStack services.


I've heard *crazy* things about actual use cases customers and operators 
are doing because of the scaling limits that projects have (ie nova has 
a limit of 300 compute nodes so ABC customer will then setup X * 300 
clouds to reach Y compute nodes because of that limit).


IMHO I'm not even sure I would want to target said use-cases in the 
first place, because they feel messed up in the first place (and it 
seems bad/dumb? to go down the rabbit hole of targeting use-cases that 
were deployed to band-aid over the initial problems that created those 
use-cases/deployments in the first place).




I think we can all agree with this. Developers don't have a lab with
1000 nodes lying around to hack on. There was OSIC but that's gone. I've
been requesting help in Nova from companies to do scale testing and help
us out with knowing what the major issues are, and report those back in
a form so we can work on those issues. People will report there are
issues, but not do the profiling, or at least not report the results of
profiling, upstream to help us out. So again, this is really up to
companies that have the resources to do this kind of scale testing and
report back and help fix the issues upstream in the community. That
doesn't require OpenStack 2.0.



So how do we close that gap? The only way I really know is by having 
people that can see the problems from the get-go, instead of having to 
discover it at some later point (when it falls over and ABC customer 
starts to start having Y clouds just to reach the target number of 
compute nodes they want to reach). Now maybe the skill level in 
openstack (especially in regards to distributed systems) is just to low 
and the only real way to gather data is by having companies do scale 
testing (ie some kind of architecting things to work after they are 
deployed); if so that's sad...


-Josh

__
OpenStack Development Mailing List (not for usage 

[openstack-dev] [nova] Multicell paginated instance lists

[Matthew Booth]

Following the forum session yesterday I've thrown up this pseudocode for
discussion:

https://review.openstack.org/463618

I want to stress that I consider nova proxying to searchlight to be a
premature optimisation rather than an intrinsically terrible idea. That
said, the searchlight solution looks very complex for both developers and
operators, and very fragile. I think we'd better going with a relatively
simple solution like this one first, and only going a couple of orders of
magnitude more complex if it turns out to be absolutely essential.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
__
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] - are you attending the Boston summit?

[Miguel Lavalle]

Dear Neutrinos,

We have a plan for tomorrow night, Wednesday 10th at 7pm. We are going to
meet at UNO Pizzeria and Grill, 731 Boylston Street Boston, MA 02116, phone
number (617) 267-8554. This location is a very easy walk of less than 5
minutes from the convention center

We are going to have an "all you can eat" menu with the following options:

House Salad
Deep Dish Pizza (cheese, pepperoni, veggie)
Pasta (penne marinara, chicken broccoli alfredo)
Fountain Soda drinks and Ice tea are included are at $16.50 per person.

They will present present each person with an individual check for this
package and charge separately for any other requests

Looking forward to see you all tomorrow night!

Regards

Miguel

On Mon, May 8, 2017 at 5:18 PM, Miguel Lavalle  wrote:

> Dear Neutrinos,
>
> I am working with Legal Sea Foods on a reservation for 30 people,
> Wednesday at 7pm. I am assuming the 30 people who registered in the
> etherpad will attend (https://etherpad.openstack.
> org/p/neutron-boston-summit-attendees). If your name is in the etherpad
> and you DON'T plan to attend, please let me know.
>
> Legal Sea Foods has several locations close to the convention center. I
> will send an update with the slected location as soon as I can finalize the
> the details with them. Please keep an eye on your inbox
>
> Cheers
>
> Miguel
>
> On Mon, May 8, 2017 at 7:57 AM, Kevin Benton  wrote:
>
>> Let's plan for a social Wednesday night. I'll update this with a location
>> once we find a place.
>>
>> On May 8, 2017 08:50, "MCCASLAND, TREVOR"  wrote:
>>
>>> Looking forward to it! RSVP? +1
>>>
>>>
>>>
>>> *From:* Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
>>> *Sent:* Saturday, May 06, 2017 12:31 AM
>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>> openstack-dev@lists.openstack.org>
>>> *Subject:* Re: [openstack-dev] [neutron] - are you attending the Boston
>>> summit?
>>>
>>>
>>>
>>> Hey Neutron Folks,
>>>
>>>
>>>
>>> Following our past tradition, we should have Neutron dinner while we are
>>> all in Boston.
>>>
>>> Miguel has few places in mind. I would propose that we nominate him as
>>> the dinner organizer lieutenant.
>>>
>>>
>>>
>>> Miguel, I hope you will take us to some cool place.
>>>
>>>
>>>
>>> Thanks
>>>
>>> -Sukhdev
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Apr 20, 2017 at 4:31 PM, Kevin Benton  wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> If you are a Neutron developer attending the Boston summit, please add
>>> your name to the etherpad here so we can plan a Neutron social and easily
>>> coordinate in person meetings: https://etherpad.ope
>>> nstack.org/p/neutron-boston-summit-attendees
>>> 
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Kevin Benton
>>>
>>>
>>> 
>>> __
>>> 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
>>> 
>>>
>>>
>>>
>>> 
>>> __
>>> 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
>>>
>>>
>> 
>> __
>> 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-dev] [neutron] - neutron social

[Kevin Benton]

See message below from Miguel for details on the neutron social.


Dear Neutrinos,

We have a plan for tomorrow night, Wednesday 10th at 7pm. We are going to
meet at UNO Pizzeria and Grill, 731 Boylston Street Boston, MA 02116, phone
number (617) 267-8554. This location is a very easy walk of less than 5
minutes from the convention center

We are going to have an "all you can eat" menu with the following options:

House Salad
Deep Dish Pizza (cheese, pepperoni, veggie)
Pasta (penne marinara, chicken broccoli alfredo)
Fountain Soda drinks and Ice tea are included are at $16.50 per person.

They will present present each person with an individual check for this
package and charge separately for any other requests

Looking forward to see you all tomorrow night!

Regards

Miguel
__
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] [congress] meeting topics

[Eric K]

Hi all,

Even though some of us are at the OS summit and may not make the meeting,
let¹s have a meeting anyway for those of us who can make it.

As usual, the collaborative list of topics are kept here:
https://etherpad.openstack.org/p/congress-meeting-topics


__
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