Re: [openstack-dev] New Python35 Jobs coming

[Andreas Jaeger]

On 07/03/2016 09:26 PM, Henry Gessau wrote:
> Clark Boylan  wrote:
>> The infra team is working on taking advantage of the new Ubuntu Xenial
>> release including running unittests on python35. The current plan is to
>> get https://review.openstack.org/#/c/336272/ merged next Tuesday (July
>> 5, 2016). This will add non voting python35 tests restricted to >=
>> master/Newton on all projects that had python34 testing.
>>
>> The expectation is that in many cases python35 tests will just work if
>> python34 testing was also working. If this is the case for your project
>> you can propose a change to openstack-infra/project-config to make these
>> jobs voting against your project. You should only need to edit
>> jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'
>> portion of the python35 jobs to do this.
>>
>> We do however expect that there will be a large group of failed tests
>> too. If your project has a specific tox.ini py34 target to restrict
>> python3 testing to a specific list of tests you will need to add a tox
>> target for py35 that does the same thing as the py34 target. We have
>> also seen bug reports against some projects whose tests rely on stable
>> error messages from Python itself which isn't always the case across
>> version changes so these tests will need to be updated as well.
>>
>> Note this change will not add python35 jobs for cases where projects
>> have special tox targets. This is restricted just to the default py35
>> unittesting.
>>
>> As always let us know if you questions,
>> Clark
> 
> How soon can projects replace py34 with py35?

As soon as you think your project is ready, you can replace py34 with
py35 for master.

> 
> I tried py35 for neutron locally, and it ran without errors.

Then let it run for a day or two in our CI, discuss with neutron team,
and send a patch for project-config to change the setup,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: 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

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

[Joshua Hesketh]

On Fri, Jul 1, 2016 at 9:26 PM, Jesse Pretorius <
jesse.pretor...@rackspace.co.uk> wrote:

> Hi all,
>
> Now that OpenStack-Ansible has the final Swift kilo-eol tag implemented
> we’ve requested a final tag [1]. Once that merges we are ready to have our
> kilo-eol tag implemented and the ‘kilo’ branch removed.
>

I assume you want to wait for the tag to merge before removing the branch?


>
> Just to make life interesting, we still have leftover ‘juno’ and
> ‘icehouse’ branches and would like to implement eol tags for them too. I
> think we have the appropriate skips in place for the juno branch so there
> should be no funky post-tag jobs kicking off for them, but the icehouse
> branch may end up with some unknown jobs kicking off. If you can help
> identify the changes we need to get implemented into project-config then we
> can be rid of the old cruft.
>

The only tag job I can see for openstack-ansible* projects is the
releasenotes one. This should be harmless as it just generates the notes
for mitaka and liberty branches. I'm going to hold off until the final tag
has merged anyway if you want to confirm this first.

Cheers,
Josh



> Thanks,
>
> Jesse
>
> --
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
>
> __
> 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] [Kolla] [docker] Storage-driver and loopback usage?

[Jeffrey Zhang]

Hi Gerard,

Here is what the docker official recommend[0]. In the prod env, the they
recommend
using the direct-lvm driver.

Kolla has no recommendation now. In the dev process, i know someone use
overlayfs,
some use btrfs. These two are both faster than others.


[0] https://docs.docker.com/engine/userguide/storagedriver/selectadriver/

On Mon, Jul 4, 2016 at 11:00 AM, Gerard Braad  wrote:

> Hi guys,
>
>
> This weekend I have been looking into some issues I encountered with
> `ostree` inside a Docker container, and this seemed to have been
> caused by the use of loopback storage with device mapper. After this
> experience I was wondering what Kolla did...
>
> Usually for development purpose, or on a laptop, it is easy to just
> work out-of-the-box. But I would not consider using devicemapper after
> this experience as a pleasant experience. I moved to all development
> environment using OverlayFS, and will evaluate this for the time
> being...
>
> What do you guys think or use? And what about the quickstart? I was
> unable to find a statement about this. I did find a change of the
> storage-driver in `kolla/tools/setup_RedHat.sh` to btrfs... and what
> is used in CI?
>
> regards,
>
>
> Gerard
>
> --
>
>Gerard Braad | http://gbraad.nl
>[ Doing Open Source Matters ]
>
> __
> 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
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [keystone] spec freeze on july 8th, 2016

[Steve Martinelli]

The keystone spec freeze is on july 8th. I am in the process of going
through the open specs [1]

I will be commenting if I think it is a potential candidate for the Newton
based on how far along the spec is, its complexity, core reviewer attention
and priority. (Thanks Matt R for the wording)

I'd like spend the bulk of the next keystone meeting on Tuesday discussing
the open specs. If you are authoring one, please try to attend.

[1]
https://review.openstack.org/#/q/project:openstack/keystone-specs+status:open
__
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

[Angus Lees]

On Sat, 2 Jul 2016 at 01:02 Matt Riedemann 
wrote:

> On 6/28/2016 4:56 PM, Sean Dague wrote:
> > On 06/28/2016 01:46 AM, Angus Lees wrote:
> >> Ok, thanks for the in-depth explanation.
> >>
> >> My take away is that we need to file any rootwrap updates as exceptions
> >> for now (so releasenotes and grenade scripts).
> >
> > That is definitely the fall back if there is no better idea. However, we
> > should try really hard to figure out if there is a non manual way
> > through this. Even if that means some compat code that we keep for a
> > release to just bridge the gap.
> >
> > -Sean
> >
>
> Walter had this for os-brick:
>
> https://review.openstack.org/#/c/329586/
>
> That would fallback to rootwrap if privsep doesn't work / not available.
> That could be a workaround for upgrading with os-brick for Newton, with
> a big fat warning logged if we use it, and then drop it in Ocata and
> require privsep.
>

Yes, this is basically a version of "submit the rootwrap filter, then wait
6 months before submitting the code that needs it".   If we don't wish to
use the exception mechanism (or adjust the policy to upgrade conf before
code as I described earlier), then we can certainly do this.  Rather than
log a big fat warning if we use privsep, we may as well just revert the
privsep change for os-brick and then resubmit it next cycle.

This thread topic isn't actually about privsep however, although a
migration to privsep will mostly mitigate this in the future which is
perhaps why it is causing topic collisions for everyone.

I see there are already a few other additions to the rootwrap filters in
nova/cinder (the comments suggest (nova) libvirt/imagebackend.py, (cinder)
remotefs.py, and (both) vzstorage.py).  The various privsep-only
suggestions about fallback strategies don't help in these other examples.  Any
corresponding code changes that rely on these new filters will also need to
be reverted and resubmitted during next cycle - or do what usually happens
and slip under the radar as they are not exercised by grenade.

 - 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] [Kolla] [docker] Storage-driver and loopback usage?

[Gerard Braad]

Hi guys,


This weekend I have been looking into some issues I encountered with
`ostree` inside a Docker container, and this seemed to have been
caused by the use of loopback storage with device mapper. After this
experience I was wondering what Kolla did...

Usually for development purpose, or on a laptop, it is easy to just
work out-of-the-box. But I would not consider using devicemapper after
this experience as a pleasant experience. I moved to all development
environment using OverlayFS, and will evaluate this for the time
being...

What do you guys think or use? And what about the quickstart? I was
unable to find a statement about this. I did find a change of the
storage-driver in `kolla/tools/setup_RedHat.sh` to btrfs... and what
is used in CI?

regards,


Gerard

-- 

   Gerard Braad | http://gbraad.nl
   [ Doing Open Source Matters ]

__
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] New Python35 Jobs coming

[Clint Byrum]

Excerpts from Henry Gessau's message of 2016-07-03 15:26:23 -0400:
> Clark Boylan  wrote:
> > The infra team is working on taking advantage of the new Ubuntu Xenial
> > release including running unittests on python35. The current plan is to
> > get https://review.openstack.org/#/c/336272/ merged next Tuesday (July
> > 5, 2016). This will add non voting python35 tests restricted to >=
> > master/Newton on all projects that had python34 testing.
> > 
> > The expectation is that in many cases python35 tests will just work if
> > python34 testing was also working. If this is the case for your project
> > you can propose a change to openstack-infra/project-config to make these
> > jobs voting against your project. You should only need to edit
> > jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'
> > portion of the python35 jobs to do this.
> > 
> > We do however expect that there will be a large group of failed tests
> > too. If your project has a specific tox.ini py34 target to restrict
> > python3 testing to a specific list of tests you will need to add a tox
> > target for py35 that does the same thing as the py34 target. We have
> > also seen bug reports against some projects whose tests rely on stable
> > error messages from Python itself which isn't always the case across
> > version changes so these tests will need to be updated as well.
> > 
> > Note this change will not add python35 jobs for cases where projects
> > have special tox targets. This is restricted just to the default py35
> > unittesting.
> > 
> > As always let us know if you questions,
> > Clark
> 
> How soon can projects replace py34 with py35?
> 
> I tried py35 for neutron locally, and it ran without errors.
> 

I think we should be aggressive on python 3.5 vs. 3.4, since anywhere
that shipped 3.4 also shipped 2.7. Otherwise we end up wasting time on
whatever subtle differences there are.

__
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] [kolla][horizon] Out of branch horizon plugins?

[Dave Walker]

Hi,

Whilst writing a Kolla plugin, I noticed some issues with the way Horizon
is configured in Kolla.

Horizon is increasingly embracing a plugin architecture with UI's and
Dashboards being maintained outside of Horizon's tree.

These can be found with the type:horizon-plugin tag in openstack/governance
[0], with 16 projects at current.

This isn't really addressed in Kolla, and is a little awkward to integrate
as the horizon docker image is pure horizon.

Some projects have a tools/register_plugin.sh which performs the grunt
work, where as others require a workflow similar to:

cp /path/to/projects/new/panel openstack_dashboard/local/enabled/
cp /path/to/local/defualt/settings
openstack_dashboard/local/local_settings.d/
cp /path/to/*policy.json openstack_dashboard/conf/
# compress if environment wants it
./manage.py collectstatic
./manage.py compress

(Separately, it would be nice if this was standardised.. but not the topic
of this thread)

It would seem logical to pack all of these into the horizon docker image,
and add a symlink into dashboard/local/enabled via ansible, policy.json and
default settings with some conditionals if enabled_$service... but this
will make the horizon docker image larger and more complicated.

What are your thoughts?

[0]
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

--
Kind Regards,
Dave Walker
__
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] New Python35 Jobs coming

[Henry Gessau]

Clark Boylan  wrote:
> The infra team is working on taking advantage of the new Ubuntu Xenial
> release including running unittests on python35. The current plan is to
> get https://review.openstack.org/#/c/336272/ merged next Tuesday (July
> 5, 2016). This will add non voting python35 tests restricted to >=
> master/Newton on all projects that had python34 testing.
> 
> The expectation is that in many cases python35 tests will just work if
> python34 testing was also working. If this is the case for your project
> you can propose a change to openstack-infra/project-config to make these
> jobs voting against your project. You should only need to edit
> jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'
> portion of the python35 jobs to do this.
> 
> We do however expect that there will be a large group of failed tests
> too. If your project has a specific tox.ini py34 target to restrict
> python3 testing to a specific list of tests you will need to add a tox
> target for py35 that does the same thing as the py34 target. We have
> also seen bug reports against some projects whose tests rely on stable
> error messages from Python itself which isn't always the case across
> version changes so these tests will need to be updated as well.
> 
> Note this change will not add python35 jobs for cases where projects
> have special tox targets. This is restricted just to the default py35
> unittesting.
> 
> As always let us know if you questions,
> Clark

How soon can projects replace py34 with py35?

I tried py35 for neutron locally, and it ran without errors.


__
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] [manila][stable] liberty periodic bitrot jobs have been failing more than a week

[Valeriy Ponomaryov]

Matt, it is not related to branch. Tempest jobs do run only when specific
files are changed. See [1].

[1]
https://github.com/openstack-infra/project-config/blob/f269e732/zuul/layout.yaml#L1066

On Sun, Jul 3, 2016 at 4:19 PM, Matt Riedemann 
wrote:

> On 7/1/2016 8:18 PM, Ravi, Goutham wrote:
>
>> Thanks Matt.
>>
>> https://review.openstack.org/#/c/334220 adds the upper constraints.
>>
>> --
>> Goutham
>>
>>
>> On 7/1/16, 5:08 PM, "Matt Riedemann"  wrote:
>>
>> The manila periodic stable/liberty jobs have been failing for at least a
>> week.
>>
>> It looks like manila isn't using upper-constraints when running unit
>> tests, not even on stable/mitaka or master. So in liberty it's pulling
>> in uncapped oslo.utils even though the upper constraint for oslo.utils
>> in liberty is 3.2.
>>
>> Who from the manila team is going to be working on fixing this, either
>> via getting upper-constraints in place in the tox.ini for manila (on all
>> supported branches) or performing some kind of workaround in the code?
>>
>>
> Thanks.
>
> I noticed that there is no Tempest / devstack job run against the
> stable/liberty change - why is there no integration testing of Manila in
> stable/liberty outside of 3rd party CI (which is not voting)?
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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
>



-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.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

Re: [openstack-dev] Syntribos Error : AttributeError: 'tuple' object has no attribute 'headers'

[OpenStack Mailing List Archive]

Link: https://openstack.nimeyo.com/89478/?show=89495#c89495
From: run2obtain 

@David. Thanks for responding, it is quite painful to use such  a service with no documentation especially as a non-python guy. BTW, what could be a possible resolution approach ?



__
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] Fail build request if we can't inject files?

[Matt Riedemann]

I want to use the gate-tempest-dsvm-neutron-full-ssh in nova since it 
runs ssh validation + neutron + config drive + metadata service, which 
will test the virtual device tagging 2.32 microversion API (added last 
week).


The job has a file injection test that fails consistently which is 
keeping it from being voting.


After debugging, the problem is the files to inject are silently ignored 
because n-cpu is configured with libvirt.inject_partition=-2 by default. 
That disables file injection:


https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030

We don't even log a warning if the user requested files to inject and we 
can't honor it. If I were a user and tried to inject files when creating 
a server but they didn't show up in the guest, I'd open a support ticket 
against my cloud provider. So I don't think a warning (that only the 
admin sees) is sufficient here. This isn't something that's discoverable 
from the API either, it's really host configuration / capability 
(something we still need to tackle).


So I propose that we fail the server create request in this case since 
the user asked nova to inject files but n-cpu is configured to not allow 
that.


I'd also think that this should trigger a reschedule to another compute. 
However, if all computes have disabled file injection, which is the default:


https://github.com/openstack/nova/blob/0c0f60031acba11d0bab0617f68b95d9b5eb8d1d/nova/conf/libvirt.py#L66

Then they'll retry 3 times and fail with an instance in error state. So 
I'm not sure if rescheduling in this case is useful. I'd think that 
deployments are either allowing file injection globally (if using 
libvirt) of they aren't, but would need some operators to chime in here.


--

Thanks,

Matt Riedemann


__
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 Mitaka Neutron LBaaS Question

[Fawaz Mohammed]

Hi Wally,

Make sure that neutron-server is running. Check neutron-server, and
neutron-l3-agent logs.

---
Regards,
Fawaz Mohammed
 .



On Sat, Jul 2, 2016 at 2:24 AM, zhihao wang 
wrote:

> Dear OpenStack Dev member:
>
> May I ask you some question about neutron lbaaS?
>
> How to install the neutron LBaaS with Octavia in Mitaka?
> I followed these two guide ,but which one I should use? (My openstack is
> Mitaka , 1 controller, 2 compute nodes)
>
> https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun  --  Ubuntu
> Packages Setup
> http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html
> -- Configuring LBaaS v2 with Octavia
>
> Here is what I did:
>
> pip install octavia
>
> and then :
> vim /etc/neutron/neutron.conf
> service_plugins =
> router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2
>
> [service_providers]
> service_provider =
> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
>
> /etc/openstack-dashboard/local_settings.py
>
>
> OPENSTACK_NEUTRON_NETWORK = {
> 'enable_lb': True
> }
>
>
> And then I restart all the neutron service and apache server
>   service neutron-server restart
>   service neutron-dhcp-agent restart
>   service neutron-metadata-agent restart
>   service neutron-l3-agent restart
>
> but and then i ran the command neutron agent-list, it return this. I am
> wondering what is wrong with this? how can I install Neutron LaaS?
>
> root@controller:~# neutron agent-list
> Unable to establish connection to http://controller:9696/v2.0/agents.json
>
>
> Please help
>
> Thanks so much
>
> Thanks
> Wally
>
>
>
> __
> 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] [tricircle] Error when running Devstack

[Fawaz Mohammed]

Hi Dongfeng,

I've noted in the title [Tricircle], but in your body mail, nothing related
to Tricircle!

It's not recommended to use the sample configuration file as it's, make
sure that you edit it as per your preferred configuration.

Also, note that it's good to run stack.sh as stack user, you can create
stack user by running:
$sudo /devstack/tools/create-stack-user.sh
Then, move the devstack folder to stack home user, or clone it again:
stack@Host$cd ~
stack@host$git clone https://git.openstack.org/openstack-dev/devstack
Edit your local.conf configuration file, then run stack.sh script.



On Sun, Jul 3, 2016 at 3:41 PM, Luck Dog  wrote:

> Hello everyone,
>
> I am trying to run DevStack on Ubuntu 14.04 in a single VirtualBox. An
> error turns up  before it successfully starts. My steps are:
> 1), Git clone DevStack,
> 2), Copy devstack/local.conf.sample to DevStack folder and rename it to
> local.conf.
> The  errors are as follows：
> Request Failed: internal server error while processing your request.
> Neutron server returns request_ids:
> ['req-e97f6276-8e19-408b-829a-004a31256453']
> lib/neutron_plugins/services/l3:create_neutron_initial_network:203
> lib/neutron_plugins/services/l3:create_neutron_initial_network:207
> [ERROR] /home/sword/DevStack/functions-common:207 Failure creating
> EXT_NET_ID for public
>
> I don't know whether it is  my wrong configuration of computer or the
> server error, I wish someone can help me with the problem. thanks!
>
> Best regards,
> Dongfeng
>
> __
> 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] Syntribos Error : AttributeError: 'tuple' object has no attribute 'headers'

[David Stanek]

On 07/02 at 15:52, OpenStack Mailing List Archive wrote:
> Link: https://openstack.nimeyo.com/89478/?show=89478#q89478
> From: run2obtain 
> 
> 
> Hi... I tried to use OpenStack Syntribos today for security testing against my
> devstack kilo cloud. I followed installation and configuration instructions
> provided at the openstack syntribos repo .Unfortunately, I received some 
> errors
> after running the command : syntribos keystone.config .opencafe/templates/
> keystone/roles_get.txt . The errors are File "/usr/local/lib/python2.7/
> dist-packages/syntribos/extensions/identity/client.py", line 146, in
> get_token_v3 return r.headers["X-Subject-Token"] AttributeError: 'tuple' 
> object
> has no attribute 'headers'. ' I have not been successful at discovering what
> could be wrong or how to resolve this issue, even after googling. Does anyone
> have a hint as to how to resolve this issue. Many thanks for your anticipated
> response.
> 

A quick look at the code[1] show that the HTTP client used by the identity
client actually returns a tuple instead of a response object. The tuple
contains two items: a response object and a signal handler object.

This is the first I've heard of this project, so I was very disappointed
to not find any docs for it.

1. 
https://github.com/openstack/syntribos/blob/master/syntribos/clients/http/base_http_client.py#L143

-- 
David Stanek
web: http://dstanek.com
blog: http://traceback.org

__
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] [manila][stable] liberty periodic bitrot jobs have been failing more than a week

[Matt Riedemann]

On 7/1/2016 8:18 PM, Ravi, Goutham wrote:

Thanks Matt.

https://review.openstack.org/#/c/334220 adds the upper constraints.

--
Goutham


On 7/1/16, 5:08 PM, "Matt Riedemann"  wrote:

The manila periodic stable/liberty jobs have been failing for at least a
week.

It looks like manila isn't using upper-constraints when running unit
tests, not even on stable/mitaka or master. So in liberty it's pulling
in uncapped oslo.utils even though the upper constraint for oslo.utils
in liberty is 3.2.

Who from the manila team is going to be working on fixing this, either
via getting upper-constraints in place in the tox.ini for manila (on all
supported branches) or performing some kind of workaround in the code?



Thanks.

I noticed that there is no Tempest / devstack job run against the 
stable/liberty change - why is there no integration testing of Manila in 
stable/liberty outside of 3rd party CI (which is not voting)?


--

Thanks,

Matt Riedemann


__
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] Questions about instance actions' update and finish

[Matt Riedemann]

On 7/3/2016 6:21 AM, Alex Xu wrote:



2016-07-02 2:32 GMT+08:00 Sean Dague >:

On 06/30/2016 08:31 AM, Andrew Laski wrote:
>
>
> On Wed, Jun 29, 2016, at 11:11 PM, Matt Riedemann wrote:
>> On 6/29/2016 10:10 PM, Matt Riedemann wrote:
>>> On 6/29/2016 6:40 AM, Andrew Laski wrote:



 On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:
> How about I sync updated_at and created_at in my patch, and leave the
> finish to the other BP, by this way, I can use updated_at for the
> timestamp filter I added and it don't need to change again once the
> finish BP is complete.

 Sounds good to me.

>>>
>>> It's been a long day so my memory might be fried, but the options we
>>> talked about in the API meeting were:
>>>
>>> 1. Setting updated_at = created_at when the instance action record is
>>> created. Laski likes this, I'm not crazy about it, especially since we
>>> don't do that for anything else.
>
> I would actually like for us to do this generally. I have the same
> thinking as Ed does elsewhere in this thread, the creation of a record
> is an update of that record. So take my comments as applying to Nova
> overall and not just this issue.

Agree. Also it just simplifies a number of things. We should just start
doing this going forward, and probably put some online data migrations
in place next cycle to update all the old records. Once updated_at can't
be null, we can handle things like this a bit better.


The marker should be a column with UniqueConstraint, the updated_at is
not. But if we say the accuracy is ok, there will have problem with
updated_at as None.


Yeah I thought about this later, we don't use a timestamp field as a 
marker for anything else, and as noted it's not a non-nullable unique 
field, plus it's mutable which worries me for a marker field (created_at 
wouldn't change, but updated_at could).




Anyway, we already freeze... probably we can begin to fix the updated_at
problem first.


>>> 2. Update the instance action's updated_at when instance action events
>>> are created. I like this since the instance action is like a parent
>>> resource and the event is the child, so when we create/modify an event
>>> we can consider it an update to the parent. Laski thought this might be
>>> weird UX given we don't expose instance action events in the REST API
>>> unless you're an admin. This is also probably not something we'd do for
>>> other related resources like server groups and server group members (but
>>> we don't page on those either right now).
>
> Right. My concern is just that the ordering of actions can change based
> on events happening which are not visible to the user. However thinking
> about it further we don't really allow multiple actions at once, except
> for a few special cases like delete, so this may not end up affecting
> any ordering as actions are mostly serial. I think this is a fine
> solution for the issue at hand. I just think #1 is a more general
> solution.
>
>>>
>>> 3. Order the results by updated_at,created_at so that if updated_at
>>> isn't set for older records, created_at will be used. I think we all
>>> agreed in the meeting to do this regardless of #1 or #2 above.

I kind of hate that as the order, because then the marker is going to
have to be really funny double timestamp, right?


The marker only needs to fill with the unique value. There isn't any
problem order with multiple column. Some time we need order with
mulitple column for stable order when the first order column is
without UniqueConstraint.



I guess that's the one thing I don't see in this patch is a functional
test that actually loads up instance actions and iterates through
demonstrating the pagination.

-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




__
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




--

Thanks,

Matt Riedemann


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

[openstack-dev] [tricircle] Error when running Devstack

[Luck Dog]

Hello everyone,

I am trying to run DevStack on Ubuntu 14.04 in a single VirtualBox. An
error turns up  before it successfully starts. My steps are:
1), Git clone DevStack,
2), Copy devstack/local.conf.sample to DevStack folder and rename it to
local.conf.
The  errors are as follows：
Request Failed: internal server error while processing your request.
Neutron server returns request_ids:
['req-e97f6276-8e19-408b-829a-004a31256453']
lib/neutron_plugins/services/l3:create_neutron_initial_network:203
lib/neutron_plugins/services/l3:create_neutron_initial_network:207
[ERROR] /home/sword/DevStack/functions-common:207 Failure creating
EXT_NET_ID for public

I don't know whether it is  my wrong configuration of computer or the
server error, I wish someone can help me with the problem. thanks!

Best regards,
Dongfeng
__
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] Questions about instance actions' update and finish

[Alex Xu]

2016-07-02 2:32 GMT+08:00 Sean Dague :

> On 06/30/2016 08:31 AM, Andrew Laski wrote:
> >
> >
> > On Wed, Jun 29, 2016, at 11:11 PM, Matt Riedemann wrote:
> >> On 6/29/2016 10:10 PM, Matt Riedemann wrote:
> >>> On 6/29/2016 6:40 AM, Andrew Laski wrote:
> 
> 
> 
>  On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:
> > How about I sync updated_at and created_at in my patch, and leave the
> > finish to the other BP, by this way, I can use updated_at for the
> > timestamp filter I added and it don't need to change again once the
> > finish BP is complete.
> 
>  Sounds good to me.
> 
> >>>
> >>> It's been a long day so my memory might be fried, but the options we
> >>> talked about in the API meeting were:
> >>>
> >>> 1. Setting updated_at = created_at when the instance action record is
> >>> created. Laski likes this, I'm not crazy about it, especially since we
> >>> don't do that for anything else.
> >
> > I would actually like for us to do this generally. I have the same
> > thinking as Ed does elsewhere in this thread, the creation of a record
> > is an update of that record. So take my comments as applying to Nova
> > overall and not just this issue.
>
> Agree. Also it just simplifies a number of things. We should just start
> doing this going forward, and probably put some online data migrations
> in place next cycle to update all the old records. Once updated_at can't
> be null, we can handle things like this a bit better.
>

The marker should be a column with UniqueConstraint, the updated_at is not.
But if we say the accuracy is ok, there will have problem with updated_at
as None.

Anyway, we already freeze... probably we can begin to fix the updated_at
problem first.


> >>> 2. Update the instance action's updated_at when instance action events
> >>> are created. I like this since the instance action is like a parent
> >>> resource and the event is the child, so when we create/modify an event
> >>> we can consider it an update to the parent. Laski thought this might be
> >>> weird UX given we don't expose instance action events in the REST API
> >>> unless you're an admin. This is also probably not something we'd do for
> >>> other related resources like server groups and server group members
> (but
> >>> we don't page on those either right now).
> >
> > Right. My concern is just that the ordering of actions can change based
> > on events happening which are not visible to the user. However thinking
> > about it further we don't really allow multiple actions at once, except
> > for a few special cases like delete, so this may not end up affecting
> > any ordering as actions are mostly serial. I think this is a fine
> > solution for the issue at hand. I just think #1 is a more general
> > solution.
> >
> >>>
> >>> 3. Order the results by updated_at,created_at so that if updated_at
> >>> isn't set for older records, created_at will be used. I think we all
> >>> agreed in the meeting to do this regardless of #1 or #2 above.
>
> I kind of hate that as the order, because then the marker is going to
> have to be really funny double timestamp, right?
>

The marker only needs to fill with the unique value. There isn't any
problem order with multiple column. Some time we need order with mulitple
column for stable order when the first order column is
without UniqueConstraint.


>
> I guess that's the one thing I don't see in this patch is a functional
> test that actually loads up instance actions and iterates through
> demonstrating the pagination.
>
> -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
>
__
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] [octavia][upgrades] upgrade loadbalancer to new amphora image

[Lingxian Kong]

Hi guys, in case you are interested, here is a script that will do the
amphora upgrade automatically (ok, it's not totally automatic, need
two inputs).

https://github.com/LingxianKong/octavia-stuff/blob/master/utils/octavia-upgrade-vms.py

Regards!
---
Lingxian Kong


On Fri, Jul 1, 2016 at 4:53 AM, Doug Wiegley
 wrote:
>
>> On Jun 30, 2016, at 7:15 AM, Ihar Hrachyshka  wrote:
>>
>>>
>>> On 30 Jun 2016, at 01:16, Brandon Logan  wrote:
>>>
>>> Hi Ihar, thanks for starting this discussion.  Comments in-line.
>>>
>>> After writing my comments in line, I might now realize that you're just
>>> talking about documenting  a way for a user to do this, and not have
>>> Octavia handle it at all.  If that's the case I apologize for my reading
>>> comprehension, but I'll keep my comments in case I'm wrong.  My brain is
>>> not working well today, sorry :(
>>
>> Right. All the mechanisms needed to apply the approach are already in place 
>> in both Octavia and Neutron as of Mitaka. The question is mostly about 
>> whether the team behind the project may endorse the alternative approach in 
>> addition to whatever is in the implementation in regards to failovers by 
>> giving space to describe it in the official docs. I don’t suggest that the 
>> approach is the sole documented, or that octavia team need to implement 
>> anything. [That said, it may be wise to look at providing some smart scripts 
>> on top of neutron/octavia API that would realize the approach without 
>> putting the burden of multiple API calls onto users.]
>
> I don’t have a problem documenting it, but I also wouldn’t personally want to 
> recommend it.
>
> We’re adding a layer of NAT, which has performance and HA implications of its 
> own.
>
> We’re adding FIPs, when the neutron advice for “simple nova-net like 
> deployment” is provider nets and linuxbridge, which don’t support them.
>
> Thanks,
> doug
>
>
>>
>>>
>>> Thanks,
>>> Brandon
>>>
>>> On Wed, 2016-06-29 at 18:14 +0200, Ihar Hrachyshka wrote:
 Hi all,

 I was looking lately at upgrades for octavia images. This includes using 
 new images for new loadbalancers, as well as for existing balancers.

 For the first problem, the amp_image_tag option that I added in Mitaka 
 seems to do the job: all new balancers are created with the latest image 
 that is tagged properly.

 As for balancers that already exist, the only way to get them use a new 
 image is to trigger an instance failure, that should rebuild failed nova 
 instance, using the new image. AFAIU the failover process is not currently 
 automated, requiring from the user to set the corresponding port to DOWN 
 and waiting for failover to be detected. I’ve heard there are plans to 
 introduce a specific command to trigger a quick-failover, that would 
 streamline the process and reduce the time needed for the process because 
 the failover would be immediately detected and processed instead of 
 waiting for keepalived failure mode to occur. Is it on the horizon? 
 Patches to review?
>>>
>>> Not that I know of and with all the work slated for Newton, I'm 99% sure
>>> it won't be done in Newton.  Perhaps Ocata.
>>
>> I see. Do we maybe want to provide a smart script that would help to trigger 
>> a failover with neutron API? [detect the port id, set it to DOWN, …]
>>

 While the approach seems rather promising and may be applicable for some 
 environments, I have several concerns about the failover approach that we 
 may want to address.

 1. HA assumption. The approach assumes there is another node running 
 available to serve requests while instance is rebuilding. For non-HA 
 amphoras, it’s not the case, meaning the image upgrade process has a 
 significant downtime.

 2. Even if we have HA, for the time of instance rebuilding, the balancer 
 cluster is degraded to a single node.

 3. (minor) during the upgrade phase, instances that belong to the same HA 
 amphora may run different versions of the image.

 What’s the alternative?

 One idea I was running with for some time is moving the upgrade complexity 
 one level up. Instead of making Octavia aware of upgrade intricacies, 
 allow it to do its job (load balance), while use neutron floating IP 
 resource to flip a switch from an old image to a new one. Let me elaborate.
>>> I'm not sure I like the idea of tying this to floating IP as there are
>>> deployers who do not use floating IPs.  Then again, we are currently
>>> depending on allowed address pairs which is also an extension, but I
>>> suspect its probably deployed in more places.  I have no proof of this
>>> though.
>>
>> I guess you already deduced that, but just for the sake of completeness: no, 
>> I don’t suggest that octavia ties its backend to FIPs. 

Re: [openstack-dev] [openstack-infra] [vitrage] branch marking policy

[Andreas Jaeger]

On 07/03/2016 09:23 AM, Elisha (Nokia - IL) Rosensweig wrote:
> Hi,
> 
>  
> 
> I tried to push "stable/liberty" as described in the link you sent (the
> command from my environment: "git branch stable/liberty HEAD && git push
> gerrit stable/liberty"), but I get:
> 
>  
> 
> *"! [remote rejected] stable/liberty -> stable/liberty (prohibited by
> Gerrit)"*
> 
> * *
> 
> Is there a problem to retroactively mark liberty branches?

It's an ACL problem.

Only members of the vitrage-release group can create branches, ask
somebody in that group to do it for you.

this is a general policy: We have small release teams that create
branches and tags for each project. Those are small since once you
pushed your tag/branch to gerrit, you cannot change it easily...


Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: 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

Re: [openstack-dev] [openstack-infra] [vitrage] branch marking policy

[Rosensweig, Elisha (Nokia - IL)]

Hi,

I tried to push "stable/liberty" as described in the link you sent (the command 
from my environment: "git branch stable/liberty HEAD && git push gerrit 
stable/liberty"), but I get:

"! [remote rejected] stable/liberty -> stable/liberty (prohibited by Gerrit)"

Is there a problem to retroactively mark liberty branches?

Elisha


From: Rosensweig, Elisha (Nokia - IL)
Sent: Thursday, June 30, 2016 3:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [openstack-infra] [vitrage] branch marking policy

Thanks! From a brief look, this seems exactly what we need.

Elisha

From: Joshua Hesketh [mailto:joshua.hesk...@gmail.com]
Sent: Thursday, June 30, 2016 3:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack-infra] [vitrage] branch marking policy

Hey Elisha,

Have you looked at http://docs.openstack.org/infra/manual/drivers.html ?

Cheers,
Josh

On Thu, Jun 30, 2016 at 9:16 PM, Rosensweig, Elisha (Nokia - IL) 
> wrote:
Hi,

We've prepared a (local) branch with Vitrage that is *Liberty-compatible*, and 
would like to mark (tag?) the branch.

What is the standard way to do this?

Thanks,

Elisha Rosensweig, Ph.D.
R Director
CloudBand, Nokia
T: +972 9793 3159


__
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