Re: [openstack-dev] [Kuryr][Magnum] - Kuryr nested containers and Magnum Integration

[Vikas Choudhary]

On Fri, Jun 24, 2016 at 7:42 PM, Hongbin Lu  wrote:

>
>
>
>
> *From:* Vikas Choudhary [mailto:choudharyvika...@gmail.com]
> *Sent:* June-22-16 3:58 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Kuryr][Magnum] - Kuryr nested containers
> and Magnum Integration
>
>
>
> Hi Eli Qiao,
>
>
>
> Please find my responses inline.
>
>
>
> On Wed, Jun 22, 2016 at 12:47 PM, taget  wrote:
>
> hi Vikas,
> thanks for you clarify, relied in lines.
>
> On 2016年06月22日 14:36, Vikas Choudhary wrote:
>
>
>
> Magnum:
>
>1. Support to pass neutron network names at container creation apis
>such as pod-create in k8s case.
>
> Hmm. Magnum has deleted all wrapper API for container creation and
> pod-create
>
> Oh, I was referring to older design then. In that case, What would be
> corresponding alternative now?
>
> Is this related to Zun somehow?
>
> *[Hongbin Lu] The alternative is native CLI tool (i.e. kubectl, docker).
> This is unrelated to Zun. Zun is a totally independent service, regardless
> of Magnum exists or not.*
>
[Vikas] Thanks for the info Hongbin. Eli Qiao also helped clearing this
aspect over irc.

>
>
>
>
>
>1. If Kuryr is used as network driver at bay creation, update heat
>template creation logic for kuryr-agent provisioning on all the bay nodes.
>This will also include passing required configuration and credentials also.
>
>
> In this case, I am confused, we need to install kuryr-agent on all bay
> nodes, so and kuryr-agent's for binding neutron ports and containers port,
> we will need to install neutron-agent on bay nodes too?
>
> Neutron-agent will not be required on bay nodes. Only kuryr-agent will be
> sufficient to plumb the vifs and vlan tagging.
>
>
>
>
>
> --
>
> Best Regards,
>
> Eli Qiao (乔立勇), Intel OTC.
>
>
> __
> 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 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-operators] Next Ops Midcycle NYC August 25-26

[Chris Morgan]

Hi there
  Sorry for the delay. I am hoping to see our organizer asap Monday when she's 
back from a trip and to get an answer for this. I don't know who the official 
organizer is but I would think we could do this to just be a credible org that 
can confirm details like you mention.

Chris (Bloomberg)

Sent from my iPhone

> On Jun  23, 2016, at 4:14 PM, Saverio Proto  wrote:
> 
> Hello there :)
> 
> is anyone from the openstack foundation or from bloomberg that can
> help out with this ?
> 
> I share this for anyone that needs visa.
> 
> for Austin we had something like this:
> https://www.openstack.org/summit/austin-2016/austin-and-travel/
> https://openstackfoundation.formstack.com/forms/visa_form_austin_summit
> 
> anyone that needs to apply for Visa will need a 'US point of contact
> information'.
> 
> Basically, if the organizer of the Ops Midcycle is officially the
> openstack foundation or bloomberg, I need to enter in my visa
> application the following info:
> 
> Organization name
> Address in the US
> Phone number
> Email
> 
> It must be a phone number and a email where in case there is a check,
> somebody can tell "yes of course, this guy exist and is coming to the
> conference" :)
> 
> How we sort this out ?
> 
> thank you
> 
> Saverio
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] No valid host can be found - SOLVED

[Turbo Fredriksson]

On Jun 25, 2016, at 12:40 AM, Turbo Fredriksson wrote:

> I'm putting Nova-Docker on hold and am trying KVM instead.


The problem seems to have been with

--property hypervisor_type=docker

when I created the image. It needed to be:

--property hypervisor_type=kvm

.. because I'm using the KVM hypervisor (I initially was
thinking to use the image with Docker, but those are created
differently).
--
Build a man a fire, and he will be warm for the night.
Set a man on fire and he will be warm for the rest of his life.


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

[Robert Collins]

Removing the pbr branch should be fine - it was an exceptional thing
to have that branch in the first place - pbr is consumed by releases
only, and due to its place in the dependency graph is very very very
hard to pin or cap.

-Rob

On 25 June 2016 at 12:37, Tony Breeds  wrote:
> On Fri, Jun 24, 2016 at 04:36:03PM -0700, Sumit Naiksatam wrote:
>> Hi Tony, Thanks for your response, and no worries! We can live with
>> the kilo-eol tag, no need to try to delete it. And as you suggested,
>> we can add a second eol tag when we actually EoL this branch.
>>
>> As regards reviving the deleted branches, would a bug have to be
>> created somewhere to track this, or is this already on the radar of
>> the infra team (thanks in advance if it already is)?
>
> No bug needed.  I'll work with the infra team to re-create the branch.  Just 
> as
> a level set it wont be this weekend.
>
> Yours Tony.
>
> __
> 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] [stable][all] Tagging kilo-eol for "the world"

[Tony Breeds]

On Fri, Jun 24, 2016 at 04:36:03PM -0700, Sumit Naiksatam wrote:
> Hi Tony, Thanks for your response, and no worries! We can live with
> the kilo-eol tag, no need to try to delete it. And as you suggested,
> we can add a second eol tag when we actually EoL this branch.
> 
> As regards reviving the deleted branches, would a bug have to be
> created somewhere to track this, or is this already on the radar of
> the infra team (thanks in advance if it already is)?

No bug needed.  I'll work with the infra team to re-create the branch.  Just as
a level set it wont be this weekend.

Yours Tony.


signature.asc
Description: PGP signature
__
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] Using multiple compute drivers in Nova?

[Turbo Fredriksson]

On Jun 25, 2016, at 12:22 AM, Clint Byrum wrote:

> Excerpts from Turbo Fredriksson's message of 2016-06-24 22:50:40 +0100:
>> The page 
>> http://docs.openstack.org/mitaka/config-reference/compute/hypervisors.html
>> states:
>> 
>>  Most installations use only one hypervisor. However, you can use
>>  ComputeFilter and ImagePropertiesFilter to schedule different
>>  hypervisors within the same installation. 
> 
> If you want to use different compute drivers on one machine, you need
> to run two copies of nova-compute on that machine.

Yeah, that's what I've heard before. I just found that documentation 
information,
and that suggests otherwise..

> One has to ask though... what two hypervisors are you wanting to use on
> the same box?

libvirt (KVM) and nova-docker. I have need for both containers and real
VMs.

I'd very much like to limit my power/cooling requirements by only
run physical machines absolutly necessary. Having to specify one+ host
for containers and one+ host for VMs will mean that these two+ hosts
will individually run "empty" for the most part..

Yes, they will fill up eventually, but I rather only have ONE Compute
running if the containers and VMs fits on ONE..
--
Life sucks and then you die


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] No valid host can be found

[Turbo Fredriksson]

I'm putting Nova-Docker on hold and am trying KVM instead.

However, that gives me:

- s n i p -
2016-06-25 00:17:22.419 607 WARNING nova.scheduler.utils 
[req-6c5e12fc-b01d-4bc5-96b9-54483ae72521 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] Failed to compute_task_build_instances: 
No valid host was found. There are not enough hosts available.
- s n i p -

My nova-scheduler.log say:

- s n i p -
2016-06-25 00:17:22.387 578 DEBUG nova.filters 
[req-6c5e12fc-b01d-4bc5-96b9-54483ae72521 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - -
 -] Filter ComputeCapabilitiesFilter returned 1 host(s) get_filtered_objects 
/usr/lib/python2.7/dist-packages/nova/filters.py:104
2016-06-25 00:17:22.388 578 DEBUG nova.scheduler.filters.image_props_filter 
[req-6c5e12fc-b01d-4bc5-96b9-54483ae72521 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] Instance contains properties 
ImageMetaProps(hw_architecture='x86_64',hw_auto_disk_config=,hw_boot_menu=,hw_cdrom_bus=,hw_cpu_cores=,hw_cpu_max_cores=,hw_cpu_max_sockets=,hw_cpu_max_threads=,hw_cpu_policy=,hw_cpu_realtime_mask=,hw_cpu_sockets=,hw_cpu_thread_policy=,hw_cpu_threads=,hw_device_id=,hw_disk_bus=,hw_disk_type=,hw_firmware_type=,hw_floppy_bus=,hw_ipxe_boot=,hw_machine_type=,hw_mem_page_size=,hw_numa_cpus=,hw_numa_mem=,hw_numa_nodes=,hw_qemu_guest_agent=,hw_rng_model=,hw_scsi_model=,hw_serial_port_count=,hw_video_model=,hw_video_ram=,hw_vif_model=,hw_vif_multiqueue_enabled=,hw_vm_mode=,hw_watchdog_action=,img_bdm_v2=,img_bittorrent=,img_block_device_mapping=,img_cache_in_nova=,im
 
g_compression_level=,img_config_drive=,img_hv_requested_version=,img_hv_type='docker',img_linked_clone=,img_mappings=,img_owner_id=,img_root_device_name=,img_signature=,img_signature_certificate_uuid=,img_signature_hash_method=,img_signature_key_type=,img_use_agent=,img_version=,os_admin_user=,os_command_line=,os_distro=,os_require_quiesce=,os_skip_agent_inject_files_at_boot=,os_skip_agent_inject_ssh=,os_type=)
 that are not provided by the compute node supported_instances [[u'i686', 
u'qemu', u'hvm'], [u'i686', u'kvm', u'hvm'], [u'x86_64', u'qemu', u'hvm'], 
[u'x86_64', u'kvm', u'hvm']] or hypervisor version 2006000 do not match 
_instance_supported 
/usr/lib/python2.7/dist-packages/nova/scheduler/filters/image_props_filter.py:95
2016-06-25 00:17:22.390 578 DEBUG nova.scheduler.filters.image_props_filter 
[req-6c5e12fc-b01d-4bc5-96b9-54483ae72521 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] (bladeA03b, bladeA03b.bayour.com) ram: 
15558MB disk: 111616MB io_ops: 0 instances: 0 does not support requested 
instance_properties host_passes 
/usr/lib/python2.7/dist-packages/nova/scheduler/filters/image_props_filter.py:109
2016-06-25 00:17:22.391 578 INFO nova.filters 
[req-6c5e12fc-b01d-4bc5-96b9-54483ae72521 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] Filter ImagePropertiesFilter returned 0 
hosts
- s n i p -

I don't understand the message, what's it actually saying?
-- 
Em - The battle cry of the cronical masturbater.
- Charlie Harper


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [Horizon] xstatic publishing update - broken xstatic-angular-bootstrap

[Richard Jones]

Hi folks,

I released a couple of broken xstatic-angular-bootstrap packages to pypi
yesterday - 0.11.0.4 and 0.11.0.5. There was to be an automated release of
0.11.0.6 through openstack-release, but I've abandoned that as it contained
the same breakage. I've performed an emergency direct upload of 0.11.0.7 to
pypi which fixes the issue, and will propose an automated release of
0.11.0.8 some time this weekend.

Future packages should not run into this sort of issue - the root cause is
a bug in the xstatic-release script, which I'm also going to address and
release as 1.1.2 this weekend.


Sorry for the trouble,

  Richard
__
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] [stable][all] Tagging kilo-eol for "the world"

[Sumit Naiksatam]

Hi Tony, Thanks for your response, and no worries! We can live with
the kilo-eol tag, no need to try to delete it. And as you suggested,
we can add a second eol tag when we actually EoL this branch.

As regards reviving the deleted branches, would a bug have to be
created somewhere to track this, or is this already on the radar of
the infra team (thanks in advance if it already is)?

~Sumit.

On Fri, Jun 24, 2016 at 4:17 PM, Tony Breeds  wrote:
> On Fri, Jun 24, 2016 at 11:20:12AM -0700, Sumit Naiksatam wrote:
>> Hi, I had earlier requested in this thread that the stable/kilo branch
>> for the following repos be not deleted:
>>
>> > openstack/group-based-policy
>> > openstack/group-based-policy-automation
>> > openstack/group-based-policy-ui
>> > openstack/python-group-based-policy-client
>>
>> and the request was ack’ed by Tony (also in this thread). However, I
>> just noticed that these branches have been deleted. Can this deletion
>> please be reversed?
>
> Firstly I appologise.  I clearly gave Josh the wrong list of repos, which
> included the repos above.
>
> I'm sure we can re-create the branch from the SHA and that *should* allow
> development to continue hhowever due to the ditributed nature of gut deleteing
> the tag is "hard".  What this means in practise is that when you do decide to
> dop the kilo branch you'll end up with a kilo-eol-for-real-this-time :) or
> similar tag.
>
> Again I'm sorry fo the mistake.
>
> Yours Tony.
>
> __
> 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] Using multiple compute drivers in Nova?

[Clint Byrum]

Excerpts from Turbo Fredriksson's message of 2016-06-24 22:50:40 +0100:
> The page 
> http://docs.openstack.org/mitaka/config-reference/compute/hypervisors.html
> states:
> 
>   Most installations use only one hypervisor. However, you can use
>   ComputeFilter and ImagePropertiesFilter to schedule different
>   hypervisors within the same installation. 
> 
> I have both those set, but the "compute_driver" is used to choose
> the driver. This is a string, so only one option is available.
> 
> How do I use more than one?

If you want to use different compute drivers on one machine, you need
to run two copies of nova-compute on that machine.

You may get some insanity on the resource tracker though, as they'll both
think they have access to the same pool of resources, leading to double
resource availability and likely a lot of failed spawns when the box
gets full.

One has to ask though... what two hypervisors are you wanting to use on
the same box?

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [ironic] Separate maintenance mode for Ironic-found faults

[Jay Faulkner]

Hi all,

At the design summit in Austin, I took an action item after the anomaly 
resolution to file a spec to separate operator-set and ironic-set maintenance. 
Now that CI testing is done and we're making progress on other priorities, I 
took time today to submit the RFE bug and a draft spec.

https://bugs.launchpad.net/ironic/+bug/1596107
https://review.openstack.org/334113

I want to make sure we have a consensus on the path forward before investing 
more time in the spec. I've defined some parts of the problem and a potential 
solution as I see it, but would appreciate input, especially from someone with 
more experience modifying existing API objects.

Thanks in advance,
Jay Faulkner
OSIC
__
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] [stable][all] Tagging kilo-eol for "the world"

[Tony Breeds]

On Fri, Jun 24, 2016 at 11:20:12AM -0700, Sumit Naiksatam wrote:
> Hi, I had earlier requested in this thread that the stable/kilo branch
> for the following repos be not deleted:
> 
> > openstack/group-based-policy
> > openstack/group-based-policy-automation
> > openstack/group-based-policy-ui
> > openstack/python-group-based-policy-client
> 
> and the request was ack’ed by Tony (also in this thread). However, I
> just noticed that these branches have been deleted. Can this deletion
> please be reversed?

Firstly I appologise.  I clearly gave Josh the wrong list of repos, which
included the repos above.

I'm sure we can re-create the branch from the SHA and that *should* allow
development to continue hhowever due to the ditributed nature of gut deleteing
the tag is "hard".  What this means in practise is that when you do decide to
dop the kilo branch you'll end up with a kilo-eol-for-real-this-time :) or
similar tag.

Again I'm sorry fo the mistake.

Yours Tony.


signature.asc
Description: PGP signature
__
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-operators] Kilo ->-> Mitaka anyone have notes :)

[Xav Paice]

FWIW, I did that with Cinder and it was great except for one DB change we
had to make regarding the server name for volumes -
http://dischord.org/2015/12/22/cinder-multi-backend-with-multiple-ceph-pools/
is a pretty good description of what I saw.  I suspect that was just a poor
configuration from our Kilo setup rather than a change specifically related
to the upgrade, but the upgrade brought it to light.

Haven't yet taken the same step with others, we're doing the upgrades one
thing at a time and for some (Nova) we'll be jumping through Liberty
because of the risk of jumping two steps at a time.

On 25 June 2016 at 06:16, Jonathan Proulx  wrote:

> Hi All,
>
> I about to start testing for our Kilo->Mitaka migration.
>
> I seem to recall many (well a few at least) people who were looking to
> do a direct Kilo to Mitaka upgrade (skipping Liberty).
>
> Blue Box apparently just did and I read Stefano's blog[1] about it,
> and while it gives me hope my plan is possible it's not realy a
> technical piece.
>
> I'm on my 7th version of OpenStack for this cloud now so not my first
> redeo as they say, but other than read Liberty and Mitaka release
> notes carefully and test like crazy wonder if anyone has seen specific
> issues or has specific advice for skiping a step here?
>
> Thanks,
> -Jon
>
> --
> [1]
> https://www.dreamhost.com/blog/2016/06/21/dreamcompute-goes-m-for-mitaka-without-unleashing-the-dragons/
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

[Walter A. Boring IV]

Does QEMU support hardware initiators? iSER?

No, this is only for case where you're doing pure software based
iSCSI client connections. If we're relying on local hardware that's
a different story.


We regularly fix issues with iSCSI attaches in the release cycles of
OpenStack,
because it's all done in python using existing linux packages.  How often

This is a great example of the benefit that in-QEMU client gives us. The
Linux iSCSI client tools have proved very unreliable in use by OpenStack.
This is a reflection of the very architectural approach. We have individual
resources needed by distinct VMs, but we're having to manage them as a host
wide resource and that's creating us unneccessary complexity and having a
poor effect on our reliability overall.

I've been doing more and more digging and research into doing this
and it seems that canonical removed libiscsi from qemu due to security 
problems

in the 14.04 LTS release cycle.

Trying to fire up a new vm manually with qemu attaching an iscsi disk via
the documented mechanism ends up with qemu complaining that it can't
open the disk 'unknown protocol'.

qemu-system-x86_64 -drive 
file=iscsi://10.52.1.11/iqn.2000-05.com.3pardata:20810002ac00383d/0 
-iscsi initiator-name=iqn.walt-qemu-initiator
qemu-system-x86_64: -drive 
file=iscsi://10.52.1.11/iqn.2000-05.com.3pardata:20810002ac00383d/0: 
could not open disk image 
iscsi://10.52.1.11/iqn.2000-05.com.3pardata:20810002ac00383d/0: Unknown 
protocol


There was bug filed against qemu back in 2014 and was marked as wont fix 
due to security issues.

https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1271573

That looks like it has been fixed since here:
https://bugs.launchpad.net/ubuntu/+source/libiscsi/+bug/1271653
But that's only xenial (16.04) support and won't be in 14.x tree.


I have also confirmed that the 
nova.virt.libvirt.volume.net.LibvirtNetVolumeDriver

fails for iscsi for the same exact reason against nova master.

I modified the nova/virt/libvirt/driver.py and changed iscsi to point to 
the LibvirtNetVolumeDriver
and tried to attach an iSCSI volume.  It failed and the libvirtd log 
showed the unknown protocol error.


The n-cpu.log entry:
2016-06-24 08:09:21.555 8891 DEBUG nova.virt.libvirt.guest 
[req-46954106-c728-43ba-b40a-5b91a1639610 admin admin] attach device 
xml: 

  
  name="iqn.2000-05.com.3pardata:20810002ac00383d/0">


  
  
  a1d0c85e-d6e6-424f-9ca7-76ecd0ce45fb

 attach_device /opt/stack/nova/nova/virt/libvirt/guest.py:251
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver 
[req-46954106-c728-43ba-b40a-5b91a1639610 admin admin] [instance: 
74092b75-dc20-47e5-9127-c63367d05b29] Failed to attach volume at 
mountpoint: /dev/vdb
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29] Traceback (most recent call last):
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29]   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 1160, in attach_volume
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29] guest.attach_device(conf, 
persistent=True, live=live)
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29]   File 
"/opt/stack/nova/nova/virt/libvirt/guest.py", line 252, in attach_device
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29] 
self._domain.attachDeviceFlags(device_xml, flags=flags)
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29]   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 186, in 
doit
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29] result = 
proxy_call(self._autowrap, f, *args, **kwargs)
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29]   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 144, in 
proxy_call
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29] rv = execute(f, *args, **kwargs)
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29]   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 125, in 
execute
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29] six.reraise(c, e, tb)
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29]   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 83, in 
tworker
2016-06-24 08:09:21.574 8891 ERROR nova.virt.libvirt.driver [instance: 
74092b75-dc20-47e5-9127-c63367d05b29] rv = meth(*args, **kwargs)
2016-06-24 

Re: [openstack-dev] [horizon] npm lint and test problems in gate

[Jeremy Stanley]

On 2016-06-24 19:12:01 + (+), Borland, Matt wrote:
> It seems that the npm-run jobs are both passing Jenkins even when the tests
> themselves fail.  I'm not sure why that is, but Cores in particular:
> 
> Please run "npm run lint && npm run test" before you +2 (or +1) anything.
> This ensures that we don't pollute master with broken linting/tests.

I started digging into this briefly, mostly so that we could rule
out a behavior change from the switch from Jenkins to
zuul-launcher/ansible. Jobs were fully on zuul-launcher and off
Jenkins by the UTC end of the 16th[1] but according to graphite[2]
failures were seen in the check pipeline for
gate-horizon-npm-run-lint up to almost noon UTC on the 18th. Worth
noting, however, the gate-horizon-npm-run-test job uses that same
configuration (just passing a different {command}) and we're still
seeing failures[3] registered for it even now.

I also don't see any obvious changes to the configuration
gate-{name}-npm-run-{command} template or npm-run builder definition
this week to account for the behavior change.

[1] http://lists.openstack.org/pipermail/openstack-infra/2016-June/004435.html
[2] http://graphite.openstack.org/render/?width=800=400=None=stats_counts.zuul.pipeline.check.job.gate-horizon-npm-run-lint.FAILURE=-24days
 >
[3] http://graphite.openstack.org/render/?width=800=400=None=stats_counts.zuul.pipeline.check.job.gate-horizon-npm-run-test.FAILURE=-24days
 >

-- 
Jeremy Stanley

__
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] Using multiple compute drivers in Nova?

[Turbo Fredriksson]

The page 
http://docs.openstack.org/mitaka/config-reference/compute/hypervisors.html
states:

  Most installations use only one hypervisor. However, you can use
  ComputeFilter and ImagePropertiesFilter to schedule different
  hypervisors within the same installation. 

I have both those set, but the "compute_driver" is used to choose
the driver. This is a string, so only one option is available.

How do I use more than one?
--
Life sucks and then you die


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [Heat] Tripleo holding on to old, bad data

[Adam Young]

A coworker and I have both had trouble recovering from failed overcloud 
deploys.  I've wiped out whatever data I can, but, even with nothing in 
the Heat Database, doing an


openstack overcloud deploy

seems to be looking for a specific Nova server by UUID:


heat resource-show 93afc25e-1ab2-4773-9949-6906e2f7c115 0

| resource_status_reason | ResourceInError: 
resources[0].resources.Controller: Went to status ERROR due 
t│·
o "Message: No valid host was found. There are not enough hosts 
available., Code: 500" | 
│·

| resource_type  | OS::TripleO::Controller


Inside the Nova log I see:


2016-06-24 21:05:06.973 15551 DEBUG nova.api.openstack.wsgi 
[req-c8a5179c-2adf-45a6-b186-7d7b29cd8f39 
bcd│·fefb36f3ca9a8f3cfa445ab40 
ec662f250a85453cb40054f3aff49b58 - - -] Returning 404 to user: Instance 
8f9│·0c961-4609-4c9b-9d62-360a40f88eed 
could not be found. __call__ 
/usr/lib/python2.7/site-packages/nova/api/│·

openstack/wsgi.py:1070


How can I get the undercloud back to a clean state?


__
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] [fuel][plugins][ovs]

[Ankit Chilakapaty -X (achilaka - SRS CONSULTING INC at Cisco)]

Thanks,

-Ankit


From: Andrew Woodward [mailto:xar...@gmail.com]
Sent: Friday, June 24, 2016 12:20 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [fuel][plugins][ovs]

You can track the fuel version supported by examining the metadata.yaml in the 
root of the plugin repo. Since there is no stable/7.0 tag the last point before 
metadata.yaml was changed to 8.0 is 
https://github.com/openstack/fuel-plugin-ovs/tree/3776734a7b93ac440aa7b2e730d743b8510aac25
 You can try building from there but your on your own to get it to work.


On Fri, Jun 24, 2016 at 10:33 AM Ankit Chilakapaty -X (achilaka - SRS 
CONSULTING INC at Cisco) > wrote:
Hello,

I’m trying to install ovs with dpdk 2.4/2.2 plugin for openstack kilo mirantis 
7.0. I’m not sure if there is a compatible version for that on the github 
openstack/fuel-plugin-ovs . If there is one, could you upload the plugin.

Thanks


[banner11]



Ankit Chilakapaty
Engineer - IT
achil...@cisco.com
Tel:

Cisco Systems, Inc.



United States
cisco.com


[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here for 
Company Registration Information.





__
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
--

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
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-operators] [gnocchi] profiling and benchmarking 2.1.x

[gordon chung]

hi,

i realised i didn't post this beyond IRC, so here are some initial 
numbers for some performance/benchmarking i did on Gnocchi.

http://www.slideshare.net/GordonChung/gnocchi-profiling-21x

as a headsup, the data above is using Ceph and with pretty much a 
default configuration. i'm currently doing more tests to see how it 
works if you actually start turning some knobs on Ceph (spoiler: it gets 
better).

cheers,

-- 
gord
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [gnocchi] profiling and benchmarking 2.1.x

[gordon chung]

hi,

i realised i didn't post this beyond IRC, so here are some initial 
numbers for some performance/benchmarking i did on Gnocchi.

http://www.slideshare.net/GordonChung/gnocchi-profiling-21x

as a headsup, the data above is using Ceph and with pretty much a 
default configuration. i'm currently doing more tests to see how it 
works if you actually start turning some knobs on Ceph (spoiler: it gets 
better).

cheers,

-- 
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

Re: [openstack-dev] [vitrage][aodh] Notifications about aodh alarm state changes

[gordon chung]

On 24/06/2016 9:58 AM, Julien Danjou wrote:
> On Thu, Jun 23 2016, Afek, Ifat (Nokia - IL) wrote:
>
>> I understood that during Aodh-Vitrage design session in Austin, you had a
>> discussion about Vitrage need for notifications about Aodh alarm state 
>> changes.
>> Did you have a chance to think about it since, and to check how this can be
>> done?
>
> IIRC this was already implemented, just not enable by default and
> probably not well documented.
>
> Actually I see we took some note here:
>
>   https://etherpad.openstack.org/p/newton-telemetry-vitrage
>
> Feel free to send patches. :)

who put my name as TODO? *shakes fist*

sorry i haven't had time to look at it but *may* have time later next 
week. feel free to take it if you have time. we can provide guidance.

cheers,

-- 
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

Re: [openstack-dev] [fuel][plugins][ovs]

[Andrew Woodward]

You can track the fuel version supported by examining the metadata.yaml in
the root of the plugin repo. Since there is no stable/7.0 tag the last
point before metadata.yaml was changed to 8.0 is
https://github.com/openstack/fuel-plugin-ovs/tree/3776734a7b93ac440aa7b2e730d743b8510aac25
You
can try building from there but your on your own to get it to work.


On Fri, Jun 24, 2016 at 10:33 AM Ankit Chilakapaty -X (achilaka - SRS
CONSULTING INC at Cisco)  wrote:

> Hello,
>
>
>
> I’m trying to install ovs with dpdk 2.4/2.2 plugin for openstack kilo
> mirantis 7.0. I’m not sure if there is a compatible version for that on the
> github openstack/fuel-plugin-ovs . If there is one, could you upload the
> plugin.
>
>
>
> Thanks
>
>
>
>
>
> [image: banner11]
>
>
>
> *Ankit Chilakapaty*
>
> Engineer - IT
>
> achil...@cisco.com
>
> Tel:
>
> *Cisco Systems, Inc.*
>
>
>
>
> United States
> cisco.com
>
>
>
> [image: http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think
> before you print.
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
>
> Please click here
>  for
> Company Registration Information.
>
>
>
>
>
>
>
>
> __
> 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
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
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] [horizon] npm lint and test problems in gate

[Borland, Matt]

Horizoneers,

It seems that the npm-run jobs are both passing Jenkins even when the tests
themselves fail.  I'm not sure why that is, but Cores in particular:

Please run "npm run lint && npm run test" before you +2 (or +1) anything.
This ensures that we don't pollute master with broken linting/tests.

Thanks!

Matt Borland


__
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] [stable][all] Tagging kilo-eol for "the world"

[Sumit Naiksatam]

Hi, I had earlier requested in this thread that the stable/kilo branch
for the following repos be not deleted:

> openstack/group-based-policy
> openstack/group-based-policy-automation
> openstack/group-based-policy-ui
> openstack/python-group-based-policy-client

and the request was ack’ed by Tony (also in this thread). However, I
just noticed that these branches have been deleted. Can this deletion
please be reversed?

Thanks,
~Sumit.

On Fri, Jun 24, 2016 at 10:32 AM, Andreas Jaeger  wrote:
> On 06/24/2016 02:09 PM, Joshua Hesketh wrote:
>>
>> Hi all,
>>
>> I have completed removing stable/kilo branches from the projects listed
>> [0]*. There are now 'kilo-eol' tags in place at the sha's where the
>> branches were.
>>
>> *There are a couple of exceptions. oslo-incubator was listed but is an
>> unmaintained project so no further action was required. Tony and I have
>> also decided to hold off
>> on openstack-dev/devstack, openstack-dev/grenade, openstack-dev/pbr
>> and openstack/requirements until we are confident removing the
>> stable/kilo branch will have no negative effects on the projects who
>> opt-ed out of being EOL'd.
>>
>> In this process we noted a couple of repositories still have branches
>> from Juno and even earlier. I haven't put together a comprehensive list
>> of old branches, but rather if your project has an outdated branch that
>> you would like removed and/or tagged as end-of-life, please let me know.
>>
>> For those interested in the script I used or other infra cores looking
>> to perform this next time, it is up for review in the release-tools
>> repo: https://review.openstack.org/333875
>
>
> Thanks, Joshua.
>
> We're now removing the special handling of kilo branches from project-config
> as well - it looks odd for some projects where kilo is removed from
> conditions and we still have icehouse or juno. Followup changes are welcome.
>
> https://review.openstack.org/334008
> https://review.openstack.org/333910
> https://review.openstack.org/333977
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
>
> __
> 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] [release][reno][infra] merging tags between branches is confusing our release notes

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2016-06-08 14:13:44 -0400:
> tl;dr: The switch from pre-versioning to post-versioning means that
> sometimes master appears to be older than stable/$previous, so we
> merge "final" tags from stable/$previous into master to make up for
> it. This introduces versions into the history of master that aren't
> *really* there, but git sees them and so does reno. That, in turn,
> means that the release notes generated from master may place some
> notes in the wrong version, suggesting that something happened
> sooner than it did. I propose that we stop merging tags, and instead
> introduce a new tag on master after we create a branch to ensure
> that the version number there is always higher than stable/$previous.

The change to implement this has merged [1].

Doug

[1] https://review.openstack.org/#/c/333421/

__
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-Infra] Gerritbot can only handle 120 channels but found 121.

[Andreas Jaeger]

On 06/24/2016 03:24 PM, BIN HU wrote:

Hello,

I submitted patch for creating a new project "openstack/gluon":
https://review.openstack.org/#/c/333843/

There is a build error: Gerritbot can only handle 120 channels but found 121.
http://logs.openstack.org/43/333843/3/check/gate-project-config-irc-access/1ec2b49/console.html

Looks like it cannot handle my IRC channel "#openstack-gluon" that I added in 
"accessbot/channels.yaml" and "gerritbot/channels.yaml" even if the access is ok 
"INFO:checkaccess:openstackinfra access ok on #openstack-gluon"

Can you help fix it by lifting the limit from 120 to 121? Or how can I fix it?


As mentioend on IRC: This is a hard limit that we cannot change. For 
now, you just cannot use gerritbot - until somebody volunteers to set up 
a second bot,


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [QA][Infra] Newton Code Sprint

[Spencer Krum]

I added a 'topics' section to the wiki. Infra has many contributors and
many projects, it's valuable to know what we'll be focusing on at the
sprint so people can know ahead of time if they should go. For me, I'm
interested in hacking on infracloud and the hardening aspect of the
puppet/ansible interaction. I know some other people want to hack on
zuulv3. It's possible an etherpad is a better format for shaking out
what topics people want to work on, which we can move to if people
prefer.


-- 
  Spencer Krum
  n...@spencerkrum.com

__
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] [fuel][plugins][ovs]

[Ankit Chilakapaty -X (achilaka - SRS CONSULTING INC at Cisco)]

Hello,

I'm trying to install ovs with dpdk 2.4/2.2 plugin for openstack kilo mirantis 
7.0. I'm not sure if there is a compatible version for that on the github 
openstack/fuel-plugin-ovs . If there is one, could you upload the plugin.

Thanks


[banner11]



Ankit Chilakapaty
Engineer - IT
achil...@cisco.com
Tel:

Cisco Systems, Inc.



United States
cisco.com


[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here for 
Company Registration Information.





__
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] [stable][all] Tagging kilo-eol for "the world"

[Andreas Jaeger]

On 06/24/2016 02:09 PM, Joshua Hesketh wrote:

Hi all,

I have completed removing stable/kilo branches from the projects listed
[0]*. There are now 'kilo-eol' tags in place at the sha's where the
branches were.

*There are a couple of exceptions. oslo-incubator was listed but is an
unmaintained project so no further action was required. Tony and I have
also decided to hold off
on openstack-dev/devstack, openstack-dev/grenade, openstack-dev/pbr
and openstack/requirements until we are confident removing the
stable/kilo branch will have no negative effects on the projects who
opt-ed out of being EOL'd.

In this process we noted a couple of repositories still have branches
from Juno and even earlier. I haven't put together a comprehensive list
of old branches, but rather if your project has an outdated branch that
you would like removed and/or tagged as end-of-life, please let me know.

For those interested in the script I used or other infra cores looking
to perform this next time, it is up for review in the release-tools
repo: https://review.openstack.org/333875


Thanks, Joshua.

We're now removing the special handling of kilo branches from 
project-config as well - it looks odd for some projects where kilo is 
removed from conditions and we still have icehouse or juno. Followup 
changes are welcome.


https://review.openstack.org/334008
https://review.openstack.org/333910
https://review.openstack.org/333977

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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]Midcycle

[Hongbin Lu]

Hi all,

The Magnum midcycle will be held in Aug 4 - 5 at Austin. Below is the link to 
register. Hope to see you all there.

https://www.eventbrite.com/e/magnum-midcycle-tickets-26245489967

Best regards,
Hongbin
__
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] [classifier] Spec detailing both approaches

[Duarte Cardoso, Igor]

Thanks Vikram!

I’ve added my approach to the spec and made it compatible with spec docs/py27, 
I’ll submit it now so part of the community can still take a look before the 
end of the week :)

Best regards,
Igor.

From: Vikram Choudhary [mailto:viks...@gmail.com]
Sent: Friday, June 24, 2016 3:09 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] [classifier] Spec detailing both 
approaches

Hi Igor/Cathy/Louis,

Thanks for driving this effort. Will certainly help with the review!

Thanks
Vikram

On Fri, Jun 24, 2016 at 5:47 PM, Duarte Cardoso, Igor 
> wrote:
Hi Cathy, Louis,

I'll reupload the Neutron spec today to openstack/neutron-specs along with the 
rst file and the neutron-classifier-inspired approach detailed, replacing [1] 
and [2] from openstack/neutron, is that okay?

Review from the Neutron community, interested consumers and neutron-classifier 
contributors will be highly appreciated.

[1] https://review.openstack.org/#/c/332584/
[2] https://review.openstack.org/#/c/332958/

Best regards,
Igor.


__
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] neutron, l2population, linuxbridge and multiple ips

[James Denton]

Hi Andreas,

LinuxBridge w/ VXLAN and l2population was incompatible with 
allowed-address-pairs, or any case where an IP may be configured on an 
interface that isn't defined on a port or moves around from VM to VM, for some 
time. It is more of a limitation of the ARP proxy implementation in the VXLAN 
kernel module more than a Neutron bug, but nonetheless, here you go:

https://bugs.launchpad.net/neutron/+bug/1445089

The workaround was to patch the LinuxBridge agent to disable the ARP proxy when 
creating vxlan interfaces. Try adding 'arp_responder=False' to the [vxlan] 
section of the linuxbridge agent config file and restart the agent. This should 
be done across all nodes, and will only apply to Liberty and above.

James

From: Andreas Scheuring 
Sent: Monday, June 20, 2016 6:06 AM
To: openstack@lists.openstack.org
Subject: Re: [Openstack] neutron, l2population, linuxbridge and multiple ips

- What about using Neutrons "allowed address pairs"?
- Or setting up a tunnel network within your existing openstack tunnel
network?



--
-
Andreas
IRC: andreas_s



On Sa, 2016-06-18 at 18:52 +0200, Joerg Streckfuss wrote:
> Dear list,
>
> I'm trying set up an isolated network for testing clustermanagers like
> keepalived on linux and carp on openbsd. This means there are ips which
> are bound to multiple ports. The main problem is when I try to configure
> new ip-addresses inside the vms and _not_ in neutron, these ips are not
> visible by the other vms. When I try to ping this ips I can see an local
> arp request inside the bridge of the requesting vm but this request does
> not reach the bridge of the destination vm. So my assumption is neutron
> in particular the l2population works only for ip addresses which are
> known by neutron ports. So in case of disabling dhcp I have to configure
> it for the neutron port and inside the vm, right?
>
> My setup is a 4-node openstack environment (one controller, three
> compute nodes), using liberty on centos7 carefully following the
> instructions under http://docs.openstack.org/liberty/install-guide-rdo/.
>
> I'm using self-service networks with one flat provider-network for
> external communication. I use VXLAN for overlay-networks. As mechanism
> drivers I use linuxbridge and l2population.
>
> The isolated network and the vms are initiated by heat templates. I
> disabled port security for each neutron port by setting
> 'port_security_enabled: false' inside the heat template.
>
> So what can I do, that a neutron isolated network behaves like a
> standard linuxbridge or especially a hardware switch, where no port
> security is configured and which forwards all kind of arp traffic?
>
> Thanks in advance,
>
> Joerg
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Fuel] Merge IRC channels

[Andrew Woodward]

There is also #fuel-devops

I never liked having all the channels, so +1

On Fri, Jun 24, 2016 at 4:25 AM Anastasia Urlapova 
wrote:

> Vova,
> please don't forget merge #fuel-qa into a #fuel
>
> On Fri, Jun 24, 2016 at 1:55 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Nice. #fuel-infra is to merged as well.
>>
>> Vladimir Kozhukalov
>>
>> On Fri, Jun 24, 2016 at 1:50 PM, Aleksandra Fedorova <
>> afedor...@mirantis.com> wrote:
>>
>>> And +1 for #fuel-infra
>>>
>>> As of now it will be more useful if infra issues related to project will
>>> be visible for project developers. We don't have much infra-related traffic
>>> on IRC for now, and we will be able to split again if we got it.
>>>
>>> On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
 Dear colleagues,

 We have a few IRC channels but the level of activity there is quite low.

 #fuel
 #fuel-dev
 #fuel-python
 #fuel-infra

 My suggestion is to merge all these channels into a single IRC channel
 #fuel.
 Other #fuel-* channels are to be deprecated.

 What do you think of this?


 Vladimir Kozhukalov


 __
 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


>>>
>>>
>>> --
>>> Aleksandra Fedorova
>>> Fuel CI Engineer
>>> bookwar
>>>
>>>
>>> __
>>> 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 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
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
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] Proposal: Architecture Working Group

[Clint Byrum]

Excerpts from Zhipeng Huang's message of 2016-06-24 18:15:30 +0200:
> Hi Clint and Amrith,
> 
> Are you guys already working on the proposal ? Is there any public access
> to see the first draft ?
> 

I've started writing something up, and I hope to submit it for review
next week.

__
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] [nova][scheduler] Next scheduler subteam meeting

[Ed Leafe]

The next meeting for the Nova Scheduler subteam will be Monday, June 27 at 
1400UTC
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160627T14

The agenda is here: https://wiki.openstack.org/wiki/Meetings/NovaScheduler

Please add any items you would like to discuss to the agenda before the 
meeting. And since we are starting to plan for the midcycle, please add any 
topics you feel would be appropriate to that section of the agenda.


-- Ed Leafe






__
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] Status of the OpenStack port to Python 3

[Sean Dague]

On 06/24/2016 11:48 AM, Doug Hellmann wrote:
> Excerpts from Dmitry Tantsur's message of 2016-06-24 10:59:14 +0200:
>> On 06/23/2016 11:21 PM, Clark Boylan wrote:
>>> On Thu, Jun 23, 2016, at 02:15 PM, Doug Hellmann wrote:
 Excerpts from Thomas Goirand's message of 2016-06-23 23:04:28 +0200:
> On 06/23/2016 06:11 PM, Doug Hellmann wrote:
>> I'd like for the community to set a goal for Ocata to have Python
>> 3 functional tests running for all projects.
>>
>> As Tony points out, it's a bit late to have this as a priority for
>> Newton, though work can and should continue. But given how close
>> we are to having the initial phase of the port done (thanks Victor!),
>> and how far we are from discussions of priorities for Ocata, it
>> seems very reasonable to set a community-wide goal for our next
>> release cycle.
>>
>> Thoughts?
>>
>> Doug
>
> +1
>
> Just think about it for a while. If we get Nova to work with Py3, and
> everything else is working, including all functional tests in Tempest,
> then after Otaca, we could even start to *REMOVE* Py2 support after
> Otaca+1. That would be really awesome to stop all the compat layer
> madness and use the new features available in Py3.

 We'll need to get some input from other distros and from deployers
 before we decide on a timeline for dropping Python 2. For now, let's
 focus on making Python 3 work. Then we can all rejoice while having the
 discussion of how much longer to support Python 2. :-)

>
> I really would love to ship a full stack running Py3 for Debian Stretch.
> However, for this, it'd be super helful to have as much visibility as
> possible. Are we setting a hard deadline for the Otaca release? Or is
> this just a goal we only "would like" to reach, but it's not really a
> big deal if we don't reach it?

 Let's see what PTLs have to say about planning, but I think if not
 Ocata then we'd want to set one for the P release. We're running
 out of supported lifetime for Python 2.7.
>>>
>>> Keep in mind that there is interest in running OpenStack on PyPy which
>>> is python 2.7. We don't have to continue supporting CPython 2.7
>>> necessarily but we may want to support python 2.7 by way of PyPy.
>>
>> PyPy folks have been working on python 3 support for some time already: 
>> http://doc.pypy.org/en/latest/release-pypy3.3-v5.2-alpha1.html
>> It's an alpha, but by the time we consider dropping Python 2 it will 
>> probably be released :)
> 
> We're targeting Python >=3.4, right now.  We'll have to decide as
> a community whether PyPy support is a sufficient reason to keep
> support for "older" versions (either 2.x or earlier versions of 3).
> Before we can have that discussion, though, we need to actually run on
> Python 3, so let's focus on that and evaluate the landscape of other
> interpreters when the porting work is done.

+1, please don't get ahead of things until there is real full stack
testing running on python3.

It would also be good if some of our operators were running on python 3
and providing feedback that it works in the real world before we even
talk about dropping. Because our upstream testing (even the full stack
testing) only can catch so much.

So next steps:

1) full stack testing of everything we've got on python3 - (are there
volunteers to get that going?)
2) complete Nova port to enable full stack testing on python3 for iaas base
3) encourage operators to deploy with python3 in production
4) gather real world feedback, develop rest of plan

-Sean

-- 
Sean Dague
http://dague.net

__
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] Proposal: Architecture Working Group

[Zhipeng Huang]

Hi Clint and Amrith,

Are you guys already working on the proposal ? Is there any public access
to see the first draft ?

On Wed, Jun 22, 2016 at 11:23 PM, Mike Perez  wrote:

> On 10:27 Jun 20, Clint Byrum wrote:
> > Excerpts from Doug Wiegley's message of 2016-06-20 10:40:56 -0600:
> > > So, it sounds like you’ve just described the job of the TC. And they
> have so far refused to define OpenStack, leading to a series of derivative
> decisions that seem … inconsistent over time.
> > >
> > > How is this body going to be different?
> > >
> > > How will it have any teeth, and not just end up with the standard
> entrenched projects ignoring it?
> > >
>
> 
>
> > Engineers have no effective place to turn to right now when there is
> > a lack of design. The TC could of course do it, but what I want to do
> > is have a more open and free-flowing group that are laser focused on
> > providing support for the design of the system. I want to work out with
> > the community at large how we add weight to the designs we choose, and
> > one good option is for the Architecture Working Group to make proposals
> > to the openstack-specs repo, which the TC would ultimately approve.
> > That's not a new process, we already have it:
> >
> > http://docs.openstack.org/project-team-guide/cross-project.html
>
> Thanks for reminding me to update that. These are actually approved by the
> cross-project spec team now.
>
>
> http://governance.openstack.org/resolutions/20160414-grant-cross-project-spec-team-voting.html
>
> --
> Mike Perez
>
> __
> 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
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [grenade] upgrades vs rootwrap

[Jeremy Stanley]

On 2016-06-24 06:47:08 -0400 (-0400), Sean Dague wrote:
[...]
> When you upgrade Apache, you don't have to change your config
> files.
[...]

*cough* (2.4) *cough*

But it still highlights your point. There's been basically one
Apache transition in recent history where a majority of people
running it needed to adjust their configs, and many of us considered
that a significant hassle.
-- 
Jeremy Stanley

__
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] Status of the OpenStack port to Python 3

[Doug Hellmann]

Excerpts from Daniel P. Berrange's message of 2016-06-24 09:25:35 +0100:
> On Thu, Jun 23, 2016 at 11:04:28PM +0200, Thomas Goirand wrote:
> > On 06/23/2016 06:11 PM, Doug Hellmann wrote:
> > > I'd like for the community to set a goal for Ocata to have Python
> > > 3 functional tests running for all projects.
> > > 
> > > As Tony points out, it's a bit late to have this as a priority for
> > > Newton, though work can and should continue. But given how close
> > > we are to having the initial phase of the port done (thanks Victor!),
> > > and how far we are from discussions of priorities for Ocata, it
> > > seems very reasonable to set a community-wide goal for our next
> > > release cycle.
> > > 
> > > Thoughts?
> > > 
> > > Doug
> > 
> > +1
> > 
> > Just think about it for a while. If we get Nova to work with Py3, and
> > everything else is working, including all functional tests in Tempest,
> > then after Otaca, we could even start to *REMOVE* Py2 support after
> > Otaca+1. That would be really awesome to stop all the compat layer
> > madness and use the new features available in Py3.
> 
> Please lets not derail discussions about completing Py3 support by
> opening up the can of worms wrt dropping Py2.
> 
> Lets get the Py3 support completed and in the hands of users and
> proven acceptable before we talk about dropping support for the python
> platform that every single deployment runs on today.
> 
> 
> Regards,
> Daniel

+1

Let's take this one step at a time. Those steps are big and take
time, during which a lot of other things may change. When we're
ready to claim full support for Python 3, then we'll look at the
current support ecosystem and discuss dropping support for 2.

Doug

__
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] Status of the OpenStack port to Python 3

[Flavio Percoco]

On 23/06/16 12:11 -0400, Doug Hellmann wrote:

Excerpts from Thomas Goirand's message of 2016-06-22 10:49:01 +0200:

On 06/22/2016 09:18 AM, Victor Stinner wrote:
> Hi,
>
> Current status: only 3 projects are not ported yet to Python 3:
>
> * nova (76% done)
> * trove (42%)
> * swift (0%)
>
>https://wiki.openstack.org/wiki/Python3
>
> Number of projects already ported:
>
> * 19 Oslo Libraries
> * 4 Development Tools
> * 22 OpenStack Clients
> * 6 OpenStack Libraries (os-brick, taskflow, glance_store, ...)
> * 12 OpenStack services approved by the TC
> * 17 OpenStack services (not approved by the TC)
>
> Raw total: 80 projects. In fact, 3 remaining projects on 83 is only 4%,
> we are so close! ;-)
>
> The next steps are to port the 3 remaining projects and work on
> functional and integration tests on Python 3.
>
> Victor

Hi Victor,

Thanks a lot for your efforts on Py3.

Do you think it looks like possible to have Nova ported to Py3 during
the Newton cycle?

Cheers,

Thomas Goirand (zigo)



I'd like for the community to set a goal for Ocata to have Python
3 functional tests running for all projects.

As Tony points out, it's a bit late to have this as a priority for
Newton, though work can and should continue. But given how close
we are to having the initial phase of the port done (thanks Victor!),
and how far we are from discussions of priorities for Ocata, it
seems very reasonable to set a community-wide goal for our next
release cycle.

Thoughts?


Sounds good to me!

We should start working with PTL's/Teams in advance to make sure we have enough
attendance at the summit session to (I'd hope to see one happening, at least) so
that we can work on a more realistic plan for Ocata.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] Status of the OpenStack port to Python 3

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2016-06-24 10:59:14 +0200:
> On 06/23/2016 11:21 PM, Clark Boylan wrote:
> > On Thu, Jun 23, 2016, at 02:15 PM, Doug Hellmann wrote:
> >> Excerpts from Thomas Goirand's message of 2016-06-23 23:04:28 +0200:
> >>> On 06/23/2016 06:11 PM, Doug Hellmann wrote:
>  I'd like for the community to set a goal for Ocata to have Python
>  3 functional tests running for all projects.
> 
>  As Tony points out, it's a bit late to have this as a priority for
>  Newton, though work can and should continue. But given how close
>  we are to having the initial phase of the port done (thanks Victor!),
>  and how far we are from discussions of priorities for Ocata, it
>  seems very reasonable to set a community-wide goal for our next
>  release cycle.
> 
>  Thoughts?
> 
>  Doug
> >>>
> >>> +1
> >>>
> >>> Just think about it for a while. If we get Nova to work with Py3, and
> >>> everything else is working, including all functional tests in Tempest,
> >>> then after Otaca, we could even start to *REMOVE* Py2 support after
> >>> Otaca+1. That would be really awesome to stop all the compat layer
> >>> madness and use the new features available in Py3.
> >>
> >> We'll need to get some input from other distros and from deployers
> >> before we decide on a timeline for dropping Python 2. For now, let's
> >> focus on making Python 3 work. Then we can all rejoice while having the
> >> discussion of how much longer to support Python 2. :-)
> >>
> >>>
> >>> I really would love to ship a full stack running Py3 for Debian Stretch.
> >>> However, for this, it'd be super helful to have as much visibility as
> >>> possible. Are we setting a hard deadline for the Otaca release? Or is
> >>> this just a goal we only "would like" to reach, but it's not really a
> >>> big deal if we don't reach it?
> >>
> >> Let's see what PTLs have to say about planning, but I think if not
> >> Ocata then we'd want to set one for the P release. We're running
> >> out of supported lifetime for Python 2.7.
> >
> > Keep in mind that there is interest in running OpenStack on PyPy which
> > is python 2.7. We don't have to continue supporting CPython 2.7
> > necessarily but we may want to support python 2.7 by way of PyPy.
> 
> PyPy folks have been working on python 3 support for some time already: 
> http://doc.pypy.org/en/latest/release-pypy3.3-v5.2-alpha1.html
> It's an alpha, but by the time we consider dropping Python 2 it will 
> probably be released :)

We're targeting Python >=3.4, right now.  We'll have to decide as
a community whether PyPy support is a sufficient reason to keep
support for "older" versions (either 2.x or earlier versions of 3).
Before we can have that discussion, though, we need to actually run on
Python 3, so let's focus on that and evaluate the landscape of other
interpreters when the porting work is done.

Doug

__
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] Proposal for a new tool: dlrn-repo

[Ben Nemec]

I'm just going to take this opportunity to point out that when RDO moved
the dlrn repos this week the tool did not break because requests is
smarter than curl.  Also, it would have been super nice to have exactly
one place to update the repo locations instead of at least 3.

On 06/13/2016 03:29 PM, Ben Nemec wrote:
> So our documented repo setup steps are three curls, a sed, and a
> multi-line bash command.  And the best part?  That's not even what we
> test.  The commands we actually use in tripleo.sh --repo-setup consist
> of the following: three curls, four seds, and (maybe) the same
> multi-line bash command.  Although whether that big list of packages in
> includepkgs is actually up to date with what we're testing is anybody's
> guess because without actually plugging both into a diff tool you
> probably can't visually find any differences.
> 
> What is my point?  That this whole process is overly complicated and
> error-prone.  If you miss one of those half dozen plus commands you're
> going to end up with a broken repo setup.  As one of the first things
> that a new user has to do in TripleO, this is a pretty poor introduction
> to the project.
> 
> My proposal is an rdo-release-esque project that will handle the repo
> setup for you, except that since dlrn doesn't really deal in releases I
> think the -repo name makes more sense.  Here's a first pass at such a
> tool: https://github.com/cybertron/dlrn-repo
> 
> This would reduce the existing commands in tripleo.sh from:
> sudo sed -i -e 's%priority=.*%priority=30%' $REPO_PREFIX/delorean-deps.repo
> sudo curl -o $REPO_PREFIX/delorean.repo
> $DELOREAN_REPO_URL/$DELOREAN_REPO_FILE
> sudo sed -i -e 's%priority=.*%priority=20%' $REPO_PREFIX/delorean.repo
> sudo curl -o $REPO_PREFIX/delorean-current.repo
> http://trunk.rdoproject.org/centos7/current/delorean.repo
> sudo sed -i -e 's%priority=.*%priority=10%'
> $REPO_PREFIX/delorean-current.repo
> sudo sed -i 's/\[delorean\]/\[delorean-current\]/'
> $REPO_PREFIX/delorean-current.repo
> sudo /bin/bash -c "cat <<-EOF>>$REPO_PREFIX/delorean-current.repo
> includepkgs=diskimage-builder,instack,instack-undercloud,os-apply-config,os-cloud-config,os-collect-config,os-net-config,os-refresh-config,python-tripleoclient,tripleo-common,openstack-tripleo-heat-templates,openstack-tripleo-image-elements,openstack-tripleo,openstack-tripleo-puppet-elements
> EOF"
> sudo yum -y install yum-plugin-priorities
> 
> to:
> sudo yum install -y http://tripleo.org/dlrn-repo.rpm # or wherever
> sudo dlrn-repo tripleo-current
> 
> As you can see in the readme it also supports the stable branch repos or
> running against latest master of everything.
> 
> Overall I think this is clearly a better user experience, and as an
> added bonus it would allow us to use the exact same code for repo
> management on the user side and in CI, which we can't have with a
> developer-specific tool like tripleo.sh.
> 
> There's plenty left to do before this would be fully integrated (import
> to TripleO, package, update docs, update CI), so I wanted to solicit
> some broader input before pursuing it further.
> 
> Thanks.
> 
> -Ben
> 
> __
> 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] [all] Status of the OpenStack port to Python 3

[Monty Taylor]

On 06/24/2016 10:10 AM, Clint Byrum wrote:
> Excerpts from Amrith Kumar's message of 2016-06-24 10:13:37 +:
>>
>>> -Original Message-
>>> From: Doug Hellmann [mailto:d...@doughellmann.com]
>>> Sent: Thursday, June 23, 2016 5:16 PM
>>> To: openstack-dev 
>>> Subject: Re: [openstack-dev] [all] Status of the OpenStack port to Python 3
>>>
>> [... snip ...]
>>>
>>> Let's see what PTLs have to say about planning, but I think if not
>>> Ocata then we'd want to set one for the P release. We're running
>>> out of supported lifetime for Python 2.7.
>>>
>>> Doug
>>>
>>
>> Doug, I believe py27 will be supported till end of 2020 but distribution 
>> vendors (os people) are not yet deploying py3 as the default.
>>
>> Could someone share the best information on when we may see Python3 be the 
>> default from the various os distribution providers. The date of 2020 for EOS 
>> leads me to believe that we're good until about the U or V release (assuming 
>> two per year) but I don't believe that's the correct way to plan for this, 
>> yes?
>>
> 
> Fedora, Ubuntu, and Gentoo are already defaulting to python3 for all
> of their OS tools, so you can have a fully functioning system without
> python2.

Also, _defaulting_ to python3 in the distro is different than python3
being available to be installed. Even with Ubuntu Trusty and RHEL7 you
can apt-get install python3 | yum install python3.

So I do not think it is important whether or not python3 is the default
python on the machine. The important thing is that on all of our
supported platforms, python3 is easily available. That means that our
distros can package OpenStack components and do the things that packages
need to do to make sure that they run with python3. We're already at
that point, so moving forward with python3 for OpenStack should not be
blocked on distro support at this point.




__
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] Status of the OpenStack port to Python 3

[Doug Hellmann]

Excerpts from Clint Byrum's message of 2016-06-24 08:10:18 -0700:
> Excerpts from Amrith Kumar's message of 2016-06-24 10:13:37 +:
> > 
> > > -Original Message-
> > > From: Doug Hellmann [mailto:d...@doughellmann.com]
> > > Sent: Thursday, June 23, 2016 5:16 PM
> > > To: openstack-dev 
> > > Subject: Re: [openstack-dev] [all] Status of the OpenStack port to Python 
> > > 3
> > > 
> > [... snip ...]
> > > 
> > > Let's see what PTLs have to say about planning, but I think if not
> > > Ocata then we'd want to set one for the P release. We're running
> > > out of supported lifetime for Python 2.7.
> > > 
> > > Doug
> > > 
> > 
> > Doug, I believe py27 will be supported till end of 2020 but distribution 
> > vendors (os people) are not yet deploying py3 as the default.
> > 
> > Could someone share the best information on when we may see Python3 be the 
> > default from the various os distribution providers. The date of 2020 for 
> > EOS leads me to believe that we're good until about the U or V release 
> > (assuming two per year) but I don't believe that's the correct way to plan 
> > for this, yes?
> > 
> 
> Fedora, Ubuntu, and Gentoo are already defaulting to python3 for all
> of their OS tools, so you can have a fully functioning system without
> python2.
> 

That's right.

Some of the distros are starting to split the version of python
they use for their operating system tools from the packages
applications use, so the "default" version of Python isn't necessarily
what we care about -- as an application, we're not supposed to use
that version.  The important thing is that it is possible to get
Python 3.4 or 3.5 packages for all of the major distros through
normal and supported mechanisms.  So, there is no longer any reason
to use distro support as a reason to put off porting.

Doug

__
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] Status of the OpenStack port to Python 3

[Clint Byrum]

Excerpts from Amrith Kumar's message of 2016-06-24 10:13:37 +:
> 
> > -Original Message-
> > From: Doug Hellmann [mailto:d...@doughellmann.com]
> > Sent: Thursday, June 23, 2016 5:16 PM
> > To: openstack-dev 
> > Subject: Re: [openstack-dev] [all] Status of the OpenStack port to Python 3
> > 
> [... snip ...]
> > 
> > Let's see what PTLs have to say about planning, but I think if not
> > Ocata then we'd want to set one for the P release. We're running
> > out of supported lifetime for Python 2.7.
> > 
> > Doug
> > 
> 
> Doug, I believe py27 will be supported till end of 2020 but distribution 
> vendors (os people) are not yet deploying py3 as the default.
> 
> Could someone share the best information on when we may see Python3 be the 
> default from the various os distribution providers. The date of 2020 for EOS 
> leads me to believe that we're good until about the U or V release (assuming 
> two per year) but I don't believe that's the correct way to plan for this, 
> yes?
> 

Fedora, Ubuntu, and Gentoo are already defaulting to python3 for all
of their OS tools, so you can have a fully functioning system without
python2.

__
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-announce] RCE vulnerability in Openstack Murano using insecure YAML tags (CVE-2016-4972)

[Kirill Zaitsev]

==
RCE vulnerability in Openstack Murano using insecure YAML tags
==

:Date: June 23, 2016
:CVE: CVE-2016-4972


Affects
~~~
- Murano: <=2015.1.1; <=1.0.2; ==2.0.0
- Murano-dashboard: <=2015.1.1; <=1.0.2; ==2.0.0
- Python-muranoclient: <=0.7.2; >=0.8.0<=0.8.4


Description
~~~
Kirill Zaitsev from Mirantis reported a vulnerability in OpenStack
Murano applications processing. Using extended YAML tags in Murano
application YAML files, an attacker can perform a Remote Code
Execution attack.

Vulnerability has been verified in all currently supported branches.
Further examination of code suggest, that it is also present in kilo and
juno versions of murano.

Patches
~~~
- https://review.openstack.org/#/c/333444/ (Liberty)
- https://review.openstack.org/#/c/333425/ (Liberty)
- https://review.openstack.org/#/c/333432/ (Liberty)
- https://review.openstack.org/#/c/333443/ (Mitaka)
- https://review.openstack.org/#/c/333424/ (Mitaka)
- https://review.openstack.org/#/c/333439/ (Mitaka)
- https://review.openstack.org/#/c/333423/ (Newton)
- https://review.openstack.org/#/c/333440/ (Newton)
- https://review.openstack.org/#/c/333428/ (Newton)


Credits
~~~
- Kirill Zaitsev from Mirantis (CVE-2016-4972)


References
~~
- https://bugs.launchpad.net/python-muranoclient/+bug/1586078
- https://bugs.launchpad.net/murano/+bug/1586079
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4972

Notes
~
- Fixes for this bug are going to be included in the upcoming releases
  of murano 1.0.3(liberty), 2.0.1(mitaka), 3.0.0(newton) and  
  python-muranoclient 0.7.3(liberty), 0.8.5(mitaka), 0.9.0(newton)


--  
Kirill Zaitsev
Murano Project Technical Lead

signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

Re: [Openstack] nova service-list error

[Turbo Fredriksson]

On Jun 24, 2016, at 3:06 PM, venkat boggarapu wrote:

> When i am trying to run the command nova service-list i am getting the
> below error


If you run the following command, what do you get?

env | grep ^OS | sort
--
Imagine you're an idiot and then imagine you're in
the government. Oh, sorry. Now I'm repeating myself
- Mark Twain


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] nova service-list error

[Eugen Block]

You need a domain in your environment variables, e.g.

export OS_USER_DOMAIN_NAME=
or
export OS_USER_DOMAIN_ID=

Your environment script should provide

 OS_PROJECT_DOMAIN_NAME
 OS_USER_DOMAIN_NAME
 OS_PROJECT_NAME
 OS_USERNAME
 OS_PASSWORD
 OS_AUTH_URL=http://controller:35357/v3 --> (or  
OS_AUTH_URL=http://controller:5000/v3)

 OS_IDENTITY_API_VERSION=3
 OS_IMAGE_API_VERSION=2

Zitat von venkat boggarapu :


HI All,

When i am trying to run the command nova service-list i am getting the
below error


ERROR (BadRequest): Expecting to find domain in project - the server could
not comply with the request since it is either malformed or otherwise
incorrect. The client is assumed to be in error. (HTTP 400) (Request-ID:
req-78bdca0c-6dda-4f4d-a571-eee336cec053)

can someone help regarding this.


With regards
venkat




--
Eugen Block voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg e-mail  : ebl...@nde.ag

Vorsitzende des Aufsichtsrates: Angelika Mozdzen
  Sitz und Registergericht: Hamburg, HRB 90934
  Vorstand: Jens-U. Mozdzen
   USt-IdNr. DE 814 013 983


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [TripleO] CI package build issues

[John Trowbridge]

A quick update on this. It appears that
https://review.rdoproject.org/r/1500 did indeed resolve the issue. There
have been no hits on the logstash query [1] since that merged.

[1]
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22cleaning%20directory%20and%20cloning%20again%5C%22%20AND%20filename%3A%5C%22console.html%5C%22

On 06/23/2016 03:50 PM, John Trowbridge wrote:
> 
> 
> On 06/23/2016 02:56 PM, Dan Prince wrote:
>> After discovering some regressions today we found what we think is a
>> package build issue in our CI environment which might be the cause of
>> our issues:
>>
>> https://bugs.launchpad.net/tripleo/+bug/1595660
>>
>> Specifically, there is a case where DLRN might not be giving an error
>> code if build failures occur, and thus our jobs don't get the updated
>> package symlink and thus give a false positive.
>>
>> Until we get this solved be careful when merging. You might look for
>> 'packages not built correctly: not updating the consistent symlink' in
>> the job output. I see over 200 of these in the last 24 hours:
>>
> 
> I updated the bug, but will reply here for completeness. The "not
> updating the consistent symlink" message appears 100% of the time when
> not building all packages in rdoinfo.
> 
> Instead what happened is we built HEAD of master instead of the refspec
> from zuul.
> 
> http://logs.openstack.org/17/324117/22/check-tripleo/gate-tripleo-ci-centos-7-nonha/3758449/console.html#_2016-06-23_03_40_49_234238
> 
> c48410a05ec0ffd11c717bcf350badc9e5f0e910 is the commit it should have built.
> 
> 4ef338574b1a7cef8b1b884d439556b24fb09718 was built instead.
> 
> So the logstash query we could use is instead:
> 
> http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22cleaning%20directory%20and%20cloning%20again%5C%22%20AND%20filename%3A%5C%22console.html%5C%22
> 
> I think https://review.rdoproject.org/r/1500 is the fix.
> 
> __
> 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] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

[Daniel P. Berrange]

On Fri, Jun 24, 2016 at 08:05:38AM -0600, John Griffith wrote:
> On Fri, Jun 24, 2016 at 2:19 AM, Daniel P. Berrange 
> wrote:
> 
> > On Thu, Jun 23, 2016 at 09:09:44AM -0700, Walter A. Boring IV wrote:
> > >
> > > volumes connected to QEMU instances eventually become directly connected?
> > >
> > > > Our long term goal is that 100% of all network storage will be
> > connected
> >
> ​Oh, didn't know this at all.  Is this something Nova has been working on
> for a while?  I'd love to hear more about the reasoning, the plan etc.  It
> would also be really neat to have an opportunity to participate.

There's no currently open Nova blueprint around this. The last time we
really discussed this in context of a spec was in relation to the request
to add LUKS support over RBD, which would have involved switching away
from using QEMU and back to in-kernel RBD.

Out of this, came work on QEMU over the last 6 months which added native
QEMU support for LUKS in QEMU 2.6. Libvirt is now integrating this and
when that's done we'll look to using it in Nova. That's like Ocata blueprint
material.


> ​This all sounds like it could be a good direction to go in.  I'd love to
> see more info on the plan, how it works, and how to test it out a bit.
> Didn't find a spec, any links, reviews or config info available?

The iSCSI stuff was originally added a several releases back:

commit f987bf1a641ffc8b26c06c920a32b8556c18e845
Author: Akira Yoshiyama 
Date:   Mon Jan 12 12:11:56 2015 +

libvirt: add QEMU built-in iSCSI initiator support

This patch allows nova-compute to use QEMU iSCSI built-in
initiator for Cinder iSCSI volume drivers. It doesn't provide
iSCSI multipath capability, but host OS doesn't have to handle
iSCSI connection for volume because QEMU does it directly with
libiscsi.

To use this, you have to write a parameter at nova.conf:

  volume_drivers = 
iscsi=nova.virt.libvirt.volume.LibvirtNetVolumeDriver,iser=nova.virt.libvirt.volume.LibvirtISERVolumeDriver,...

or just

  volume_drivers = iscsi=nova.virt.libvirt.volume.LibvirtNetVolumeDriver

Note that qemu-system-x86 in Ubuntu has no iSCSI built-in
initiator support because libiscsi isn't in main repository
but universe. I've tested qemu-system-x86 built with libiscsi2
package of Debian on Ubuntu 14.04.

Change-Id: Ieb9a03d308495be4e8c54b5c6c0ff781ea7f0559
Implements: blueprint qemu-built-in-iscsi-initiator



Note that since that time though, I see we've lost ability to enable this,
since we removed the "volume_drivers" config parameter. We ought to re-add
an explicit config param to turn this on, rather than doing it indirectly
via the volume driver class choice.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] nova service-list error

[venkat boggarapu]

HI All,

When i am trying to run the command nova service-list i am getting the
below error


ERROR (BadRequest): Expecting to find domain in project - the server could
not comply with the request since it is either malformed or otherwise
incorrect. The client is assumed to be in error. (HTTP 400) (Request-ID:
req-78bdca0c-6dda-4f4d-a571-eee336cec053)

can someone help regarding this.


With regards
venkat
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Kuryr][Magnum] - Kuryr nested containers and Magnum Integration

[Hongbin Lu]

From: Vikas Choudhary [mailto:choudharyvika...@gmail.com]
Sent: June-22-16 3:58 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Kuryr][Magnum] - Kuryr nested containers and 
Magnum Integration

Hi Eli Qiao,

Please find my responses inline.

On Wed, Jun 22, 2016 at 12:47 PM, taget 
> wrote:
hi Vikas,
thanks for you clarify, relied in lines.
On 2016年06月22日 14:36, Vikas Choudhary wrote:

Magnum:

  1.  Support to pass neutron network names at container creation apis such as 
pod-create in k8s case.
Hmm. Magnum has deleted all wrapper API for container creation and pod-create
Oh, I was referring to older design then. In that case, What would be 
corresponding alternative now?
Is this related to Zun somehow?
[Hongbin Lu] The alternative is native CLI tool (i.e. kubectl, docker). This is 
unrelated to Zun. Zun is a totally independent service, regardless of Magnum 
exists or not.




  1.  If Kuryr is used as network driver at bay creation, update heat template 
creation logic for kuryr-agent provisioning on all the bay nodes. This will 
also include passing required configuration and credentials also.

In this case, I am confused, we need to install kuryr-agent on all bay nodes, 
so and kuryr-agent's for binding neutron ports and containers port, we will 
need to install neutron-agent on bay nodes too?
Neutron-agent will not be required on bay nodes. Only kuryr-agent will be 
sufficient to plumb the vifs and vlan tagging.





--

Best Regards,

Eli Qiao (乔立勇), Intel OTC.

__
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] [neutron] [classifier] Spec detailing both approaches

[Vikram Choudhary]

Hi Igor/Cathy/Louis,

Thanks for driving this effort. Will certainly help with the review!

Thanks
Vikram

On Fri, Jun 24, 2016 at 5:47 PM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Hi Cathy, Louis,
>
>
>
> I'll reupload the Neutron spec today to openstack/neutron-specs along with
> the rst file and the neutron-classifier-inspired approach detailed,
> replacing [1] and [2] from openstack/neutron, is that okay?
>
>
>
> Review from the Neutron community, interested consumers and
> neutron-classifier contributors will be highly appreciated.
>
>
>
> [1] https://review.openstack.org/#/c/332584/
>
> [2] https://review.openstack.org/#/c/332958/
>
>
>
> Best regards,
>
> Igor.
>
>
>
> __
> 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] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

[John Griffith]

On Fri, Jun 24, 2016 at 2:19 AM, Daniel P. Berrange 
wrote:

> On Thu, Jun 23, 2016 at 09:09:44AM -0700, Walter A. Boring IV wrote:
> >
> > volumes connected to QEMU instances eventually become directly connected?
> >
> > > Our long term goal is that 100% of all network storage will be
> connected
>
​Oh, didn't know this at all.  Is this something Nova has been working on
for a while?  I'd love to hear more about the reasoning, the plan etc.  It
would also be really neat to have an opportunity to participate.
​


> > > to directly by QEMU. We already have the ability to partially do this
> with
> > > iSCSI, but it is lacking support for multipath. As & when that gap is
> > > addressed though, we'll stop using the host OS for any iSCSI stuff.
>
​
Any chance anybody has any insight on how to make this work?  I tried
configuring this last week and it appears to be broken in a few places.

> >
> > > So if you're requiring access to host iSCSI volumes, it'll work in the
> > > short-medium term, but in the medium-long term we're not going to use
> > > that so plan accordingly.
> >
> > What is the benefit of this largely monolithic approach?  It seems that
> > moving everything into QEMU is diametrically opposed to the unix model
> > itself and
> > is just a re-implementation of what already exists in the linux world
> > outside of QEMU.
>
> There are many benefits to having it inside QEMU. First it gives us
> improved isolation between VMs, because we can control the network
> I/O directly against the VM using cgroup resource controls.

It gives
> us improved security, particularly in combination with LUKS encryption
> since the unencrypted block device is not directly visible / accessible
> to any other process. It gives us improved reliability / managability
> since we avoid having to spawn the iscsi client tools which have poor
> error reporting and have been frequent sources of instability in our
>
​True, the iscsi tools aren't the greatest.
​


> infrastructure (eg see how we have to blindly re-run the same command
> many times over because it randomly times out). It will give us improved
> I/O performance because of a shorter I/O path to get requests from QEMU
> out to the network.
>
​I'd love to hear more on the design and how it all comes together.
Particularly the performance info.  Like I said, I tried to set it up
against master but seems I'm either missing something in the config or it's
broken.​


>
> NB, this is not just about iSCSI, the same is all true for RBD where
> we've also stopped using in-kernel RBD client and do it all in QEMU.
>
> > Does QEMU support hardware initiators? iSER?


> No, this is only for case where you're doing pure software based
> iSCSI client connections. If we're relying on local hardware that's
> a different story.
>
​I'm confused, so what's the iser driver referenced in the patch commit
message:  https://review.openstack.org/#/c/135854/
​

​So there's a different story for that?
​

>
> >
> > We regularly fix issues with iSCSI attaches in the release cycles of
> > OpenStack,
> > because it's all done in python using existing linux packages.  How often
>
> This is a great example of the benefit that in-QEMU client gives us. The
> Linux iSCSI client tools have proved very unreliable in use by OpenStack.
> This is a reflection of the very architectural approach. We have individual
> resources needed by distinct VMs, but we're having to manage them as a host
> wide resource and that's creating us unneccessary complexity and having a
> poor effect on our reliability overall.
>
> > are QEMU
> > releases done and upgraded on customer deployments vs. python packages
> > (os-brick)?
>
> We're removing the entire layer of instability by removing the need to
> deal with any command line tools, and thus greatly simplifying our
> setup on compute nodes. No matter what we might do in os-brick it'll
> never give us a simple or reliable system - we're just papering over
> the flaws by doing stuff like blindly re-trying iscsi commands upon
> failure.
>
​This all sounds like it could be a good direction to go in.  I'd love to
see more info on the plan, how it works, and how to test it out a bit.
Didn't find a spec, any links, reviews or config info available?

​Wish I would've caught this on ML or IRC or wherever, would've loved to
have participated a bit.​


> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [vitrage][aodh] Notifications about aodh alarm state changes

[Julien Danjou]

On Thu, Jun 23 2016, Afek, Ifat (Nokia - IL) wrote:

> I understood that during Aodh-Vitrage design session in Austin, you had a
> discussion about Vitrage need for notifications about Aodh alarm state 
> changes.
> Did you have a chance to think about it since, and to check how this can be
> done?

IIRC this was already implemented, just not enable by default and
probably not well documented.

Actually I see we took some note here:

  https://etherpad.openstack.org/p/newton-telemetry-vitrage

Feel free to send patches. :)

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


signature.asc
Description: PGP signature
__
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] Networking issues with neutron-linuxbridge-agent

[Eugen Block]

If you are using the Neutron API for security groups, then I think  
you need firewall_driver=nova.virt.firewall.NoopFirewallDriver in  
nova.conf - that's what devstack does.


I think this was really the solution! I tried to provoke the  
interruption in three different ways that broke the connection before,  
but I couldn't! I hope this is it, I'll report if the interruptions  
return, but so far thank you very much!!!



Zitat von Darragh O'Reilly :


On Friday, 24 June 2016, 9:15, Eugen Block  wrote:

Make sure nova is using the noop driver.



I'm trying to use ceilometer, in that case the docs say to use
messagingv2 driver, so that's what I did. And until two weeks ago it
worked just fine, I had no networking issues.




Your iptables output is showing entries from both nova-compute and  
neutron. If you are using the Neutron API for security groups, then  
I think you need  
firewall_driver=nova.virt.firewall.NoopFirewallDriver in nova.conf -  
that's what devstack does.




--
Eugen Block voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg e-mail  : ebl...@nde.ag

Vorsitzende des Aufsichtsrates: Angelika Mozdzen
  Sitz und Registergericht: Hamburg, HRB 90934
  Vorstand: Jens-U. Mozdzen
   USt-IdNr. DE 814 013 983


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] What can make Cinder not find Image? (Was: Create instance fails on creating block device - Block Device Mapping is Invalid)

[Turbo Fredriksson]

On Jun 24, 2016, at 2:04 PM, Cynthia Lopes wrote:

> Sorry, what command precisely did you run when you got those logs? Are you
> trying to boot a vm from a volume is it?

openstack server create --image cirros --flavor m1.tiny --nic 
net-id=2bb7b8e2-188f-4e46-bf4d-ef5ec81ddb4d --wait test


It turned out I missed a part of the Nova-Docker setup - copy
the docker image to Glance.

When fixing that part, I then got other problems (see other mail).

> I find it weird that you are seeing the volume name on the request instead
> of the volume id: GET
> http://10.0.4.1:8776/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/test
> 
> This should be: GET
> http://10.0.4.1:8776/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/8dbd3b7c-e36b-433f-a3b0-d701f63f63c2


That is probably Nova-Docker that works in a special way..
--
Michael Jackson is not going to buried or cremated
but recycled into shopping bags so he can remain white,
plastic and dangerous for kids to play with.


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] What can make Cinder not find Image? (Was: Create instance fails on creating block device - Block Device Mapping is Invalid)

[Cynthia Lopes]

Sorry, what command precisely did you run when you got those logs? Are you
trying to boot a vm from a volume is it?

I find it weird that you are seeing the volume name on the request instead
of the volume id: GET
http://10.0.4.1:8776/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/test

This should be: GET
http://10.0.4.1:8776/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/8dbd3b7c-e36b-433f-a3b0-d701f63f63c2



2016-06-23 23:31 GMT+01:00 Turbo Fredriksson :

> - s n i p -
> 2016-06-23 23:08:25.277 25887 INFO cinder.api.openstack.wsgi
> [req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949
> 2985b96e27f048cd92a18d
> b0dd03aa23 - - -] GET
> http://10.0.4.1:8776/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/test
> 2016-06-23 23:08:25.278 25887 DEBUG cinder.api.openstack.wsgi
> [req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949
> 2985b96e27f048cd92a18
> db0dd03aa23 - - -] Empty body provided in request get_body
> /usr/lib/python2.7/dist-packages/cinder/api/openstack/wsgi.py:936
> 2016-06-23 23:08:25.278 25887 DEBUG cinder.api.openstack.wsgi
> [req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949
> 2985b96e27f048cd92a18
> db0dd03aa23 - - -] Calling method ' >'
> _process_stack /
> usr/lib/python2.7/dist-packages/cinder/api/openstack/wsgi.py:1092
> 2016-06-23 23:08:25.362 25887 INFO cinder.api.openstack.wsgi
> [req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949
> 2985b96e27f048cd92a18db0dd03aa23 - - -] HTTP exception thrown: Volume test
> could not be found.
> 2016-06-23 23:08:25.363 25887 INFO cinder.api.openstack.wsgi
> [req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949
> 2985b96e27f048cd92a18db0dd03aa23 - - -]
> http://10.0.4.1:8776/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/test
> returned with HTTP 404
> 2016-06-23 23:08:25.366 25887 INFO eventlet.wsgi.server
> [req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949
> 2985b96e27f048cd92a18db0dd03aa23 - - -] 10.0.4.1 "GET
> /v2/2985b96e27f048cd92a18db0dd03aa23/volumes/test HTTP/1.1" status: 404
> len: 418 time: 0.8508980
> - s n i p -
>
> and yet:
>
> - s n i p -
> bladeA01b:~# openstack volume list
>
>
> +--+--+---+--+-+
> | ID   | Display Name | Status| Size |
> Attached to |
>
> +--+--+---+--+-+
> | 8dbd3b7c-e36b-433f-a3b0-d701f63f63c2 | test | available |5
> | |
>
> +--+--+---+--+-+
> - s n i p -
>
> That's with the "admin" user+password etc though..
> --
> There are no dumb questions,
> unless a customer is asking them.
> - Unknown
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] How to setup very simple networking? (Was: What can make Cinder not find Image? (Was: Create instance fails on creating block device - Block Device Mapping is Invalid))

[Turbo Fredriksson]

On Jun 23, 2016, at 11:31 PM, Turbo Fredriksson wrote:

> - s n i p -
> 2016-06-23 23:08:25.362 25887 INFO cinder.api.openstack.wsgi 
> [req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949 
> 2985b96e27f048cd92a18db0dd03aa23 - - -] HTTP exception thrown: Volume test 
> could not be found.
> - s n i p -
> 

Oups, that one was mine! I forgot/missed to copy the docker image
to Glance!


As far as i can tell, I'm now "all good". It now "only" (!!! :)
complains about the network :( :(.

- s n i p -
2016-06-24 13:42:25.141 10978 WARNING novadocker.virt.docker.driver 
[req-c98bae39-dbb0-4b36-808d-004684ae3a2c 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] [instance: 
1988a860-13f6-44cf-b40c-5709b815f381] Cannot setup network: Cannot find any PID 
under container 
"708a45db07705d7f4393fc60886ae4e894dccc2ce02ef7eb77dd701abc750752"
2016-06-24 13:42:25.141 10978 ERROR novadocker.virt.docker.driver [instance: 
1988a860-13f6-44cf-b40c-5709b815f381] Traceback (most recent call last):
2016-06-24 13:42:25.141 10978 ERROR novadocker.virt.docker.driver [instance: 
1988a860-13f6-44cf-b40c-5709b815f381]   File 
"/usr/local/lib/python2.7/dist-packages/novadocker/virt/docker/driver.py", line 
490, in _start_container
2016-06-24 13:42:25.141 10978 ERROR novadocker.virt.docker.driver [instance: 
1988a860-13f6-44cf-b40c-5709b815f381] self._attach_vifs(instance, 
network_info)
2016-06-24 13:42:25.141 10978 ERROR novadocker.virt.docker.driver [instance: 
1988a860-13f6-44cf-b40c-5709b815f381]   File 
"/usr/local/lib/python2.7/dist-packages/novadocker/virt/docker/driver.py", line 
241, in _attach_vifs
2016-06-24 13:42:25.141 10978 ERROR novadocker.virt.docker.driver [instance: 
1988a860-13f6-44cf-b40c-5709b815f381] raise 
RuntimeError(msg.format(container_id))
2016-06-24 13:42:25.141 10978 ERROR novadocker.virt.docker.driver [instance: 
1988a860-13f6-44cf-b40c-5709b815f381] RuntimeError: Cannot find any PID under 
container "708a45db07705d7f4393fc60886ae4e894dccc2ce02ef7eb77dd701abc750752"
2016-06-24 13:42:25.141 10978 ERROR novadocker.virt.docker.driver [instance: 
1988a860-13f6-44cf-b40c-5709b815f381]
- s n i p -

I'm not sure what that error exactly mean though.


Provided my network looks like this:

+ [external_ip - internet]
  +- Contego (DHCP, DNS, NTP, Primary Gateway/Firewall)
 + [192.168.4/24]  -+- Old VMs, Static IPs
 + [192.168.5/24]  -+- Old VMs, Dynamic IPs
 + [192.168.63/24] -+- Guest network
 + [192.168.69/24] -+- Physical machines
   +- Celia (Block Storage - 30TB+/ZoL, LDAP, Kerberos 
V, SMB, AFP, AFS, NFS, iSCSI)
   +- Negotia (Current VM host)
 + [10.0.0/16] -+- Blade Center 
   + [10.0.1/24]  -+- Management/iLO network (Blade 
Center 1)
   + [10.0.2/24]  -+- Management/iLO network (Blade 
Center 2)
   + [10.0.3/24]  -+- Blade Center 1 - Blade hosts, eth0
   + [10.0.4/24]  -+- Blade Center 1 - Blade hosts, eth1
   + [10.0.5/24]  -+- Blade Center 2 - Blade hosts, eth0
   + [10.0.6/24]  -+- Blade Center 2 - Blade hosts, eth1
   + [10.9x.0/24] -+- Virtual Machines

My primary (and at the moment only) Control node have the IP
"10.0.4.1/10.99.0.1" and my first (and at the moment only)
Compute have the IP "10.0.4.3".

My plan (?) was to put the OS router on 10.99.0.254 and route it
"down" to the physical hosts eth0 (10.99.0.1) and then on to 
Contego which is my firewall/gateway to the 'Net. I don't expect
any traffic IN that way though..

Then all VMs gets a 10.99.0.x address (if I'm quick, I can actually
see that happening already - but because it fails to start, the IP
is removed from the instance).


My question is, how do I get traffic between 10.99.0.1 and 10.99.0.254??

This is my current network setup. Although, I have no idea what I'm doing,
I just winged it to get SOMETHING..

  
https://github.com/FransUrbo/openstack_bladecenter/blob/master/local_setup_openstack-control.sh#L647-L681

What am I missing?
--
You know, boys, a nuclear reactor is a lot like a woman.
You just have to read the manual and press the right buttons
- Homer Simpson


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [openstack-ansible] Change of default database collation

[Major Hayden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/24/2016 12:07 AM, Jimmy McCrory wrote:
> The question then comes to how to best handle upgrades from Mitaka to Newton.
> Any input for the current proposal[3] from anyone that may have experience 
> with any project's database migration scripts, or MySQL-based databases in 
> general, would be appreciated.

Your proposal looks fine, and from what I read, it seems like the difference 
between utf8_unicode and utf8_general is mainly around sorting Unicode 
characters.  Then again, I'm no collation/unicode expert, so I'll gladly defer 
to anyone with more experience there. ;)

Do we know if a change from utf8_unicode_ci to utf8_general_ci will change data 
in the database?  If it doesn't, I'd imagine that a wholesale conversion to 
utf8_general_ci (as you've proposed in 333733) would be just fine.  There are 
some small performance concerns documented[1], but they don't look huge.

[1] 
http://stackoverflow.com/questions/766809/whats-the-difference-between-utf8-general-ci-and-utf8-unicode-ci

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXbSsXAAoJEHNwUeDBAR+x8KYP/01HJ3P2SqjsiUJuMp3zJPV7
y1elLRFC8KnjOwGShRxLYheASTHgszPFhV0SBdynBgVRtpFo3uB7Az1Yzt9hU4lL
dRNhvDChZuSDlMw+6K1w/bzS0p244984t/RIHTd8aqtd10nLE3IeCOMOlvE9FkHO
10r6NoN3NTLkxGmksqyDCTDEXzPBQZ2VYwsAeAKHSAVRGYba4kitYEqs002GvAx7
2GeZrjSb7ZVpAjF1cF4KBTyB0CPaPS1wXzk7yeHQouK8LgbhBKqPGSzBiQkhYRdN
7WohOJTOIqc8T9IgXufUGJbYhQ5CWfHcaESv3a9CHqWCHQsaAx9E0PrMRVAo4Jb1
3DRis03GCw3/+jts3WJR0t21slO5wW/u69BuvSuZ4FjYvJMOprLkufFHXr+j873D
SXwzXFem4ZaxENGtwe2R+bTDchLb2kf9JCgs9RMSnLRX0GmiAaG4XP7SC0Pl10nX
IiWOK5PcL3phlCQRIFn/djTFi8zo7+I1nGXxprNILtBspqzGaZK2NeId0DEQSZpI
+Ycn0YbjNA82ZW6hPwLljWwX5E9Q41Mc5bpwST14oKN9uHRkABMh/YSMg0apRnlI
8nTP1JSHLNsBIu34Ns9zcbvoQF9UsWoX6uIcJSHCbop9kb0ZvWz+UB/Biobm6JY0
wd1HIBAPXpRgsETr4OuL
=63dN
-END PGP SIGNATURE-

__
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] Networking issues with neutron-linuxbridge-agent

[Darragh O'Reilly]

On Friday, 24 June 2016, 9:15, Eugen Block  wrote:
>> Make sure nova is using the noop driver.

> I'm trying to use ceilometer, in that case the docs say to use  
> messagingv2 driver, so that's what I did. And until two weeks ago it  
> worked just fine, I had no networking issues.



Your iptables output is showing entries from both nova-compute and neutron. If 
you are using the Neutron API for security groups, then I think you need 
firewall_driver=nova.virt.firewall.NoopFirewallDriver in nova.conf - that's 
what devstack does.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [grenade] upgrades vs rootwrap

[Angus Lees]

On Fri, 24 Jun 2016 at 21:04 Sean Dague  wrote:

> On 06/24/2016 05:19 AM, Daniel P. Berrange wrote:
> > On Fri, Jun 24, 2016 at 11:12:27AM +0200, Thierry Carrez wrote:
> >> No perfect answer here... I'm hesitating between (0), (1) and (4). (4)
> is
> >> IMHO the right solution, but it's a larger change for downstream. (1)
> is a
> >> bit of a hack, where we basically hardcode in rootwrap that it's being
> >> transitioned to privsep. That's fine, but only if we get rid of rootwrap
> >> soon. So only if we have a plan for (4) anyway. Option (0) is a bit of a
> >> hard sell for upgrade procedures -- if we need to take a hit in that
> area,
> >> let's do (4) directly...
> >>
> >> In summary, I think the choice is between (1)+(4) and doing (4)
> directly.
> >> How doable is (4) in the timeframe we have ? Do we all agree that (4)
> is the
> >> endgame ?
> >
> > We've already merged change to privsep to allow nova/cinder/etc to
> > initialize the default helper command to use rootwrap:
> >
> >
> https://github.com/openstack/oslo.privsep/commit/9bf606327d156de52c9418d5784cd7f29e243487
> >
> > So we just need new release of privsep & add code to nova to initialize
> > it and we're sorted.
>
> Actually, I don't think so. Matt ran that test scenario, and we're
> missing the rootwrap rule that lets privsep-helper run as root. So we
> fail to start the daemon from the unpriv nova compute process post upgrade.
>

Right, I thought that recent privsep change would address this, but we're
having this conversation because it turns out that simply updating code
only is not sufficient.  I (and I presume all the other members of the
earlier review/email discussion) had just assumed that we already had a
sensible process for making orderly changes to rootwrap files.

As I've since learned however, the current openstack upgrade process
doesn't talk about updating the rootwrap files, ever.  The only reason
we've been able to make reasonable progress since this was instituted is
either through the grenade exception mechanism, or by slipping things
through in drivers that are not tested by grenade.  Hence me opening this
fun can of worms for broader discussion in this thread.  You're welcome :-)

 - Gus
__
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] Spec detailing both approaches

[Duarte Cardoso, Igor]

Hi Cathy, Louis,

I'll reupload the Neutron spec today to openstack/neutron-specs along with the 
rst file and the neutron-classifier-inspired approach detailed, replacing [1] 
and [2] from openstack/neutron, is that okay?

Review from the Neutron community, interested consumers and neutron-classifier 
contributors will be highly appreciated.

[1] https://review.openstack.org/#/c/332584/
[2] https://review.openstack.org/#/c/332958/

Best regards,
Igor.

__
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] [mistal] Mistral logo ideas?

[ala.rezmerita]

De : REZMERITA Ala OBS/OCB
Envoyé : vendredi 24 juin 2016 14:07
À : OpenStack Development Mailing List (not for usage questions)
Objet : RE:[openstack-dev] [mistal] Mistral logo ideas?

Hi folks,

maybe something based on compass rose?



De : Ilya Kutukov [ikutu...@mirantis.com]
Envoyé : vendredi 24 juin 2016 13:25
À : OpenStack Development Mailing List (not for usage questions)
Objet : Re: [openstack-dev] [mistal] Mistral logo ideas?

Maybe smth like this
[Inline image 1]

On Fri, Jun 24, 2016 at 2:18 PM, Ilya Kutukov 
> wrote:
Here is top-down projection 
https://www.the-blueprints.com/blueprints-depot/ships/ships-france/nmf-mistral-l9013.png

On Fri, Jun 24, 2016 at 2:17 PM, Ilya Kutukov 
> wrote:
Look, Mistral landing markup (white stripes and circles with numbers) looks 
like tasks queue:
https://patriceayme.files.wordpress.com/2014/05/mistral.jpg

On Fri, Jun 24, 2016 at 12:55 PM, Hardik 
> 
wrote:
+1 :)


On Friday 24 June 2016 03:08 PM, Nikolay Makhotkin wrote:
I like the idea of the logo being a stylized wind turbine. Perhaps it could be
a turbine with a gust of wind. Then we can show that Mistral harnesses the
power of the wind :-)

I like this idea! Combine Mistral functionality symbol with wind :)

--
Best Regards,
Nikolay



__
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





_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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] [stable][all] Tagging kilo-eol for "the world"

[Joshua Hesketh]

Hi all,

I have completed removing stable/kilo branches from the projects listed
[0]*. There are now 'kilo-eol' tags in place at the sha's where the
branches were.

*There are a couple of exceptions. oslo-incubator was listed but is an
unmaintained project so no further action was required. Tony and I have
also decided to hold off
on openstack-dev/devstack, openstack-dev/grenade, openstack-dev/pbr
and openstack/requirements until we are confident removing the stable/kilo
branch will have no negative effects on the projects who opt-ed out of
being EOL'd.

In this process we noted a couple of repositories still have branches from
Juno and even earlier. I haven't put together a comprehensive list of old
branches, but rather if your project has an outdated branch that you would
like removed and/or tagged as end-of-life, please let me know.

For those interested in the script I used or other infra cores looking to
perform this next time, it is up for review in the release-tools repo:
https://review.openstack.org/333875

Cheers,
Josh

[0] https://gist.github.com/tbreeds/7de812a5d363fab4bd425beae5084c87


On Sat, Jun 11, 2016 at 12:41 AM, Boden Russell  wrote:

> On 6/2/16 4:31 AM, Tony Breeds wrote:
> > Any projects that will be EOL'd will need all open reviews abandoned
> before it
> > can be processed.
>
> openstack/vmware-nsx kilo patches have been abandoned in preparation for
> the EOL.
>
> 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
>
__
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] [Puppet] Suggestions for Dynamic enabling of SRIOV nic agent

[Clayton O'Neill]

I would probably create a custom fact to identify which ones have
sriov capable NICs and use that to selectively enable installation of
the correct packages, setup aggregates, etc.

On Fri, Jun 24, 2016 at 7:19 AM, Sanjay Upadhyay  wrote:
> Hello Folks,
>
> Wondering what is the best approach to dynamically generating info of SRIOV
> capable hosts in a cluster?
>
> The problem is, user want to deploy sriov-nic-agent on compute nodes, with
> mixed set of h/w configuration, ie set of compute nodes which do not have
> SR-IOV nics and a set of nodes which have SR-IOV capable nics.
>
> From the perspective of nova, nova can spawn hosts requiring sr-iov via host
> aggregation or flavors (scheduler_default_filters =
> RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter
> )
>
> However, from puppet side, we should enable sriov nic agent only on the
> nodes with sr-iov nics. What is the best approach to address this?
>
> regards
> /sanjay
>
> __
> 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] [mistal] Mistral logo ideas?

[Ilya Kutukov]

Maybe smth like this
[image: Inline image 1]

On Fri, Jun 24, 2016 at 2:18 PM, Ilya Kutukov  wrote:

> Here is top-down projection
> https://www.the-blueprints.com/blueprints-depot/ships/ships-france/nmf-mistral-l9013.png
>
> On Fri, Jun 24, 2016 at 2:17 PM, Ilya Kutukov 
> wrote:
>
>> Look, Mistral landing markup (white stripes and circles with numbers)
>> looks like tasks queue:
>> https://patriceayme.files.wordpress.com/2014/05/mistral.jpg
>>
>> On Fri, Jun 24, 2016 at 12:55 PM, Hardik <
>> hardik.par...@nectechnologies.in> wrote:
>>
>>> +1 :)
>>>
>>>
>>> On Friday 24 June 2016 03:08 PM, Nikolay Makhotkin wrote:
>>>
>>> I like the idea of the logo being a stylized wind turbine. Perhaps it
 could be
 a turbine with a gust of wind. Then we can show that Mistral harnesses
 the
 power of the wind :-)
>>>
>>>
>>> I like this idea! Combine Mistral functionality symbol with wind :)
>>>
>>> --
>>> Best Regards,
>>> Nikolay
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [Fuel] Merge IRC channels

[Anastasia Urlapova]

Vova,
please don't forget merge #fuel-qa into a #fuel

On Fri, Jun 24, 2016 at 1:55 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Nice. #fuel-infra is to merged as well.
>
> Vladimir Kozhukalov
>
> On Fri, Jun 24, 2016 at 1:50 PM, Aleksandra Fedorova <
> afedor...@mirantis.com> wrote:
>
>> And +1 for #fuel-infra
>>
>> As of now it will be more useful if infra issues related to project will
>> be visible for project developers. We don't have much infra-related traffic
>> on IRC for now, and we will be able to split again if we got it.
>>
>> On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> Dear colleagues,
>>>
>>> We have a few IRC channels but the level of activity there is quite low.
>>>
>>> #fuel
>>> #fuel-dev
>>> #fuel-python
>>> #fuel-infra
>>>
>>> My suggestion is to merge all these channels into a single IRC channel
>>> #fuel.
>>> Other #fuel-* channels are to be deprecated.
>>>
>>> What do you think of this?
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Aleksandra Fedorova
>> Fuel CI Engineer
>> bookwar
>>
>> __
>> 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 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] [mistal] Mistral logo ideas?

[Ilya Kutukov]

Here is top-down projection
https://www.the-blueprints.com/blueprints-depot/ships/ships-france/nmf-mistral-l9013.png

On Fri, Jun 24, 2016 at 2:17 PM, Ilya Kutukov  wrote:

> Look, Mistral landing markup (white stripes and circles with numbers)
> looks like tasks queue:
> https://patriceayme.files.wordpress.com/2014/05/mistral.jpg
>
> On Fri, Jun 24, 2016 at 12:55 PM, Hardik  > wrote:
>
>> +1 :)
>>
>>
>> On Friday 24 June 2016 03:08 PM, Nikolay Makhotkin wrote:
>>
>> I like the idea of the logo being a stylized wind turbine. Perhaps it
>>> could be
>>> a turbine with a gust of wind. Then we can show that Mistral harnesses
>>> the
>>> power of the wind :-)
>>
>>
>> I like this idea! Combine Mistral functionality symbol with wind :)
>>
>> --
>> Best Regards,
>> Nikolay
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [Puppet] Suggestions for Dynamic enabling of SRIOV nic agent

[Sanjay Upadhyay]

Hello Folks,

Wondering what is the best approach to dynamically generating info of SRIOV
capable hosts in a cluster?

The problem is, user want to deploy sriov-nic-agent on compute nodes, with
mixed set of h/w configuration, ie set of compute nodes which do not have
SR-IOV nics and a set of nodes which have SR-IOV capable nics.

>From the perspective of nova, nova can spawn hosts requiring sr-iov via
host aggregation or flavors (scheduler_default_filters =
RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter
)

However, from puppet side, we should enable sriov nic agent only on the
nodes with sr-iov nics. What is the best approach to address this?

regards
/sanjay
__
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] [mistal] Mistral logo ideas?

[Ilya Kutukov]

Look, Mistral landing markup (white stripes and circles with numbers) looks
like tasks queue:
https://patriceayme.files.wordpress.com/2014/05/mistral.jpg

On Fri, Jun 24, 2016 at 12:55 PM, Hardik 
wrote:

> +1 :)
>
>
> On Friday 24 June 2016 03:08 PM, Nikolay Makhotkin wrote:
>
> I like the idea of the logo being a stylized wind turbine. Perhaps it
>> could be
>> a turbine with a gust of wind. Then we can show that Mistral harnesses
>> the
>> power of the wind :-)
>
>
> I like this idea! Combine Mistral functionality symbol with wind :)
>
> --
> Best Regards,
> Nikolay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Create instance fails on creating block device - Block Device Mapping is Invalid

[Yngvi Páll Þorfinnsson]

Can anyone advise on or provide a documentation for Octavia installation ?

Rgds
Yngvi


-Original Message-
From: Yngvi Páll Þorfinnsson 
Sent: 23. júní 2016 15:42
To: Turbo Fredriksson ; openstack@lists.openstack.org
Subject: Re: [Openstack] Create instance fails on creating block device - Block 
Device Mapping is Invalid

I think it's possible we're far away from the correct path ;-) It's not 
mentioned at all in the openstack lbaas V2 documentation, but I think it's 
necessary to install Octavia on the controller machine first.
Then configure neutron on all compute nodes to support lbaas ...
Someone please correct me, if I'm wrong on this

Cheers
Yngvi

-Original Message-
From: Turbo Fredriksson [mailto:tu...@bayour.com]
Sent: 23. júní 2016 13:36
To: openstack@lists.openstack.org
Subject: Re: [Openstack] Create instance fails on creating block device - Block 
Device Mapping is Invalid

On Jun 23, 2016, at 2:10 PM, Turbo Fredriksson wrote:

> But even after disabling them, they're still show as 
> "status=disabled,state=up"
> with a "cinder service-list".. ?

I tried anyway, but creating a volume (empty or from an image) gave the host 
field as empty. And the status was Error!

So apparently I need to figure out a way to configure "local storage".


The LVM volume shows:

- s n i p -
bladeA01b:~# openstack volume show test | grep host
| os-vol-host-attr:host | bladeA01b@lvm#LVM_iSCSI |
- s n i p -
--
Build a man a fire, and he will be warm for the night.
Set a man on fire and he will be warm for the rest of his life.


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [grenade] upgrades vs rootwrap

[Sean Dague]

On 06/24/2016 05:19 AM, Daniel P. Berrange wrote:
> On Fri, Jun 24, 2016 at 11:12:27AM +0200, Thierry Carrez wrote:
>> No perfect answer here... I'm hesitating between (0), (1) and (4). (4) is
>> IMHO the right solution, but it's a larger change for downstream. (1) is a
>> bit of a hack, where we basically hardcode in rootwrap that it's being
>> transitioned to privsep. That's fine, but only if we get rid of rootwrap
>> soon. So only if we have a plan for (4) anyway. Option (0) is a bit of a
>> hard sell for upgrade procedures -- if we need to take a hit in that area,
>> let's do (4) directly...
>>
>> In summary, I think the choice is between (1)+(4) and doing (4) directly.
>> How doable is (4) in the timeframe we have ? Do we all agree that (4) is the
>> endgame ?
> 
> We've already merged change to privsep to allow nova/cinder/etc to
> initialize the default helper command to use rootwrap:
> 
>   
> https://github.com/openstack/oslo.privsep/commit/9bf606327d156de52c9418d5784cd7f29e243487
> 
> So we just need new release of privsep & add code to nova to initialize
> it and we're sorted.

Actually, I don't think so. Matt ran that test scenario, and we're
missing the rootwrap rule that lets privsep-helper run as root. So we
fail to start the daemon from the unpriv nova compute process post upgrade.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [Fuel] Merge IRC channels

[Vladimir Kozhukalov]

Nice. #fuel-infra is to merged as well.

Vladimir Kozhukalov

On Fri, Jun 24, 2016 at 1:50 PM, Aleksandra Fedorova  wrote:

> And +1 for #fuel-infra
>
> As of now it will be more useful if infra issues related to project will
> be visible for project developers. We don't have much infra-related traffic
> on IRC for now, and we will be able to split again if we got it.
>
> On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> We have a few IRC channels but the level of activity there is quite low.
>>
>> #fuel
>> #fuel-dev
>> #fuel-python
>> #fuel-infra
>>
>> My suggestion is to merge all these channels into a single IRC channel
>> #fuel.
>> Other #fuel-* channels are to be deprecated.
>>
>> What do you think of this?
>>
>>
>> Vladimir Kozhukalov
>>
>> __
>> 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
>>
>>
>
>
> --
> Aleksandra Fedorova
> Fuel CI Engineer
> bookwar
>
> __
> 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] [Fuel] Merge IRC channels

[Vladimir Kozhukalov]

Ok, let's then start from merger of

#fuel-dev
#fuel-python
#fuel-ui
#fuel-library

into a single channel #fuel. #fuel-infra is to stay separate for a while.

Vladimir Kozhukalov

On Fri, Jun 24, 2016 at 1:41 PM, Andrew Maksimov 
wrote:

> +1 for merging #fuel #fuel-dev #fuel-python and #fuel-library to #fuel.
>
> Not sure about #fuel-infra though, one of the purposes of #fuel-infra -
> support requests to infra team, I think #fuel channel will be too noisy if
> we redirect all support requests to it.
>
> Regards,
> Andrey
>
>
> On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> We have a few IRC channels but the level of activity there is quite low.
>>
>> #fuel
>> #fuel-dev
>> #fuel-python
>> #fuel-infra
>>
>> My suggestion is to merge all these channels into a single IRC channel
>> #fuel.
>> Other #fuel-* channels are to be deprecated.
>>
>> What do you think of this?
>>
>>
>> Vladimir Kozhukalov
>>
>> __
>> 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 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] [Fuel] Merge IRC channels

[Aleksandra Fedorova]

And +1 for #fuel-infra

As of now it will be more useful if infra issues related to project will be
visible for project developers. We don't have much infra-related traffic on
IRC for now, and we will be able to split again if we got it.

On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> We have a few IRC channels but the level of activity there is quite low.
>
> #fuel
> #fuel-dev
> #fuel-python
> #fuel-infra
>
> My suggestion is to merge all these channels into a single IRC channel
> #fuel.
> Other #fuel-* channels are to be deprecated.
>
> What do you think of this?
>
>
> Vladimir Kozhukalov
>
> __
> 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
>
>


-- 
Aleksandra Fedorova
Fuel CI Engineer
bookwar
__
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] [grenade] upgrades vs rootwrap

[Sean Dague]

On 06/24/2016 05:12 AM, Thierry Carrez wrote:
> Angus Lees wrote:
>> [...]
>> None of these are great, but:
>>
>> Possibility 1:  Backdoor rootwrap
>>
>> However if we assume rootwrap already exists then we _could_ rollout a
>> new version of oslo.rootwrap that contains a backdoor that allows
>> privsep-helper to be run as root for any context, without the need to
>> install a new rootwrap filter.
>>
>> Disclaimers:
>>
>> - It wouldn't work for virtualenvs, because the "privsep-helper"
>> executable won't be in sudo's usual PATH.
>>
>> - Retro-fitting something like that to rootwrap feels like it's skirting
>> close to some sort of ethical contract we've made with admins regarding
>> rootwrap's featureset.  Not saying we shouldn't do it, just that we
>> should think about how an operator is going to feel about that.
>>
>>
>> Possibility 2: Wider rootwrap filter
>>
>> In the past, I've been proposing rootwrap filters that match only
>> specific privsep "privileged contexts" by name.  On further reflection,
>> if we're assuming the existing python modules installed into root's
>> python path are already trustworthy (and we _are_ assuming that), then
>> it might also be reasonable to trust *any* privsep entrypoint declared
>> within that module path.  This gives a larger attack surface to think
>> about (particularly if python libraries including privsep decorators
>> were installed for some reason other than providing privsep entry
>> points), but there's no reason why this is _necessarily_ an issue.
>>
>> This allows us to get to a single rootwrap filter per-project (or
>> rather, "per-rootwrap") since projects use separate rootwrap config
>> directories - so we would still have to do a thing once per project.
>>
>>
>> Possibility 3: Skip rootwrap, use just sudo
>>
>> sudoers isn't very expressive - but we could install a new rootwrap-like
>> wrapper into sudoers once system-wide, which includes some sort of logic
>> to start privsep-helpers.  This could be as simple as a small shell
>> script.  The advantage this has over rootwrap is that it would contain
>> some sort of system-wide config, rather than per-project.
>>
>> Downsides
>>
>> - Would still need to be installed once system-wide.
>>
>> - Would need to be configured per-virtualenv, since otherwise we have no
>> way to know which virtualenvs should be given root powers.
>>
>>
>> Possibility 4: Run as root initially
>>
>> Another option would be to follow the usual Unix daemon model: Start the
>> process with all required privileges, and avoid sudo/rootwrap entirely.
>>
>> In this version, we take a once-off hit to tell everyone to start
>> running their OpenStack agents as root (probably from init/systemd), and
>> right at the top of main() we fork() the privsep-helper and then drop to
>> a regular uid.  No sudo or rootwrap ever (although the unprivileged code
>> could continue to use it while we clean up all the legacy code).
>>
>> A glorious future, but still a big per-project deployment change that
>> has to be managed somehow.
> 
> I'm adding Possibility (0): change Grenade so that rootwrap filters from
> N+1 are put in place before you upgrade.

If you do that as general course what you are saying is that every
installer and install process includes overwriting all of rootwrap
before every upgrade. Keep in mind we do upstream upgrade as offline,
which means that we've fully shut down the cloud. This would remove the
testing requirement that rootwrap configs were even compatible between N
and N+1. And you think this is theoretical, you should see the patches
I've gotten over the years to grenade because people didn't see an issue
with that at all. :)

I do get that people don't like the constraints we've self imposed, but
we've done that for very good reasons. The #1 complaint from operators,
for ever, has been the pain and danger of upgrading. That's why we are
still trademarking new Juno clouds. When you upgrade Apache, you don't
have to change your config files.

As an asside, one of our major inhibitors to smooth upgrade are these
giant conf trees which exist for users to modify in /etc, but not in a
really clear override way: policy, paste, rootwrap. Policy is being
solved right now by moving defaults to code (in Nova, but all the
infrastructure is in oslo.policy, and should be a quick transition for
other projects once we've proved it out) and keeping etc as only
overrides. Morgan and I talked about the same kind of approach with
paste, he's going to sniff that one out. Once we get to privsep, I think
we have it solved for rootwrap. But that transition is hard. Because the
existing system was designed without thinking about the upgrade
implications.

> No perfect answer here... I'm hesitating between (0), (1) and (4). (4)
> is IMHO the right solution, but it's a larger change for downstream. (1)
> is a bit of a hack, where we basically hardcode in rootwrap that it's
> being transitioned to privsep. That's fine, but only if we get rid of
> 

Re: [openstack-dev] [Fuel] Merge IRC channels

[Vitaly Kramskikh]

+1 for this, #fuel-ui should also be merged there I think.

2016-06-24 13:26 GMT+03:00 Vladimir Kozhukalov :

> Dear colleagues,
>
> We have a few IRC channels but the level of activity there is quite low.
>
> #fuel
> #fuel-dev
> #fuel-python
> #fuel-infra
>
> My suggestion is to merge all these channels into a single IRC channel
> #fuel.
> Other #fuel-* channels are to be deprecated.
>
> What do you think of this?
>
>
> Vladimir Kozhukalov
>
> __
> 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
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] [Fuel] Merge IRC channels

[Andrew Maksimov]

+1 for merging #fuel #fuel-dev #fuel-python and #fuel-library to #fuel.

Not sure about #fuel-infra though, one of the purposes of #fuel-infra -
support requests to infra team, I think #fuel channel will be too noisy if
we redirect all support requests to it.

Regards,
Andrey


On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> We have a few IRC channels but the level of activity there is quite low.
>
> #fuel
> #fuel-dev
> #fuel-python
> #fuel-infra
>
> My suggestion is to merge all these channels into a single IRC channel
> #fuel.
> Other #fuel-* channels are to be deprecated.
>
> What do you think of this?
>
>
> Vladimir Kozhukalov
>
> __
> 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] [Fuel] Merge IRC channels

[Vladimir Kozhukalov]

Dear colleagues,

We have a few IRC channels but the level of activity there is quite low.

#fuel
#fuel-dev
#fuel-python
#fuel-infra

My suggestion is to merge all these channels into a single IRC channel
#fuel.
Other #fuel-* channels are to be deprecated.

What do you think of this?


Vladimir Kozhukalov
__
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][pci-passthrough] definitely specify VFIO driver as the host PCI driver for passthrough

[Chen Fan]

On 2016年06月24日 16:55, Daniel P. Berrange wrote:

On Fri, Jun 24, 2016 at 04:52:31PM +0800, Chen Fan wrote:


On 2016年06月24日 16:20, Daniel P. Berrange wrote:

On Fri, Jun 24, 2016 at 12:27:57PM +0800, Chen Fan wrote:

hi all,
   in openstack, we can use the pci passthrough feature now, refer to
   https://wiki.openstack.org/wiki/Pci_passthrough
   but we can't definitely specify the host pci driver is LEGACY_KVM or
newer VFIO,
   new VFIO driver is more safer, and higher-performance user-space driver
   than legacy kvm driver (pci-stub), the benefit relative to kvm
assignment driver
   could refer to http://lwn.net/Articles/474088/.
   In additional, VFIO driver provides the GPU passthrough as primary card
support.
   I think it is more useful for further GPU passthrough support in
openstack.

   Openstack relies on the libvirt nodedev device configuration to do pci
passthrough,
   with managed mode, the configured device is automatically detached and
re-attached
   with KVM or VFIO driver that depended on the host driver modules
configuration,
   so now we can't specify the driver in openstack to VFIO mode, I think
we should need
   to add this feature support in openstack to get pci passhthrough more
scalability.

   a simply idea is to add a option in nova.conf HOST_PCI_MODEL = VFIO
/KVM to specify
   the pci passthrough device driver is using VFIO driver.
   any comments are welcome. :)

I don't see any reason to add a configuration option. If the host is
capable of doing VFIO, libvirt will always aim to use VFIO in preference
to the legacy system.

Hi Daniel,

 sorry, I directly reference the implementation of nodedev in libvirt, in
function
virHostdevPreparePCIDevices :
  257 if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)
  258 virPCIDeviceSetStubDriver(pci, VIR_PCI_STUB_DRIVER_VFIO);
  259 else if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN)
  260 virPCIDeviceSetStubDriver(pci, VIR_PCI_STUB_DRIVER_XEN);
  261 else
  262 virPCIDeviceSetStubDriver(pci, VIR_PCI_STUB_DRIVER_KVM);

IIUC, the stub driver should be "legacy KVM", do we need to change the stub
drvier
to VIR_PCI_STUB_DRIVER_VFIO by default.

If libvirt uses VFIO, then it'll use the VFIO stub driver, which is fine.

Thanks for you kind explanation, I have reread //the code about the
implementation of pci driver backend in libvirt, you are right, by default
the backend driver is VFIO.

Thanks,
Chen





Regards,
Daniel


--
Sincerely,
Chen Fan

__
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] Status of the OpenStack port to Python 3

[Amrith Kumar]

> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: Thursday, June 23, 2016 5:16 PM
> To: openstack-dev 
> Subject: Re: [openstack-dev] [all] Status of the OpenStack port to Python 3
> 
[... snip ...]
> 
> Let's see what PTLs have to say about planning, but I think if not
> Ocata then we'd want to set one for the P release. We're running
> out of supported lifetime for Python 2.7.
> 
> Doug
> 

Doug, I believe py27 will be supported till end of 2020 but distribution 
vendors (os people) are not yet deploying py3 as the default.

Could someone share the best information on when we may see Python3 be the 
default from the various os distribution providers. The date of 2020 for EOS 
leads me to believe that we're good until about the U or V release (assuming 
two per year) but I don't believe that's the correct way to plan for this, yes?

-amrith


__
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] [mistal] Mistral logo ideas?

[Hardik]

+1 :)

On Friday 24 June 2016 03:08 PM, Nikolay Makhotkin wrote:


I like the idea of the logo being a stylized wind turbine. Perhaps
it could be
a turbine with a gust of wind. Then we can show that Mistral
harnesses the
power of the wind :-)


I like this idea! Combine Mistral functionality symbol with wind :)

--
Best Regards,
Nikolay


__
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] [mistal] Mistral logo ideas?

[Nikolay Makhotkin]

>
> I like the idea of the logo being a stylized wind turbine. Perhaps it
> could be
> a turbine with a gust of wind. Then we can show that Mistral harnesses the
> power of the wind :-)


I like this idea! Combine Mistral functionality symbol with wind :)

-- 
Best Regards,
Nikolay
__
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] [grenade] upgrades vs rootwrap

[Daniel P. Berrange]

On Fri, Jun 24, 2016 at 11:12:27AM +0200, Thierry Carrez wrote:
> Angus Lees wrote:
> > [...]
> > None of these are great, but:
> > 
> > Possibility 1:  Backdoor rootwrap
> > 
> > However if we assume rootwrap already exists then we _could_ rollout a
> > new version of oslo.rootwrap that contains a backdoor that allows
> > privsep-helper to be run as root for any context, without the need to
> > install a new rootwrap filter.
> > 
> > Disclaimers:
> > 
> > - It wouldn't work for virtualenvs, because the "privsep-helper"
> > executable won't be in sudo's usual PATH.
> > 
> > - Retro-fitting something like that to rootwrap feels like it's skirting
> > close to some sort of ethical contract we've made with admins regarding
> > rootwrap's featureset.  Not saying we shouldn't do it, just that we
> > should think about how an operator is going to feel about that.
> > 
> > 
> > Possibility 2: Wider rootwrap filter
> > 
> > In the past, I've been proposing rootwrap filters that match only
> > specific privsep "privileged contexts" by name.  On further reflection,
> > if we're assuming the existing python modules installed into root's
> > python path are already trustworthy (and we _are_ assuming that), then
> > it might also be reasonable to trust *any* privsep entrypoint declared
> > within that module path.  This gives a larger attack surface to think
> > about (particularly if python libraries including privsep decorators
> > were installed for some reason other than providing privsep entry
> > points), but there's no reason why this is _necessarily_ an issue.
> > 
> > This allows us to get to a single rootwrap filter per-project (or
> > rather, "per-rootwrap") since projects use separate rootwrap config
> > directories - so we would still have to do a thing once per project.
> > 
> > 
> > Possibility 3: Skip rootwrap, use just sudo
> > 
> > sudoers isn't very expressive - but we could install a new rootwrap-like
> > wrapper into sudoers once system-wide, which includes some sort of logic
> > to start privsep-helpers.  This could be as simple as a small shell
> > script.  The advantage this has over rootwrap is that it would contain
> > some sort of system-wide config, rather than per-project.
> > 
> > Downsides
> > 
> > - Would still need to be installed once system-wide.
> > 
> > - Would need to be configured per-virtualenv, since otherwise we have no
> > way to know which virtualenvs should be given root powers.
> > 
> > 
> > Possibility 4: Run as root initially
> > 
> > Another option would be to follow the usual Unix daemon model: Start the
> > process with all required privileges, and avoid sudo/rootwrap entirely.
> > 
> > In this version, we take a once-off hit to tell everyone to start
> > running their OpenStack agents as root (probably from init/systemd), and
> > right at the top of main() we fork() the privsep-helper and then drop to
> > a regular uid.  No sudo or rootwrap ever (although the unprivileged code
> > could continue to use it while we clean up all the legacy code).
> > 
> > A glorious future, but still a big per-project deployment change that
> > has to be managed somehow.
> 
> I'm adding Possibility (0): change Grenade so that rootwrap filters from N+1
> are put in place before you upgrade.
> 
> No perfect answer here... I'm hesitating between (0), (1) and (4). (4) is
> IMHO the right solution, but it's a larger change for downstream. (1) is a
> bit of a hack, where we basically hardcode in rootwrap that it's being
> transitioned to privsep. That's fine, but only if we get rid of rootwrap
> soon. So only if we have a plan for (4) anyway. Option (0) is a bit of a
> hard sell for upgrade procedures -- if we need to take a hit in that area,
> let's do (4) directly...
> 
> In summary, I think the choice is between (1)+(4) and doing (4) directly.
> How doable is (4) in the timeframe we have ? Do we all agree that (4) is the
> endgame ?

We've already merged change to privsep to allow nova/cinder/etc to
initialize the default helper command to use rootwrap:

  
https://github.com/openstack/oslo.privsep/commit/9bf606327d156de52c9418d5784cd7f29e243487

So we just need new release of privsep & add code to nova to initialize
it and we're sorted.

We can also revert the changes we made to devstack to update nova.conf
for privsep too.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [grenade] upgrades vs rootwrap

[Thierry Carrez]

Angus Lees wrote:

[...]
None of these are great, but:

Possibility 1:  Backdoor rootwrap

However if we assume rootwrap already exists then we _could_ rollout a
new version of oslo.rootwrap that contains a backdoor that allows
privsep-helper to be run as root for any context, without the need to
install a new rootwrap filter.

Disclaimers:

- It wouldn't work for virtualenvs, because the "privsep-helper"
executable won't be in sudo's usual PATH.

- Retro-fitting something like that to rootwrap feels like it's skirting
close to some sort of ethical contract we've made with admins regarding
rootwrap's featureset.  Not saying we shouldn't do it, just that we
should think about how an operator is going to feel about that.


Possibility 2: Wider rootwrap filter

In the past, I've been proposing rootwrap filters that match only
specific privsep "privileged contexts" by name.  On further reflection,
if we're assuming the existing python modules installed into root's
python path are already trustworthy (and we _are_ assuming that), then
it might also be reasonable to trust *any* privsep entrypoint declared
within that module path.  This gives a larger attack surface to think
about (particularly if python libraries including privsep decorators
were installed for some reason other than providing privsep entry
points), but there's no reason why this is _necessarily_ an issue.

This allows us to get to a single rootwrap filter per-project (or
rather, "per-rootwrap") since projects use separate rootwrap config
directories - so we would still have to do a thing once per project.


Possibility 3: Skip rootwrap, use just sudo

sudoers isn't very expressive - but we could install a new rootwrap-like
wrapper into sudoers once system-wide, which includes some sort of logic
to start privsep-helpers.  This could be as simple as a small shell
script.  The advantage this has over rootwrap is that it would contain
some sort of system-wide config, rather than per-project.

Downsides

- Would still need to be installed once system-wide.

- Would need to be configured per-virtualenv, since otherwise we have no
way to know which virtualenvs should be given root powers.


Possibility 4: Run as root initially

Another option would be to follow the usual Unix daemon model: Start the
process with all required privileges, and avoid sudo/rootwrap entirely.

In this version, we take a once-off hit to tell everyone to start
running their OpenStack agents as root (probably from init/systemd), and
right at the top of main() we fork() the privsep-helper and then drop to
a regular uid.  No sudo or rootwrap ever (although the unprivileged code
could continue to use it while we clean up all the legacy code).

A glorious future, but still a big per-project deployment change that
has to be managed somehow.


I'm adding Possibility (0): change Grenade so that rootwrap filters from 
N+1 are put in place before you upgrade.


No perfect answer here... I'm hesitating between (0), (1) and (4). (4) 
is IMHO the right solution, but it's a larger change for downstream. (1) 
is a bit of a hack, where we basically hardcode in rootwrap that it's 
being transitioned to privsep. That's fine, but only if we get rid of 
rootwrap soon. So only if we have a plan for (4) anyway. Option (0) is a 
bit of a hard sell for upgrade procedures -- if we need to take a hit in 
that area, let's do (4) directly...


In summary, I think the choice is between (1)+(4) and doing (4) 
directly. How doable is (4) in the timeframe we have ? Do we all agree 
that (4) is the endgame ?


--
Thierry Carrez (ttx)

__
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][qos] Egress minimum bandwidth assurance

[Alonso Hernandez, Rodolfo]

Hello:

Ichihara, thank you for your answer. It was just a test to find out how to 
setup correctly the egress traffic shaping. I was facing this situation and I 
found the problem: I was using bridges with datapath_type = netdev, instead of 
system. That was the main problem. Now I can correctly apply a QoS and a queue, 
and assign a traffic to this queue.

To avoid using veth between bridges, I’m implementing the following solution:

-  Create a new queue for each min-qos rule applied to a port (the same 
min-qos rule could be applied to several ports, of course).

-  Because ovs only shapes traffic in the egress direction (ovs point 
of view):

o   Create a qos policy for each port in br-int in the same network of the port 
to apply the qos; then assign the created queue to this qos policy.

o   Create a qos policy for the external port in br-tun, and then assign the 
queue

o   Create a qos policy for the external port for the br-phy in the same 
network, and assign the queue

-  In br-int, table 0, enqueue all traffic going into ovs from the port 
with qos policy assigned to the queue created.

With this implementation, you don’t need to use veth and all traffic going from 
the port with the qos policy assigned to other VM or external port (physical 
bridge, tunnel) will be shaped. Of course, this implementation is a bit 
tangled, so please be gentle in the code-review.

Regards.


From: Hirofumi Ichihara [mailto:ichihara.hirof...@lab.ntt.co.jp]
Sent: Tuesday, June 21, 2016 10:27 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance


On 2016/06/15 18:54, Alonso Hernandez, Rodolfo wrote:
Hello:

Context: try to develop a driver for this feature in OVS.

During the last week I’ve been testing several scenarios to make a POC of this 
feature.

Scenario 1:
3 VM connected to br-int, sending traffic through br-physical to other host (an 
external physical machine).
The first VM will have a min BW of 15 Mb. The physical port will be limited to 
20 Mb, so for VM2 and VM3 should be only 5 Mb of available BW.
Those three VM are using iperf to inject traffic against the external host.

A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.
B) Another qos policy and queue with this minimum BW is created at 
int-phy-patchport. The traffic is not shapped.
C) Another qos policy and queue with this minimum BW is created at 
phy-int-phy-patchport. The traffic is not shapped.
D) Another qos policy and queue with this minimum BW is created at physical 
port. The traffic is still not shapped.
In OVS all traffic from VM1 is filtered to match the correct qos and queues at 
the ports.
It seems that this scenario doesn't expect some scenarios like DVR and multiple 
NIC. I thought that the queue should be set in br-int with veth(instead of 
patch port) between br-int and bt-tun. However, I guess that this may occur a 
issue that traffic cannot turn back in br-int. That may happen in Scenario2 
case.

Therefore, I think that we should set the queue to physical port but we have a 
problem how do we specify the NIC in some cases(vlan, vxlan, DVR mode router 
and DVR FloatingIP).




Scenario 2:
Similar to scenario 1, but using a fourth VM to act as server. In this case, 
traffic only goes through br-int.
A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.
B) Another qos policy and queue with this minimum BW is created at output port 
(VM4 server port). The traffic is still not shapped.


I think we cannot manage this case because we doesn't know MAX bandwidth of 
traffic in br-int and the bandwidth is usually enough.
We should focus our attention on a case that the traffic goes out to other 
nodes.

Thanks,
Hirofumi


I need some help with this implementation, because I’m running out of time an 
ideas!

Thank you in advance.




__

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] [mistal] Mistral logo ideas?

[Dougal Matthews]

On 22 June 2016 at 06:35, Renat Akhmerov  wrote:

> Hi,
>
> We’d like to finally come up with a logo for Mistral and it’d be cool to
> hear some ideas from the community.
>
> Some ideas from me:
> • A picture of a graph (but the point is that it must be very very
> simple)
> • A picture of a rocket (meaning that Mistral helps take off of
> the ground)
> • A picture of a conductor (meaning that Mistral orchestrates
> things)
>

This makes me think of Heat a bit too much.


> • A picture of a fast train
> • A picture of a puzzle (meaning that Mistral helps gluing things)
> • Something related with wind (like Mistral wind)
>

Ideally it would be nice to have something that matches the meaning of the
name. Maybe we can combine wind with one of the other ideas.

I like the idea of the logo being a stylized wind turbine. Perhaps it could
be
a turbine with a gust of wind. Then we can show that Mistral harnesses the
power of the wind :-)



>
>
> 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 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] Status of the OpenStack port to Python 3

[Dmitry Tantsur]

On 06/23/2016 11:21 PM, Clark Boylan wrote:

On Thu, Jun 23, 2016, at 02:15 PM, Doug Hellmann wrote:

Excerpts from Thomas Goirand's message of 2016-06-23 23:04:28 +0200:

On 06/23/2016 06:11 PM, Doug Hellmann wrote:

I'd like for the community to set a goal for Ocata to have Python
3 functional tests running for all projects.

As Tony points out, it's a bit late to have this as a priority for
Newton, though work can and should continue. But given how close
we are to having the initial phase of the port done (thanks Victor!),
and how far we are from discussions of priorities for Ocata, it
seems very reasonable to set a community-wide goal for our next
release cycle.

Thoughts?

Doug


+1

Just think about it for a while. If we get Nova to work with Py3, and
everything else is working, including all functional tests in Tempest,
then after Otaca, we could even start to *REMOVE* Py2 support after
Otaca+1. That would be really awesome to stop all the compat layer
madness and use the new features available in Py3.


We'll need to get some input from other distros and from deployers
before we decide on a timeline for dropping Python 2. For now, let's
focus on making Python 3 work. Then we can all rejoice while having the
discussion of how much longer to support Python 2. :-)



I really would love to ship a full stack running Py3 for Debian Stretch.
However, for this, it'd be super helful to have as much visibility as
possible. Are we setting a hard deadline for the Otaca release? Or is
this just a goal we only "would like" to reach, but it's not really a
big deal if we don't reach it?


Let's see what PTLs have to say about planning, but I think if not
Ocata then we'd want to set one for the P release. We're running
out of supported lifetime for Python 2.7.


Keep in mind that there is interest in running OpenStack on PyPy which
is python 2.7. We don't have to continue supporting CPython 2.7
necessarily but we may want to support python 2.7 by way of PyPy.


PyPy folks have been working on python 3 support for some time already: 
http://doc.pypy.org/en/latest/release-pypy3.3-v5.2-alpha1.html
It's an alpha, but by the time we consider dropping Python 2 it will 
probably be released :)




Clark

__
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] [nova][pci-passthrough] definitely specify VFIO driver as the host PCI driver for passthrough

[Daniel P. Berrange]

On Fri, Jun 24, 2016 at 04:52:31PM +0800, Chen Fan wrote:
> 
> 
> On 2016年06月24日 16:20, Daniel P. Berrange wrote:
> > On Fri, Jun 24, 2016 at 12:27:57PM +0800, Chen Fan wrote:
> > > hi all,
> > >   in openstack, we can use the pci passthrough feature now, refer to
> > >   https://wiki.openstack.org/wiki/Pci_passthrough
> > >   but we can't definitely specify the host pci driver is LEGACY_KVM or
> > > newer VFIO,
> > >   new VFIO driver is more safer, and higher-performance user-space 
> > > driver
> > >   than legacy kvm driver (pci-stub), the benefit relative to kvm
> > > assignment driver
> > >   could refer to http://lwn.net/Articles/474088/.
> > >   In additional, VFIO driver provides the GPU passthrough as primary 
> > > card
> > > support.
> > >   I think it is more useful for further GPU passthrough support in
> > > openstack.
> > > 
> > >   Openstack relies on the libvirt nodedev device configuration to do 
> > > pci
> > > passthrough,
> > >   with managed mode, the configured device is automatically detached 
> > > and
> > > re-attached
> > >   with KVM or VFIO driver that depended on the host driver modules
> > > configuration,
> > >   so now we can't specify the driver in openstack to VFIO mode, I 
> > > think
> > > we should need
> > >   to add this feature support in openstack to get pci passhthrough 
> > > more
> > > scalability.
> > > 
> > >   a simply idea is to add a option in nova.conf HOST_PCI_MODEL = VFIO
> > > /KVM to specify
> > >   the pci passthrough device driver is using VFIO driver.
> > >   any comments are welcome. :)
> > I don't see any reason to add a configuration option. If the host is
> > capable of doing VFIO, libvirt will always aim to use VFIO in preference
> > to the legacy system.
> Hi Daniel,
> 
> sorry, I directly reference the implementation of nodedev in libvirt, in
> function
> virHostdevPreparePCIDevices :
>  257 if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)
>  258 virPCIDeviceSetStubDriver(pci, VIR_PCI_STUB_DRIVER_VFIO);
>  259 else if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN)
>  260 virPCIDeviceSetStubDriver(pci, VIR_PCI_STUB_DRIVER_XEN);
>  261 else
>  262 virPCIDeviceSetStubDriver(pci, VIR_PCI_STUB_DRIVER_KVM);
> 
> IIUC, the stub driver should be "legacy KVM", do we need to change the stub
> drvier
> to VIR_PCI_STUB_DRIVER_VFIO by default.

If libvirt uses VFIO, then it'll use the VFIO stub driver, which is fine.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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-ansible] L3HA problem

[fabrice grelaud]

> Le 22 juin 2016 à 19:40, Assaf Muller  a écrit :
> 
> On Wed, Jun 22, 2016 at 12:02 PM, fabrice grelaud
> > wrote:
>> 
>> Le 22 juin 2016 à 17:35, fabrice grelaud  a
>> écrit :
>> 
>> 
>> Le 22 juin 2016 à 15:45, Assaf Muller  a écrit :
>> 
>> On Wed, Jun 22, 2016 at 9:24 AM, fabrice grelaud
>>  wrote:
>> 
>> Hi,
>> 
>> we deployed our openstack infrastructure with your « exciting » project
>> openstack-ansible (mitaka 13.1.2) but we have some problems with L3HA after
>> create router.
>> 
>> Our infra (closer to the doc):
>> 3 controllers nodes (with bond0 (br-mgmt, br-storage), bond1 (br-vxlan,
>> br-vlan))
>> 2 compute nodes (same for network)
>> 
>> We create an external network (vlan type), an internal network (vxlan type)
>> and a router connected to both networks.
>> And when we launch an instance (cirros), we can’t receive an ip on the vm.
>> 
>> We have:
>> 
>> root@p-osinfra03-utility-container-783041da:~# neutron
>> l3-agent-list-hosting-router router-bim
>> +--+---++---+--+
>> | id   | host
>> | admin_state_up | alive | ha_state |
>> +--+---++---+--+
>> | 3c7918e5-3ad6-4f82-a81b-700790e3c016 |
>> p-osinfra01-neutron-agents-container-f1ab9c14 | True | :-)   |
>> active   |
>> | f2bf385a-f210-4dbc-8d7d-4b7b845c09b0 |
>> p-osinfra02-neutron-agents-container-48142ffe | True  | :-)   |
>> active   |
>> | 55350fac-16aa-488e-91fd-a7db38179c62 |
>> p-osinfra03-neutron-agents-container-2f6557f0 | True  | :-)   |
>> active   |
>> +--+---++---+—+
>> 
>> I know, i got a problem now because i should have :-) active, :-) standby,
>> :-) standby… Snif...
>> 
>> root@p-osinfra01-neutron-agents-container-f1ab9c14:~# ip netns
>> qrouter-eeb2147a-5cc6-4b5e-b97c-07cfc141e8e6
>> qdhcp-0ba266fb-15c4-4566-ae88-92d4c8fd2036
>> 
>> root@p-osinfra01-neutron-agents-container-f1ab9c14:~# ip netns exec
>> qrouter-eeb2147a-5cc6-4b5e-b97c-07cfc141e8e6 ip a sh
>> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
>> default
>>   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>   inet 127.0.0.1/8 scope host lo
>>  valid_lft forever preferred_lft forever
>>   inet6 ::1/128 scope host
>>  valid_lft forever preferred_lft forever
>> 2: ha-4a5f0287-91@if6:  mtu 1450 qdisc
>> pfifo_fast state UP group default qlen 1000
>>   link/ether fa:16:3e:c2:67:a9 brd ff:ff:ff:ff:ff:ff
>>   inet 169.254.192.1/18 brd 169.254.255.255 scope global ha-4a5f0287-91
>>  valid_lft forever preferred_lft forever
>>   inet 169.254.0.1/24 scope global ha-4a5f0287-91
>>  valid_lft forever preferred_lft forever
>>   inet6 fe80::f816:3eff:fec2:67a9/64 scope link
>>  valid_lft forever preferred_lft forever
>> 3: qr-44804d69-88@if9:  mtu 1450 qdisc
>> pfifo_fast state UP group default qlen 1000
>>   link/ether fa:16:3e:a5:8c:f2 brd ff:ff:ff:ff:ff:ff
>>   inet 192.168.100.254/24 scope global qr-44804d69-88
>>  valid_lft forever preferred_lft forever
>>   inet6 fe80::f816:3eff:fea5:8cf2/64 scope link
>>  valid_lft forever preferred_lft forever
>> 4: qg-c5c7378e-1d@if12:  mtu 1500 qdisc
>> pfifo_fast state UP group default qlen 1000
>>   link/ether fa:16:3e:b6:4c:97 brd ff:ff:ff:ff:ff:ff
>>   inet 147.210.240.11/23 scope global qg-c5c7378e-1d
>>  valid_lft forever preferred_lft forever
>>   inet 147.210.240.12/32 scope global qg-c5c7378e-1d
>>  valid_lft forever preferred_lft forever
>>   inet6 fe80::f816:3eff:feb6:4c97/64 scope link
>>  valid_lft forever preferred_lft forever
>> 
>> Same result on infra02 and infra03, qr and qg interfaces have the same ip,
>> and ha interfaces the address 169.254.0.1.
>> 
>> If we stop 2 neutron agent containers (p-osinfra02, p-osinfra03) and we
>> restart the first (p-osinfra01), we can reboot the instance and we got an
>> ip, a floating ip and we can access by ssh from internet to the vm. (Note:
>> after few time, we loss our connectivity too).
>> 
>> But if we restart the two containers, we got a ha_state to « standby » until
>> the three become « active » and finally we have the problem again.
>> 
>> The three routers on infra 01/02/03 are seen as master.
>> 
>> If we ping from our instance to the router (internal network 192.168.100.4
>> to 192.168.100.254) we can see some ARP Request
>> ARP, Request who-has 192.168.100.254 tell 192.168.100.4, length 28
>> ARP, Request who-has 192.168.100.254 tell 192.168.100.4, length 28

Re: [openstack-dev] [nova][pci-passthrough] definitely specify VFIO driver as the host PCI driver for passthrough

[Chen Fan]

On 2016年06月24日 16:20, Daniel P. Berrange wrote:

On Fri, Jun 24, 2016 at 12:27:57PM +0800, Chen Fan wrote:

hi all,
  in openstack, we can use the pci passthrough feature now, refer to
  https://wiki.openstack.org/wiki/Pci_passthrough
  but we can't definitely specify the host pci driver is LEGACY_KVM or
newer VFIO,
  new VFIO driver is more safer, and higher-performance user-space driver
  than legacy kvm driver (pci-stub), the benefit relative to kvm
assignment driver
  could refer to http://lwn.net/Articles/474088/.
  In additional, VFIO driver provides the GPU passthrough as primary card
support.
  I think it is more useful for further GPU passthrough support in
openstack.

  Openstack relies on the libvirt nodedev device configuration to do pci
passthrough,
  with managed mode, the configured device is automatically detached and
re-attached
  with KVM or VFIO driver that depended on the host driver modules
configuration,
  so now we can't specify the driver in openstack to VFIO mode, I think
we should need
  to add this feature support in openstack to get pci passhthrough more
scalability.

  a simply idea is to add a option in nova.conf HOST_PCI_MODEL = VFIO
/KVM to specify
  the pci passthrough device driver is using VFIO driver.
  any comments are welcome. :)

I don't see any reason to add a configuration option. If the host is
capable of doing VFIO, libvirt will always aim to use VFIO in preference
to the legacy system.

Hi Daniel,

sorry, I directly reference the implementation of nodedev in 
libvirt, in function

virHostdevPreparePCIDevices :
 257 if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO)
 258 virPCIDeviceSetStubDriver(pci, VIR_PCI_STUB_DRIVER_VFIO);
 259 else if (pcisrc->backend == 
VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN)

 260 virPCIDeviceSetStubDriver(pci, VIR_PCI_STUB_DRIVER_XEN);
 261 else
 262 virPCIDeviceSetStubDriver(pci, VIR_PCI_STUB_DRIVER_KVM);

IIUC, the stub driver should be "legacy KVM", do we need to change the 
stub drvier

to VIR_PCI_STUB_DRIVER_VFIO by default.

Thanks,
Chen




Regards,
Daniel


--
Sincerely,
Chen Fan


__
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] Status of the OpenStack port to Python 3

[Daniel P. Berrange]

On Thu, Jun 23, 2016 at 10:08:22AM +0200, Sylvain Bauza wrote:
> 
> 
> Le 23/06/2016 02:42, Tony Breeds a écrit :
> > On Wed, Jun 22, 2016 at 12:13:21PM +0200, Victor Stinner wrote:
> > > Le 22/06/2016 à 10:49, Thomas Goirand a écrit :
> > > > Do you think it looks like possible to have Nova ported to Py3 during
> > > > the Newton cycle?
> > > It doesn't depend on me: I'm sending patches, and then I have to wait for
> > > reviews. The question is more how to accelerate reviews.
> > Clearly I'm far from authorative but given how close we are to R-14 which is
> > the Nova non-priority feature freeze[1] and the python3 port isn't listed as
> > a priority[2] I'd guess that this wont land in Newton.
> > 
> > [1] 
> > http://releases.openstack.org/newton/schedule.html#nova-non-priority-feature-freeze
> > [2] 
> > http://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html
> 
> Well, IIRC we discussed in the previous year on some of those blueprints
> (including the Py3 effort) that are not really features (rather refactoring
> items) and which shouldn't be hit by the non-priority feature freeze.
> That doesn't mean we could merge those anytime of course, but I don't think
> we would procedurally -2 them.

Certainly anything which is merely fixing unit tests is valid to be merged
pretty much any time. Stuff which touches actual functional code can be
evaluated on a case by case basis to decide whether it is reasonable to
merge at the particular point in the release process we're at. IOW, I see
no reason to arbitrarily block Py3 work on non-prio freeze - we'll just
carry on with it as part of our natural review process - it'll just have
to take back-seat to reviews for priority features.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] Status of the OpenStack port to Python 3

[Victor Stinner]

Le 22/06/2016 à 09:18, Victor Stinner a écrit :

Current status: only 3 projects are not ported yet to Python 3:

* nova (76% done)
* trove (42%)
* swift (0%)


If you want to help, please review my patches! I sent patches to these 
projects.


Nova:
https://review.openstack.org/#/c/332686/

Swift:
https://review.openstack.org/#/c/333297/

Trove:
https://review.openstack.org/#/c/333262/
https://review.openstack.org/#/c/333267/
https://review.openstack.org/#/c/184400/ PyMySQL!
(Since december 2015, Trove already merged 17 of my patches for py3!)


Others wrote Python 3 patches, please review these patches too!

Nova:
https://review.openstack.org/#/q/topic:bp/nova-python3-newton+status:open

Swift:
https://review.openstack.org/#/q/project:openstack/swift+branch:master+topic:py3+status:open


Victor

__
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] Status of the OpenStack port to Python 3

[Daniel P. Berrange]

On Thu, Jun 23, 2016 at 11:04:28PM +0200, Thomas Goirand wrote:
> On 06/23/2016 06:11 PM, Doug Hellmann wrote:
> > I'd like for the community to set a goal for Ocata to have Python
> > 3 functional tests running for all projects.
> > 
> > As Tony points out, it's a bit late to have this as a priority for
> > Newton, though work can and should continue. But given how close
> > we are to having the initial phase of the port done (thanks Victor!),
> > and how far we are from discussions of priorities for Ocata, it
> > seems very reasonable to set a community-wide goal for our next
> > release cycle.
> > 
> > Thoughts?
> > 
> > Doug
> 
> +1
> 
> Just think about it for a while. If we get Nova to work with Py3, and
> everything else is working, including all functional tests in Tempest,
> then after Otaca, we could even start to *REMOVE* Py2 support after
> Otaca+1. That would be really awesome to stop all the compat layer
> madness and use the new features available in Py3.

Please lets not derail discussions about completing Py3 support by
opening up the can of worms wrt dropping Py2.

Lets get the Py3 support completed and in the hands of users and
proven acceptable before we talk about dropping support for the python
platform that every single deployment runs on today.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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][pci-passthrough] definitely specify VFIO driver as the host PCI driver for passthrough

[Daniel P. Berrange]

On Fri, Jun 24, 2016 at 12:27:57PM +0800, Chen Fan wrote:
> hi all,
>  in openstack, we can use the pci passthrough feature now, refer to
>  https://wiki.openstack.org/wiki/Pci_passthrough
>  but we can't definitely specify the host pci driver is LEGACY_KVM or
> newer VFIO,
>  new VFIO driver is more safer, and higher-performance user-space driver
>  than legacy kvm driver (pci-stub), the benefit relative to kvm
> assignment driver
>  could refer to http://lwn.net/Articles/474088/.
>  In additional, VFIO driver provides the GPU passthrough as primary card
> support.
>  I think it is more useful for further GPU passthrough support in
> openstack.
> 
>  Openstack relies on the libvirt nodedev device configuration to do pci
> passthrough,
>  with managed mode, the configured device is automatically detached and
> re-attached
>  with KVM or VFIO driver that depended on the host driver modules
> configuration,
>  so now we can't specify the driver in openstack to VFIO mode, I think
> we should need
>  to add this feature support in openstack to get pci passhthrough more
> scalability.
> 
>  a simply idea is to add a option in nova.conf HOST_PCI_MODEL = VFIO
> /KVM to specify
>  the pci passthrough device driver is using VFIO driver.
>  any comments are welcome. :)

I don't see any reason to add a configuration option. If the host is
capable of doing VFIO, libvirt will always aim to use VFIO in preference
to the legacy system.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

[Daniel P. Berrange]

On Thu, Jun 23, 2016 at 09:09:44AM -0700, Walter A. Boring IV wrote:
> 
> volumes connected to QEMU instances eventually become directly connected?
> 
> > Our long term goal is that 100% of all network storage will be connected
> > to directly by QEMU. We already have the ability to partially do this with
> > iSCSI, but it is lacking support for multipath. As & when that gap is
> > addressed though, we'll stop using the host OS for any iSCSI stuff.
> > 
> > So if you're requiring access to host iSCSI volumes, it'll work in the
> > short-medium term, but in the medium-long term we're not going to use
> > that so plan accordingly.
> 
> What is the benefit of this largely monolithic approach?  It seems that
> moving everything into QEMU is diametrically opposed to the unix model
> itself and
> is just a re-implementation of what already exists in the linux world
> outside of QEMU.

There are many benefits to having it inside QEMU. First it gives us
improved isolation between VMs, because we can control the network
I/O directly against the VM using cgroup resource controls. It gives
us improved security, particularly in combination with LUKS encryption
since the unencrypted block device is not directly visible / accessible
to any other process. It gives us improved reliability / managability
since we avoid having to spawn the iscsi client tools which have poor
error reporting and have been frequent sources of instability in our
infrastructure (eg see how we have to blindly re-run the same command
many times over because it randomly times out). It will give us improved
I/O performance because of a shorter I/O path to get requests from QEMU
out to the network.

NB, this is not just about iSCSI, the same is all true for RBD where
we've also stopped using in-kernel RBD client and do it all in QEMU.

> Does QEMU support hardware initiators? iSER?

No, this is only for case where you're doing pure software based
iSCSI client connections. If we're relying on local hardware that's
a different story.

> 
> We regularly fix issues with iSCSI attaches in the release cycles of
> OpenStack,
> because it's all done in python using existing linux packages.  How often

This is a great example of the benefit that in-QEMU client gives us. The
Linux iSCSI client tools have proved very unreliable in use by OpenStack.
This is a reflection of the very architectural approach. We have individual
resources needed by distinct VMs, but we're having to manage them as a host
wide resource and that's creating us unneccessary complexity and having a
poor effect on our reliability overall.

> are QEMU
> releases done and upgraded on customer deployments vs. python packages
> (os-brick)?

We're removing the entire layer of instability by removing the need to
deal with any command line tools, and thus greatly simplifying our
setup on compute nodes. No matter what we might do in os-brick it'll
never give us a simple or reliable system - we're just papering over
the flaws by doing stuff like blindly re-trying iscsi commands upon
failure.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] Networking issues with neutron-linuxbridge-agent

[Eugen Block]

Make sure nova is using the noop driver.


I'm trying to use ceilometer, in that case the docs say to use  
messagingv2 driver, so that's what I did. And until two weeks ago it  
worked just fine, I had no networking issues.



double check your security groups config


The security groups also seem to be fine, my colleague works via ssh  
on those instances. And the interruption can be caused by deleting an  
instance in a different project with it's own security groups, it just  
has to run on the same compute node.



Zitat von Darragh O'Reilly :

double check your security groups config. Make sure nova is using  
the noop driver.




--
Eugen Block voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg e-mail  : ebl...@nde.ag

Vorsitzende des Aufsichtsrates: Angelika Mozdzen
  Sitz und Registergericht: Hamburg, HRB 90934
  Vorstand: Jens-U. Mozdzen
   USt-IdNr. DE 814 013 983


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [all] Status of the OpenStack port to Python 3

[Victor Stinner]

Le 23/06/2016 à 23:04, Thomas Goirand a écrit :

Just think about it for a while. If we get Nova to work with Py3, and
everything else is working, including all functional tests in Tempest,


Hum, that's a long list of expectations :-)



then after Otaca, we could even start to *REMOVE* Py2 support after
Otaca+1. That would be really awesome to stop all the compat layer
madness and use the new features available in Py3.


Even if everything works well, I disagree that we must drop immediately 
Python 2 support. We should give time to deployers to prepare their 
migration to Python 3. We need at least have one cycle *fully* 
compatible with Python 3 to be able to *prepare* dropping Python 2 support.


In practice, we already support Python 2 and Python 3 in the same code 
base. We already paid the price of supporting both major versions. Once 
all code is ported, it shouldn't be too expensive to maintain both versions.


One concrete issue is that running tests on Python 2 *and* Python 3 
multiply the risk of random failures by 2. It's just math... In my 
experience, fixing random failures is not the most favorite task of 
developers...


If you want to deprecate Python 2, the first question is *when* we can 
start to make Python 2 checks non-voting.




However, for this, it'd be super helful to have as much visibility as
possible. Are we setting a hard deadline for the Otaca release? Or is
this just a goal we only "would like" to reach, but it's not really a
big deal if we don't reach it?


In my experience, Python 3 work is seen as background refactoring work, 
and it is rarely seen as high-priority. You should be prepared to have 
to wait :-)


Victor

__
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] what do you work on upstream of OpenStack?

[Steve Martinelli]

Thanks for that Clint!
On Jun 24, 2016 1:28 AM, "Clint Byrum"  wrote:

> Excerpts from Doug Hellmann's message of 2016-06-23 08:37:04 -0400:
> > Excerpts from Doug Hellmann's message of 2016-06-13 15:11:17 -0400:
> > > I'm trying to pull together some information about contributions
> > > that OpenStack community members have made *upstream* of OpenStack,
> > > via code, docs, bug reports, or anything else to dependencies that
> > > we have.
> > >
> > > If you've made a contribution of that sort, I would appreciate a
> > > quick note.  Please reply off-list, there's no need to spam everyone,
> > > and I'll post the summary if folks want to see it.
> > >
> > > Thanks,
> > > Doug
> > >
> >
> > I've summarized the results of all of your responses (on and off
> > list) on a blog post this morning [1]. I removed individual names
> > because I was concentrating on the community as a whole, rather than
> > individual contributions.
> >
> > I'm sure there are projects not listed, either because I missed
> > something in my summary or because someone didn't reply. Please feel
> > free to leave a comment on the post with references to other projects.
> > It's not necessary to link to specific commits or bugs or anything like
> > that, unless there's something you would especially like to highlight.
> >
> > Thank you for your input into the survey. I'm impressed with the
> > breadth of the results. I'm very happy to know that our community,
> > which so often seems to be focused on building new projects, also
> > contributes to existing projects that we all rely on.
> >
> > [1]
> https://doughellmann.com/blog/2016/06/23/openstack-contributions-to-other-open-source-projects/
>
> That is pretty cool.
>
> I forgot to reply to your original request, but I did a lot of python3
> porting on the pysaml2 project in support of Keystone's python3 port.
>
> https://github.com/rohe/pysaml2/commits?author=SpamapS
>
> __
> 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