Re: [openstack-dev] [Horizon] Blueprints for Outreachy internship

[Matthias Runge]

On 26/02/16 10:36, Sayali Lunkad wrote:
> Hello,
> 
> I am looking for some blueprints in horizon that can be set aside for
> the Outreachy Internship
> program. If anyone has any
> blueprints in mind which are not needed anytime soon as well as not so
> difficult to implement please let me know so we can include these as
> tasks for the interns.
> These blueprints will be worked on around May - August, 2016.
> 
> Regards,
> Sayali.
> 

Hello Sayali,

there are a few blueprints in Horizon, which would fit into that area,
just to name a few (not limited to)

* https://blueprints.launchpad.net/horizon/+spec/per-user-limit-summary
* https://blueprints.launchpad.net/horizon/+spec/context-sensitive-help
*
https://blueprints.launchpad.net/horizon/+spec/download-images-and-snapshots

In general, https://blueprints.launchpad.net/horizon
gives a HUGE list of ideas. For specific questions, a interested person
should try to understand a blueprint and should either send a mail here,
should stop by  at #openstack-horizon or send me a mail.

Matthias

__
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-Dev][Manila] BP https://blueprints.launchpad.net/manila/+spec/access-groups

[Koderer, Marc]

Hi  Nidhi,

It’s might also a good idea to have a short discussion during the manila 
meeting [1].
You can simply add your topic to the agenda.

Regards
Marc

[1]: https://wiki.openstack.org/wiki/Manila/Meetings 


> On 26 Feb 2016, at 10:52, nidhi.h...@wipro.com wrote:
> 
> Hi Manila Team,
>  
> I am working on
> https://blueprints.launchpad.net/manila/+spec/access-groups 
> 
>  
> For this I have created initial document as attached with the mail.
> It contains DB CLI REST API related changes.
>  
> Could you please have a look and share your opinion.
>  
> Kindly let me know, if there is some understanding gap, 
> or something I have missed to document or 
> share your comments in general to make it better.
>  
> Thank you.
> Nidhi Mittal Hada
> Architect | PES / COE – Kolkata India
> Wipro Limited
> M +91 74 3910 9883 | O +91 33 3095 4767 | VOIP +91 33 3095 4767
>  
>  
>  
> The information contained in this electronic message and any attachments to 
> this message are intended for the exclusive use of the addressee(s) and may 
> contain proprietary, confidential or privileged information. If you are not 
> the intended recipient, you should not disseminate, distribute or copy this 
> e-mail. Please notify the sender immediately and destroy all copies of this 
> message and any attachments. WARNING: Computer viruses can be transmitted via 
> email. The recipient should check this email and any attachments for the 
> presence of viruses. The company accepts no liability for any damage caused 
> by any virus transmitted by this email. www.wipro.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 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] unblocking the gate

[Andreas Jaeger]

On 2016-02-29 06:59, Steven Dake (stdake) wrote:
> Hey folks,
> 
> It should be obvious that commiters should be testing their changes, but
> unfortunately this is not always the case.  With the recent state of the
> gate relating to the introduction of Docker 1.10.z breaking the gate
>  for 1 week followed by a keystone change upstream breaking the gate for
> one week, I'd like to make certain the gate stays green.  
> 
> Jeffrey Zhang resolved the gate with [1].  I'd ask that everyone that
> has a patch in the queue rebase on master and resubmit their changes.

This is not needed, the CI system always rebases if you run tests. To
get current tests, a simple "recheck" is enough.

Also, we test in the gate before merging - again after rebasing to head.
That should take care of not merging anything broken. Running recheck
after a larger change will ensure that you have recent results.

>  The result of that should be a green gate.  If you already have votes
> on your patches and they are rebased, I believe gerrit will leave the
> vote intact.  If not, the core reviewers who reviewed your patch
> originally will be happy to ack a simple rebase on master.
> 
> For core reviewers:
> Please do not approve patches that do not pass the gate.  If the gate is
> broken, our priority should be on fixing the gate.  Please wait for
> workflows until the gate is green or a recheck has produced a green
> gate.  I realize our gate isn't perfect, but if its half-red it doesn't
> give developers a good sense of confidence their patch is correct (or
> not correct).  What ends up happening in that scenario is core reviewers
> end up having to pull down every change to personally test it.  We have
> a lot of work queued up, and the gate should provide some level of
> confidence that the change doesn't break things, especially with the
> recent addition of the dead-chicken testing nova boot operation.
> 
> When it comes to multinode, we will have to do manual testing, but I'd
> prefer to sort out any breakages during the RCs since manual testing
> won't necessarily test the same merge order as the core reviewers are
> using to manually test multinode.

Andreas

> Thanks in advance!
> -steve
> 
> [1] https://review.openstack.org/#/c/285625
> 
> 
> __
> 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
> 


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

Re: [openstack-dev] [fuel] Fuel plugins: lets have some rules

[Andreas Jaeger]

On 2016-02-27 00:54, Dmitry Borodaenko wrote:
> On Thu, Feb 25, 2016 at 08:31:26AM +0100, Andreas Jaeger wrote:
>> On 2016-02-03 03:27, Dmitry Borodaenko wrote:
>>> [...]
>>> Level 1. Plugin is actively supported by Fuel team
>>>
>>> As we expand plugin capabilities and move more functionality from Fuel
>>> core into plugins, we will inevitably get to the point where some
>>> plugins are required to successfully complete even a basic deployment
>>> (aka "pass BVT"). Even before that, we may decide that some plugins are
>>> important enough for our reference architecture to allow the state of
>>> these plugins to affect our release cycle: allow Critical bugs in them
>>> to affect Fuel release, cover them in acceptance testing for Fuel
>>> releases and maintenance updates, and so on.
>>
>>
>>> Obviously, whole Fuel team is expected to support such plugins, and is
>>> self-motivated to provide timely help to their maintainers to keep them
>>> healthy. In addition to the expectations from the previous support
>>> level, we should track the list of these release-critical plugins in the
>>> policy section of fuel-specs [7].
>>
>> So, these are plugins that will be officially part of fuel team? You
>> depend on it for successful installation...
> 
> Yes, they will officially become a part of Fuel project. First such
> example is likely to be the Murano plugin [0], so we can use it a the
> guinea pig to try out this process.
> 
> [0] https://review.openstack.org/269567
> 
> As described in the corresponding spec [1], we plan this plugin to
> co-exist with the current non-plugin implementation for Mitaka, and then
> let the legacy non-plugin implementation be superceded by
> fuel-plugin-murano as soon as the latter reaches maturity (hopefully
> early in Newton cycle).
> 
> [1] https://review.openstack.org/275124

Why is the corresponding spec not mentioned as part of the infra change?

> 
> Since this is not a straight-forward moving of existing code into its
> own git repo (like we've recently done for fuel-virtualbox and fuel-ui),
> I think it's too early to register the new plugin repo in
> openstack/governance, but eventually (as soon as it's ready to become
> the default way to deploy Murano with Fuel) we should add it there.

That's not a reason under the big tent to not add it to the governance
documentation. There's no need to incubate it outside the tree.

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

[Shubham Keyal]

hey all,

can i use this plugin( LMA ) without installing fuel. i mean can i install
it independently. if yes, then how?.

Shubham Keyal
Software Engineer - I
*M*: +91 9003529711,
2nd FLOOR, WEST WING,
SALARPURIA SUPREME, MARATHAHALLI, BENGALURU
Download Our App
[image: A]

[image:
A]

[image:
W]

__
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] audience for release notes

[Thomas Goirand]

On 02/28/2016 11:26 PM, Doug Hellmann wrote:
> The plan is to build setuptools integration into reno so that when
> we build our sdists they include a cache file of the data that reno
> derives from the git history, so that without git present reno can
> use the cache file instead of the git history.

Do you remember we don't use sdist tarballs in Debian, but generate our
own from "git archive"? I don't want to change this workflow, especially
that we plan to build packages from git trunk, meaning we'll need to
build on each commit. So please don't design your fix around using sdist
tarballs, which by the way, add a lot of metadata which aren't desirable.

Cheers,

Thomas Goirand (zigo)


__
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] audience for release notes

[Thomas Goirand]

Hi Doug,

Thanks for your reply, it's much appreciated!

On 02/28/2016 11:40 PM, Doug Hellmann wrote:
> Excerpts from Thomas Goirand's message of 2016-02-28 22:56:51 +0800:
>>> I believe Thomas is referring to:
>>>
>>> https://bugs.launchpad.net/reno/+bug/1520096
>>
>> The funny part about this bug is that it was opened against Reno, which
>> by design, is doing things wrongly. Then the issue was kind of turned
> 
> Please try to remember that your use case is not the only use case we
> have.

I get that. Though such a tool should be designed so that it meets the
requirements of everyone. That's not the case yet for downstream
distributions at least.

> Reno was designed to meet a very specific set of criteria and
> requirements to solve a problem the release team identified. Building
> release notes documents without git history has been on the list of
> requirements for quite some time, we just haven't gotten to it yet.

The point which I was trying to do, is that until this is fixed, Reno
shouldn't be used yet.

> I've outlined the approach we have planned in my other email so
> I won't repeat it here.

Oh, it looks like I missed it. What was the subject?

>> It is still my view that projects should revert using Reno asap until
>> the issue is fixed in Reno. Sure, I could potentially open a bug for
>> each and every package which has the issue, but IMO that's not the way
>> to go.
> 
> Projects should not use reno in their developer documentation.

The thing is, they do, and I don't see it changed just by writing
"please don't do this" in a thread like this one. I wish to be proven
wrong though.

On 02/28/2016 11:48 PM, Doug Hellmann wrote:
> This may not have been widely implemented, so where you're
> encountering issues please file bugs. It's relatively simple to fix
> the projects for this cycle, in case we don't get the git-free
> scanner for reno implemented this cycle.

I'll make sure to file bugs as I see it happening, yes. Though it will
probably be too late to avoid what I'm expecting (ie: the time of
downstream distro package maintainers will be already wasted, and b3
will already be released).

>> By the way, Reno itself is doing so many gpg keys that the system
>> building it can't have enough entropy, and then the unit tests are
>> timing-out. Is there a way to fix this?
> 
> Give this a try and see if it works any better:
> https://review.openstack.org/285812

Oh, thanks so much! I'll try and give feedback on review.d.o. Is the
issue around the (missed) use of --debug-quick-random?

Why do we need Reno unit tests to generate so many GPG keys btw, why not
just one or 2?

Cheers,

Thomas Goirand (zigo)


__
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] playing tricircle with devstack under two-region configuration

[时鹏飞]

And, I find ew_bridge has a gateway:

root@node1:/home/stack# neutron subnet-show 34405fae-e796-48ae-a6e7-f7943b84a117
+---+---+
| Field | Value |
+---+---+
| allocation_pools  | {"start": "100.0.0.2", "end": "100.0.0.254"}  |
| cidr  | 100.0.0.0/24  |
| dns_nameservers   |   |
| enable_dhcp   | False |
| gateway_ip| 100.0.0.1 |
| host_routes   |   |
| id| 34405fae-e796-48ae-a6e7-f7943b84a117  |
| ip_version| 4 |
| ipv6_address_mode |   |
| ipv6_ra_mode  |   |
| name  | ew_bridge_subnet_f55068b6dcfd4b4d9d357b46eedc6644 |
| network_id| 0828b209-71a0-481e-9e2c-5c68d2b18387  |
| subnetpool_id | f7360e3b-f74c-474f-9ee5-e43657dd077f  |
| tenant_id | f55068b6dcfd4b4d9d357b46eedc6644  |
+---+---+

but in the port there is no device for gateway 100.0.0.1

root@node1:/home/stack# neutron port-list
+--+--+---+--+
| id   | name | 
mac_address   | fixed_ips|
+--+--+---+--+
| 5ff4f7c4-5e47-4cc5-8a17-e011938bd930 | 5ff4f7c4-5e47-4cc5-8a17-e011938bd930 | 
fa:16:3e:d0:1e:8e | {"subnet_id": "aeb34101-0e0f-402c-94a4-e4d45235d531",|
|  |  | 
  | "ip_address": "10.0.2.3"}|
| 4f2fb455-8cc5-43ea-87cd-4d4d845548a0 | 4f2fb455-8cc5-43ea-87cd-4d4d845548a0 | 
fa:16:3e:ed:d2:49 | {"subnet_id": "aeb34101-0e0f-402c-94a4-e4d45235d531",|
|  |  | 
  | "ip_address": "10.0.2.1"}|
| 67e16de6-ad02-4e5f-b035-6525a5a6dcc4 |  | 
fa:16:3e:c6:07:65 | {"subnet_id": "aeb34101-0e0f-402c-94a4-e4d45235d531",|
|  |  | 
  | "ip_address": "10.0.2.2"}|
| 15cc5862-443f-44a0-a060-33a66b0686cc | 15cc5862-443f-44a0-a060-33a66b0686cc | 
fa:16:3e:b9:2c:14 | {"subnet_id": "34405fae-e796-48ae-a6e7-f7943b84a117",|
|  |  | 
  | "ip_address": "100.0.0.3"}   |
| 5367f76e-6a00-478d-b9b8-54d0b4754da7 | 5367f76e-6a00-478d-b9b8-54d0b4754da7 | 
fa:16:3e:01:70:36 | {"subnet_id": "34405fae-e796-48ae-a6e7-f7943b84a117",|
|  |  | 
  | "ip_address": "100.0.0.2"}   |
| 1be92584-a800-474f-a105-877e8a30875f | 1be92584-a800-474f-a105-877e8a30875f | 
fa:16:3e:5d:0d:59 | {"subnet_id": "6a1cafcd-6bc7-4788-8a38-b26616dd43a4",|
|  |  | 
  | "ip_address": "10.0.1.3"}|
| fda27c48-ce7c-4852-b9f6-4af7da2d0b3d | fda27c48-ce7c-4852-b9f6-4af7da2d0b3d | 
fa:16:3e:26:f3:40 | {"subnet_id": "6a1cafcd-6bc7-4788-8a38-b26616dd43a4",|
|  |  | 
  | "ip_address": "10.0.1.1"}|
| 7b51933e-edb4-4210-9df4-e346fe99fded |  | 
fa:16:3e:8f:d7:ad | {"subnet_id": "6a1cafcd-6bc7-4788-8a38-b26616dd43a4",|
|  |  | 
  | "ip_address": "10.0.1.2"}|
| 4b5a8392-abfc-4261-b98f-e39e377991a7 |  | 
fa:16:3e:ae:bc:4d | "

Re: [openstack-dev] [kolla] unblocking the gate

[Steven Dake (stdake)]

The gate is still blocked apparently by yet another gate-breaking regression.  
That regression is resolved in this change set:
https://review.openstack.org/#/c/285875/

Please rebase once that hits green and hits the repository.

From: Steven Dake >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Sunday, February 28, 2016 at 10:59 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla] unblocking the gate

Hey folks,

It should be obvious that commiters should be testing their changes, but 
unfortunately this is not always the case.  With the recent state of the gate 
relating to the introduction of Docker 1.10.z breaking the gate  for 1 week 
followed by a keystone change upstream breaking the gate for one week, I'd like 
to make certain the gate stays green.

Jeffrey Zhang resolved the gate with [1].  I'd ask that everyone that has a 
patch in the queue rebase on master and resubmit their changes.  The result of 
that should be a green gate.  If you already have votes on your patches and 
they are rebased, I believe gerrit will leave the vote intact.  If not, the 
core reviewers who reviewed your patch originally will be happy to ack a simple 
rebase on master.

For core reviewers:
Please do not approve patches that do not pass the gate.  If the gate is 
broken, our priority should be on fixing the gate.  Please wait for workflows 
until the gate is green or a recheck has produced a green gate.  I realize our 
gate isn't perfect, but if its half-red it doesn't give developers a good sense 
of confidence their patch is correct (or not correct).  What ends up happening 
in that scenario is core reviewers end up having to pull down every change to 
personally test it.  We have a lot of work queued up, and the gate should 
provide some level of confidence that the change doesn't break things, 
especially with the recent addition of the dead-chicken testing nova boot 
operation.

When it comes to multinode, we will have to do manual testing, but I'd prefer 
to sort out any breakages during the RCs since manual testing won't necessarily 
test the same merge order as the core reviewers are using to manually test 
multinode.

Thanks in advance!
-steve

[1] https://review.openstack.org/#/c/285625
__
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] unblocking the gate

[Steven Dake (stdake)]

Hey folks,

It should be obvious that commiters should be testing their changes, but 
unfortunately this is not always the case.  With the recent state of the gate 
relating to the introduction of Docker 1.10.z breaking the gate  for 1 week 
followed by a keystone change upstream breaking the gate for one week, I'd like 
to make certain the gate stays green.

Jeffrey Zhang resolved the gate with [1].  I'd ask that everyone that has a 
patch in the queue rebase on master and resubmit their changes.  The result of 
that should be a green gate.  If you already have votes on your patches and 
they are rebased, I believe gerrit will leave the vote intact.  If not, the 
core reviewers who reviewed your patch originally will be happy to ack a simple 
rebase on master.

For core reviewers:
Please do not approve patches that do not pass the gate.  If the gate is 
broken, our priority should be on fixing the gate.  Please wait for workflows 
until the gate is green or a recheck has produced a green gate.  I realize our 
gate isn't perfect, but if its half-red it doesn't give developers a good sense 
of confidence their patch is correct (or not correct).  What ends up happening 
in that scenario is core reviewers end up having to pull down every change to 
personally test it.  We have a lot of work queued up, and the gate should 
provide some level of confidence that the change doesn't break things, 
especially with the recent addition of the dead-chicken testing nova boot 
operation.

When it comes to multinode, we will have to do manual testing, but I'd prefer 
to sort out any breakages during the RCs since manual testing won't necessarily 
test the same merge order as the core reviewers are using to manually test 
multinode.

Thanks in advance!
-steve

[1] https://review.openstack.org/#/c/285625
__
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] Testing of angular promise based code paths

[Richard Jones]

Hi all,

I've just added a comment to a review and I think I'd like to ask for a
broader discussion of whether I'm correct.

The review is here: https://review.openstack.org/#/c/284857/2

It boils down to: when testing code that uses a promise, should we *use* a
promise to have the follow-on callback invoked, or should we mock/spy and
then manually perform the same action the promise would if resolved?

The two forms are, broadly, pretending that a promise fired:

  it('successful submit calls the successCallback', function() {
*var successFunc = {success: angular.noop};*
*spyOn(successFunc, 'success');*
spyOn(nova, 'createKeypair')*.and.returnValue(successFunc);*
spyOn(toastService, 'add').and.returnValue({ add: angular.noop });
ctrl.submit();
*var successCallback = successFunc.success.calls.argsFor(0)[0];*
*var data = {name: 'newKeypair'};*
*successCallback(data);*
expect(toastService.add).toHaveBeenCalledWith(
'success',
'Successfully imported key pair newKeypair.'
);
  });

or actually using a promise and making it fire:

it('should load container contents', function test() {
  *var deferred = $q.defer();*
  spyOn(swiftAPI, 'getObjects')*.and.returnValue(deferred.promise);*
  service.selectContainer('spam');
  expect(service.containerName).toEqual('spam');
  expect(swiftAPI.getObjects).toHaveBeenCalledWith('spam', {delimiter:
'/'});
  *deferred.resolve({data: {items: ['two', 'items']}});*
  *$rootScope.$apply();*
  expect(service.objects).toEqual(['two', 'items']);
  expect(service.pseudo_folder_hierarchy).toEqual([]);
});


 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] Mitaka, Xenial, OVS Firewall Driver, DPDK, VXLAN and Provider Networks

[Kevin Benton]

We aren't too far off from being able to support this now. The agent-based
ML2 drivers already bind based on a combination of VNIC type and the host
so multiple agents with different types can run on the same host.

I think the only part that is missing is each driver being able to inform
Nova which bridge to plug into.
On Feb 28, 2016 7:48 PM, "Assaf Muller"  wrote:

> On Sat, Feb 27, 2016 at 6:55 PM, Martinx - ジェームズ
>  wrote:
> > Hey guys!
> >
> >  Next Ubuntu and Mitaka are promising something ultra mega cool!
> >
> >  Look at this!
> >
> > ---
> > root@mitaka-1:~# apt install neutron-openvswitch-agent
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > The following additional packages will be installed:
> >   dpdk libdpdk0 openvswitch-common openvswitch-switch
> > ---
> >
> >  Xenial will brings DPDK-2.2 fully supported for 5 years!
> >
> >  However, I am curious about the following scenarios:
> >
> >  Will be possible to use, at the same time (same Network and Compute
> nodes /
> > Host Aggregate):
> >
> >  1- Regular OVS bridges without DPDK for VXLAN Networks, with
> > OVS-Firewall-Driver and;
> >
> >  2- OVS powered by DPDK for Provider Networks only ( without any
> firewall,
> > current case anyway, due to
> > https://bugs.launchpad.net/neutron/+bug/1531205).
>
> Currently, a host may run a single OVS agent, configured for either
> regular OVS or OVS-DPDK. You cannot run both on a single host. You can
> mix and match between different hosts though. It is something we
> discussed a bit, but no concrete plans to change this at this time.
>
> We could support this by allowing an OVS agent to support two
> datapaths simultaneously by configuring two integration bridges, each
> with its own type. We would add a DPDK VNIC type so Nova would plug
> the VNIC to the correct bridge. Each integration bridge would have its
> own bridge mappings (The kernel datapath integration bridge would be
> connected to br-tun or to a VLAN bridge, and the DPDK datapath
> integration bridge would be connected to its own set of VLAN provider
> bridges. Another way to accomplish this use case is to start two OVS
> agents on the same host, each configured appropriately, but we'd need
> to make changes to ML2 to support this, perhaps differentiate between
> the two agents via an agent_type and bind ports appropriately. Again,
> we'd need a new VNIC type for DPDK ports.
>
> >
> > ?
> >
> >  I have NFV Instances that are also, DPDK L2 Bridges running on KVM
> Guest /
> > VirtIO, that are physically wired using Provider Networks (flat and
> vlans).
> >
> >  So, for the Instance's vNICs (eth1 and eth2) that are used as a L2
> bridge,
> > I don't want any kind of ovs-firewall (I'm not affected by LP #1531205 on
> > this case) and I want OVS+DPDK under it but, for SSH into the Instance to
> > manage it (via its eth0), it is still using regular VXLAN with Security
> > Groups - OVS-Firewall from now on (no need for DPDK under eth0 / VXLAN).
> >
> >  I'm curious about this specially because the OVS Ubuntu package, makes
> use
> > of Debian's Alternatives subsystem, and we need to choose one OVS
> (default),
> > or another (with DPDK), via "update-alternatives", so, will be possible
> to
> > select OVS with DPDK but, use regular bridges with it as well (for VXLAN
> > networks)?
> >
> >  If yes, how to create a VXLAN network with regular OVS and another
> > FLAT/VLAN network with OVS+DPDK ?
> >
> >  Thanks in advance!
> >
> > Best,
> > Thiago
> >
> >
> __
> > 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

[openstack-dev] [nova-scheduler] Scheduler sub-group meeting - Agenda 2/29

[Dugger, Donald D]

Meeting on #openstack-meeting-alt at 1400 UTC (7:00AM MDT)



1) Patches/Reviews - 
https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking

2) Bugs - https://bugs.launchpad.net/nova/+bugs?field.tag=scheduler

3) Opens

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

__
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] Mitaka, Xenial, OVS Firewall Driver, DPDK, VXLAN and Provider Networks

[Assaf Muller]

On Sat, Feb 27, 2016 at 6:55 PM, Martinx - ジェームズ
 wrote:
> Hey guys!
>
>  Next Ubuntu and Mitaka are promising something ultra mega cool!
>
>  Look at this!
>
> ---
> root@mitaka-1:~# apt install neutron-openvswitch-agent
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
>   dpdk libdpdk0 openvswitch-common openvswitch-switch
> ---
>
>  Xenial will brings DPDK-2.2 fully supported for 5 years!
>
>  However, I am curious about the following scenarios:
>
>  Will be possible to use, at the same time (same Network and Compute nodes /
> Host Aggregate):
>
>  1- Regular OVS bridges without DPDK for VXLAN Networks, with
> OVS-Firewall-Driver and;
>
>  2- OVS powered by DPDK for Provider Networks only ( without any firewall,
> current case anyway, due to
> https://bugs.launchpad.net/neutron/+bug/1531205).

Currently, a host may run a single OVS agent, configured for either
regular OVS or OVS-DPDK. You cannot run both on a single host. You can
mix and match between different hosts though. It is something we
discussed a bit, but no concrete plans to change this at this time.

We could support this by allowing an OVS agent to support two
datapaths simultaneously by configuring two integration bridges, each
with its own type. We would add a DPDK VNIC type so Nova would plug
the VNIC to the correct bridge. Each integration bridge would have its
own bridge mappings (The kernel datapath integration bridge would be
connected to br-tun or to a VLAN bridge, and the DPDK datapath
integration bridge would be connected to its own set of VLAN provider
bridges. Another way to accomplish this use case is to start two OVS
agents on the same host, each configured appropriately, but we'd need
to make changes to ML2 to support this, perhaps differentiate between
the two agents via an agent_type and bind ports appropriately. Again,
we'd need a new VNIC type for DPDK ports.

>
> ?
>
>  I have NFV Instances that are also, DPDK L2 Bridges running on KVM Guest /
> VirtIO, that are physically wired using Provider Networks (flat and vlans).
>
>  So, for the Instance's vNICs (eth1 and eth2) that are used as a L2 bridge,
> I don't want any kind of ovs-firewall (I'm not affected by LP #1531205 on
> this case) and I want OVS+DPDK under it but, for SSH into the Instance to
> manage it (via its eth0), it is still using regular VXLAN with Security
> Groups - OVS-Firewall from now on (no need for DPDK under eth0 / VXLAN).
>
>  I'm curious about this specially because the OVS Ubuntu package, makes use
> of Debian's Alternatives subsystem, and we need to choose one OVS (default),
> or another (with DPDK), via "update-alternatives", so, will be possible to
> select OVS with DPDK but, use regular bridges with it as well (for VXLAN
> networks)?
>
>  If yes, how to create a VXLAN network with regular OVS and another
> FLAT/VLAN network with OVS+DPDK ?
>
>  Thanks in advance!
>
> Best,
> Thiago
>
> __
> 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] playing tricircle with devstack under two-region configuration

[时鹏飞]

Hi, Yipei

you should 

export OS_REGION_NAME=RegionOne

which is the name of your top openstack region.

Best Regards

Pengfei Shi (时鹏飞)
Shanghai Jiao Tong University
Network & Information Center Room 304

shipengfe...@gmail.com






> On Feb 29, 2016, at 10:02 AM, Yipei Niu  wrote:
> 
> Hi Pengfei,
> 
> I also encounter the same error when installing devstack on node2. I insert a 
> command "export OS_REGION_NAME=Pod2" in line 1262 in stack.sh and it works. 
> However, I am not sure whether it is correct. I am trying to verify it. 
> Recently, I try to re-install devstack on node1, but I encounter some errors. 
> The link is http://paste.openstack.org/show/488005/ 
> . Do you have any suggestion about 
> it?
> 
> To Joe and Zhiyuan, could you please give me some advice about how to solve 
> it?
> 
> Best regards,
> Yipei
> 
> On Wed, Feb 24, 2016 at 9:29 AM, Yipei Niu  > wrote:
> Hi Joe and Zhiyuan,
> 
> My VM has recovered. When I re-install devstack in node1, I encounter the 
> following errors.
> 
> The info in stack.sh.log is as follows:
> 
> 2016-02-23 11:18:27.238 | Error: Service n-sch is not running
> 2016-02-23 11:18:27.238 | + 
> /home/stack/devstack/functions-common:service_check:L1625:   '[' -n 
> /opt/stack/status/stack/n-sch.failure ']'
> 2016-02-23 11:18:27.238 | + 
> /home/stack/devstack/functions-common:service_check:L1626:   die 1626 'More 
> details about the above errors can be found with screen, with 
> ./rejoin-stack.sh'
> 2016-02-23 11:18:27.238 | + /home/stack/devstack/functions-common:die:L186:   
> local exitcode=0
> 2016-02-23 11:18:27.239 | [Call Trace]
> 2016-02-23 11:18:27.239 | ./stack.sh:1354:service_check
> 2016-02-23 11:18:27.239 | /home/stack/devstack/functions-common:1626:die
> 2016-02-23 11:18:27.261 | [ERROR] /home/stack/devstack/functions-common:1626 
> More details about the above errors can be found with screen, with 
> ./rejoin-stack.sh
> 2016-02-23 11:18:28.271 | Error on exit
> 2016-02-23 11:18:28.953 | df: '/run/user/112/gvfs': Permission denied
> 
> The info in n-sch.log is as follows:
> 
> stack@nyp-VirtualBox:~/devstack$ /usr/local/bin/nova-scheduler --config-file 
> /et ^Mc/nova/nova.conf & echo $! >/opt/stack/status/stack/n-sch.pid; fg || 
> echo "n-sch ^M failed to start" | tee "/opt/stack/status/stack/n-sch.failure"
> [1] 29467
> /usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf
> 2016-02-23 19:13:00.050 ^[[00;32mDEBUG oslo_db.api [^[[00;36m-^[[00;32m] 
> ^[[01;35m^[[00;32mLoading backend 'sqlalchemy' from 
> 'nova.db.sqlalchemy.api'^[[00m ^[[00;33mfrom (pid=29467) _load_backend 
> /usr/local/lib/python2.7/dist-packages/oslo_db/api.py:238^[[00m
> 2016-02-23 19:13:00.300 ^[[01;33mWARNING oslo_reports.guru_meditation_report 
> [^[[00;36m-^[[01;33m] ^[[01;35m^[[01;33mGuru mediation now registers SIGUSR1 
> and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be 
> registered in a future release, so please use SIGUSR2 to generate 
> reports.^[[00m
> 2016-02-23 19:13:00.304 ^[[01;31mCRITICAL nova [^[[00;36m-^[[01;31m] 
> ^[[01;35m^[[01;31mValueError: Empty module name
> ^[[00m
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mTraceback (most 
> recent call last):
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
> "/usr/local/bin/nova-scheduler", line 10, in 
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
> sys.exit(main())
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
> "/opt/stack/nova/nova/cmd/scheduler.py", line 43, in main
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
> topic=CONF.scheduler_topic)
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
> "/opt/stack/nova/nova/service.py", line 281, in create
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
> db_allowed=db_allowed)
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
> "/opt/stack/nova/nova/service.py", line 167, in __init__
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mself.manager = 
> manager_class(host=self.host, *args, **kwargs)
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
> "/opt/stack/nova/nova/scheduler/manager.py", line 49, in __init__
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mself.driver = 
> importutils.import_object(scheduler_driver)
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 44, 
> in import_object
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mreturn 
> import_class(import_str)(*args, **kwargs)
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 30, 
> in import_class
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova 

Re: [openstack-dev] [tricircle] playing tricircle with devstack under two-region configuration

[Yipei Niu]

Hi Pengfei,

I also encounter the same error when installing devstack on node2. I insert
a command "export OS_REGION_NAME=Pod2" in line 1262 in stack.sh and it
works. However, I am not sure whether it is correct. I am trying to verify
it. Recently, I try to re-install devstack on node1, but I encounter some
errors. The link is http://paste.openstack.org/show/488005/. Do you have
any suggestion about it?

To Joe and Zhiyuan, could you please give me some advice about how to solve
it?

Best regards,
Yipei

On Wed, Feb 24, 2016 at 9:29 AM, Yipei Niu  wrote:

> Hi Joe and Zhiyuan,
>
> My VM has recovered. When I re-install devstack in node1, I encounter the
> following errors.
>
> The info in stack.sh.log is as follows:
>
> 2016-02-23 11:18:27.238 | Error: Service n-sch is not running
> 2016-02-23 11:18:27.238 | +
> /home/stack/devstack/functions-common:service_check:L1625:   '[' -n
> /opt/stack/status/stack/n-sch.failure ']'
> 2016-02-23 11:18:27.238 | +
> /home/stack/devstack/functions-common:service_check:L1626:   die 1626 'More
> details about the above errors can be found with screen, with
> ./rejoin-stack.sh'
> 2016-02-23 11:18:27.238 | +
> /home/stack/devstack/functions-common:die:L186:   local exitcode=0
> 2016-02-23 11:18:27.239 | [Call Trace]
> 2016-02-23 11:18:27.239 | ./stack.sh:1354:service_check
> 2016-02-23 11:18:27.239 | /home/stack/devstack/functions-common:1626:die
> 2016-02-23 11:18:27.261 | [ERROR]
> /home/stack/devstack/functions-common:1626 More details about the above
> errors can be found with screen, with ./rejoin-stack.sh
> 2016-02-23 11:18:28.271 | Error on exit
> 2016-02-23 11:18:28.953 | df: '/run/user/112/gvfs': Permission denied
>
> The info in n-sch.log is as follows:
>
> stack@nyp-VirtualBox:~/devstack$ /usr/local/bin/nova-scheduler
> --config-file /et ^Mc/nova/nova.conf & echo $!
> >/opt/stack/status/stack/n-sch.pid; fg || echo "n-sch ^M failed to start" |
> tee "/opt/stack/status/stack/n-sch.failure"
> [1] 29467
> /usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf
> 2016-02-23 19:13:00.050 ^[[00;32mDEBUG oslo_db.api [^[[00;36m-^[[00;32m]
> ^[[01;35m^[[00;32mLoading backend 'sqlalchemy' from
> 'nova.db.sqlalchemy.api'^[[00m ^[[00;33mfrom (pid=29467) _load_backend
> /usr/local/lib/python2.7/dist-packages/oslo_db/api.py:238^[[00m
> 2016-02-23 19:13:00.300 ^[[01;33mWARNING
> oslo_reports.guru_meditation_report [^[[00;36m-^[[01;33m]
> ^[[01;35m^[[01;33mGuru mediation now registers SIGUSR1 and SIGUSR2 by
> default for backward compatibility. SIGUSR1 will no longer be registered in
> a future release, so please use SIGUSR2 to generate reports.^[[00m
> 2016-02-23 19:13:00.304 ^[[01;31mCRITICAL nova [^[[00;36m-^[[01;31m]
> ^[[01;35m^[[01;31mValueError: Empty module name
> ^[[00m
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mTraceback (most
> recent call last):
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
> "/usr/local/bin/nova-scheduler", line 10, in 
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>  sys.exit(main())
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
> "/opt/stack/nova/nova/cmd/scheduler.py", line 43, in main
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>  topic=CONF.scheduler_topic)
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
> "/opt/stack/nova/nova/service.py", line 281, in create
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>  db_allowed=db_allowed)
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
> "/opt/stack/nova/nova/service.py", line 167, in __init__
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>  self.manager = manager_class(host=self.host, *args, **kwargs)
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
> "/opt/stack/nova/nova/scheduler/manager.py", line 49, in __init__
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mself.driver
> = importutils.import_object(scheduler_driver)
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line
> 44, in import_object
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mreturn
> import_class(import_str)(*args, **kwargs)
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line
> 30, in import_class
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>  __import__(mod_str)
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mValueError:
> Empty module name
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
> n-sch failed to start
>
>
> Best regards,
> Yipei
>
> On Tue, Feb 23, 2016 at 10:23 AM, Yipei Niu  wrote:
>
>> Hi Jeo,
>>
>> I have checked. The Neutron API has not started, but no process is
>> listening 9696.
>>
>> Best regards,
>> Yipei
>>
>
>

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

[王华]

Hi Corey,

What is the steps when we do zero downtime upgrades? Can you explain it in
detail? Or is there any docs for it?

Best Regards
Wanghua

On Sat, Feb 27, 2016 at 9:26 PM, Corey O'Brien 
wrote:

> We discussed this at the midcycle as a part of zero downtime upgrades. In
> order to be able to do Magnum upgrades, we talked about directing all DB
> access through a service that understands the schema for both the current
> and previous versions of the database. Moving direct DB access into the API
> will make it harder to do zero downtime upgrades in the future. I think we
> should leave things the way they are today.
>
> Corey
>
> On Fri, Feb 26, 2016, 22:08 王华  wrote:
>
>> Hi all,
>>
>> I want to allow magnum-api to access DB, so that magnum-api can work even
>> if magnum-conductor is down.
>>
>> Best Regards,
>> Wanghua
>>
>> On Thu, Feb 4, 2016 at 3:42 PM, 王华  wrote:
>>
>>> I think we should allow magnum-api to access DB directly like nova-api.
>>>
>>> As describe in [1], nova may have many compute nodes and it may take an
>>> hour or a month to upgrade. But the number of magnum-api and
>>> magnum-conductor is limited, the upgrade of them is fast. They don't
>>> benefit from the method. We should upgrade them like the control services
>>> in nova and upgrade them together.
>>>
>>> In this step, you will upgrade everything but the compute nodes. This
>>> means nova-api, nova-scheduler, nova-conductor, nova-consoleauth,
>>> nova-network, and nova-cert. In reality, this needs to be done fairly
>>> atomically. So, shut down all of the affected services, roll the new code,
>>> and start them back up. This will result in some downtime for your API, but
>>> in reality, it should be easy to quickly perform the swap. In later
>>> releases, we’ll reduce the pain felt here by eliminating the need for the
>>> control services to go together.
>>>
>>> [1]
>>> http://www.danplanet.com/blog/2015/06/26/upgrading-nova-to-kilo-with-minimal-downtime/
>>>
>>>
>>> On Thu, Feb 4, 2016 at 4:59 AM, Hongbin Lu 
>>> wrote:
>>>
 I can clarify Eli’s question further.



 1) is this by designed that we don't allow magnum-api to access DB
 directly ？

 Yes, that is what it is. Actually, The magnum-api was allowed to access
 DB directly in before. After the indirection API patch landed [1],
 magnum-api starts using magnum-conductor as a proxy to access DB. According
 to the inputs from oslo team, this design allows operators to take down
 either magnum-api or magnum-conductor to upgrade. This is not the same as
 nova-api, because nova-api, nova-scheduler, and nova-conductor are assumed
 to be shutdown all together as an atomic unit.



 I think we should make our own decision here. If we can pair magnum-api
 with magnum-conductor as a unit, we can remove the indirection API and
 allow both binaries to access DB. This could mitigate the potential
 performance bottleneck of message queue. On the other hand, if we stay with
 the current design, we would allow magnum-api and magnum-conductor to scale
 independently. Thoughts?



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



 Best regards,

 Hongbin



 *From:* Kumari, Madhuri [mailto:madhuri.kum...@intel.com]
 *Sent:* February-03-16 10:57 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Magnum] API service won't work if
 conductor down?



 Corey the one you are talking about has changed to coe-service-*.



 Eli, IMO we should display proper error message. M-api service should
 only have read permission.



 Regards,

 Madhuri



 *From:* Corey O'Brien [mailto:coreypobr...@gmail.com
 ]
 *Sent:* Wednesday, February 3, 2016 6:50 PM
 *To:* OpenStack Development Mailing List (not for usage questions) <
 openstack-dev@lists.openstack.org>
 *Subject:* Re: [openstack-dev] [Magnum] API service won't work if
 conductor down?



 The service-* commands aren't related to the magnum services (e.g.
 magnum-conductor). The service-* commands are for services on the bay that
 the user creates and deletes.



 Corey



 On Wed, Feb 3, 2016 at 2:25 AM Eli Qiao  wrote:

 hi
 Whey I try to run magnum service-list to list all services (seems now
 we only have m-cond service), it m-cond is down(which means no conductor at
 all),
 API won't response and will return a timeout error.

 taget@taget-ThinkStation-P300:~/devstack$ magnum service-list
 ERROR: Timed out waiting for a reply to message ID
 fd1e9529f60f42bf8db903bbf75bbade (HTTP 500)

 

Re: [openstack-dev] [tricircle] playing tricircle with devstack under two-region configuration

[joehuang]

Hi, Pengfei,

Volume type is not supported in Tricircle yet.

Best Regards
Chaoyi Huang ( Joe Huang )

From: 时鹏飞 [mailto:shipengfe...@gmail.com]
Sent: Sunday, February 28, 2016 9:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle] playing tricircle with devstack under 
two-region configuration

Hi,Joe and Zhiyuan,

When I install the devstack in Node2, it occur errors when test 
cinder_volume_types:

2016-02-27 17:05:00.920 | + ./devstack/stack.sh:main:L1267:   
create_volume_types
2016-02-27 17:05:00.920 | + 
/home/stack/devstack/lib/cinder:create_volume_types:L549:   is_service_enabled 
c-api
2016-02-27 17:05:00.927 | + 
/home/stack/devstack/functions-common:is_service_enabled:L2026:   return 0
2016-02-27 17:05:00.927 | + 
/home/stack/devstack/lib/cinder:create_volume_types:L549:   [[ -n 
lvm:lvmdriver-1 ]]
2016-02-27 17:05:00.927 | + 
/home/stack/devstack/lib/cinder:create_volume_types:L550:   local be be_name
2016-02-27 17:05:00.928 | + 
/home/stack/devstack/lib/cinder:create_volume_types:L551:   for be in 
'${CINDER_ENABLED_BACKENDS//,/ }'
2016-02-27 17:05:00.928 | + 
/home/stack/devstack/lib/cinder:create_volume_types:L552:   be_name=lvmdriver-1
2016-02-27 17:05:00.928 | + 
/home/stack/devstack/lib/cinder:create_volume_types:L553:   openstack volume 
type create --property volume_backend_name=lvmdriver-1 lvmdriver-1
2016-02-27 17:05:02.937 | Unable to establish connection to 
http://10.50.11.5:19997/v2/00d182cbe7664762809f4f5a0866635d/types
2016-02-27 17:05:03.025 | + 
/home/stack/devstack/lib/cinder:create_volume_types:L1:   exit_trap
2016-02-27 17:05:03.025 | + ./devstack/stack.sh:exit_trap:L474:   local r=1
2016-02-27 17:05:03.027 | ++ ./devstack/stack.sh:exit_trap:L475:   jobs -p
2016-02-27 17:05:03.028 | + ./devstack/stack.sh:exit_trap:L475:   jobs=
2016-02-27 17:05:03.028 | + ./devstack/stack.sh:exit_trap:L478:   [[ -n '' ]]
2016-02-27 17:05:03.028 | + ./devstack/stack.sh:exit_trap:L484:   kill_spinner
2016-02-27 17:05:03.028 | + ./devstack/stack.sh:kill_spinner:L370:   '[' '!' -z 
'' ']'
2016-02-27 17:05:03.029 | + ./devstack/stack.sh:exit_trap:L486:   [[ 1 -ne 0 ]]
2016-02-27 17:05:03.029 | + ./devstack/stack.sh:exit_trap:L487:   echo 'Error 
on exit'
2016-02-27 17:05:03.029 | Error on exit
2016-02-27 17:05:03.029 | + ./devstack/stack.sh:exit_trap:L488:   
generate-subunit 1456592181 522 fail
2016-02-27 17:05:03.375 | + ./devstack/stack.sh:exit_trap:L489:   [[ -z 
/opt/stack/logs ]]
2016-02-27 17:05:03.375 | + ./devstack/stack.sh:exit_trap:L492:   
/home/stack/devstack/tools/worlddump.py -d /opt/stack/logs
stack@node2:~$ 2016-02-27 17:05:03.843 | + ./devstack/stack.sh:exit_trap:L498:  
 exit 1


Best Regards
Pengfei Shi (时鹏飞)
Shanghai Jiao Tong University
Network & Information Center Room 304

shipengfe...@gmail.com





On Feb 24, 2016, at 9:29 AM, Yipei Niu 
> wrote:

Hi Joe and Zhiyuan,

My VM has recovered. When I re-install devstack in node1, I encounter the 
following errors.

The info in stack.sh.log is as follows:

2016-02-23 11:18:27.238 | Error: Service n-sch is not running
2016-02-23 11:18:27.238 | + 
/home/stack/devstack/functions-common:service_check:L1625:   '[' -n 
/opt/stack/status/stack/n-sch.failure ']'
2016-02-23 11:18:27.238 | + 
/home/stack/devstack/functions-common:service_check:L1626:   die 1626 'More 
details about the above errors can be found with screen, with ./rejoin-stack.sh'
2016-02-23 11:18:27.238 | + /home/stack/devstack/functions-common:die:L186:   
local exitcode=0
2016-02-23 11:18:27.239 | [Call Trace]
2016-02-23 11:18:27.239 | ./stack.sh:1354:service_check
2016-02-23 11:18:27.239 | /home/stack/devstack/functions-common:1626:die
2016-02-23 11:18:27.261 | [ERROR] /home/stack/devstack/functions-common:1626 
More details about the above errors can be found with screen, with 
./rejoin-stack.sh
2016-02-23 11:18:28.271 | Error on exit
2016-02-23 11:18:28.953 | df: '/run/user/112/gvfs': Permission denied

The info in n-sch.log is as follows:

stack@nyp-VirtualBox:~/devstack$ /usr/local/bin/nova-scheduler --config-file 
/et ^Mc/nova/nova.conf & echo $! >/opt/stack/status/stack/n-sch.pid; fg || echo 
"n-sch ^M failed to start" | tee "/opt/stack/status/stack/n-sch.failure"
[1] 29467
/usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf
2016-02-23 19:13:00.050 ^[[00;32mDEBUG oslo_db.api [^[[00;36m-^[[00;32m] 
^[[01;35m^[[00;32mLoading backend 'sqlalchemy' from 
'nova.db.sqlalchemy.api'^[[00m ^[[00;33mfrom (pid=29467) _load_backend 
/usr/local/lib/python2.7/dist-packages/oslo_db/api.py:238^[[00m
2016-02-23 19:13:00.300 ^[[01;33mWARNING oslo_reports.guru_meditation_report 
[^[[00;36m-^[[01;33m] ^[[01;35m^[[01;33mGuru mediation now registers SIGUSR1 
and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be 
registered in a future release, so please use SIGUSR2 to generate reports.^[[00m
2016-02-23 

Re: [openstack-dev] gertty and git diff -U problem

[Neil Jerram]

FYI, all working fine after 'pip install GitPython=1.0.1' (in the virtualenv).


  Original Message
From: Neil Jerram
Sent: Sunday, 28 February 2016 20:42
To: Jeremy Stanley; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] gertty and git diff -U problem


Thanks Jeremy! I'll try those solutions.

  Original Message
From: Jeremy Stanley
Sent: Sunday, 28 February 2016 19:57
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] gertty and git diff -U problem


On 2016-02-28 19:33:29 + (+), Neil Jerram wrote:
> I've just tried to start using gertty, installed in a virtualenv
> using 'pip install gertty' - which means I have version 1.3.1.
[...]
> Any recommendations for getting past this? I think it's to do with
> git-diff not liking the space between -U and 1.

It's due to a non-backwards-compatible behavior change in GitPython,
rather than a bug in Gertty itself:
https://github.com/gitpython-developers/GitPython/issues/382

You might try rolling back to GitPython 1.0.1 in your environment to
to work around it temporarily, or update to Gertty's master branch
which avoids installing 1.0.2 and later via
https://review.openstack.org/279582
--
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 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] Show TripleO: A terminal dashboard

[Steve Baker]

On 27/02/16 09:06, Ben Nemec wrote:

Interesting!  So this could conceivably be another consumer of the API,
right?  A sort of CLI UI?

On 02/25/2016 01:10 PM, Dougal Matthews wrote:

Hi all,

Over the past couple of weeks in my spare time I put together a basic
Python urwid dashboard for TripleO. You can see the usage and some
screenshots here:

http://python-tripleodash.readthedocs.org

The project is in very early stages (read as: very limited and buggy),
but I've found it useful already. At the moment it is read only but
there is no reason that needs to be the case going forward.

Ultimately I think it could become both a dashboard and a handy getting
started wizard.Good q It does this to a small extent now by listing the
commands needed to register nodes if none are found.

I wanted to share this for now and see if it interested anyone else.

Cheers,
Dougal


Very nice, I wonder if this dashboard would be a better home for my 
proposed commands for monitoring software deployments on the nodes [1]? 
It seems like a good match because it is aimed at monitoring the status 
of the deployment rather than triggering changes.


The tripleo-common changes would still need to land, but the UI would 
move from tripleoclient to tripleodash.


[1] 
https://review.openstack.org/#/q/status:open++branch:master+topic:bp/tripleo-manage-software-deployments


__
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][vote] Proposing Angus Salkeld for kolla-core

[Angus Salkeld]

On Mon, Feb 29, 2016 at 5:04 AM Steven Dake (stdake) 
wrote:

> Angus,
>
> You received 7 +1 votes with no veto votes in the voting window and we
> require 6 votes or more to join the core team at the time you were
> proposed.  As a result, I have removed you from kolla-mesos-core and added
> you to kolla-core.
>
> Welcome to the core reviewer team!
>

Thank you! I'll also pay more attention to main kolla reviews (I realise
that I have been somewhat focused on the kolla-mesos stuff).

-Angus


>
> Regards
> -steve
>
>
> From: Steven Dake 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Friday, February 19, 2016 at 11:04 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [kolla][vote] Proposing Angus Salkeld for
> kolla-core
>
> Angus is already in kolla-mesos-core but doesn't have broad ability to
> approve changes for all of kolla-core.  We agreed by majority vote in Tokyo
> that folks in kolla-mesos-core that integrated well with the project would
> be moved from kolla-mesos-core to kolla-core.  Once kolla-mesos-core is
> empty, we will deprecate that group.
>
> Angus has clearly shown his commitment to Kolla:
> He is #9 in reviews for Mitaka and #3 in commits(!) as well as shows a
> solid PDE of 64 (meaning 64 days of interaction with either reviews,
> commits, or mailing list participation.
>
> Count my vote as a +1.  If your on the fence, feel free to abstain.  A
> vote of –1 is a VETO vote, which terminates the voting process.  If there
> is unanimous approval prior to February 26, or a veto vote, the voting will
> be closed and appropriate changes made.
>
> Remember now we agreed it takes a majority vote to approve a core
> reviewer, which means Angus needs a +1 support from at least 6 core
> reviewers with no veto votes.
>
> Regards,
> -steve
>
> __
> 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] gertty and git diff -U problem

[Neil Jerram]

Thanks Jeremy! I'll try those solutions.

  Original Message
From: Jeremy Stanley
Sent: Sunday, 28 February 2016 19:57
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] gertty and git diff -U problem


On 2016-02-28 19:33:29 + (+), Neil Jerram wrote:
> I've just tried to start using gertty, installed in a virtualenv
> using 'pip install gertty' - which means I have version 1.3.1.
[...]
> Any recommendations for getting past this? I think it's to do with
> git-diff not liking the space between -U and 1.

It's due to a non-backwards-compatible behavior change in GitPython,
rather than a bug in Gertty itself:
https://github.com/gitpython-developers/GitPython/issues/382

You might try rolling back to GitPython 1.0.1 in your environment to
to work around it temporarily, or update to Gertty's master branch
which avoids installing 1.0.2 and later via
https://review.openstack.org/279582
--
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 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] gertty and git diff -U problem

[Jeremy Stanley]

On 2016-02-28 19:33:29 + (+), Neil Jerram wrote:
> I've just tried to start using gertty, installed in a virtualenv
> using 'pip install gertty' - which means I have version 1.3.1.
[...]
> Any recommendations for getting past this? I think it's to do with
> git-diff not liking the space between -U and 1.

It's due to a non-backwards-compatible behavior change in GitPython,
rather than a bug in Gertty itself:
https://github.com/gitpython-developers/GitPython/issues/382

You might try rolling back to GitPython 1.0.1 in your environment to
to work around it temporarily, or update to Gertty's master branch
which avoids installing 1.0.2 and later via
https://review.openstack.org/279582
-- 
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-dev] gertty and git diff -U problem

[Neil Jerram]

I've just tried to start using gertty, installed in a virtualenv using 'pip 
install gertty' - which means I have version 1.3.1.

When I try to look at any Diff, though, I get a traceback ending with:

git.exc.GitCommandError: 'git diff --color=never -U 1 [...]' returned with 
exit code 128
stderr: 'fatal: ambiguous argument '1': unknown revision or path not in the 
working tree.
Use '--' to separate paths from revisions, like this:
'git  [] -- [...]'
'

Any recommendations for getting past this? I think it's to do with git-diff not 
liking the space between -U and 1.

Thanks,
  Neil

__
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] A proposal to separate the design summit

[Jeremy Stanley]

On 2016-02-26 19:16:55 + (+), Hongbin Lu wrote:
[...]
> I want to point out the fact that some projects were holding
> online midcycle because their developers were not able to get
> approval for a pure contributor event.

This may be true for some teams, but please don't assume that cost
is the only reason why a team might hold a virtual mid-cycle event
instead of an in-person one. I personally much prefer the virtual
approach, as I am considerably more productive when I don't have to
travel (granted, it does require some additional care to filter out
other day-to-day distractions and effectively sequester myself to
focus solely on the event; in-person gatherings provide a slightly
more constant reminder of what I'm supposed to be doing).
-- 
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] [kolla][vote] Proposing Angus Salkeld for kolla-core

[Steven Dake (stdake)]

Angus,

You received 7 +1 votes with no veto votes in the voting window and we require 
6 votes or more to join the core team at the time you were proposed.  As a 
result, I have removed you from kolla-mesos-core and added you to kolla-core.

Welcome to the core reviewer team!

Regards
-steve


From: Steven Dake >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, February 19, 2016 at 11:04 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla][vote] Proposing Angus Salkeld for kolla-core

Angus is already in kolla-mesos-core but doesn't have broad ability to approve 
changes for all of kolla-core.  We agreed by majority vote in Tokyo that folks 
in kolla-mesos-core that integrated well with the project would be moved from 
kolla-mesos-core to kolla-core.  Once kolla-mesos-core is empty, we will 
deprecate that group.

Angus has clearly shown his commitment to Kolla:
He is #9 in reviews for Mitaka and #3 in commits(!) as well as shows a solid 
PDE of 64 (meaning 64 days of interaction with either reviews, commits, or 
mailing list participation.

Count my vote as a +1.  If your on the fence, feel free to abstain.  A vote of 
-1 is a VETO vote, which terminates the voting process.  If there is unanimous 
approval prior to February 26, or a veto vote, the voting will be closed and 
appropriate changes made.

Remember now we agreed it takes a majority vote to approve a core reviewer, 
which means Angus needs a +1 support from at least 6 core reviewers with no 
veto votes.

Regards,
-steve

__
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] How do I calculate the semantic version prior to a release?

[Jeremy Stanley]

On 2016-02-28 10:30:18 + (+), Neil Jerram wrote:
[...]
> In the networking-calico project, which is release:independent, we
> keep the Debian and RPM packaging together with the non-packaging
> code. When the time comes for a release, we'd like to update the
> Debian and RPM versions and changelogs first (and merge that) and
> then ask for the project to be tagged and released to PyPI. We'd
> like the Debian and RPM versions to match the tag and PyPI version
> - and so my original question in this thread was really 'how can
> we predict what the next tag and PyPI version will be?'
[...]

Distro package maintainers generally recommend against that
approach, since requiring an upstream version bump when you're only
adjusting the packaging is somewhat misleading. Say you need to
tweak some platform-specific metadata in the RPM package... it's
potentially misleading for there to be a new upstream release of the
software, and also a new DEB package, with no actual changes to
either. It's usually suggested to keep your packaging at least in a
different branch per distro, or even in a separate Git repository
entirely, so that the state of the packaging files is not
unnecessarily entangled with the state of the software itself (and
vice versa).
-- 
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] How do I calculate the semantic version prior to a release?

[Jeremy Stanley]

On 2016-02-27 07:53:13 +1300 (+1300), Robert Collins wrote:
[...]
> We certainly do -
> http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/juno/pbr-semver.rst
> was the spec for it. All it relies on is the use of git tags for
> release, + the sem-ver pseudo-header to provoke major and minor
> version bumps.
[...]
> No - its much more than that. See
> http://docs.openstack.org/developer/pbr/#version

Thanks! Somehow the Sem-Ver: pseudo header implementation escaped my
notice, so I was definitely working on an outdated understanding.
-- 
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] audience for release notes

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2016-02-28 10:40:44 -0500:
> Excerpts from Thomas Goirand's message of 2016-02-28 22:56:51 +0800:
> > On 02/28/2016 01:18 AM, Davanum Srinivas wrote:
> > > Thomas,
> > > 
> > > Please try and let use know what kind of problems you see in Debian as
> > > projects have already switched to reno.
> > 
> > Dims,
> > 
> > Unfortunately, if I wrote about this, that's because I tried, and
> > experienced not very nice things packaging Mitaka b1 and b2. I sometimes
> > had to patch out the reno sphinx module to be able to build the sphinx
> > docs of some packages. For example:
> > 
> > http://anonscm.debian.org/cgit/openstack/python-os-client-config.git/tree/debian/patches/remove-the-use-of-reno.patch?h=debian/mitaka
> > 
> > I don't think the above patch is the way to go, because:
> > - We should address this in a more general way, not on individual
> > (Debian) packages
> > - Running "sphinx-build" should always work, no mater what
> > - The release notes also belongs in a Debian package
> > 
> > I already wrote about it to Doug. I opened a general topic about not
> > using git (and more specifically in this case: "git log") when
> > generating the documentation (see below the reference to the thread).
> > But it's looking like that's still not enough. :(
> > 
> > > I believe Thomas is referring to:
> > >
> > > https://bugs.launchpad.net/reno/+bug/1520096
> > 
> > The funny part about this bug is that it was opened against Reno, which
> > by design, is doing things wrongly. Then the issue was kind of turned
> 
> Please try to remember that your use case is not the only use case we
> have. Reno was designed to meet a very specific set of criteria and
> requirements to solve a problem the release team identified. Building
> release notes documents without git history has been on the list of
> requirements for quite some time, we just haven't gotten to it yet.
> 
> > around, and fixed in python-neutronclient. However, many other packages
> > have the problem too, and I don't believe that they will somehow all be
> > magically fixed and understand what should be done or not.
> > 
> > To me, the issue should really be fixed into Reno itself (if it is even
> > fixable...).
> > 
> > By the way, this bug was opened in November, even before Mitaka b1,
> > which gave enough time to understand that Reno isn't working the way it
> > should (ie: it relies on git at "sphinx-build" time, which it shouldn't).
> > 
> > One way I would see to fix the issue, would be having Reno to actually
> > write the release notes in an RST format, but just *not* when invoking
> > sphinx-build. Then such a generated file could be stored in the Git
> > repository of each individual projects, plus a gate job for checking
> > it's up-to-date could be written. That's of course just an idea, and as
> > I maintain all of OpenStack packages in Debian (350 source packages and
> > counting...), I unfortunately can't volunteer to implement it. :/
> 
> No, we won't be checking compiled documents into git. The history of
> doing that with configuration sample files, and other generated pages,
> has clearly demonstrated that to be a bad solution to this type of
> problem. I've outlined the approach we have planned in my other email so
> I won't repeat it here.
> 
> > 
> > >
> > http://lists.openstack.org/pipermail/openstack-dev/2016-February/thread.html#86917
> > 
> > Yeah, that's the thread I am referring to above. Thanks Steve, for
> > pointing it out so I don't have to do the search myself! :)
> > 
> > It is still my view that projects should revert using Reno asap until
> > the issue is fixed in Reno. Sure, I could potentially open a bug for
> > each and every package which has the issue, but IMO that's not the way
> > to go.
> 
> Projects should not use reno in their developer documentation. They
> should use a separate sphinx build set up to run under "tox -e
> releasenotes" with the relevant CI jobs to ensure the results are
> published under docs.openstack.org/releasenotes. None of that will
> interfere with your packaging.

I should expand on this point. Early on, I did suggest that projects
without deployer-facing notes *could* do this. But since earlier
discussions of the issues related to packaging came up, we've revised
that advice to say that all projects should split their docs and release
notes. This may not have been widely implemented, so where you're
encountering issues please file bugs. It's relatively simple to fix the
projects for this cycle, in case we don't get the git-free scanner for
reno implemented this cycle.

> 
> > 
> > By the way, Reno itself is doing so many gpg keys that the system
> > building it can't have enough entropy, and then the unit tests are
> > timing-out. Is there a way to fix this?
> 
> Give this a try and see if it works any better:
> https://review.openstack.org/285812
> 
> Doug

__
OpenStack 

Re: [openstack-dev] [all] audience for release notes

[Doug Hellmann]

Excerpts from Thomas Goirand's message of 2016-02-28 22:56:51 +0800:
> On 02/28/2016 01:18 AM, Davanum Srinivas wrote:
> > Thomas,
> > 
> > Please try and let use know what kind of problems you see in Debian as
> > projects have already switched to reno.
> 
> Dims,
> 
> Unfortunately, if I wrote about this, that's because I tried, and
> experienced not very nice things packaging Mitaka b1 and b2. I sometimes
> had to patch out the reno sphinx module to be able to build the sphinx
> docs of some packages. For example:
> 
> http://anonscm.debian.org/cgit/openstack/python-os-client-config.git/tree/debian/patches/remove-the-use-of-reno.patch?h=debian/mitaka
> 
> I don't think the above patch is the way to go, because:
> - We should address this in a more general way, not on individual
> (Debian) packages
> - Running "sphinx-build" should always work, no mater what
> - The release notes also belongs in a Debian package
> 
> I already wrote about it to Doug. I opened a general topic about not
> using git (and more specifically in this case: "git log") when
> generating the documentation (see below the reference to the thread).
> But it's looking like that's still not enough. :(
> 
> > I believe Thomas is referring to:
> >
> > https://bugs.launchpad.net/reno/+bug/1520096
> 
> The funny part about this bug is that it was opened against Reno, which
> by design, is doing things wrongly. Then the issue was kind of turned

Please try to remember that your use case is not the only use case we
have. Reno was designed to meet a very specific set of criteria and
requirements to solve a problem the release team identified. Building
release notes documents without git history has been on the list of
requirements for quite some time, we just haven't gotten to it yet.

> around, and fixed in python-neutronclient. However, many other packages
> have the problem too, and I don't believe that they will somehow all be
> magically fixed and understand what should be done or not.
> 
> To me, the issue should really be fixed into Reno itself (if it is even
> fixable...).
> 
> By the way, this bug was opened in November, even before Mitaka b1,
> which gave enough time to understand that Reno isn't working the way it
> should (ie: it relies on git at "sphinx-build" time, which it shouldn't).
> 
> One way I would see to fix the issue, would be having Reno to actually
> write the release notes in an RST format, but just *not* when invoking
> sphinx-build. Then such a generated file could be stored in the Git
> repository of each individual projects, plus a gate job for checking
> it's up-to-date could be written. That's of course just an idea, and as
> I maintain all of OpenStack packages in Debian (350 source packages and
> counting...), I unfortunately can't volunteer to implement it. :/

No, we won't be checking compiled documents into git. The history of
doing that with configuration sample files, and other generated pages,
has clearly demonstrated that to be a bad solution to this type of
problem. I've outlined the approach we have planned in my other email so
I won't repeat it here.

> 
> >
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/thread.html#86917
> 
> Yeah, that's the thread I am referring to above. Thanks Steve, for
> pointing it out so I don't have to do the search myself! :)
> 
> It is still my view that projects should revert using Reno asap until
> the issue is fixed in Reno. Sure, I could potentially open a bug for
> each and every package which has the issue, but IMO that's not the way
> to go.

Projects should not use reno in their developer documentation. They
should use a separate sphinx build set up to run under "tox -e
releasenotes" with the relevant CI jobs to ensure the results are
published under docs.openstack.org/releasenotes. None of that will
interfere with your packaging.

> 
> By the way, Reno itself is doing so many gpg keys that the system
> building it can't have enough entropy, and then the unit tests are
> timing-out. Is there a way to fix this?

Give this a try and see if it works any better:
https://review.openstack.org/285812

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] audience for release notes

[Doug Hellmann]

Excerpts from Thomas Goirand's message of 2016-02-28 01:09:36 +0800:
> On 02/26/2016 08:34 PM, Doug Hellmann wrote:
> > We implemented reno for this cycle to replace the old wiki-based
> > system for writing release notes for deployers, operators, and
> > end-users.
> 
> Is the fact that Reno does "git log" when building the docs a solved
> problem? Because from my past experience with Mitaka b1 / b2, any doc
> using reno will refuse to "sphinx-build" in Debian. If it wasn't fixed,
> then I would suggest to *not* use Reno just yet.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

This is part of why we put the release notes document build separate
from the main documentation build (the other reason being so we could
link to something without "developer" in the URL).

The plan is to build setuptools integration into reno so that when
we build our sdists they include a cache file of the data that reno
derives from the git history, so that without git present reno can
use the cache file instead of the git history. That work hasn't
been done yet, because it has not yet been the highest priority
task related to all of the release automation changes we're
implementing, because as I stated above it shouldn't be necessary
to build packages (including documentation) for projects. If we
don't get to it by the end of Mitaka, it will happen early in Newton.

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

[openstack-dev] [Neutron][Dragonflow] IRC Meeting tomorrow (2/29) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 2/29) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-02-22-09.00.html

Please update the agenda if you have any subject you would like to discuss
about.
__
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] audience for release notes

[Thomas Goirand]

On 02/28/2016 01:18 AM, Davanum Srinivas wrote:
> Thomas,
> 
> Please try and let use know what kind of problems you see in Debian as
> projects have already switched to reno.

Dims,

Unfortunately, if I wrote about this, that's because I tried, and
experienced not very nice things packaging Mitaka b1 and b2. I sometimes
had to patch out the reno sphinx module to be able to build the sphinx
docs of some packages. For example:

http://anonscm.debian.org/cgit/openstack/python-os-client-config.git/tree/debian/patches/remove-the-use-of-reno.patch?h=debian/mitaka

I don't think the above patch is the way to go, because:
- We should address this in a more general way, not on individual
(Debian) packages
- Running "sphinx-build" should always work, no mater what
- The release notes also belongs in a Debian package

I already wrote about it to Doug. I opened a general topic about not
using git (and more specifically in this case: "git log") when
generating the documentation (see below the reference to the thread).
But it's looking like that's still not enough. :(

> I believe Thomas is referring to:
>
> https://bugs.launchpad.net/reno/+bug/1520096

The funny part about this bug is that it was opened against Reno, which
by design, is doing things wrongly. Then the issue was kind of turned
around, and fixed in python-neutronclient. However, many other packages
have the problem too, and I don't believe that they will somehow all be
magically fixed and understand what should be done or not.

To me, the issue should really be fixed into Reno itself (if it is even
fixable...).

By the way, this bug was opened in November, even before Mitaka b1,
which gave enough time to understand that Reno isn't working the way it
should (ie: it relies on git at "sphinx-build" time, which it shouldn't).

One way I would see to fix the issue, would be having Reno to actually
write the release notes in an RST format, but just *not* when invoking
sphinx-build. Then such a generated file could be stored in the Git
repository of each individual projects, plus a gate job for checking
it's up-to-date could be written. That's of course just an idea, and as
I maintain all of OpenStack packages in Debian (350 source packages and
counting...), I unfortunately can't volunteer to implement it. :/

>
http://lists.openstack.org/pipermail/openstack-dev/2016-February/thread.html#86917

Yeah, that's the thread I am referring to above. Thanks Steve, for
pointing it out so I don't have to do the search myself! :)

It is still my view that projects should revert using Reno asap until
the issue is fixed in Reno. Sure, I could potentially open a bug for
each and every package which has the issue, but IMO that's not the way
to go.

By the way, Reno itself is doing so many gpg keys that the system
building it can't have enough entropy, and then the unit tests are
timing-out. Is there a way to fix this?

Cheers,

Thomas Goirand (zigo)


__
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] How do I calculate the semantic version prior to a release?

[Neil Jerram]

Many thanks to everyone who has replied in this thread. 

In case you have further comment, I'll explain what prompted my question.  ‎In 
the networking-calico project, which is release:independent, we keep the Debian 
and RPM packaging together with the non-packaging code. When the time comes for 
a release, we'd like to update the Debian and RPM versions and changelogs first 
(and merge that) and then ask for the project to be tagged and released to 
PyPI. We'd like the Debian and RPM versions to match the tag and PyPI version - 
and so my original question in this thread was really 'how can we predict what 
the next tag and PyPI version will be?'

I hope that makes sense; thanks again for all the follow ups so far. 

Regards, 
       Neil 


  Original Message  
From: Robert Collins
Sent: Friday, 26 February 2016 18:53
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] How do I calculate the semantic version prior to a 
release?

On 27 February 2016 at 00:13, Neil Jerram  wrote:
> I understand the semantic versioning algorithm for calculating a new
> version. But what do I run, in a git repository, to do that calculation
> for me, and output:

pbr does that automatically, generating a pre-release version. The
regular part of the version is the lowest version number you can use
that will match the semver rules.

> - the new semantic version that would be used if I asked for a formal
> release to PyPI

We were/are going to add a command to tag for you, but just querying
it would be good too.

> - the corresponding Debian version

I don't think we expose that yet (but we should).

> - the corresponding RPM version.

As already mentioned, the rpm_version command exposes this.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] Mitaka, Xenial, OVS Firewall Driver, DPDK, VXLAN and Provider Networks

[James Page]

Hi Thiago
On Sat, 27 Feb 2016 at 23:58 Martinx - ジェームズ 
wrote:
[...]

However, I am curious about the following scenarios:
>
>  Will be possible to use, at the same time (same Network and Compute nodes
> / Host Aggregate):
>
>  1- Regular OVS bridges without DPDK for VXLAN Networks, with
> OVS-Firewall-Driver and;
>
>  2- OVS powered by DPDK for Provider Networks only ( without any firewall,
> current case anyway, due to
> https://bugs.launchpad.net/neutron/+bug/1531205).
>
> ?
>
>  I have NFV Instances that are also, DPDK L2 Bridges running on KVM Guest
> / VirtIO, that are physically wired using Provider Networks (flat and
> vlans).
>
>  So, for the Instance's vNICs (eth1 and eth2) that are used as a L2
> bridge, I don't want any kind of ovs-firewall (I'm not affected by LP
> #1531205 on this case) and I want OVS+DPDK under it but, for SSH into the
> Instance to manage it (via its eth0), it is still using regular VXLAN with
> Security Groups - OVS-Firewall from now on (no need for DPDK under eth0 /
> VXLAN).
>
>  I'm curious about this specially because the OVS Ubuntu package, makes
> use of Debian's Alternatives subsystem, and we need to choose one OVS
> (default), or another (with DPDK), via "update-alternatives", so, will be
> possible to select OVS with DPDK but, use regular bridges with it as well
> (for VXLAN networks)?
>

We're shipping two binaries due to the baseline CPU requirement for DPDK
being above the general baseline in Ubuntu; the DPDK enabled binary
supports all of the things that the vanilla binary does + DPDK.


>  If yes, how to create a VXLAN network with regular OVS and another
> FLAT/VLAN network with OVS+DPDK ?
>

Not sure whether a mixed mode openvswitch deployment is possible on a
single compute node - I can see how to switch between netdev and system
based bridges in the agent configuration, but that applies at the agent
level, not to specific bridges.

Cheers

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