date:20160330


John Dickinson wrote:

On Thursday, I'd like to proposed swapping Swift's 1:30pm session with Fuel's 
2:20pm session. This will give Swift a contiguous time block in the afternoon, 
and Fuel's session would line up right after their full morning (albeit after 
the lunch break).

I have not had a chance to talk to anyone on the Fuel team about this.


John,

You are giving a conference talk at 2:20pm on Thursday, which is why I 
left that as a hole in the Swift Design Summit schedule.


Swapping is definitely possible, but I figured you would not 
intentionally create a conflict for you here ?


--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] Austin Design Summit track layout


Mark McClain wrote:

Would it be possible to move the Astara fish bowl session to Thursday morning?  
It would avoid the conflict with Tacker.  We’re hoping to see where the teams 
could cooperate across projects in the future.


Yes, I'll move it to Thursday 9am, unless someone objects.

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] Austin Design Summit track layout


Matt Riedemann wrote:



On 3/29/2016 2:48 AM, Thierry Carrez wrote:

Matt Riedemann wrote:

I see one problem. The single stable team fishbowl session is scheduled
for the last slot on Thursday (5pm). The conflict I have with that is
the nova team does it's priority/scheduling talk in the last session on
the last day for design summit fishbowl sessions (non-meetup style).

I'm wondering if we could move the stable session to 4:10 on Thursday. I
don't see any infra/QA sessions happening at that time, which is the
cross-project people we need for the stable session.


There is the release management fishbowl session at 4:10pm on Thursday
that would conflict (a lot of people are involved in both). Maybe we
could swap those two (put stable at 4:10pm and relmgt at 5:00pm). It
looks like that would work ?



That would work for me. I wouldn't be at the release mgmt one at 5pm,
but I didn't know it was happening anyway, or that I'd be required to be
there.


OK, let's do the swap. It's not perfect, but then since Nova has 
sessions all the time, nothing is.


--
Thierry Carrez (ttx)

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

[openstack-dev] [OpenStack] "nova list" doesn't show networks for few instances

2016-03-30 Thread varun bhatnagar

Hi,

I am using OpenStack Juno on a multinode setup.
When I did nova list I couldn't see any interfaces attached to few of my
VMs although in Dashboard they are visible.

-+
| ID   | Name  | Status | Task State |
Power State | Networks
|
+--+---+++-+--+
| e111e5b6-4a90-4a3b-a465-19000fe1a81d | VM-3  | ACTIVE | -  |
Running |
   |
| 78c465e9-09a6-477b-9374-9a5eb455ab2b | VM-4  | ACTIVE | -  |
Running |
   |
| 6cfdef27-018a-4fd3-8f4f-856d804d415b | VM-5  | ACTIVE | -  |
Running |
   |
| 94f4bddb-e2d5-48e8-88ae-169aba75ebd4 | VM-6  | ACTIVE | -  |
Running |
   |

| c72a4d9d-fcd1-4b12-90de-ec46fc950ad2 | VM-7 | ACTIVE | -  |
Running | internal=3001::b, 10.0.0.13, 192.168.154.68
   |
+--+---+++-+--+


Can anyone please tell me what is causing this and how to fix it?

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

[openstack-dev] [Heat] Meeting time

2016-03-30 Thread Thomas Herve

Hi all,

I'd like to be able to attend at least one of the IRC meeting, and it
doesn't really work right now. So if you'd like to come to meetings,
please fill the following doodle:
http://doodle.com/poll/4m6aicfnwuug86rs

Note that I'll try to make the best choice depending on my selfish
availability, and who's already active currently in meetings. I may
just move the 20UTC meeting to something like 15UTC if that's OK.

Thanks!

-- 
Thomas

__
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] [Senlin] Asking about launching an instance in Senlin cluster

2016-03-30 Thread Ethan Lynn

Hi Cuong,
First you need to create a profile, and then create a cluster.
There is some examples in senlin/example/profiles, you can start with this one 
https://github.com/openstack/senlin/blob/master/examples/profiles/cirros_basic/nova_server.yaml
 


Copy this file and modify image or flavor or key_name as you like, then use 
following command to create a profile:
# openstack cluster profile create my_profile --spec-file nova_server.yaml

Then create a cluster based on this profile:
# openstack cluster create my_cluster —profile my_profile --desired-capacity 1



Best Regards,
Ethan Lynn
xuanlangj...@gmail.com




> On Mar 30, 2016, at 15:39, Nguyen Huy Cuong  wrote:
> 
> Dear OpenStack Supporter,
> 
> I am Cuong Nguyen, an Vietnamese IT engineer.
> 
> Currently, I am researching about Senlin to apply for my work.
> I research to launch an virtual machine on a Senlin cluster.
> Could you please advice me to perform this action?
> If I am missing something, please let me know.
> 
> Thank and best regards,
> 
> Cuong Nguyen.
> 
> __
> 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] [release][telemetry] Ceilometer Mitaka RC3 available

Due to a new release-critical issue spotted in Ceilometer during RC2 
testing, a new release candidate was created for Mitaka. You can find 
the RC2 source code tarball at:


https://tarballs.openstack.org/ceilometer/ceilometer-6.0.0.0rc3.tar.gz

Unless new release-critical issues are found that warrant a last-minute 
release candidate respin, this tarball will be formally released as the 
final "Mitaka" version on April 7th.


Alternatively, you can directly test the mitaka release branches at:

http://git.openstack.org/cgit/openstack/ceilometer/log/?h=stable/mitaka

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/ceilometer/+filebug

and tag it *mitaka-rc-potential* to bring it to the Ceilometer release 
crew's attention.


Thanks!

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Openstack] [OpenStack] "nova list" doesn't show networks for few instances

2016-03-30 Thread Remo Mattei

Wrong user? 

Try --all-tenants and see what shows up as an admin

Inviato da iPhone

> Il giorno 30 mar 2016, alle ore 10:08, varun bhatnagar 
>  ha scritto:
> 
> Hi,
> 
> I am using OpenStack Juno on a multinode setup.
> When I did nova list I couldn't see any interfaces attached to few of my VMs 
> although in Dashboard they are visible.
> 
> -+
> | ID   | Name  | Status | Task State | 
> Power State | Networks
>  |
> +--+---+++-+--+
> | e111e5b6-4a90-4a3b-a465-19000fe1a81d | VM-3  | ACTIVE | -  | 
> Running | 
>  |
> | 78c465e9-09a6-477b-9374-9a5eb455ab2b | VM-4  | ACTIVE | -  | 
> Running | 
>  |
> | 6cfdef27-018a-4fd3-8f4f-856d804d415b | VM-5  | ACTIVE | -  | 
> Running | 
>  |
> | 94f4bddb-e2d5-48e8-88ae-169aba75ebd4 | VM-6  | ACTIVE | -  | 
> Running | 
>  |
> 
> | c72a4d9d-fcd1-4b12-90de-ec46fc950ad2 | VM-7 | ACTIVE | -  | Running 
> | internal=3001::b, 10.0.0.13, 192.168.154.68 
>  |
> +--+---+++-+--+
> 
> 
> Can anyone please tell me what is causing this and how to fix it?
> 
> BR,
> Varun
> 
> !DSPAM:1,56fb8b2b98152623519187!
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> !DSPAM:1,56fb8b2b98152623519187!


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

Re: [openstack-dev] [Heat] Meeting time

2016-03-30 Thread Thomas Herve

On Wed, Mar 30, 2016 at 10:13 AM, Thomas Herve  wrote:
> Hi all,
>
> I'd like to be able to attend at least one of the IRC meeting, and it
> doesn't really work right now. So if you'd like to come to meetings,
> please fill the following doodle:
> http://doodle.com/poll/4m6aicfnwuug86rs

The times are in UTC!

-- 
Thomas

__
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 list" doesn't show networks for few instances

2016-03-30 Thread Rikimaru Honjo


Do you use "2014.2.4" of Juno?
If your OpenStack version is older than "2014.2.4", you might be hit the 
following bug.

https://bugs.launchpad.net/nova/+bug/1407664



Rikimaru Honjo
honjo.rikim...@po.ntts.co.jp

On 2016/03/30 17:08, varun bhatnagar wrote:

Hi,

I am using OpenStack Juno on a multinode setup.
When I did nova list I couldn't see any interfaces attached to few of my
VMs although in Dashboard they are visible.

-+
| ID   | Name  | Status | Task State |
Power State | Networks
 |
+--+---+++-+--+
| e111e5b6-4a90-4a3b-a465-19000fe1a81d | VM-3  | ACTIVE | -  |
Running |
|
| 78c465e9-09a6-477b-9374-9a5eb455ab2b | VM-4  | ACTIVE | -  |
Running |
|
| 6cfdef27-018a-4fd3-8f4f-856d804d415b | VM-5  | ACTIVE | -  |
Running |
|
| 94f4bddb-e2d5-48e8-88ae-169aba75ebd4 | VM-6  | ACTIVE | -  |
Running |
|

| c72a4d9d-fcd1-4b12-90de-ec46fc950ad2 | VM-7 | ACTIVE | -  |
Running | internal=3001::b, 10.0.0.13, 192.168.154.68
|
+--+---+++-+--+


Can anyone please tell me what is causing this and how to fix it?

BR,
Varun



__
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] [Openstack] [OpenStack] "nova list" doesn't show networks for few instances

2016-03-30 Thread varun bhatnagar

Hello Remo,

No, there is just one user "admin" and when I gave --all-tenants it
returned the same output (without networks)

BR,
Varun

On Wed, Mar 30, 2016 at 10:20 AM, Remo Mattei  wrote:

> Wrong user?
>
> Try --all-tenants and see what shows up as an admin
>
> Inviato da iPhone
>
> > Il giorno 30 mar 2016, alle ore 10:08, varun bhatnagar <
> varun292...@gmail.com> ha scritto:
> >
> > Hi,
> >
> > I am using OpenStack Juno on a multinode setup.
> > When I did nova list I couldn't see any interfaces attached to few of my
> VMs although in Dashboard they are visible.
> >
> > -+
> > | ID   | Name  | Status | Task State
> | Power State | Networks
>  |
> >
> +--+---+++-+--+
> > | e111e5b6-4a90-4a3b-a465-19000fe1a81d | VM-3  | ACTIVE | -
> | Running |
>   |
> > | 78c465e9-09a6-477b-9374-9a5eb455ab2b | VM-4  | ACTIVE | -
> | Running |
>   |
> > | 6cfdef27-018a-4fd3-8f4f-856d804d415b | VM-5  | ACTIVE | -
> | Running |
>   |
> > | 94f4bddb-e2d5-48e8-88ae-169aba75ebd4 | VM-6  | ACTIVE | -
> | Running |
>   |
> >
> > | c72a4d9d-fcd1-4b12-90de-ec46fc950ad2 | VM-7 | ACTIVE | -  |
> Running | internal=3001::b, 10.0.0.13, 192.168.154.68
> |
> >
> +--+---+++-+--+
> >
> >
> > Can anyone please tell me what is causing this and how to fix it?
> >
> > BR,
> > Varun
> >
> > !DSPAM:1,56fb8b2b98152623519187!
> > ___
> > Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to : openst...@lists.openstack.org
> > Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
> >
> > !DSPAM:1,56fb8b2b98152623519187!
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] unit test failures due to new release of Routes package (v2.3)

Aditya Vaja wrote:

Hi,

I'm seeing unit test failures when I test locally after a fresh git clone
of neutron master.

$ ./run_tests.sh -V -f

Honestly, you should avoid using the script, and instead rely on tox. With
tox, requirements are properly constrained, so you would not be hit by the
issue.

log excerpt: http://paste.openstack.org/show/492384/

I update the requirements.txt to use 'Routes<2.0,>=1.12.3' and all the
tests work fine.
I see there was a new release (v2.3 ) of Routes on 28th March 2016 [1],
which seems to have caused the issue, specifically:

- Concatenation fix when using submappers with path prefixes. Multiple
submappers combined the path prefix inside the controller argument in
non-obvious ways. The controller argument will now be properly carried through
when using submappers. PR #28[2].

Is anyone else noticing the test failures?
Should I submit this requirements.txt change as a patch or should we pass
the required two args as the patch? I can do the requirement.txt change.
For the latter, somebody who knows what goes on in the extensions.py
__init__() should take a look.

I assume this will also affect the stable branches, since the Routes
package versin in requirements.txt in previous versions was same as in
master.

--
Aditya
[1]
https://routes.readthedocs.org/en/latest/changes.html#release-2-3-march-28-2016
[2]
https://github.com/bbangert/routes/pull/28/files?diff=unified#diff-b54de741c3f86d76eb4bce4a223054aaL154

__
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] Just make Mitaka deploy Liberty within the Liberty branch

2016-03-30 Thread Paul Bourke


+1

On 30/03/16 04:27, Steven Dake (stdake) wrote:

Dear cores,

inc0 has been investigating our backport options for 1.1.0 and they look
bleak.  At this time we would have to backport heka because of changes
in Docker 1.10.z which are incompatible with the syslog dev file.  We
had originally spoken about just taking Mitaka and placing it in
Liberty, validating the defaults directory of Ansible, fixing the repo
pointers, fixing the source pointers, and modifying containers as
necessary to make that happen.

I know this is vastly different then what we have discussed in the past
related to Liberty management, but beyond giving up entirely on Liberty
which is unacceptable to me, it seems like our only option.

The good news is we will be able to leverage all of the testing we have
done with liberty and all of the testing we have done developing Mitaka,
and have a smooth stable backport experience for Mitaka and Liberty.

Consider this proposal a +1 vote for me.  Our core team has 11 members,
which means we need 6 +1 votes in order for this new plan to pass.  Note
I see no other options, so abstaining or voting –1 is in essence
recommending abandonment of the Liberty branch.

I'll leave voting open for 7 days until Tuesday April 5th unless there
is a majority before then.  If  there is a majority prior to the voting
deadline, I'll close voting early but leave discussion open for those
that wish to have it.

We won't be having this happen again, as our Mitaka architecture is
stable and strong minus a few straggling bugs remaining.

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] Nominating Vikram Hosakot for Core Reviewer

2016-03-30 Thread Kwasniewska, Alicja

+1

-Original Message-
From: Ryan Hallisey [mailto:rhall...@redhat.com] 
Sent: Tuesday, March 29, 2016 6:40 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core 
Reviewer

+1

- Original Message -
From: "Paul Bourke" 
To: openstack-dev@lists.openstack.org
Sent: Tuesday, March 29, 2016 12:10:38 PM
Subject: Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core 
Reviewer

+1

On 29/03/16 17:07, Steven Dake (stdake) wrote:
> Hey folks,
>
> Consider this proposal a +1 in favor of Vikram joining the core 
> reviewer team.  His reviews are outstanding.  If he doesn’t have 
> anything useful to add to a review, he doesn't pile on the review with 
> more –1s which are slightly disheartening to people.  Vikram has 
> started a trend amongst the core reviewers of actually diagnosing gate 
> failures in peoples patches as opposed to saying gate failed please 
> fix.  He does this diagnosis in nearly every review I see, and if he 
> is stumped  he says so.  His 30 days review stats place him in pole 
> position and his 90 day review stats place him in second position.  Of 
> critical notice is that Vikram is ever-present on IRC which in my 
> professional experience is the #1 indicator of how well a core reviewer will 
> perform long term.
>Besides IRC and review requirements, we also have code requirements 
> for core reviewers.  Vikram has implemented only 10 patches so far, 
> butI feel he could amp this up if he had feature work to do.  At the 
> moment we are in a holding pattern on master development because we 
> need to fix Mitaka bugs.  That said Vikram is actively working on 
> diagnosing root causes of people's bugs in the IRC channel pretty much 
> 12-18 hours a day so we can ship Mitaka in a working bug-free state.
>
> Our core team consists of 11 people.  Vikram requires at minimum 6 +1 
> votes, with no veto –2 votes within a 7 day voting window to end on 
> April 7th.  If there is a veto vote prior to April 7th I will close 
> voting.  If there is a unanimous vote prior to April 7th, I will make 
> appropriate changes in gerrit.
>
> Regards
> -steve
>
> [1] http://stackalytics.com/report/contribution/kolla-group/30
> [2] http://stackalytics.com/report/contribution/kolla-group/90
>
>
> __
>  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 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] Just make Mitaka deploy Liberty within the Liberty branch

2016-03-30 Thread Kwasniewska, Alicja

+1


-Original Message-
From: Paul Bourke [mailto:paul.bou...@oracle.com] 
Sent: Wednesday, March 30, 2016 11:00 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty 
within the Liberty branch

+1

On 30/03/16 04:27, Steven Dake (stdake) wrote:
> Dear cores,
>
> inc0 has been investigating our backport options for 1.1.0 and they 
> look bleak.  At this time we would have to backport heka because of 
> changes in Docker 1.10.z which are incompatible with the syslog dev 
> file.  We had originally spoken about just taking Mitaka and placing 
> it in Liberty, validating the defaults directory of Ansible, fixing 
> the repo pointers, fixing the source pointers, and modifying 
> containers as necessary to make that happen.
>
> I know this is vastly different then what we have discussed in the 
> past related to Liberty management, but beyond giving up entirely on 
> Liberty which is unacceptable to me, it seems like our only option.
>
> The good news is we will be able to leverage all of the testing we 
> have done with liberty and all of the testing we have done developing 
> Mitaka, and have a smooth stable backport experience for Mitaka and Liberty.
>
> Consider this proposal a +1 vote for me.  Our core team has 11 
> members, which means we need 6 +1 votes in order for this new plan to 
> pass.  Note I see no other options, so abstaining or voting -1 is in 
> essence recommending abandonment of the Liberty branch.
>
> I'll leave voting open for 7 days until Tuesday April 5th unless there 
> is a majority before then.  If  there is a majority prior to the 
> voting deadline, I'll close voting early but leave discussion open for 
> those that wish to have it.
>
> We won't be having this happen again, as our Mitaka architecture is 
> stable and strong minus a few straggling bugs remaining.
>
> 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

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

[openstack-dev] [fuel][plugins][ovs] NSH Query

2016-03-30 Thread Vikram Choudhary

Hi Folks,

We were trying https://github.com/openstack/fuel-plugin-ovs.git, and has
below query:

*Our Setup:*
  SF
|

Classifier---SFF
-Destination
   |- vxlan-gpe tunnel with NSH -|

*Query:*
1. At SF, we want to receive the packet with NSH content but only the
payload is received as the 'NSH' part is removed when the vxlan header is
stripped off. In this regard, we would like to know what should be the OVS
flow-rule / Tunnel or equivalent config option for SFF, so that the NSH
header is retained in the packet while it's sent to the SF?

2. What is the use of "nsh_covert" option?

Thanks
Vikram
__
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] Nominating Vikram Hosakot for Core Reviewer

2016-03-30 Thread Kwasniewska, Alicja


+1


-Original Message-
From: Michal Rostecki [mailto:michal.roste...@gmail.com] 
Sent: Wednesday, March 30, 2016 7:18 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core 
Reviewer

+1

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

__
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] Austin Design Summit track layout

2016-03-30 Thread Vladimir Kozhukalov

On Wed, Mar 30, 2016 at 11:01 AM, Thierry Carrez 
wrote:

> John Dickinson wrote:
>
>> On Thursday, I'd like to proposed swapping Swift's 1:30pm session with
>> Fuel's 2:20pm session. This will give Swift a contiguous time block in the
>> afternoon, and Fuel's session would line up right after their full morning
>> (albeit after the lunch break).
>>
>> I have not had a chance to talk to anyone on the Fuel team about this.
>>
>
> John,
>
> You are giving a conference talk at 2:20pm on Thursday, which is why I
> left that as a hole in the Swift Design Summit schedule.
>
> Swapping is definitely possible, but I figured you would not intentionally
> create a conflict for you here ?

It is ok for us to swap these two slots.
__
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] Austin Design Summit track layout

See new version attached. This will be pushed to the official schedule 
tomorrow, so please reply here today if you see any major issue with it.


Changes:
- swapped the release and stable slots to accommodate mriedem
- moved Astara fishbowl to Thu morning to avoid conflict with Tacker
- moved OpenStackClient, Stable and Release to a larger fishbowl room

Cheers,

--
Thierry Carrez (ttx)


DSLayout-20160330.pdf
Description: Adobe PDF document
__
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] [Openstack] Problem after reboot fuel-master VM

2016-03-30 Thread Samer Machara

Hello, 
I have rebooted the "fuel-master" VM and after that, I cannot access the Fuel 
UI. What I am missing. Please check the image to see the error. 

Another question, How can I rediscover a node that was removed from the pool of 
available nodes, and also add new nodes to the pool. I clone a fuel-slave node 
but, it is not recognized by fuel 

Thanks in advance. 

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

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

2016-03-30 Thread Vladimir Kuklin

Hi, Vikram

++ plugin authors explicitly

On Wed, Mar 30, 2016 at 12:20 PM, Vikram Choudhary 
wrote:

> Hi Folks,
>
> We were trying https://github.com/openstack/fuel-plugin-ovs.git, and has
> below query:
>
> *Our Setup:*
>   SF
> |
>
> Classifier---SFF
> -Destination
>|- vxlan-gpe tunnel with NSH -|
>
> *Query:*
> 1. At SF, we want to receive the packet with NSH content but only the
> payload is received as the 'NSH' part is removed when the vxlan header is
> stripped off. In this regard, we would like to know what should be the
> OVS flow-rule / Tunnel or equivalent config option for SFF, so that the NSH
> header is retained in the packet while it's sent to the SF?
>
> 2. What is the use of "nsh_covert" option?
>
> Thanks
> Vikram
>
> __
> 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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@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] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

2016-03-30 Thread Igor Kalnitsky

Hey Fuelers,

I know that you probably wouldn't like to hear that, but in my opinion
Fuel has to stop using Shotgun. It's nothing more but a command runner
over SSH. Besides, it has well known issues such as retrieving remote
directories with broken symlinks inside.

So I propose to find a modern alternative and reuse it. If we stop
supporting Shotgun, we can spend extra time to focus on more important
things.

As an example, we can consider to use Ansible. It should not be tricky
to generate Ansible playbook instead of generating Shotgun one.
Ansible is a  well known tool for devops and cloud operators, and they
we will only benefit if we provide possibility to extend diagnostic
recipes in usual (for them) way. What do you think?

Thanks,
- Igor

On Tue, Mar 29, 2016 at 7:52 PM, Roman Prykhodchenko  wrote:
> Please, propose your options here then:
> https://etherpad.openstack.org/p/shotgun-rename
>
> 29 бер. 2016 р. о 18:15 Jay Pipes  написав(ла):
>
> On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote:
>
> Should we propose options and then arrange a poll?
>
>
> Yup, ++ :)
>
> 29 бер. 2016 р. о 16:40 Neil Jerram 
> написав(ла):
>
> On 29/03/16 15:17, Jay Pipes wrote:
>
> Hi!
>
> Once Shotgun is pulled out of Fuel, may I suggest renaming it to
> something different? I know in the past that Anita and a few others
> thought the name was not something we should really be encouraging in
> the OpenStack ecosystem.
>
> Just something to consider since it's being decoupled anyway and may be
> a good opportunity to rename at that point...
>
> Best,
> -jay
>
>
> +1
>
> 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
>
>
>
>
> __
> 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 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] [Openstack] Problem after reboot fuel-master VM

2016-03-30 Thread Vladimir Kuklin

Hi, Samer

It seems that Nailgun has not started. Could you please provide us with the
version of Fuel you are using? You can find logs for nailgun in:

for <9.0/pre-Mitaka versions
/var/log//nailgun/

for current Mitaka:

/var/log/nailgun/

On Wed, Mar 30, 2016 at 12:38 PM, Samer Machara <
samer.mach...@telecom-sudparis.eu> wrote:

> Hello,
>   I have rebooted the "fuel-master " VM and after that, I cannot access
> the Fuel UI. What I am missing. Please check the image to see the error.
>
> Another question,  How can I rediscover a node tha t was removed from
> the pool of available nodes, and also add new nodes to the pool. I clone a
> fuel-slave node but, it is not recognized by fuel
>
> Thanks in advance.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@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

[openstack-dev] [TripleO] Stable Branch policy for Liberty/Mitaka (revisited)

2016-03-30 Thread Steven Hardy

Hi all,

Some time ago we had a discussion re $subject [1] which I want to revisit,
because the stable/mitaka branches have now been created.

That thread, and various IRC discussions have led to (I believe) the
following consensus:

1. stable/mitaka will align with the normal stable/maint backport policy[2],
which is in general "bugfixes only".  The only exception to this is patches
that are required to enable upgrade from the stable to current version.

2. To align with the above, from now on, stable/liberty will also move to a
"bugfix only" mode, as we cannot allow an older stable branch to gain
features not present on stable/mitaka (or we regress on upgrade).

In the event non-bugfix patches are required folks may mail this list, or
raise a topic in the weekly meeting justifying a backport exception, but in
general I think our stance will be no, after our experience with stable/liberty.

Currently there are two possible exceptions we're considering, which are
things that just missed the mitaka branch deadline:

- Gnocchi integration [3]
- Plumgrid integration [4]

One additional request - please ensure all bugfix backports have a bug
referenced in the commit message, this will help us track which fixes are
resolved in the various branches.

Relatedly - when you raise or triage a bug, please tag it
"mitaka-backport-potential" if you belive it's a likely candidate for
stable backport (so we can track pending fixes which need to be resolved in
the various branches).

Any questions/comments please shout - thanks! :)

Steve

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-February/086249.html
[2] 
http://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-March/090721.html
[4] 
https://review.openstack.org/#/q/I07025f67ec3f3399aac4dcd10cc37e857772548b,n,z

__
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] [Shotgun] Decoupling Shotgun from Fuel


FWIW, as a naive bystander:

On 30/03/16 11:06, Igor Kalnitsky wrote:
> Hey Fuelers,
>
> I know that you probably wouldn't like to hear that, but in my opinion
> Fuel has to stop using Shotgun. It's nothing more but a command runner
> over SSH. Besides, it has well known issues such as retrieving remote
> directories with broken symlinks inside.

It makes sense to me that a command runner over SSH might not need to be 
a whole Fuel-specific component.

> So I propose to find a modern alternative and reuse it. If we stop
> supporting Shotgun, we can spend extra time to focus on more important
> things.
>
> As an example, we can consider to use Ansible. It should not be tricky
> to generate Ansible playbook instead of generating Shotgun one.
> Ansible is a  well known tool for devops and cloud operators, and they
> we will only benefit if we provide possibility to extend diagnostic
> recipes in usual (for them) way. What do you think?

But isn't Ansible also over-complicated for just running commands over SSH?

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] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

2016-03-30 Thread Roman Prykhodchenko

+1 to discarding shotgun. Should we register a BP for that?

> 30 бер. 2016 р. о 12:03 Igor Kalnitsky  написав(ла):
> 
> Hey Fuelers,
> 
> I know that you probably wouldn't like to hear that, but in my opinion
> Fuel has to stop using Shotgun. It's nothing more but a command runner
> over SSH. Besides, it has well known issues such as retrieving remote
> directories with broken symlinks inside.
> 
> So I propose to find a modern alternative and reuse it. If we stop
> supporting Shotgun, we can spend extra time to focus on more important
> things.
> 
> As an example, we can consider to use Ansible. It should not be tricky
> to generate Ansible playbook instead of generating Shotgun one.
> Ansible is a  well known tool for devops and cloud operators, and they
> we will only benefit if we provide possibility to extend diagnostic
> recipes in usual (for them) way. What do you think?
> 
> Thanks,
> - Igor
> 
> On Tue, Mar 29, 2016 at 7:52 PM, Roman Prykhodchenko  wrote:
>> Please, propose your options here then:
>> https://etherpad.openstack.org/p/shotgun-rename
>> 
>> 29 бер. 2016 р. о 18:15 Jay Pipes  написав(ла):
>> 
>> On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote:
>> 
>> Should we propose options and then arrange a poll?
>> 
>> 
>> Yup, ++ :)
>> 
>> 29 бер. 2016 р. о 16:40 Neil Jerram 
>> написав(ла):
>> 
>> On 29/03/16 15:17, Jay Pipes wrote:
>> 
>> Hi!
>> 
>> Once Shotgun is pulled out of Fuel, may I suggest renaming it to
>> something different? I know in the past that Anita and a few others
>> thought the name was not something we should really be encouraging in
>> the OpenStack ecosystem.
>> 
>> Just something to consider since it's being decoupled anyway and may be
>> a good opportunity to rename at that point...
>> 
>> Best,
>> -jay
>> 
>> 
>> +1
>> 
>> 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
>> 
>> 
>> 
>> 
>> __
>> 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 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [election][tc] Candidacy

2016-03-30 Thread Julien Danjou

Hi folks,

I hereby announce my candidacy for the OpenStack Technical Committee election.

Most of you probably know me by now, and for those who don't yet, let's say
I've been around for almost 5 years now in the OpenStack community. I am
currently acting as the PTL for Telemetry. I've been working on that project
for a while and been tacking technical debt as a member of the Oslo team for a
long time too.

I wrote a blog post about my view of the current state of the OpenStack project
as a whole, what I'd like to fix, and how I think the TC should behave.

I invite you to give it a quick read, and if you agree with what I wrote, I'd
like to encourage you to vote for me. And even to vote for other people whose
view might join mine. :)

  https://julien.danjou.info/blog/2016/openstack-schizophrenia

Cheers,
-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


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

Re: [openstack-dev] [Openstack-stable-maint][stable] Stable check of openstack/trove failed

Stable maintainers,

I'm happy to fix in Kilo if required, the issue is Routes 
2.3. It is a neat cherry-pick.

Please advise.

-amrith

> -Original Message-
> From: A mailing list for the OpenStack Stable Branch test reports.
> [mailto:openstack-stable-ma...@lists.openstack.org]
> Sent: Wednesday, March 30, 2016 2:14 AM
> To: openstack-stable-ma...@lists.openstack.org
> Subject: [Openstack-stable-maint] Stable check of openstack/trove failed
> 
> Build failed.
> 
> - periodic-trove-docs-kilo http://logs.openstack.org/periodic-
> stable/periodic-trove-docs-kilo/7617cd9/ : SUCCESS in 1m 11s
> - periodic-trove-python27-db-kilo http://logs.openstack.org/periodic-
> stable/periodic-trove-python27-db-kilo/5a9dc8d/ : FAILURE in 1m 09s
> - periodic-trove-docs-liberty http://logs.openstack.org/periodic-
> stable/periodic-trove-docs-liberty/6b08993/ : SUCCESS in 4m 10s
> - periodic-trove-python27-db-liberty http://logs.openstack.org/periodic-
> stable/periodic-trove-python27-db-liberty/595efcf/ : FAILURE in 1m 56s
> - periodic-trove-docs-mitaka http://logs.openstack.org/periodic-
> stable/periodic-trove-docs-mitaka/c2668d6/ : SUCCESS in 6m 23s
> - periodic-trove-python27-db-mitaka http://logs.openstack.org/periodic-
> stable/periodic-trove-python27-db-mitaka/acfe098/ : FAILURE in 8m 30s
> 
> ___
> Openstack-stable-maint mailing list
> openstack-stable-ma...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint

__
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] [Openstack] Problem after reboot fuel-master VM

2016-03-30 Thread Samer Machara

Hi Vladimir, 
I'm using fuel 7.0, Which log I need to see? 
- Original Message -

From: " Vladimir Kuklin vkuklin at mirantis.com 
To: "OpenStack Development Mailing List"  
Sent: Wed Mar 30 10:06:22 UTC 2016 
Subject: [Fuel] [Openstack] Problem after reboot fuel-master VM 
Hi, Samer

It seems that Nailgun has not started. Could you please provide us with the
version of Fuel you are using? You can find logs for nailgun in:

for <9.0/pre-Mitaka versions
/var/log//nailgun/

for current Mitaka:

/var/log/nailgun/ 
- Original Message -

From: "Samer Machara"  
To: "OpenStack Development Mailing List"  
Sent: Wednesday, March 30, 2016 11:38:44 AM 
Subject: [Fuel] [Openstack] Problem after reboot fuel-master VM 

Hello, 
I have rebooted the "fuel-master" VM and after that, I cannot access the Fuel 
UI. What I am missing. Please check the image to see the error. 

Another question, How can I rediscover a node that was removed from the pool of 
available nodes, and also add new nodes to the pool. I clone a fuel-slave node 
but, it is not recognized by fuel 

Thanks in advance. 

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

Re: [openstack-dev] [Fuel] [Openstack] Problem after reboot fuel-master VM

2016-03-30 Thread Samer Machara

Thanks, 
Problem solved by magic. It looks like, the nailgun service take some time to 
start up in my computer. 

- Original Message -

From: "Samer Machara"  
To: "OpenStack Development Mailing List"  
Sent: Wednesday, March 30, 2016 12:39:35 PM 
Subject: Re: [Fuel] [Openstack] Problem after reboot fuel-master VM 

Hi Vladimir, 
I'm using fuel 7.0, Which log I need to see? 
- Original Message -

From: " Vladimir Kuklin vkuklin at mirantis.com 
To: "OpenStack Development Mailing List"  
Sent: Wed Mar 30 10:06:22 UTC 2016 
Subject: [Fuel] [Openstack] Problem after reboot fuel-master VM 
Hi, Samer

It seems that Nailgun has not started. Could you please provide us with the
version of Fuel you are using? You can find logs for nailgun in:

for <9.0/pre-Mitaka versions
/var/log//nailgun/

for current Mitaka:

/var/log/nailgun/ 
- Original Message -

From: "Samer Machara"  
To: "OpenStack Development Mailing List"  
Sent: Wednesday, March 30, 2016 11:38:44 AM 
Subject: [Fuel] [Openstack] Problem after reboot fuel-master VM 

Hello, 
I have rebooted the "fuel-master" VM and after that, I cannot access the Fuel 
UI. What I am missing. Please check the image to see the error. 

Another question, How can I rediscover a node that was removed from the pool of 
available nodes, and also add new nodes to the pool. I clone a fuel-slave node 
but, it is not recognized by fuel 

Thanks in advance. 

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

Re: [openstack-dev] [fuel] Component Leads Elections

2016-03-30 Thread Vladimir Kozhukalov

Dmitry,

"No need to rush" does not mean we should postpone
team structure changes until Ocata. IMO, CL role
(when it is exposed to Fuel) contradicts to our
modularization activities. Fuel should be an aggregator
of components. What if we decide to use Ironic or
Neutron as Fuel components? Should we chose also
Ironic CL? NO! Ironic is an independent
project with its own PTL.

I agree with Mike that we could remove this CL
role in a month if have consensus. But does it
make any sense to chose CLs now and then
immediately remove this role? Probably, it is better
to make a decision right now. I'd really like to
see here in this ML thread opinions of our current
CLs and other people.



Vladimir Kozhukalov

On Tue, Mar 29, 2016 at 11:21 PM, Dmitry Borodaenko <
dborodae...@mirantis.com> wrote:

> On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote:
> > > I think this call is too late to change a structure for now. I suggest
> > > that we always respect the policy we've accepted, and follow it.
> > >
> > > If Component Leads role is under a question, then I'd continue the
> > > discussion, hear opinion of current component leads, and give this a
> time
> > > to be discussed. I'd have nothing against removing this role in a month
> > > from now if we reach a consensus on this topic - no need to wait for
> the
> > > cycle end.
> >
> > Sure, there is no need to rush. I'd also like to see current CL opinions.
>
> Considering that, while there's an ongoing discussion on how to change
> Fuel team structure for Ocata, there's also an apparent consensus that
> we still want to have component leads for Newton, I'd like to call once
> again for volunteers to self-nominate for component leads of
> fuel-library, fuel-web, and fuel-ui. We've got 2 days left until
> nomination period is over, and no volunteer so far :(
>
> --
> Dmitry Borodaenko
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][nova][stable][sr-iov] Status of physical_device_mappings

Seems like the explanation below indeed suggests that’s a regression for
Mitaka. We’ll track the bug for a backport. I don’t think that we can block
the initial Mitaka release for that though. So let’s work on the master fix
right now, and target the fix for Mitaka for one of the first minor updates
for the branch.

Ihar

Vladimir Eremin wrote:

Hi jay,

There was no ability to setup this configuration WITH Neutron SR-IOV ML2
agent in Liberty. That what you pointed out and you’re totally correct.

But in Liberty, you’re not required to use Neutron SR-IOV ML2 agent to
get this functionality works. And if you configure only nova-compute and
neutron-server (WITHOUT Neutron SR-IOV ML2 agent), you could achieve
desired configuration.

Basically:
* Liberty: you can use agent and you will be limited in physnets, or you
can use it without agent.

* Mitaka: you should use agent and you will be limited in physnets.

So, regression is introduced by making Neutron SR-IOV ML2 agent required.
And this easy-fix removes the problem.

--
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.

On Mar 23, 2016, at 11:01 PM, Jay Pipes wrote:

+tags for stable and nova

Hi Vladimir, comments inline. :)

On 03/21/2016 05:16 AM, Vladimir Eremin wrote:

Hey OpenStackers,

I’ve recently found out, that changing of use neutron sriov-agent in
Mitaka from optional to required[1] makes a kind of regression.

While I understand that it is important for you to be able to associate
more than one NIC to a physical network, I see no evidence that there
was a *regression* in Mitaka. I don't see any ability to specify more
than one NIC for a physical network in the Liberty Neutron SR-IOV ML2
agent:

https://github.com/openstack/neutron/blob/stable/liberty/neutron/common/utils.py#L223-L225

Before Mitaka, there was possible to use any number of NICs with one
Neutron physnet just by specifying pci_passthrough_whitelist in nova:

[default]
pci_passthrough_whitelist = { "devname": "eth3", "physical_network": "physnet2”},{ "devname":
"eth4", "physical_network": "physnet2”},

which means, that eth3 and eth4 will be used for physnet2 in some manner.

Yes, *in Nova*, however from what I can tell, this functionality never
existed in the parse_mappings() function in neutron.common.utils module.

In Mitaka, there also required to setup neutron sriov-agent as well:

[sriov_nic]
physical_device_mappings = physnet2:eth3

The problem actually is to unable to specify this mapping as
"physnet2:eth3,physnet2:eth4” due to implementation details, so it is
clearly a regression.

A regression means that a change broke some previously-working
functionality. This is not a regression, since there apparently was
never such functionality in Neutron.

I’ve filed bug[2] for it and proposed a patch[3]. Originally
physical_device_mappings is converted to dict, where physnet name goes
to key, and interface name to value:

parse_mappings('physnet2:eth3’)

{‘physnet2’: 'eth3’}

parse_mappings('physnet2:eth3,physnet2:eth4’)

ValueError: Key physnet2 in mapping: 'physnet2:eth4' not unique

I’ve changed it a bit, so interface name is stored in list, so now this
case is working:

parse_mappings_multi('physnet2:eth3,physnet2:eth4’)

{‘physnet2’: [‘eth3’, 'eth4’]}

I’d like to see this fix[3] in master and Mitaka branch.

I understand you really want this functionality in Mitaka. And I will
leave it up to the stable team to determine whether this code should be
backported to stable/mitaka. However, I will point out that this is a
new feature, not a bug fix for a regression. There is no regression
because the ability for Neutron to use more than one NIC with a physnet
was never supported as far as I can tell.

Best,
-jay

Moshe Levi also proposed to refactor this part of code to remove
physical_device_mappings and reuse data that nova provides somehow.
I’ll file the RFE as soon as I figure out how it should work.

[1]:
http://docs.openstack.org/liberty/networking-guide/adv_config_sriov.html

[2]: https://bugs.launchpad.net/neutron/+bug/1558626
[3]: https://review.openstack.org/294188

--
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage quest

[openstack-dev] [telemetry] Rescheduling IRC meetings

2016-03-30 Thread Julien Danjou

Hi folks,

I've recently noticed that our way of collaborating is now mostly done
asynchronously through Gerrit and the mailing list. Which is good since
it's easy for everyone to participate. Some synchronous discussion
happens in #openstack-telemetry, which is also a good thing since it's a
handy medium for that.

On the other hand, I've noted that our IRC meetings are being less and
less useful these last weeks. Most of them only ran for a few minutes,
and were essentially gordc doing his PTL smalltalk alone.

Therefore I would suggest to schedule those meetings every 2 weeks
rather than every week as it is currently.

Thoughts?

Cheers,
-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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

Re: [openstack-dev] [Fuel] [Openstack] Problem after reboot fuel-master VM

2016-03-30 Thread Adam Heczko

Samer my 2c are:
after Fuel node reboot just run 'docker ps -a' to get information if all
containers have been already running.

On Wed, Mar 30, 2016 at 1:07 PM, Samer Machara <
samer.mach...@telecom-sudparis.eu> wrote:

> Thanks,
>Problem solved by magic.  It looks like,  the nailgun service take some
> time to start up in my computer.
>
> --
> *From: *"Samer Machara" 
> *To: *"OpenStack Development Mailing List" <
> openstack-dev@lists.openstack.org>
> *Sent: *Wednesday, March 30, 2016 12:39:35 PM
> *Subject: *Re: [Fuel] [Openstack] Problem after reboot fuel-master VM
>
>
> Hi Vladimir,
>   I'm using fuel 7.0, Which log I need to see?
>
> --
> *From: *"*Vladimir Kuklin* vkuklin at mirantis.com
> 
> *To: *"OpenStack Development Mailing List" <
> openstack-dev@lists.openstack.org>
> *Sent: **Wed Mar 30 10:06:22 UTC 2016*
> *Subject: *[Fuel] [Openstack] Problem after reboot fuel-master VM
>
> Hi, Samer
>
> It seems that Nailgun has not started. Could you please provide us with the
> version of Fuel you are using? You can find logs for nailgun in:
>
> for <9.0/pre-Mitaka versions
> /var/log//nailgun/
>
> for current Mitaka:
>
> /var/log/nailgun/
>
> --
> *From: *"Samer Machara" 
> *To: *"OpenStack Development Mailing List" <
> openstack-dev@lists.openstack.org>
> *Sent: *Wednesday, March 30, 2016 11:38:44 AM
> *Subject: *[Fuel] [Openstack] Problem after reboot fuel-master VM
>
> Hello,
>   I have rebooted the "fuel-master" VM and after that, I cannot access the
> Fuel UI. What I am missing. Please check the image to see the error.
>
> Another question,  How can I rediscover a node that was removed from
> the pool of available nodes, and also add new nodes to the pool. I clone a
> fuel-slave node but, it is not recognized by fuel
>
> Thanks in advance.
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [trove] Trove team meeting today, 1800 UTC, #openstack-meeting-alt

We have weekly team meetings on Wednesdays at 18:00 UTC in 
#openstack-meeting-alt

Meeting agenda is at https://wiki.openstack.org/wiki/Meetings/TroveMeeting

We have a lengthy agenda for today so please review ahead of time.

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

Re: [openstack-dev] [telemetry] Rescheduling IRC meetings

2016-03-30 Thread Chris Dent


On Wed, 30 Mar 2016, Julien Danjou wrote:


Thoughts?


+1

I especially agree that asynch (gerrit and email) interaction is far
more accessible and productive.

Another option on the meetings would be to do what the cross project
meetings do: Only have the meeting if there are agenda items.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [telemetry] Rescheduling IRC meetings

2016-03-30 Thread Julien Danjou

On Wed, Mar 30 2016, Chris Dent wrote:

> Another option on the meetings would be to do what the cross project
> meetings do: Only have the meeting if there are agenda items.

That's a good idea, I'd be totally cool with that too. We could send a
mail indicating there would be meeting with a 1 week prior notice.

I can change the meeting page to inform people of that, if that's cool
with every one.

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

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

Re: [openstack-dev] [neutron] unit test failures due to new release of Routes package (v2.3)

Also:

https://review.openstack.org/298482

and it's children in stable/xyz

Thanks to Henry for helping review the Trove changes for this issue.

-amrith

> -Original Message-
> From: Henry Gessau [mailto:hen...@gessau.net]
> Sent: Tuesday, March 29, 2016 9:05 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [neutron] unit test failures due to new
> release of Routes package (v2.3)
> 
> https://launchpad.net/bugs/1563028
> https://review.openstack.org/298855
> 
> Aditya Vaja  wrote:
> > Hi,
> >
> > I'm seeing unit test failures when I test locally after a fresh git
> > clone of neutron master.
> >
> > $ ./run_tests.sh -V -f
> >
> > log excerpt: http://paste.openstack.org/show/492384/
> >
> > I update the requirements.txt to use 'Routes<2.0,>=1.12.3' and all the
> > tests work fine.
> > I see there was a new release (v2.3 ) of Routes on 28th March 2016
> > [1], which seems to have caused the issue, specifically:
> >  - Concatenation fix when using submappers with path prefixes.
> > Multiple submappers combined the path prefix inside the controller
> > argument in non-obvious ways. The controller argument will now be
> > properly carried through when using submappers. PR #28[2].
> >
> > Is anyone else noticing the test failures?
> > Should I submit this requirements.txt change as a patch or should we
> > pass the required two args as the patch? I can do the requirement.txt
> > change. For the latter, somebody who knows what goes on in the
> > extensions.py __init__() should take a look.
> >
> > I assume this will also affect the stable branches, since the Routes
> > package versin in requirements.txt in previous versions was same as in
> master.
> >
> > --
> > Aditya
> > [1]
> > https://routes.readthedocs.org/en/latest/changes.html#release-2-3-marc
> > h-28-2016 [2]
> > https://github.com/bbangert/routes/pull/28/files?diff=unified#diff-b54
> > de741c3f86d76eb4bce4a223054aaL154
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

2016-03-30 Thread Igor Kalnitsky

Neil Jerram wrote:
> But isn't Ansible also over-complicated for just running commands over SSH?

It may be not so "simple" to ignore that. Ansible has a lot of modules
which might be very helpful. For instance, Shotgun makes a database
dump and there're Ansible modules with the same functionality [1].

Don't think I advocate Ansible as a replacement. My point is, let's
think about reusing ready solutions. :)

- igor


[1]: http://docs.ansible.com/ansible/list_of_database_modules.html

On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram  wrote:
>
> FWIW, as a naive bystander:
>
> On 30/03/16 11:06, Igor Kalnitsky wrote:
>> Hey Fuelers,
>>
>> I know that you probably wouldn't like to hear that, but in my opinion
>> Fuel has to stop using Shotgun. It's nothing more but a command runner
>> over SSH. Besides, it has well known issues such as retrieving remote
>> directories with broken symlinks inside.
>
> It makes sense to me that a command runner over SSH might not need to be
> a whole Fuel-specific component.
>
>> So I propose to find a modern alternative and reuse it. If we stop
>> supporting Shotgun, we can spend extra time to focus on more important
>> things.
>>
>> As an example, we can consider to use Ansible. It should not be tricky
>> to generate Ansible playbook instead of generating Shotgun one.
>> Ansible is a  well known tool for devops and cloud operators, and they
>> we will only benefit if we provide possibility to extend diagnostic
>> recipes in usual (for them) way. What do you think?
>
> But isn't Ansible also over-complicated for just running commands over SSH?
>
> 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

__
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] [release][all] What is upper-constraints.txt?

2016-03-30 Thread Davanum Srinivas

Folks,

Quick primer/refresh because of some gate/CI issues we saw last few
days with Routes===2.3

upper-constraints.txt is the current set of all the global libraries
that should be used by all the CI jobs.

This file is in the openstack/requirements repo:
http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt
http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/mitaka

Anyone working on a project, please ensure that all CI jobs respect
constraints, example from trove below. If jobs don't respect
constraints then they are more likely to break:
https://review.openstack.org/#/c/298850/

Anyone deploying openstack, please consult this file as it's the one
*sane* set of libraries that we test with.

Yes, global-requirements.txt has the ranges that end up in project
requirements files. However, upper-constraints.txt is what we test for
sure in OpenStack CI.

Thanks,
Dims

-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [Openstack] Problem after reboot fuel-master VM

2016-03-30 Thread Vladimir Kuklin

Samer, you could always use `dockerctl check all|` command.

On Wed, Mar 30, 2016 at 2:47 PM, Adam Heczko  wrote:

> Samer my 2c are:
> after Fuel node reboot just run 'docker ps -a' to get information if all
> containers have been already running.
>
> On Wed, Mar 30, 2016 at 1:07 PM, Samer Machara <
> samer.mach...@telecom-sudparis.eu> wrote:
>
>> Thanks,
>>Problem solved by magic.  It looks like,  the nailgun service take
>> some time to start up in my computer.
>>
>> --
>> *From: *"Samer Machara" 
>> *To: *"OpenStack Development Mailing List" <
>> openstack-dev@lists.openstack.org>
>> *Sent: *Wednesday, March 30, 2016 12:39:35 PM
>> *Subject: *Re: [Fuel] [Openstack] Problem after reboot fuel-master VM
>>
>>
>> Hi Vladimir,
>>   I'm using fuel 7.0, Which log I need to see?
>>
>> --
>> *From: *"*Vladimir Kuklin* vkuklin at mirantis.com
>> 
>> *To: *"OpenStack Development Mailing List" <
>> openstack-dev@lists.openstack.org>
>> *Sent: **Wed Mar 30 10:06:22 UTC 2016*
>> *Subject: *[Fuel] [Openstack] Problem after reboot fuel-master VM
>>
>> Hi, Samer
>>
>> It seems that Nailgun has not started. Could you please provide us with the
>> version of Fuel you are using? You can find logs for nailgun in:
>>
>> for <9.0/pre-Mitaka versions
>> /var/log//nailgun/
>>
>> for current Mitaka:
>>
>> /var/log/nailgun/
>>
>> --
>> *From: *"Samer Machara" 
>> *To: *"OpenStack Development Mailing List" <
>> openstack-dev@lists.openstack.org>
>> *Sent: *Wednesday, March 30, 2016 11:38:44 AM
>> *Subject: *[Fuel] [Openstack] Problem after reboot fuel-master VM
>>
>> Hello,
>>   I have rebooted the "fuel-master" VM and after that, I cannot access
>> the Fuel UI. What I am missing. Please check the image to see the error.
>>
>> Another question,  How can I rediscover a node that was removed from
>> the pool of available nodes, and also add new nodes to the pool. I clone a
>> fuel-slave node but, it is not recognized by fuel
>>
>> Thanks in advance.
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@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

[openstack-dev] [neutron] PBAM Extension RFE

2016-03-30 Thread Boden Russell

I recently added a Neutron RFE [1] that proposes a new extension called
Pluggable Backend Association Mappings (PBAM). This admin-based
extension allows consumers to view Neutron / backend resource mappings,
quickly identify mappings that are out of sync and remediate them.

If this sounds interesting to you, please join us on the RFE [1] for a
discussion and see [2] for a video demo and [3] for the PoC repo that
contains detailed documentation about the extension.

Thanks

[1] https://bugs.launchpad.net/neutron/+bug/1563538
[2] https://www.youtube.com/watch?v=qAY8U8vgbzc
[3] https://github.com/bodenr/neutron/tree/feature/pbam

__
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] [Shotgun] Decoupling Shotgun from Fuel

On 30/03/16 13:35, Igor Kalnitsky wrote:
> Neil Jerram wrote:
>> But isn't Ansible also over-complicated for just running commands over SSH?
>
> It may be not so "simple" to ignore that. Ansible has a lot of modules
> which might be very helpful. For instance, Shotgun makes a database
> dump and there're Ansible modules with the same functionality [1].
>
> Don't think I advocate Ansible as a replacement. My point is, let's
> think about reusing ready solutions. :)

Agreed.
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] [release][all] What is upper-constraints.txt?

2016-03-30 Thread Andreas Jaeger

On 2016-03-30 14:33, Davanum Srinivas wrote:
> Folks,
> 
> Quick primer/refresh because of some gate/CI issues we saw last few
> days with Routes===2.3
> 
> upper-constraints.txt is the current set of all the global libraries
> that should be used by all the CI jobs.

We're not ready yet for such a general recommendation, see below for
some details.

> This file is in the openstack/requirements repo:
> http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt
> http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/mitaka
> 
> Anyone working on a project, please ensure that all CI jobs respect
> constraints, example from trove below. If jobs don't respect
> constraints then they are more likely to break:
> https://review.openstack.org/#/c/298850/
> 
> Anyone deploying openstack, please consult this file as it's the one
> *sane* set of libraries that we test with.
> 
> Yes, global-requirements.txt has the ranges that end up in project
> requirements files. However, upper-constraints.txt is what we test for
> sure in OpenStack CI.


Note that upper-constraints is not ready for full usage in the project.
It only works in check and gate jobs but especially does not work in
post jobs. If you implement it improperly, your jobs will fail - and
post jobs will fail silently (see also [1] for an infra discussion).
Before infra can support this everywhere, our tools need to be fixed to
handle constraints in all queues.

Right now, I consider upper-constraints experimental since it does not
work for all queues and is not fool-proof. So, if you go down this road,
triple check that *all* your jobs do the right thing,

Andreas

[1]
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-15-19.03.html



-- 
 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] [release][all][ptls] the plan for the final week of the Mitaka release

2016-03-30 Thread Doug Hellmann


Folks,

We are approaching the final week of the Mitaka release cycle, and
the release team wants to make sure everyone is clear about what
will be happening and what the policies for changes are.

First, a few dates:

* Tomorrow 31 March is the final day for requesting release
  candidates for projects following the milestone release model.

* Friday 1 April is the last day for requesting full releases for
  service projects following the intermediary release model.

* Early next Thursday, 7 April, we will tag the most recent release
  candidate for each milestone project as the final release and
  announce that Mitaka has been released.

During the week between 31 March and 7 April, the release team will
reject or postpone requests for new library releases and new service
release candidates by default. Only truly critical bug fixes (which
could not be fixed post-release, as determined by the release team)
may end up triggering releases during this time.

Although we will be extremely picky about which changes can go into
new release candidates, critical fixes will be considered. It is
better to have no extraneous changes merged into stable/mitaka
during this period to avoid having to revert a non-critical change
in order to prepare a new release candidate for a critical issue.
Please do not approve patches unless they are for CRITICAL fixes.
The release team reserves the right to refuse to release a project
with extraneous changes added.

I have some personal travel planned early next week. While I'm
unavailable, Thierry is going to manage the release team and release
process. If he tells you "no", don't expect me to tell you "yes".

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] [release][all] What is upper-constraints.txt?

2016-03-30 Thread Jim Rollenhagen

On Wed, Mar 30, 2016 at 08:33:06AM -0400, Davanum Srinivas wrote:
> Folks,
> 
> Quick primer/refresh because of some gate/CI issues we saw last few
> days with Routes===2.3
> 
> upper-constraints.txt is the current set of all the global libraries
> that should be used by all the CI jobs.
> 
> This file is in the openstack/requirements repo:
> http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt
> http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/mitaka
> 
> Anyone working on a project, please ensure that all CI jobs respect
> constraints, example from trove below. If jobs don't respect
> constraints then they are more likely to break:
> https://review.openstack.org/#/c/298850/

While I agree that projects should do this, do keep in mind that
projects that do not run tests on openstack/requirements changes still
have plenty of room for breaks when u-c changes are merged. :)

// jim

> 
> Anyone deploying openstack, please consult this file as it's the one
> *sane* set of libraries that we test with.
> 
> Yes, global-requirements.txt has the ranges that end up in project
> requirements files. However, upper-constraints.txt is what we test for
> sure in OpenStack CI.
> 
> Thanks,
> Dims
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> 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] [magnum] Discuss the blueprint "support-private-registry"

2016-03-30 Thread Ricardo Rocha

Hi.

On Wed, Mar 30, 2016 at 3:59 AM, Eli Qiao  wrote:
>
> Hi Hongbin
>
> Thanks for starting this thread,
>
>
>
> I initial propose this bp because I am in China which is behind China great
> wall and can not have access of gcr.io directly, after checking our
> cloud-init script, I see that
>
> lots of code are *hard coded* to using gcr.io, I personally though this is
> not good idea. We can not force user/customer to have internet access in
> their environment.
>
> I proposed to use insecure-registry to give customer/user (Chinese or whom
> doesn't have gcr.io access) a chance to switch use their own
> insecure-registry to deploy
> k8s/swarm bay.
>
> For your question:
>>  Is the private registry secure or insecure? If secure, how to handle
>> the authentication secrets. If insecure, is it OK to connect a secure bay to
>> an insecure registry?
> An insecure-resigtry should be 'secure' one, since customer need to setup it
> and make sure it's clear one and in this case, they could be a private
> cloud.
>
>>  Should we provide an instruction for users to pre-install the private
>> registry? If not, how to verify the correctness of this feature?
>
> The simply way to pre-install private registry is using insecure-resigtry
> and docker.io has very simple steps to start it [1]
> for other, docker registry v2 also supports using TLS enable mode but this
> will require to tell docker client key and crt file which will make
> "support-private-registry" complex.
>
> [1] https://docs.docker.com/registry/
> [2]https://docs.docker.com/registry/deploying/

'support-private-registry' and 'allow-insecure-registry' sound different to me.

We're using an internal docker registry at CERN (v2, TLS enabled), and
have the magnum nodes setup to use it.

We just install our CA certificates in the nodes (cp to
etc/pki/ca-trust/source/anchors/, update-ca-trust) - had to change the
HEAT templates for that, and submitted a blueprint to be able to do
similar things in a cleaner way:
https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig

That's all that is needed, the images are then prefixed with the
registry dns location when referenced - example:
docker.cern.ch/my-fancy-image.

Things we found on the way:
- registry v2 doesn't seem to allow anonymous pulls (you can always
add an account with read-only access everywhere, but it means you need
to always authenticate at least with this account)
https://github.com/docker/docker/issues/17317
- swarm 1.1 and kub8s 1.0 allow authentication to the registry from
the client (which was good news, and it works fine), handy if you want
to push/pull with authentication.

Cheers,
  Ricardo

>
>
>
> On 2016年03月30日 07:23, Hongbin Lu wrote:
>
> Hi team,
>
>
>
> This is the item we didn’t have time to discuss in our team meeting, so I
> started the discussion in here.
>
>
>
> Here is the blueprint:
> https://blueprints.launchpad.net/magnum/+spec/support-private-registry . Per
> my understanding, the goal of the BP is to allow users to specify the url of
> their private docker registry where the bays pull the kube/swarm images (if
> they are not able to access docker hub or other public registry). An
> assumption is that users need to pre-install their own private registry and
> upload all the required images to there. There are several potential issues
> of this proposal:
>
> · Is the private registry secure or insecure? If secure, how to
> handle the authentication secrets. If insecure, is it OK to connect a secure
> bay to an insecure registry?
>
> · Should we provide an instruction for users to pre-install the
> private registry? If not, how to verify the correctness of this feature?
>
>
>
> Thoughts?
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Best Regards, Eli Qiao (乔立勇)
> Intel OTC China
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

2016-03-30 Thread Vladimir Kozhukalov

Igor,

I can not agree more. Wherever possible we should
use existent mature solutions. Ansible is really
convenient and well known solution, let's try to
use it.

Yet another thing should be taken into account.
One of Shotgun features is diagnostic report
that could then be attached to bugs to identify
the content of env. This report could also be
used to reproduce env and then fight a bug.
I'd like we to have this kind of report.
Is it possible to implement such a feature
using Ansible? If yes, then let's switch to Ansible
as soon as possible.



Vladimir Kozhukalov

On Wed, Mar 30, 2016 at 3:31 PM, Igor Kalnitsky 
wrote:

> Neil Jerram wrote:
> > But isn't Ansible also over-complicated for just running commands over
> SSH?
>
> It may be not so "simple" to ignore that. Ansible has a lot of modules
> which might be very helpful. For instance, Shotgun makes a database
> dump and there're Ansible modules with the same functionality [1].
>
> Don't think I advocate Ansible as a replacement. My point is, let's
> think about reusing ready solutions. :)
>
> - igor
>
>
> [1]: http://docs.ansible.com/ansible/list_of_database_modules.html
>
> On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram 
> wrote:
> >
> > FWIW, as a naive bystander:
> >
> > On 30/03/16 11:06, Igor Kalnitsky wrote:
> >> Hey Fuelers,
> >>
> >> I know that you probably wouldn't like to hear that, but in my opinion
> >> Fuel has to stop using Shotgun. It's nothing more but a command runner
> >> over SSH. Besides, it has well known issues such as retrieving remote
> >> directories with broken symlinks inside.
> >
> > It makes sense to me that a command runner over SSH might not need to be
> > a whole Fuel-specific component.
> >
> >> So I propose to find a modern alternative and reuse it. If we stop
> >> supporting Shotgun, we can spend extra time to focus on more important
> >> things.
> >>
> >> As an example, we can consider to use Ansible. It should not be tricky
> >> to generate Ansible playbook instead of generating Shotgun one.
> >> Ansible is a  well known tool for devops and cloud operators, and they
> >> we will only benefit if we provide possibility to extend diagnostic
> >> recipes in usual (for them) way. What do you think?
> >
> > But isn't Ansible also over-complicated for just running commands over
> SSH?
> >
> > 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
>
> __
> 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] [telemetry] Rescheduling IRC meetings

2016-03-30 Thread gordon chung

On 30/03/2016 8:06 AM, Julien Danjou wrote:
> On Wed, Mar 30 2016, Chris Dent wrote:
>
>> Another option on the meetings would be to do what the cross project
>> meetings do: Only have the meeting if there are agenda items.
>
> That's a good idea, I'd be totally cool with that too. We could send a
> mail indicating there would be meeting with a 1 week prior notice.
>

you don't like watching me talk to myself?

i believe this problem arises mainly at the beginning and end of cycle 
where we don't have any issues regarding blueprints as they were just 
discussed or won't be discussed. it also doesn't help that the meeting 
time is tied to North America when most of our devs are not here.

that said, i do prefer following the cross project model. when should we 
assign cut off for meeting items? we shouldn't make cutoff so late that 
it causes people to sit around waiting to see if there's a meeting or not.

cheers,

-- 
gord

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

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

2016-03-30 Thread Doug Hellmann



On Wed, Mar 30, 2016, at 03:37 AM, Thomas Goirand wrote:
> On 03/29/2016 08:33 PM, Doug Hellmann wrote:
> > If the core doc team isn't able to help you maintain it, maybe it's a
> > candidate for a separate guide, just like we're discussing for projects
> > that aren't part of the DefCore set included in the main guide.
> > 
> > Doug
> 
> This is exactly what I don't want. Only installing the packages
> themselves is different. Like for example, "apt-get install foo" and
> answering a few debconf prompts is often enough to get packages to work,
> without the need for manual setup of dbs, or rabbitMQ credentials. But
> that's maybe 20% of the install-guide, and the rest of is left
> untouched, with no conditionals. For example the description of the
> services, testing them after install, etc. Having a separated guide
> would mean that someone would be left to write a full install-guide from
> scratch, alone. That isn't desirable.
> 
> It is also my hope that the packaging on upstream infra will get going.
> If it does, it will make more sense to get the Debian guide up to speed,
> and probably there will be more contributors.

Perhaps that common content should be a separate guide? I don't know the
best solution, but I don't think requiring any one team to keep up with
*everything* needed to install all projects on all platforms using all
available tools is the right approach. See Conway's Law.

Doug

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

__
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] [magnum][kuryr] Shared session in design summit

2016-03-30 Thread Hongbin Lu

Gal,

Thursday 4:10 – 4:50 conflicts with a Magnum workroom session, but we can 
choose from:

· 11:00 – 11:40

· 11:50 – 12:30

· 3:10 – 3:50

Please let us know if some of the slots don’t work well with your schedule.

Best regards,
Hongbin

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: March-30-16 2:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][kuryr] Shared session in design summit

Anything you pick is fine with me, Kuryr fishbowl session is on Thursday 4:10 - 
4:50, i personally
think the Magnum integration is important enough and i dont mind using this 
time for the session as well.

Either way i am also ok with the 11-11:40 and the 11:50-12:30 sessions or the 
3:10-3:50

On Tue, Mar 29, 2016 at 11:32 PM, Hongbin Lu 
mailto:hongbin...@huawei.com>> wrote:
Hi all,

As discussed before, our team members want to establish a shared session 
between Magnum and Kuryr. We expected a lot of attendees in the session so we 
need a large room (fishbowl). Currently, Kuryr has only 1 fishbowl session, and 
they possibly need it for other purposes. A solution is to promote one of the 
Magnum fishbowl session to be the shared session, or leverage one of the free 
fishbowl slot. The schedule is as below.

Please vote your favorite time slot: http://doodle.com/poll/zuwercgnw2uecs5y .

Magnum fishbowl session:

• 11:00 - 11:40 (Thursday)

• 11:50 - 12:30

• 1:30 - 2:10

• 2:20 - 3:00

• 3:10 - 3:50

Free fishbowl slots:

• 9:00 – 9:40 (Thursday)

• 9:50 – 10:30

• 3:10 – 3:50 (conflict with Magnum session)

• 4:10 – 4:50 (conflict with Magnum session)

• 5:00 – 5:40 (conflict with Magnum session)

Best regards,
Hongbin

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



--
Best Regards ,

The G.
__
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] Mitaka RC packages for openSUSE and SLES available

2016-03-30 Thread Thomas Bechtold

Hi,

In the last few weeks we've been working hard on stabilizing the Mitaka
packages, and the packages currently available in Cloud:OpenStack:Mitaka
[0] pass early testing.

Feel free to try them out by adding the repository:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Mitaka/$DI
STRO/

to your repository list. We currently maintain + test the packages for
SLE 12SP1 and openSUSE Leap 42.1.
We also started to automatically  track the stable/mitaka branches for
the different services so the packages are automatically updated when CI
passes.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks !

Have a lot of fun,
Tom

__
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] [Shotgun] Decoupling Shotgun from Fuel

2016-03-30 Thread Adam Heczko

Osquery [1] could also be considered as providing a lot of useful
informations in a convenient way.

[1] https://osquery.io/


On Wed, Mar 30, 2016 at 3:20 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Igor,
>
> I can not agree more. Wherever possible we should
> use existent mature solutions. Ansible is really
> convenient and well known solution, let's try to
> use it.
>
> Yet another thing should be taken into account.
> One of Shotgun features is diagnostic report
> that could then be attached to bugs to identify
> the content of env. This report could also be
> used to reproduce env and then fight a bug.
> I'd like we to have this kind of report.
> Is it possible to implement such a feature
> using Ansible? If yes, then let's switch to Ansible
> as soon as possible.
>
> 
>
> Vladimir Kozhukalov
>
> On Wed, Mar 30, 2016 at 3:31 PM, Igor Kalnitsky 
> wrote:
>
>> Neil Jerram wrote:
>> > But isn't Ansible also over-complicated for just running commands over
>> SSH?
>>
>> It may be not so "simple" to ignore that. Ansible has a lot of modules
>> which might be very helpful. For instance, Shotgun makes a database
>> dump and there're Ansible modules with the same functionality [1].
>>
>> Don't think I advocate Ansible as a replacement. My point is, let's
>> think about reusing ready solutions. :)
>>
>> - igor
>>
>>
>> [1]: http://docs.ansible.com/ansible/list_of_database_modules.html
>>
>> On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram 
>> wrote:
>> >
>> > FWIW, as a naive bystander:
>> >
>> > On 30/03/16 11:06, Igor Kalnitsky wrote:
>> >> Hey Fuelers,
>> >>
>> >> I know that you probably wouldn't like to hear that, but in my opinion
>> >> Fuel has to stop using Shotgun. It's nothing more but a command runner
>> >> over SSH. Besides, it has well known issues such as retrieving remote
>> >> directories with broken symlinks inside.
>> >
>> > It makes sense to me that a command runner over SSH might not need to be
>> > a whole Fuel-specific component.
>> >
>> >> So I propose to find a modern alternative and reuse it. If we stop
>> >> supporting Shotgun, we can spend extra time to focus on more important
>> >> things.
>> >>
>> >> As an example, we can consider to use Ansible. It should not be tricky
>> >> to generate Ansible playbook instead of generating Shotgun one.
>> >> Ansible is a  well known tool for devops and cloud operators, and they
>> >> we will only benefit if we provide possibility to extend diagnostic
>> >> recipes in usual (for them) way. What do you think?
>> >
>> > But isn't Ansible also over-complicated for just running commands over
>> SSH?
>> >
>> > 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
>>
>> __
>> 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
>
>


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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

2016-03-30 Thread Tomasz 'Zen' Napierala

Hi,

Do we have any requirements for the new tool? Do we know what we don’t like 
about current implementation, what should be avoided, etc.? Before that we can 
only speculate.
From my ops experience, shotgun like tools will not work conveniently on medium 
to big environments. Even on medium env amount of logs is just too huge to 
handle by such simple tool. In such environments better pattern is to use 
dedicated log collection / analysis tool, just like StackLight.
At the other hand I’m not sure if ansible is the right tool for that. It has 
some features (like ‘fetch’ command) but in general it’s a configuration 
management tool, and I’m not sure how it would act under such heavy load.

Regards,

> On 30 Mar 2016, at 15:20, Vladimir Kozhukalov  
> wrote:
> 
> Igor,
> 
> I can not agree more. Wherever possible we should
> use existent mature solutions. Ansible is really
> convenient and well known solution, let's try to 
> use it. 
> 
> Yet another thing should be taken into account. 
> One of Shotgun features is diagnostic report
> that could then be attached to bugs to identify 
> the content of env. This report could also be 
> used to reproduce env and then fight a bug. 
> I'd like we to have this kind of report. 
> Is it possible to implement such a feature
> using Ansible? If yes, then let's switch to Ansible
> as soon as possible.
> 
> 
> 
> Vladimir Kozhukalov
> 
> On Wed, Mar 30, 2016 at 3:31 PM, Igor Kalnitsky  
> wrote:
> Neil Jerram wrote:
> > But isn't Ansible also over-complicated for just running commands over SSH?
> 
> It may be not so "simple" to ignore that. Ansible has a lot of modules
> which might be very helpful. For instance, Shotgun makes a database
> dump and there're Ansible modules with the same functionality [1].
> 
> Don't think I advocate Ansible as a replacement. My point is, let's
> think about reusing ready solutions. :)
> 
> - igor
> 
> 
> [1]: http://docs.ansible.com/ansible/list_of_database_modules.html
> 
> On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram  
> wrote:
> >
> > FWIW, as a naive bystander:
> >
> > On 30/03/16 11:06, Igor Kalnitsky wrote:
> >> Hey Fuelers,
> >>
> >> I know that you probably wouldn't like to hear that, but in my opinion
> >> Fuel has to stop using Shotgun. It's nothing more but a command runner
> >> over SSH. Besides, it has well known issues such as retrieving remote
> >> directories with broken symlinks inside.
> >
> > It makes sense to me that a command runner over SSH might not need to be
> > a whole Fuel-specific component.
> >
> >> So I propose to find a modern alternative and reuse it. If we stop
> >> supporting Shotgun, we can spend extra time to focus on more important
> >> things.
> >>
> >> As an example, we can consider to use Ansible. It should not be tricky
> >> to generate Ansible playbook instead of generating Shotgun one.
> >> Ansible is a  well known tool for devops and cloud operators, and they
> >> we will only benefit if we provide possibility to extend diagnostic
> >> recipes in usual (for them) way. What do you think?
> >
> > But isn't Ansible also over-complicated for just running commands over SSH?
> >
> > 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
> 
> __
> 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

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
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] [magnum] Discuss the blueprint"support-private-registry"

2016-03-30 Thread Kai Qiang Wu

I agree to that support-private-registry should be secure. As insecure
seems not much useful for production use.
Also I understood the point setup related CA could be diffcult than normal
HTTP, but we want to know if
https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig

Could address the issue and make templates clearer to understood ? If
related patch or spec proposed, we are glad to review and make it better.




Thanks

Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   Ricardo Rocha 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   30/03/2016 09:09 pm
Subject:Re: [openstack-dev] [magnum] Discuss the
blueprint   "support-private-registry"



Hi.

On Wed, Mar 30, 2016 at 3:59 AM, Eli Qiao  wrote:
>
> Hi Hongbin
>
> Thanks for starting this thread,
>
>
>
> I initial propose this bp because I am in China which is behind China
great
> wall and can not have access of gcr.io directly, after checking our
> cloud-init script, I see that
>
> lots of code are *hard coded* to using gcr.io, I personally though this
is
> not good idea. We can not force user/customer to have internet access in
> their environment.
>
> I proposed to use insecure-registry to give customer/user (Chinese or
whom
> doesn't have gcr.io access) a chance to switch use their own
> insecure-registry to deploy
> k8s/swarm bay.
>
> For your question:
>>  Is the private registry secure or insecure? If secure, how to
handle
>> the authentication secrets. If insecure, is it OK to connect a secure
bay to
>> an insecure registry?
> An insecure-resigtry should be 'secure' one, since customer need to setup
it
> and make sure it's clear one and in this case, they could be a private
> cloud.
>
>>  Should we provide an instruction for users to pre-install the private
>> registry? If not, how to verify the correctness of this feature?
>
> The simply way to pre-install private registry is using insecure-resigtry
> and docker.io has very simple steps to start it [1]
> for other, docker registry v2 also supports using TLS enable mode but
this
> will require to tell docker client key and crt file which will make
> "support-private-registry" complex.
>
> [1] https://docs.docker.com/registry/
> [2]https://docs.docker.com/registry/deploying/

'support-private-registry' and 'allow-insecure-registry' sound different to
me.

We're using an internal docker registry at CERN (v2, TLS enabled), and
have the magnum nodes setup to use it.

We just install our CA certificates in the nodes (cp to
etc/pki/ca-trust/source/anchors/, update-ca-trust) - had to change the
HEAT templates for that, and submitted a blueprint to be able to do
similar things in a cleaner way:
https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig

That's all that is needed, the images are then prefixed with the
registry dns location when referenced - example:
docker.cern.ch/my-fancy-image.

Things we found on the way:
- registry v2 doesn't seem to allow anonymous pulls (you can always
add an account with read-only access everywhere, but it means you need
to always authenticate at least with this account)
https://github.com/docker/docker/issues/17317
- swarm 1.1 and kub8s 1.0 allow authentication to the registry from
the client (which was good news, and it works fine), handy if you want
to push/pull with authentication.

Cheers,
  Ricardo

>
>
>
> On 2016年03月30日 07:23, Hongbin Lu wrote:
>
> Hi team,
>
>
>
> This is the item we didn’t have time to discuss in our team meeting, so I
> started the discussion in here.
>
>
>
> Here is the blueprint:
> https://blueprints.launchpad.net/magnum/+spec/support-private-registry .
Per
> my understanding, the goal of the BP is to allow users to specify the url
of
> their private docker registry where the bays pull the kube/swarm images
(if
> they are not able to access docker hub or other public registry). An
> assumption is that users need to pre-install their own private registry
and
> upload all the required images to there. There are several potential
issues
> of this proposal:
>
> ・ Is the private registry secure or insecure? If secure, how to
> handle the authentication secrets. If insecure, is it OK to connect a
secure
> bay to an insecure registry?
>
> ・ Should we provide an instruction for users to pre-install the
> private registry? If not, how to verify the correctness of this feature?
>
>
>
> Thoughts?
>
>
>
> Best regards,
>
> Hongbin
>
>
>
>
_

Re: [openstack-dev] [release][all] What is upper-constraints.txt?

> -Original Message-
> From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
> Sent: Wednesday, March 30, 2016 9:01 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [release][all] What is upper-constraints.txt?
> 
> On Wed, Mar 30, 2016 at 08:33:06AM -0400, Davanum Srinivas wrote:
> > Folks,
> >
> > Quick primer/refresh because of some gate/CI issues we saw last few
> > days with Routes===2.3
> >
> > upper-constraints.txt is the current set of all the global libraries
> > that should be used by all the CI jobs.
> >
> > This file is in the openstack/requirements repo:
> > http://git.openstack.org/cgit/openstack/requirements/tree/upper-constr
> > aints.txt
> > http://git.openstack.org/cgit/openstack/requirements/tree/upper-constr
> > aints.txt?h=stable/mitaka
> >
> > Anyone working on a project, please ensure that all CI jobs respect
> > constraints, example from trove below. If jobs don't respect
> > constraints then they are more likely to break:
> > https://review.openstack.org/#/c/298850/
> 
> While I agree that projects should do this, do keep in mind that projects
> that do not run tests on openstack/requirements changes still have plenty
> of room for breaks when u-c changes are merged. :)
> 

[amrith] Speaking only from personal experience, I'd rather see gate/check jobs 
fail when u-c changes, rather than each time some python library in the wide 
world changes in an unexpected way. But, I suspect there are benefits in having 
canaries in the coal mine.

The more interesting part of this though is that we should be exhorting 
deployers to rely on u-c.txt or potentially something better like pip freeze. 
But I'm not a deployer and I don't know whether that would work for deployers 
at large.

> // jim
> 
> >
> > Anyone deploying openstack, please consult this file as it's the one
> > *sane* set of libraries that we test with.
> >
> > Yes, global-requirements.txt has the ranges that end up in project
> > requirements files. However, upper-constraints.txt is what we test for
> > sure in OpenStack CI.
> >
> > Thanks,
> > Dims
> >
> > --
> > Davanum Srinivas :: https://twitter.com/dims
> >
> > __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [release][all] What is upper-constraints.txt?

> -Original Message-
> From: Andreas Jaeger [mailto:a...@suse.com]
> Sent: Wednesday, March 30, 2016 9:03 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [release][all] What is upper-constraints.txt?
> 
> On 2016-03-30 14:33, Davanum Srinivas wrote:
> > Folks,
> >
> > Quick primer/refresh because of some gate/CI issues we saw last few
> > days with Routes===2.3
> >
> > upper-constraints.txt is the current set of all the global libraries
> > that should be used by all the CI jobs.
> 
> We're not ready yet for such a general recommendation, see below for some
> details.
> 
> > This file is in the openstack/requirements repo:
> > http://git.openstack.org/cgit/openstack/requirements/tree/upper-constr
> > aints.txt
> > http://git.openstack.org/cgit/openstack/requirements/tree/upper-constr
> > aints.txt?h=stable/mitaka
> >
> > Anyone working on a project, please ensure that all CI jobs respect
> > constraints, example from trove below. If jobs don't respect
> > constraints then they are more likely to break:
> > https://review.openstack.org/#/c/298850/
> >
> > Anyone deploying openstack, please consult this file as it's the one
> > *sane* set of libraries that we test with.
> >
> > Yes, global-requirements.txt has the ranges that end up in project
> > requirements files. However, upper-constraints.txt is what we test for
> > sure in OpenStack CI.
> 
> 
> Note that upper-constraints is not ready for full usage in the project.
> It only works in check and gate jobs but especially does not work in post
> jobs. If you implement it improperly, your jobs will fail - and post jobs
> will fail silently (see also [1] for an infra discussion).
> Before infra can support this everywhere, our tools need to be fixed to
> handle constraints in all queues.
> 
> Right now, I consider upper-constraints experimental since it does not
> work for all queues and is not fool-proof. So, if you go down this road,
> triple check that *all* your jobs do the right thing,

[amrith] I'm really thrilled that dims sent this to the ML, and that we got 
your review comments Andreas. I'll try my best to fix them and ping you for a 
re-review.

> 
> Andreas
> 
> [1]
> http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-15-
> 19.03.html
> 
> 
> 
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [kloudbuster] authorization failed problem

2016-03-30 Thread Akshay Kumar Sanghai

Hi Alec,
Thanks for clarifying. I didnot have the cinder service previously. It was
not a complete setup. Now, I did the setup of cinder service.
Output of keystone service list.
[image: Inline image 1]
I installed the setup of openstack using the installation guide for ubuntu
and for kloudbuster, its a pypi based installation. So, I am running
kloudbuster using the CLI option.
kloudbuster --tested-rc keystone-openrc.sh --tested-passwd * --config
kb.cfg

contents of kb.cfg:
image_name: 'kloudbuster'

I added the kloudbuster v5 version as glance image with name as
kloudbuster.

I don't understand some basic things. If you can help, then that would be
great.
-Does the server side means the cloud generating the traffic and client
side means the the cloud on which connections are established? Can you
please elaborate on client, server and proxy?
-while running the kloudbuster, I saw "setting up redis connection". Can
you please expain to which connection is established and why? Is it
KB_PROXY?

Please find attached the run of kloudbuster as a file. I have still not
succeeded in running the kloudbuster, some errors.
I appreciate your help Alec.

Thanks,
Akshay

On Mon, Mar 28, 2016 at 8:59 PM, Alec Hothan (ahothan) 
wrote:

>
> Can you describe what you mean by "do not have a cinder service"?
> Can you provide the output of "keystone service-list"?
>
> We'd have to know a bit more about what you have been doing:
> how did you install your openstack, how did you install kloudbuster, which
> kloudbuster qcow2 image version did you use, who did you run kloudbuster
> (cli or REST or web UI), what config file have you been using, complete log
> of the run (including backtrace)...
>
> But the key is - you should really have a fully working openstack
> deployment before using kloudbuster. Nobody has never tried so far to use
> kloudbuster without such basic service as cinder working.
>
> Thanks
>
>   Alec
>
>
>
> From: Akshay Kumar Sanghai 
> Date: Monday, March 28, 2016 at 6:51 AM
> To: OpenStack List , Alec Hothan <
> ahot...@cisco.com>
> Cc: "Yichen Wang (yicwang)" 
> Subject: Re: [openstack-dev] [kloudbuster] authorization failed problem
>
> Hi Alec,
> Thanks for the help. I ran into another problem. At present I do not have
> a cinder service. So ,when i am trying to run kloudbuster, I am getting
> this error:
> "EndpointNotFound: publicURL endpoint for volumev2 service not found"
> Is it possible to run the scale test (creation of VMs, router, network)
> without having a cinder service? Any option that can be used so that
> kloudbuster can run without cinder.
>
> Thanks,
> Akshay
>
> On Wed, Mar 23, 2016 at 9:05 PM, Alec Hothan (ahothan) 
> wrote:
>
>> Hi Akshay
>>
>> The URL you are using is a private address (
>> http://192.168.138.51:5000/v2.0) and is likely the reason it does not
>> work.
>> If you run the kloudbuster App in the cloud, this app needs to have
>> access to the cloud under test.
>> So even if you can access 192.168.138.51 from your local browser (which
>> runs on your workstation or laptop) it may not be accessible from a VM that
>> runs in your cloud.
>> For that to work you need to get an URL that is reachable from the VM.
>>
>> In some cases where the cloud under test is local, it is easier to just
>> run kloudbuster locally as well (from the same place where you can ping
>> 192.168.138.51).
>> You can either use a local VM to run the kloudbuster image (vagrant,
>> virtual box...) or just simpler, install kloudbuster locally using git
>> clone or pip install (see the installation instructions in the doc
>> http://kloudbuster.readthedocs.org/en/latest/).
>>
>> Regards,
>>
>>Alec
>>
>>
>>
(vkb) root@controller:~# kloudbuster --tested-rc keystone-openrc.sh 
--tested-passwd sanghai --config kb.cfg
2016-03-30 19:37:35 WARNING No public key is found or specified to instantiate 
VMs. You will not be able to access the VMs spawned by KloudBuster.
2016-03-30 19:37:36 INFO Creating kloud: KBs
2016-03-30 19:37:36 INFO Creating kloud: KBc
2016-03-30 19:37:36 INFO Creating tenant: KBs-T0
2016-03-30 19:37:36 INFO Creating user: KBs-T0-U
2016-03-30 19:37:36 INFO Creating routers and networks for tenant KBs-T0
2016-03-30 19:37:38 INFO Scheduled to create VMs for network KBs-T0-U-R0-N0...
2016-03-30 19:37:38 INFO Creating tenant: KBc-T0
2016-03-30 19:37:38 INFO Creating user: KBc-T0-U
2016-03-30 19:37:39 INFO Creating routers and networks for tenant KBc-T0
2016-03-30 19:37:40 INFO Scheduled to create VMs for network KBc-T0-U-R0-N0...
2016-03-30 19:37:41 INFO Creating Instance: KB-PROXY
2016-03-30 19:37:51 INFO Setting up the redis connections...
2016-03-30 19:39:59 INFO Preparing metadata for VMs... (Server)
2016-03-30 19:39:59 INFO Creating Instance: KBs-T0-U-R0-N0-I0
2016-03-30 19:40:08 INFO Preparing metadata for VMs... (Client)
2016-03-30 19:40:08 INFO Creating Instance: KBc-T0-U-R0-N0-I0
2016-03-30 19:40:17 INFO Provision Details (Tested Kloud)
+---+--+---+---

Re: [openstack-dev] [all] Austin Design Summit track layout


Sylvain Bauza  wrote:




Le 29/03/2016 09:48, Thierry Carrez a écrit :

Matt Riedemann wrote:

I see one problem. The single stable team fishbowl session is scheduled
for the last slot on Thursday (5pm). The conflict I have with that is
the nova team does it's priority/scheduling talk in the last session on
the last day for design summit fishbowl sessions (non-meetup style).

I'm wondering if we could move the stable session to 4:10 on Thursday. I
don't see any infra/QA sessions happening at that time, which is the
cross-project people we need for the stable session.


There is the release management fishbowl session at 4:10pm on Thursday  
that would conflict (a lot of people are involved in both). Maybe we  
could swap those two (put stable at 4:10pm and relmgt at 5:00pm). It  
looks like that would work ?


I'd then have the same problem than Matt here as I'm the Release CPL for  
Nova. That said, given I think I'm the only person probably having the  
issue, I can say fair enough and try to clone myself before the Summit :-)


Actually, now that I am a release CPL for Neutron, as well as stable  
representative for the project, and both release and stable sessions are  
overlapping with 2 out of 4 Neutron sessions on that day, plus I have a  
talk to do that same day in the morning, I am concerned that I will need to  
skip 3 of 4 design sessions for Neutron on Thursday. Which honestly is  
*very* painful for me.


With that in mind, could we try to move at least some of those cross  
sessions to e.g. 1:30 - 2:10 where we don’t have Neutron sessions at all,  
neither any infra/qa slots [docs only]?


Ihar

__
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] [magnum][kuryr] Shared session in design summit

2016-03-30 Thread Gal Sagie

All these slots are fine with me, added Kuryr team as CC to make sure most
can attend any of these times.



On Wed, Mar 30, 2016 at 5:12 PM, Hongbin Lu  wrote:

> Gal,
>
>
>
> Thursday 4:10 – 4:50 conflicts with a Magnum workroom session, but we can
> choose from:
>
> · 11:00 – 11:40
>
> · 11:50 – 12:30
>
> · 3:10 – 3:50
>
>
>
> Please let us know if some of the slots don’t work well with your schedule.
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
> *Sent:* March-30-16 2:00 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [magnum][kuryr] Shared session in design
> summit
>
>
>
> Anything you pick is fine with me, Kuryr fishbowl session is on
> Thursday 4:10 - 4:50, i personally
>
> think the Magnum integration is important enough and i dont mind using
> this time for the session as well.
>
>
>
> Either way i am also ok with the 11-11:40 and the 11:50-12:30 sessions or
> the 3:10-3:50
>
>
>
> On Tue, Mar 29, 2016 at 11:32 PM, Hongbin Lu 
> wrote:
>
> Hi all,
>
>
>
> As discussed before, our team members want to establish a shared session
> between Magnum and Kuryr. We expected a lot of attendees in the session so
> we need a large room (fishbowl). Currently, Kuryr has only 1 fishbowl
> session, and they possibly need it for other purposes. A solution is to
> promote one of the Magnum fishbowl session to be the shared session, or
> leverage one of the free fishbowl slot. The schedule is as below.
>
>
>
> Please vote your favorite time slot:
> http://doodle.com/poll/zuwercgnw2uecs5y .
>
>
>
> Magnum fishbowl session:
>
> · 11:00 - 11:40 (Thursday)
>
> · 11:50 - 12:30
>
> · 1:30 - 2:10
>
> · 2:20 - 3:00
>
> · 3:10 - 3:50
>
>
>
> Free fishbowl slots:
>
> · 9:00 – 9:40 (Thursday)
>
> · 9:50 – 10:30
>
> · 3:10 – 3:50 (conflict with Magnum session)
>
> · 4:10 – 4:50 (conflict with Magnum session)
>
> · 5:00 – 5:40 (conflict with Magnum session)
>
>
>
> Best regards,
>
> Hongbin
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> Best Regards ,
>
> The G.
>
> __
> 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
>
>


-- 
Best Regards ,

The G.
__
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] [magnum] Generate atomic images using diskimage-builder

2016-03-30 Thread Hongbin Lu

Another use case I can think of is to cache the required docker images in the 
Glance image.

This is an important use case because we have containerized most of the COE 
components (e.g. kube-scheduler, swarm-manager, etc.). As a result, each bay 
needs to pull docker images over the Internet on provisioning or scaling stage. 
If a large number of bays pull docker images at the same time, it will generate 
a lot of traffic. Therefore, it is desirable to have all the required docker 
images pre-downloaded into the Glance image. I expect we can leverage 
diskimage-builder to achieve the goal.

Best regards,
Hongbin

From: Ton Ngo [mailto:t...@us.ibm.com]
Sent: March-29-16 4:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Generate atomic images using 
diskimage-builder


In multiple occasions in the past, we have had to use version of some software 
that's not available yet
in the upstream image for bug fixes or new features (Kubernetes, Docker, 
Flannel,...). Eventually the upstream
image would catch up, but having the tool to customize let us push forward with 
development, and gate tests
if it makes sense.

Ton Ngo,


[Inactive hide details for Yolanda Robla Mota ---03/29/2016 01:35:48 PM---So 
the advantages I can see with diskimage-builder are]Yolanda Robla Mota 
---03/29/2016 01:35:48 PM---So the advantages I can see with diskimage-builder 
are: - we reuse the same tooling that is present

From: Yolanda Robla Mota 
mailto:yolanda.robla-m...@hpe.com>>
To: 
mailto:openstack-dev@lists.openstack.org>>
Date: 03/29/2016 01:35 PM
Subject: Re: [openstack-dev] [magnum] Generate atomic images using 
diskimage-builder





So the advantages I can see with diskimage-builder are:
- we reuse the same tooling that is present in other openstack projects
to generate images, rather than relying on an external image
- it improves the control we have on the contents of the image, instead
of seeing that as a black box. At the moment we can rely on the default
tree for fedora 23, but this can be updated per magnum needs
- reusability: we have atomic 23 now, but why not create magnum images
with dib, for ubuntu, or any other distros ? Relying on
diskimage-builder makes it easy and flexible, because it's a matter of
adding the right elements.

Best
Yolanda

El 29/03/16 a las 21:54, Steven Dake (stdake) escribió:
> Adrian,
>
> Makes sense.  Do the images have to be built to be mirrored though?  Can't
> they just be put on the mirror sites fro upstream?
>
> Thanks
> -steve
>
> On 3/29/16, 11:02 AM, "Adrian Otto" 
> mailto:adrian.o...@rackspace.com>> wrote:
>
>> Steve,
>>
>> I¹m very interested in having an image locally cached in glance in each
>> of the clouds used by OpenStack infra. The local caching of the glance
>> images will produce much faster gate testing times. I don¹t care about
>> how the images are built, but we really do care about the performance
>> outcome.
>>
>> Adrian
>>
>>> On Mar 29, 2016, at 10:38 AM, Steven Dake (stdake) 
>>> mailto:std...@cisco.com>>
>>> wrote:
>>>
>>> Yolanda,
>>>
>>> That is a fantastic objective.  Matthieu asked why build our own images
>>> if
>>> the upstream images work and need no further customization?
>>>
>>> Regards
>>> -steve
>>>
>>> On 3/29/16, 1:57 AM, "Yolanda Robla Mota" 
>>> mailto:yolanda.robla-m...@hpe.com>>
>>> wrote:
>>>
 Hi
 The idea is to build own images using diskimage-builder, rather than
 downloading the image from external sources. By that way, the image can
 live in our mirrors, and is built using the same pattern as other
 images
 used in OpenStack.
 It also opens the door to customize the images, using custom trees, if
 there is a need for it. Actually we rely on official tree for Fedora 23
 Atomic (https://dl.fedoraproject.org/pub/fedora/linux/atomic/23/) as
 default.

 Best,
 Yolanda

 El 29/03/16 a las 10:17, Mathieu Velten escribió:
> Hi,
>
> We are using the official Fedora Atomic 23 images here (on Mitaka M1
> however) and it seems to work fine with at least Kubernetes and Docker
> Swarm.
> Any reason to continue building specific Magnum image ?
>
> Regards,
>
> Mathieu
>
> Le mercredi 23 mars 2016 à 12:09 +0100, Yolanda Robla Mota a écrit :
>> Hi
>> I wanted to start a discussion on how Fedora Atomic images are being
>> built. Currently the process for generating the atomic images used
>> on
>> Magnum is described here:
>> http://docs.openstack.org/developer/magnum/dev/build-atomic-image.htm
>> l.
>> The image needs to be built manually, uploaded to fedorapeople, and
>> then
>> consumed from there in the magnum tests.
>> I have been working on a feature to allow diskimage-builder to
>> generate
>> these images. The code that makes it possible is here:
>> https://review.openstack.org/287167
>> This

Re: [openstack-dev] [Neutron]Relationship between physical networks and segment

On 29/03/16 20:42, Miguel Lavalle wrote:
> Hi,

Hi Miguel,

> I am writing a patchset to build a mapping between hosts and network
> segments. The goal of this mapping is to be able to say whether a host
> has access to a given network segment. I am building this mapping
> assuming that if a host A has a bridges mapping containing 'physnet 1'
> and a segment has 'physnet 1' in its 'physical_network' attribute, then
> the host has access to that segment.
>
> 1) Is this assumption correct? Looking at method check_segment_for_agent
> in
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/mech_agent.py#n180
> seems to me to suggest that my assumption is correct?

Yes, I would say so.  In other words: if a host can access a particular 
physical network, it can access all segments that use that physical network.

>
> 2) Furthermore, when a segment is mapped to a physical network, is there
> a one to one relationship between segments and physical nets?

No; I would say that segments are N:1 with physical networks, with VLANs 
being the most obvious example.

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] [magnum] Discuss the blueprint"support-private-registry"

2016-03-30 Thread Ricardo Rocha

Hi.

On Wed, Mar 30, 2016 at 4:20 PM, Kai Qiang Wu  wrote:

> I agree to that support-private-registry should be secure. As insecure
> seems not much useful for production use.
> Also I understood the point setup related CA could be diffcult than normal
> HTTP, but we want to know if
> https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig
>
> Could address the issue and make templates clearer to understood ? If
> related patch or spec proposed, we are glad to review and make it better.
>

Yes, some local customization of the node setup would be great and help
with the CA setup - we're willing to implement that blueprint.

Cheers,
Ricardo


>
>
>
>
> Thanks
>
> Best Wishes,
>
> 
> Kai Qiang Wu (吴开强 Kennan）
> IBM China System and Technology Lab, Beijing
>
> E-mail: wk...@cn.ibm.com
> Tel: 86-10-82451647
> Address: Building 28(Ring Building), ZhongGuanCun Software Park,
> No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193
>
> 
> Follow your heart. You are miracle!
>
> [image: Inactive hide details for Ricardo Rocha ---30/03/2016 09:09:14
> pm---Hi. On Wed, Mar 30, 2016 at 3:59 AM, Eli Qiao  Rocha ---30/03/2016 09:09:14 pm---Hi. On Wed, Mar 30, 2016 at 3:59 AM, Eli
> Qiao  wrote:
>
> From: Ricardo Rocha 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 30/03/2016 09:09 pm
> Subject: Re: [openstack-dev] [magnum] Discuss the blueprint
> "support-private-registry"
> --
>
>
>
> Hi.
>
> On Wed, Mar 30, 2016 at 3:59 AM, Eli Qiao  wrote:
> >
> > Hi Hongbin
> >
> > Thanks for starting this thread,
> >
> >
> >
> > I initial propose this bp because I am in China which is behind China
> great
> > wall and can not have access of gcr.io directly, after checking our
> > cloud-init script, I see that
> >
> > lots of code are *hard coded* to using gcr.io, I personally though this
> is
> > not good idea. We can not force user/customer to have internet access in
> > their environment.
> >
> > I proposed to use insecure-registry to give customer/user (Chinese or
> whom
> > doesn't have gcr.io access) a chance to switch use their own
> > insecure-registry to deploy
> > k8s/swarm bay.
> >
> > For your question:
> >>  Is the private registry secure or insecure? If secure, how to
> handle
> >> the authentication secrets. If insecure, is it OK to connect a secure
> bay to
> >> an insecure registry?
> > An insecure-resigtry should be 'secure' one, since customer need to
> setup it
> > and make sure it's clear one and in this case, they could be a private
> > cloud.
> >
> >>  Should we provide an instruction for users to pre-install the private
> >> registry? If not, how to verify the correctness of this feature?
> >
> > The simply way to pre-install private registry is using insecure-resigtry
> > and docker.io has very simple steps to start it [1]
> > for other, docker registry v2 also supports using TLS enable mode but
> this
> > will require to tell docker client key and crt file which will make
> > "support-private-registry" complex.
> >
> > [1] https://docs.docker.com/registry/
> > [2]https://docs.docker.com/registry/deploying/
>
> 'support-private-registry' and 'allow-insecure-registry' sound different
> to me.
>
> We're using an internal docker registry at CERN (v2, TLS enabled), and
> have the magnum nodes setup to use it.
>
> We just install our CA certificates in the nodes (cp to
> etc/pki/ca-trust/source/anchors/, update-ca-trust) - had to change the
> HEAT templates for that, and submitted a blueprint to be able to do
> similar things in a cleaner way:
> https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig
>
> That's all that is needed, the images are then prefixed with the
> registry dns location when referenced - example:
> docker.cern.ch/my-fancy-image.
>
> Things we found on the way:
> - registry v2 doesn't seem to allow anonymous pulls (you can always
> add an account with read-only access everywhere, but it means you need
> to always authenticate at least with this account)
> https://github.com/docker/docker/issues/17317
> - swarm 1.1 and kub8s 1.0 allow authentication to the registry from
> the client (which was good news, and it works fine), handy if you want
> to push/pull with authentication.
>
> Cheers,
>  Ricardo
>
> >
> >
> >
> > On 2016年03月30日 07:23, Hongbin Lu wrote:
> >
> > Hi team,
> >
> >
> >
> > This is the item we didn’t have time to discuss in our team meeting, so I
> > started the discussion in here.
> >
> >
> >
> > Here is the blueprint:
> > https://blueprints.launchpad.net/magnum/+spec/support-private-registry .
> Per
> > my understanding, the goal of the BP is to allow users to specify the
> url of
> > their private docker registry where the bays pull the kube/swarm images
> (if
> > they

Re: [openstack-dev] [telemetry] Rescheduling IRC meetings

2016-03-30 Thread Emilien Macchi

On Wed, Mar 30, 2016 at 7:57 AM, Chris Dent  wrote:
> On Wed, 30 Mar 2016, Julien Danjou wrote:
>
>> Thoughts?
>
>
> +1
>
> I especially agree that asynch (gerrit and email) interaction is far
> more accessible and productive.
>
> Another option on the meetings would be to do what the cross project
> meetings do: Only have the meeting if there are agenda items.

That is an excellent idea.
I'm not working in Telemetry team, but we have the same situation in
Puppet OpenStack, where we don't have (or a very few topics) since the
last months.
I also think it's because we don't wait for meetings to solve our
problems, and do it in async, which is fine for our project.

I'll pick the idea and propose it to my team ;-)

> --
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> 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
>



-- 
Emilien Macchi

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

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

2016-03-30 Thread Pavel Bondar

On 12.02.2016 15:01, Ihar Hrachyshka wrote:
> Salvatore Orlando  wrote:
>
>> On 11 February 2016 at 20:17, John Belamaric
>>  wrote:
>>
>>> On Feb 11, 2016, at 12:04 PM, Armando M.  wrote:
>>>
>>>
>>>
>>> On 11 February 2016 at 07:01, John Belamaric
>>>  wrote:
>>>
>>>
>>>
>>> It is only internal implementation changes.
>>>
>>> That's not entirely true, is it? There are config variables to
>>> change and it opens up the possibility of a scenario that the
>>> operator may not care about.
>>>
>>
>> If we were to remove the non-pluggable version altogether, then the
>> default for ipam_driver would switch from None to internal.
>> Therefore, there would be no config file changes needed.
>>
>> I think this is correct.
>> Assuming the migration path to Neutron will include the data
>> transformation from built-in to pluggable IPAM, do we just remove the
>> old code and models?
>> On the other hand do you think it might make sense to give operators
>> a chance to rollback - perhaps just in case some nasty bug pops up?
>
> They can always revert to a previous release. And if we enable the new
> implementation start of Newton, we’ll have enough time to fix bugs
> that will pop up in gate.
>
We are now in early Newton, so it is good time to discuss plan for
pluggable ipam for this release cycle.

Kevin Benton commented on review page for current migration to pluggable
approach [1]:
>
> IMO this cannot be optional. It's going to be a nightmare to try to
> support two IPAM systems that people may have switched between at
> various points in time. I would much rather go all-in on the upgrade
> by making it automatic with alembic and removing the option to use the
> legacy IPAM code completely.
>
> I've already been bitten by testing the new IPAM code with the config
> option and switching back which resulted in undeletable subnets. Now
> we can always yell at anyone that changes the config option like I
> did, but it takes a lot of energy to yell at users and they don't care
> for it much. :)
>
> Even ignoring the support issue, consider schema changes. This
> migration script will have to be constantly updated to work with
> whatever the current state of the schema is on both sets of ipam
> tables. Without constant in-tree testing enforcing that, we are one
> schema change away from this script breaking.
>
> So let's bite the bullet and make this a normal contract migration.
> Either the new ipam system is stable enough for us to commit to
> supporting it and fix whatever bugs it may have, or we need to remove
> it from the tree. Supporting both systems is unsustainable.
>
This sound reasonable to me. It simplify support and testing (testing
both implementations in gate with full coverage is not easy).
>From user prospective there should be no visible changes between
pluggable ipam and non-pluggable.
And making switch early in release cycle gives us enough time to fix any
bug we will find in pluggable implementation.

Right now we have some open bugs for pluggable code [2], but they are
still possible to fix.

Does it make sense to you?

[1] https://review.openstack.org/#/c/277767/
[2] https://bugs.launchpad.net/neutron/+bug/1543094
>> What's the team level of confidence in the robustness of the
>> reference IPAM driver?
>>
>> Salvatore
>>
>>
>>
>>
>> John
>>
>>
>>
>> __
>>
>> 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 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] Is the Intel SRIOV CI running and if so, what does it test?

2016-03-30 Thread Matt Riedemann


Intel has a few third party CIs in the third party systems wiki [1].

I was talking with Moshe Levi today about expanding coverage for 
mellanox CI in nova, today they run an SRIOV CI for vnic type 'direct'. 
I'd like them to also start running their 'macvtap' CI on the same nova 
changes (that job only runs in neutron today I think).


I'm trying to see what we have for coverage on these different NFV 
configurations, and because of limited resources to run NFV CI, don't 
want to duplicate work here.


So I'm wondering what the various Intel NFV CI jobs run, specifically 
the Intel Networking CI [2], Intel NFV CI [3] and Intel SRIOV CI [4].


From the wiki it looks like the Intel Networking CI tests ovs-dpdk but 
only for Neutron. Could that be expanded to also test on Nova changes 
that hit a sub-set of the nova tree?


I really don't know what the latter two jobs test as far as 
configuration is concerned, the descriptions in the wikis are pretty 
empty (please update those to be more specific).


Please also include in the wiki the recheck method for each CI so I 
don't have to dig through Gerrit comments to find one.


[1] https://wiki.openstack.org/wiki/ThirdPartySystems
[2] https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-Networking-CI
[3] https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-NFV-CI
[4] https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-SRIOV-CI

--

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] [all] Austin Design Summit track layout


Ihar Hrachyshka wrote:

I'd then have the same problem than Matt here as I'm the Release CPL
for Nova. That said, given I think I'm the only person probably having
the issue, I can say fair enough and try to clone myself before the
Summit :-)


Actually, now that I am a release CPL for Neutron, as well as stable
representative for the project, and both release and stable sessions are
overlapping with 2 out of 4 Neutron sessions on that day, plus I have a
talk to do that same day in the morning, I am concerned that I will need
to skip 3 of 4 design sessions for Neutron on Thursday. Which honestly
is *very* painful for me.

With that in mind, could we try to move at least some of those cross
sessions to e.g. 1:30 - 2:10 where we don’t have Neutron sessions at
all, neither any infra/qa slots [docs only]?


There is an Oslo slot we could maybe swap Stable with. Would that work ?

--
Thierry Carrez (ttx)

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

[openstack-dev] [magnum][magnum-ui] Have magnum jobs respect upper-constraints.txt

2016-03-30 Thread Hongbin Lu

Hi team,

After a quick check, it seems python-magnumclient and magnum-ui don't use upper 
constraints. Magnum (the main repo) uses upper constraints in integration tests 
(gate-functional-*), but doesn't use it in others (e.g. py27, py34, pep8, docs, 
coverage). The missing of upper constraints could be problematic. Tickets were 
created to fix that: https://bugs.launchpad.net/trove/+bug/1563038 .

Best regards,
Hongbin

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: March-30-16 8:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [release][all] What is upper-constraints.txt?

Folks,

Quick primer/refresh because of some gate/CI issues we saw last few days with 
Routes===2.3

upper-constraints.txt is the current set of all the global libraries that 
should be used by all the CI jobs.

This file is in the openstack/requirements repo:
http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt
http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/mitaka

Anyone working on a project, please ensure that all CI jobs respect 
constraints, example from trove below. If jobs don't respect constraints then 
they are more likely to break:
https://review.openstack.org/#/c/298850/

Anyone deploying openstack, please consult this file as it's the one
*sane* set of libraries that we test with.

Yes, global-requirements.txt has the ranges that end up in project requirements 
files. However, upper-constraints.txt is what we test for sure in OpenStack CI.

Thanks,
Dims

--
Davanum Srinivas :: https://twitter.com/dims

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

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

[openstack-dev] [Fuel] Extra red tape for filing bugs

2016-03-30 Thread Roman Prykhodchenko

Guys,

I’m not trying to be a foreteller but with a bug template this huge and 
complicated people will either not follow it or track bugs somewhere else. 
Perhaps we should make it simpler?

Detailed bug description:
 
Steps to reproduce:
 
Expected results:
 
Actual result:
 
Reproducibility:
 
Workaround:
 
Impact:
 
Description of the environment:
 Operation system: 
 Versions of components: 
 Reference architecture: 
 Network model: 
 Related projects installed: 
Additional information:
 


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Extra red tape for filing bugs

2016-03-30 Thread Roman Prykhodchenko

We also often use bugtracker as a TODO tracker. This template does not work for 
TODOs at all. I understand that it’s not technically mandatory to follow it, 
but if that Fuel Bug Checker is going to spam on every single TODO, our inboxes 
will overflow.

> 30 бер. 2016 р. о 17:37 Roman Prykhodchenko  написав(ла):
> 
> Guys,
> 
> I’m not trying to be a foreteller but with a bug template this huge and 
> complicated people will either not follow it or track bugs somewhere else. 
> Perhaps we should make it simpler?
> 
> Detailed bug description:
> 
> Steps to reproduce:
> 
> Expected results:
> 
> Actual result:
> 
> Reproducibility:
> 
> Workaround:
> 
> Impact:
> 
> Description of the environment:
> Operation system: 
> Versions of components: 
> Reference architecture: 
> Network model: 
> Related projects installed: 
> Additional information:
> 
> 
> 
> - romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

On 11/03/16 23:20, Carl Baldwin wrote:
> Hi,

Hi Carl, and sorry for the lateness of this reply.

> I have started to get into coding [1] for the Neutron routed networks
> specification [2].
>
> This spec proposes a new association between network segments and
> subnets.  This affects how IPAM needs to work because until we know
> where the port is going to land, we cannot allocate an IP address for
> it.

Note: according to the text and discussion at 
https://review.openstack.org/#/c/263898/, Neutron actually _does_ 
already know where the port is going to land (i.e. the chosen host) at 
the time when it is first allocating an IP address.  At least in the 
most common case, which is when the user request is "launch instance(s) 
on  network".

> Also, IPAM will need to somehow be aware of segments.  We have
> proposed a host / segment mapping which could be transformed to a host
> / subnet mapping for IPAM purposes.
>
> I wanted to get the opinion of folks like Salvatore, John Belamaric,
> and you (if you interested) on this.  How will this affect the
> interface to pluggable IPAM and how can pluggable implementations can
> accommodate this change.

Well, first of all we have a problem that the pluggable IPAM interface 
is not documented as it is already.  So it is tricky to comment at all 
on how that interface might need to change. :-)

Petra Sargent, with a little of my help, has started documenting the 
interface at https://review.openstack.org/#/c/289460/, but I think there 
is still lots more to be said there - so I would encourage anyone with 
existing knowledge of the IPAM interface to go there and contribute 
useful chunks of extra explanatory text.

With that as a big caveat, here are my thoughts so far.  The pluggable 
IPAM interface has core Neutron code on one side, and pluggable IPAM 
drivers on the other.  As a general principle, it's better if we can 
keep complexity on the core side, and keep the IPAM drivers as simple as 
possible to write and maintain; because there is only one Neutron core, 
and there will in future be many IPAM drivers.

I believe it's already the case that the core tells the driver about the 
subnet(s) that the driver can allocate an IP from.  (Although I'm not 
sure exactly what form that takes, and also if the subnet(s) is/are 
specified on a per-instance basis or per-group of instances, or 
something else.)  Therefore, in the case where segments are being used, 
and subnets are defined with affinity to those segments, the core could 
handle that by reducing the set of subnets that it offers to the driver; 
and that would not require any change to existing IPAM drivers.

At least in the first implementation, I would _not_ pass any new 
segment-specific information over the pluggable IPAM interface (i.e. to 
the driver), because I don't see any reason for the driver to need this; 
I think it's better to contain the handling of that within the Neutron core.

I believe that the core does _not_ tell the driver about the chosen host 
for the port for which an IP allocation is wanted (i.e. 
port['binding:host_id']).  I would like this information to be passed to 
the driver, so as to enable cases where some kind of host-subnet 
affinity is desirable, but that affinity cannot be described by Neutron 
segment objects.  So in this case the driver should receive

- all of the subnet(s) that are defined for the relevant Network

- the chosen host

and it would use its own out-of-band knowledge to decide how to allocate 
an IP from some subrange of the available subnet(s), depending on the 
chosen host.

Finally, I believe that the current pluggable IPAM interface technically 
already allows the last paragraph to be achieved - but that it is pretty 
hard and complex to do that, as it requires subclassing many classes. 
Assuming I'm right about that, I don't think that such a simple 
interface enhancement should require so much work, and hence I'd prefer 
binding:host_id to be added to the core interface.

>  Obviously, we wouldn't require
> implementations to support it

"implementations" = existing IPAM drivers, here?  I think what we need 
can be done in a way such that there is no "it" for them to support.

> but routed networks wouldn't be very
> useful without it.

Here, I assume that "it" means "allocating IPs in a host- or 
segment-dependent way", and I agree with you that this is a practical 
requirement for large scale routed network usage.

>  So, those implementations would not be compatible
> when routed networks are deployed.

(Again, I think we shouldn't need to say this.)

> Another related topic was brought up in the recent Neutron mid-cycle.
> We talked about adding a service type attribute to to subnets.  The
> reason for this change is to allow operators to create special subnets
> on a network to be used only by certain kinds of ports.  For example,
> DVR fip namespace gateway ports burn a public IP for no good reason.
> This new feature would allow operator

Re: [openstack-dev] [all] Austin Design Summit track layout


Thierry Carrez  wrote:


Ihar Hrachyshka wrote:

I'd then have the same problem than Matt here as I'm the Release CPL
for Nova. That said, given I think I'm the only person probably having
the issue, I can say fair enough and try to clone myself before the
Summit :-)


Actually, now that I am a release CPL for Neutron, as well as stable
representative for the project, and both release and stable sessions are
overlapping with 2 out of 4 Neutron sessions on that day, plus I have a
talk to do that same day in the morning, I am concerned that I will need
to skip 3 of 4 design sessions for Neutron on Thursday. Which honestly
is *very* painful for me.

With that in mind, could we try to move at least some of those cross
sessions to e.g. 1:30 - 2:10 where we don’t have Neutron sessions at
all, neither any infra/qa slots [docs only]?


There is an Oslo slot we could maybe swap Stable with. Would that work ?


Depends on which slot we talk about. If it’s the morning one, that’s the  
time I have to give the talk, so it would not work for me; if that’s the  
one in the afternoon [at the time of a ‘docs’ session], that one would work  
for me just fine.


Thanks in advance,

Ihar

__
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] [magnum][magnum-ui] Have magnum jobs respect upper-constraints.txt

2016-03-30 Thread Andreas Jaeger

On 03/30/2016 05:31 PM, Hongbin Lu wrote:
> Hi team,
> 
> After a quick check, it seems python-magnumclient and magnum-ui don't use 
> upper constraints. Magnum (the main repo) uses upper constraints in 
> integration tests (gate-functional-*), but doesn't use it in others (e.g. 
> py27, py34, pep8, docs, coverage). The missing of upper constraints could be 
> problematic. Tickets were created to fix that: 
> https://bugs.launchpad.net/trove/+bug/1563038 .

As mentioned in the other thread: Do not run it in post jobs! Double
check everything to not break your publishing of documents, release
notes or tarballs,

Andreas

> Best regards,
> Hongbin
> 
> -Original Message-
> From: Davanum Srinivas [mailto:dava...@gmail.com] 
> Sent: March-30-16 8:33 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [release][all] What is upper-constraints.txt?
> 
> Folks,
> 
> Quick primer/refresh because of some gate/CI issues we saw last few days with 
> Routes===2.3
> 
> upper-constraints.txt is the current set of all the global libraries that 
> should be used by all the CI jobs.
> 
> This file is in the openstack/requirements repo:
> http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt
> http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/mitaka
> 
> Anyone working on a project, please ensure that all CI jobs respect 
> constraints, example from trove below. If jobs don't respect constraints then 
> they are more likely to break:
> https://review.openstack.org/#/c/298850/
> 
> Anyone deploying openstack, please consult this file as it's the one
> *sane* set of libraries that we test with.
> 
> Yes, global-requirements.txt has the ranges that end up in project 
> requirements files. However, upper-constraints.txt is what we test for sure 
> in OpenStack CI.
> 
> Thanks,
> Dims
> 
> --
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> 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
> 


-- 
 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] [Neutron] Segments, subnet types, and IPAM

On 29/03/16 19:16, Carl Baldwin wrote:
> I've been playing with this a bit on this patch set [1].  I haven't
> gotten very far yet but it has me thinking.
>
> Calico has a similar use case in mind as I do.  Essentially, we both
> want to group subnets to allow for aggregation of routes.  (a) In
> routed networks, we want to group them by segment and the boundaries
> are hard meaning that if an IP is requested from a particular segment,
> IPAM should fail if it can't allocate it from the same.
>
> (b) For Calico, I believe that the goal is to group by host.  Their
> boundaries are soft meaning that it is okay to allocate any IP on the
> network but one that allows maximum route aggregation is strongly
> preferred.

Correct, and thanks for thinking about this case.

> (c) Brian Haley will soon post a spec to address the need to group
> subnets by service type.  This is another sort of grouping but is
> orthogonal to the need to group for routing purposes.  Here, we're
> trying to group like ports together so that we can use different types
> of addresses.  This kind of grouping could coexist with route grouping
> since they are orthogonal.
>
> Given all this grouping, it seems like it might make sense to add some
> sort of grouping feature to IPAM.  Here's how I'm thinking it will
> work.
>
> 1.  When a subnet is allocated, a group id(s) can be passed with the
> request.  IPAM will remember the group id with the subnet.
> 2.  When an IP address is needed, a group id(s) can be passed with the
> request.  IPAM will try to allocate from a subnet with a matching
> group id(s).

When you say "a group id(s) can be passed", are you thinking of the API 
into Neutron (e.g. from Nova), or of the API between the Neutron core 
and a pluggable IPAM driver?  (Or some other API?)

My guess is you mean the API between Neutron core and a pluggable IPAM 
driver.  For that case, I think your suggestion would make sense if 
information about all available subnets was passed upfront to the driver 
- i.e. whenever the network/subnet data model changes - but I am not 
sure if that is what happens.  Rather, I think it might be the case that 
the available subnets/CIDRs are passed to the driver for each IP 
allocation that is wanted.

If that last sentence is correct, then the Neutron core could do the 
filtering-by-group-id itself, and simply pass a filtered set of 
subnets/CIDRs to the driver, and I think that that would be simpler.

> 3.  If no IP address is available that exactly matches the group id(s)
> then IPAM may fall back to another subnet.  This behavior needs to be
> different for the various use cases mentioned which is where it gets
> kind of complicated.
>(a) No fallback is allowed.  The IP allocation should fail.
>(b) We can fall back to any other subnet.  There might be some
> reasons to prefer some over others but this could get complicated
> fast.
>(c) We can fall back to any subnet with None as its group (legacy
> subnets) but not to other groups (e.g. if I'm trying to allocate a
> floating IP address, I don't want to fall back to a subnet meant for
> DVR gateways because those aren't public IP addresses).
>
> I put (s) after group id in many cases above because it appears that
> we can have more than one kind of orthogonal grouping to consider at
> the same time.
>
> What do folks think?
>
> Am I trying to generalize too much and making it complicated?

FWIW, I don't think so.  But I'd like to be a lot surer about the shape 
of the existing pluggable IPAM interface.

Regards,
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] [magnum][magnum-ui] Have magnum jobs respect upper-constraints.txt

Thanks Hongbin, I've updated the bug summary to be more generic.

-amrith

> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> Sent: Wednesday, March 30, 2016 11:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [magnum][magnum-ui] Have magnum jobs respect
> upper-constraints.txt
> 
> Hi team,
> 
> After a quick check, it seems python-magnumclient and magnum-ui don't use
> upper constraints. Magnum (the main repo) uses upper constraints in
> integration tests (gate-functional-*), but doesn't use it in others (e.g.
> py27, py34, pep8, docs, coverage). The missing of upper constraints could
> be problematic. Tickets were created to fix that:
> https://bugs.launchpad.net/trove/+bug/1563038 .
> 
> Best regards,
> Hongbin
> 
> -Original Message-
> From: Davanum Srinivas [mailto:dava...@gmail.com]
> Sent: March-30-16 8:33 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [release][all] What is upper-constraints.txt?
> 
> Folks,
> 
> Quick primer/refresh because of some gate/CI issues we saw last few days
> with Routes===2.3
> 
> upper-constraints.txt is the current set of all the global libraries that
> should be used by all the CI jobs.
> 
> This file is in the openstack/requirements repo:
> http://git.openstack.org/cgit/openstack/requirements/tree/upper-
> constraints.txt
> http://git.openstack.org/cgit/openstack/requirements/tree/upper-
> constraints.txt?h=stable/mitaka
> 
> Anyone working on a project, please ensure that all CI jobs respect
> constraints, example from trove below. If jobs don't respect constraints
> then they are more likely to break:
> https://review.openstack.org/#/c/298850/
> 
> Anyone deploying openstack, please consult this file as it's the one
> *sane* set of libraries that we test with.
> 
> Yes, global-requirements.txt has the ranges that end up in project
> requirements files. However, upper-constraints.txt is what we test for
> sure in OpenStack CI.
> 
> Thanks,
> Dims
> 
> --
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

On 29/03/16 21:55, Carl Baldwin wrote:
>
> I thought of another type of grouping which could benefit pluggable
> IPAM today.  It occurred to me as I was refreshing my memory on how
> pluggable IPAM works when there are multiple subnets on a network.
> Currently, Neutron's backend pulls the subnets  and then tries to ask
> the IPAM driver for an IP on each one in turn [1].  This is
> inefficient and I think it is a natural opportunity to evolve the IPAM
> interface to allow this to be handled within the driver itself.  The
> driver could optimize it to avoid repeated round-trips to an external
> server.

Yes, that sounds sensible.  It would be nice to continue supporting the 
current pattern too though.

> Anyway, it occurred to me that this is just like segment aware IPAM
> except that the network is the group instead of the segment.  The IPAM
> driver could consider it another orthogonal grouping of subnets (even
> though it isn't really orthogonal to Neutron's point of view).  I
> could provide an implementation that would provide a shim for existing
> IPAM drivers to work without modification.  In fact, I could do that
> for all the types of grouping I've mentioned.

Yes - I think this is the same as I've been saying in previous replies, 
i.e. that the Neutron core can filter the subnets before it offers them 
to the driver.  Is that what you meant too?

 > Drivers could choose to
> sub-class the behavior to optimize it if they have the capability.
>
> Carl
>
> [1] 
> https://github.com/openstack/neutron/blob/4a6d05e410/neutron/db/ipam_pluggable_backend.py#L88

While we're here...

 def _ipam_try_allocate_ip(self, context, ipam_driver, port, ip_dict):
 factory = ipam_driver.get_address_request_factory()
 ip_request = factory.get_request(context, port, ip_dict)
 ipam_subnet = ipam_driver.get_subnet(ip_dict['subnet_id'])
 return ipam_subnet.allocate(ip_request)

What is the benefit of the separate "ipam_subnet = " line?  Why not just:

 def _ipam_try_allocate_ip(self, context, ipam_driver, port, ip_dict):
 factory = ipam_driver.get_address_request_factory()
 ip_request = factory.get_request(context, port, ip_dict)
 return ipam_driver.allocate(ip_request)

Similarly, what is the benefit of calling the driver twice to convert 
from (available info) to (request object) and then from (request object) 
to (IP allocation)?  Why not go directly from (available info) to (IP 
allocation)?

Finally, while I'm asking IPAM interface questions, what are subnet 
requests for?

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] [neutron] [ipam] Migration to pluggable IPAM

On 30/03/16 16:08, Pavel Bondar wrote:

> We are now in early Newton, so it is good time to discuss plan for
> pluggable ipam for this release cycle.
>
> Kevin Benton commented on review page for current migration to pluggable
> approach [1]:
>>
>> IMO this cannot be optional. It's going to be a nightmare to try to
>> support two IPAM systems that people may have switched between at
>> various points in time. I would much rather go all-in on the upgrade
>> by making it automatic with alembic and removing the option to use the
>> legacy IPAM code completely.
>>
>> I've already been bitten by testing the new IPAM code with the config
>> option and switching back which resulted in undeletable subnets. Now
>> we can always yell at anyone that changes the config option like I
>> did, but it takes a lot of energy to yell at users and they don't care
>> for it much. :)
>>
>> Even ignoring the support issue, consider schema changes. This
>> migration script will have to be constantly updated to work with
>> whatever the current state of the schema is on both sets of ipam
>> tables. Without constant in-tree testing enforcing that, we are one
>> schema change away from this script breaking.
>>
>> So let's bite the bullet and make this a normal contract migration.
>> Either the new ipam system is stable enough for us to commit to
>> supporting it and fix whatever bugs it may have, or we need to remove
>> it from the tree. Supporting both systems is unsustainable.
>>
> This sound reasonable to me. It simplify support and testing (testing
> both implementations in gate with full coverage is not easy).
>  From user prospective there should be no visible changes between
> pluggable ipam and non-pluggable.
> And making switch early in release cycle gives us enough time to fix any
> bug we will find in pluggable implementation.
>
> Right now we have some open bugs for pluggable code [2], but they are
> still possible to fix.
>
> Does it make sense to you?

Yes!  Kill the non-pluggable code already.  Neutron desperately needs to 
have less and simpler code in any area where it can possibly get it.

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] Austin Design Summit track layout

2016-03-30 Thread John Dickinson

Yes, I checked on that. Based on where in the schedule that is, and based on 
the way we're planning on doing the working sessions, it will be just fine for 
me to not be in that particular session. It's much better for the community 
that we have the contiguous block that I personally be present in that time 
slot.

--John




On 30 Mar 2016, at 1:01, Thierry Carrez wrote:

> John Dickinson wrote:
>> On Thursday, I'd like to proposed swapping Swift's 1:30pm session with 
>> Fuel's 2:20pm session. This will give Swift a contiguous time block in the 
>> afternoon, and Fuel's session would line up right after their full morning 
>> (albeit after the lunch break).
>>
>> I have not had a chance to talk to anyone on the Fuel team about this.
>
> John,
>
> You are giving a conference talk at 2:20pm on Thursday, which is why I left 
> that as a hole in the Swift Design Summit schedule.
>
> Swapping is definitely possible, but I figured you would not intentionally 
> create a conflict for you here ?
>
> -- 
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [all] Austin Design Summit track layout

2016-03-30 Thread Matt Riedemann




On 3/30/2016 10:42 AM, Ihar Hrachyshka wrote:

Thierry Carrez  wrote:


Ihar Hrachyshka wrote:

I'd then have the same problem than Matt here as I'm the Release CPL
for Nova. That said, given I think I'm the only person probably having
the issue, I can say fair enough and try to clone myself before the
Summit :-)


Actually, now that I am a release CPL for Neutron, as well as stable
representative for the project, and both release and stable sessions are
overlapping with 2 out of 4 Neutron sessions on that day, plus I have a
talk to do that same day in the morning, I am concerned that I will need
to skip 3 of 4 design sessions for Neutron on Thursday. Which honestly
is *very* painful for me.

With that in mind, could we try to move at least some of those cross
sessions to e.g. 1:30 - 2:10 where we don’t have Neutron sessions at
all, neither any infra/qa slots [docs only]?


There is an Oslo slot we could maybe swap Stable with. Would that work ?


Depends on which slot we talk about. If it’s the morning one, that’s the
time I have to give the talk, so it would not work for me; if that’s the
one in the afternoon [at the time of a ‘docs’ session], that one would
work for me just fine.

Thanks in advance,

Ihar

__
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



1:30pm on Thursday (first slot after lunch is unconference for nova) 
would work for me.


--

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] [all] Austin Design Summit track layout


John Dickinson wrote:

Yes, I checked on that. Based on where in the schedule that is, and based on 
the way we're planning on doing the working sessions, it will be just fine for 
me to not be in that particular session. It's much better for the community 
that we have the contiguous block that I personally be present in that time 
slot.


OK, I'll make the swap happen then.

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Rally] single router per tenant in network context

2016-03-30 Thread Akshay Kumar Sanghai

Hi Aleksandr,
Thanks Aleksandr. According to your references,I made the necessary changes
to the code for single router , but now facing problems in the resource
cleanup. While I correct the code, Can you suggest how to generate traffic
between the VMs ? Is there any tool that is generally used for traffic
generation?

Thanks,
Akshay

On Wed, Mar 16, 2016 at 1:41 PM, Aleksandr Maretskiy <
amarets...@mirantis.com> wrote:

> Hi,
>
> network context creates router for each network automatically, so you can
> not reduce the number of routers with this context
>
> https://github.com/openstack/rally/blob/master/rally/plugins/openstack/context/network/networks.py#L79
>
> However you can create and use own network context plugin, inherited from
> https://github.com/openstack/rally/blob/master/rally/plugins/openstack/context/network/networks.py#L31
> and override its setup() method - create single router per tenant and then
> attach it to each created network, like here
> https://github.com/openstack/rally/blob/master/rally/plugins/openstack/wrappers/network.py#L342-L343
>
> Ask me if you need more help
>
>
> On Tue, Mar 15, 2016 at 7:58 PM, Akshay Kumar Sanghai <
> akshaykumarsang...@gmail.com> wrote:
>
>> Hi,
>> I have a openstack setup with 1 controller node, 1 network node and 2
>> compute nodes. I want to perform scale testing of the setup in the
>> following manner:
>>
>> - Create 10 tenants
>> - Create 1 router per tenant
>> - Create 100 neutron networks across 10 tenants attached to the router
>> - Create 500 VMs spread across 10 tenants attached to the networks
>>
>> I used the boot_server scenario and defined the number of networks and
>> tenants in the network and users context respectively. But I want only one
>> router to be created per tenant. In the current case, one router is created
>> per network.
>>
>> Do i have an option to accomplish this using the existing rally code? Or
>> should i go ahead and make some change in the network context for my use
>> case?
>>
>> Thanks,
>> Akshay
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Austin Design Summit track layout


Matt Riedemann wrote:

1:30pm on Thursday (first slot after lunch is unconference for nova)
would work for me.


OK, I'll make that swap too (unless Josh hits me with a trout over the 
night)


--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

2016-03-30 Thread Carl Baldwin

On Wed, Mar 30, 2016 at 9:03 AM, Pavel Bondar  wrote:
> Kevin Benton commented on review page for current migration to pluggable
> approach [1]:
>
> IMO this cannot be optional. It's going to be a nightmare to try to support
> two IPAM systems that people may have switched between at various points in
> time. I would much rather go all-in on the upgrade by making it automatic
> with alembic and removing the option to use the legacy IPAM code completely.
>
> I've already been bitten by testing the new IPAM code with the config option
> and switching back which resulted in undeletable subnets. Now we can always
> yell at anyone that changes the config option like I did, but it takes a lot
> of energy to yell at users and they don't care for it much. :)
>
> Even ignoring the support issue, consider schema changes. This migration
> script will have to be constantly updated to work with whatever the current
> state of the schema is on both sets of ipam tables. Without constant in-tree
> testing enforcing that, we are one schema change away from this script
> breaking.
>
> So let's bite the bullet and make this a normal contract migration. Either
> the new ipam system is stable enough for us to commit to supporting it and
> fix whatever bugs it may have, or we need to remove it from the tree.
> Supporting both systems is unsustainable.
>
> This sound reasonable to me. It simplify support and testing (testing both
> implementations in gate with full coverage is not easy).
> From user prospective there should be no visible changes between pluggable
> ipam and non-pluggable.
> And making switch early in release cycle gives us enough time to fix any bug
> we will find in pluggable implementation.

This is what I want too but some people wanted to allow choice.

> Right now we have some open bugs for pluggable code [2], but they are still
> possible to fix.

Yes, we've got to fix this one but I think we have a way forward.  I'm
actually going to be working in IPAM for the next week or two on work
related to the thread I posted to yesterday [3].  Maybe I could help
out with this.  Could you get this migration lined up in review and
then we'll tackle the bugs as a joint effort?  Hopefully we can make
the switch before summit.

Carl

> Does it make sense to you?
>
> [1] https://review.openstack.org/#/c/277767/
> [2] https://bugs.launchpad.net/neutron/+bug/1543094

[3] http://lists.openstack.org/pipermail/openstack-dev/2016-March/090748.html

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

Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch

2016-03-30 Thread Jeff Peeler

On Wed, Mar 30, 2016 at 3:52 AM, Steven Dake (stdake)  wrote:
>
>
> From: Jeffrey Zhang 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, March 30, 2016 at 12:29 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty
> within the Liberty branch
>
> +1
>
> A lot of changes has been make in Mitaka. Backport is difficult.
>
> But using Mitaka deploy Liberty also has *much works*. For example,
> revert config file change which deprecated in Mitaka and Liberty support.
>
> A important one is the `keystone-manage bootstrap` command to create the
> keystone admin account. This is adderecently and only exist in the Mitaka
> branch. So when using this method, we should revert some commit and use
> the old way method.
>
>
> Agreed.

I'm sure there will be some checking and such once all the code has
been shuffled around, but I think doing this work is better than
abandoning a branch. So +1 to proposal.

__
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] Just make Mitaka deploy Liberty within the Liberty branch

2016-03-30 Thread Michal Rostecki


On 03/30/2016 09:51 AM, Steven Dake (stdake) wrote:

Michal,

We can't commit to that.  We discussed it at midcycle and unable to commit
to it then.  We are essentially abandoning the 1.0.0 release and replacing
it with 1.1.0 because of the documentation outlined here:

http://docs.openstack.org/developer/kolla/liberty-deployment-warning.html


If we could have made data containers work this whole discussion would
have been moot in the first place because it was the trigger for this
discussion.



OK, makes sense. Then I'm fully +1.

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

Re: [openstack-dev] Fw:Extending API via Plugins

2016-03-30 Thread Serg Melikyan

Hi wangzhh,

I think this look reasonable, but I would prefer to have a proper spec for
this feature. I generally like to have extendable API in Murano.

On Thu, Mar 24, 2016 at 8:49 PM, 王正浩  wrote:

> I'm sorry that I forgot to tell you murano-paste.ini should be modified to
> ...
> [app:apiv1app]
> paste.app_factory = murano.api.v1.router:APIRouterV1.factory
> ...
> And the file [4] is murano/api/v1/extensions_base.py
>
> -- Original --
> *From: * "王正浩";
> *Date: * Fri, Mar 25, 2016 11:10 AM
> *To: * "List";
> *Cc: * "smelikyan";
> *Subject: * Extending API via Plugins
>
> Hi Serg Melikyan,
> I don't know much about CF Broker API. I'm sorry that I
> have no real use-case. But here is a test one which I plan to
> complete.
>
> I modified murano/common/wsgi.py[0], murano/api/v1/router.py[1],
> added
> ...
> murano.api.v1.extensions =
> test = murano.api.v1.extensions.test:testAPI
> ...
> to the setup.cfg[2]. Imply the class testAPI[3].
> The class testAPI  inherit a base class APIExtensionBase[4].
> I'll show you my code.
> P.S. I copied it from nova. So there are some extra code, hope you don't
> mind.
> [0] http://paste.openstack.org/show/491841/
> [1] http://paste.openstack.org/show/491840/
> [2] http://paste.openstack.org/show/491842/
> [3] http://paste.openstack.org/show/491845/
> [4] http://paste.openstack.org/show/491843/
>



-- 
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979
__
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] Just make Mitaka deploy Liberty within the Liberty branch

2016-03-30 Thread Ryan Hallisey

Agreed this needs to happen +1,

- Original Message -
From: "Jeff Peeler" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, March 30, 2016 1:22:31 PM
Subject: Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty 
within the Liberty branch

On Wed, Mar 30, 2016 at 3:52 AM, Steven Dake (stdake)  wrote:
>
>
> From: Jeffrey Zhang 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, March 30, 2016 at 12:29 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty
> within the Liberty branch
>
> +1
>
> A lot of changes has been make in Mitaka. Backport is difficult.
>
> But using Mitaka deploy Liberty also has *much works*. For example,
> revert config file change which deprecated in Mitaka and Liberty support.
>
> A important one is the `keystone-manage bootstrap` command to create the
> keystone admin account. This is adderecently and only exist in the Mitaka
> branch. So when using this method, we should revert some commit and use
> the old way method.
>
>
> Agreed.

I'm sure there will be some checking and such once all the code has
been shuffled around, but I think doing this work is better than
abandoning a branch. So +1 to proposal.

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

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

Re: [openstack-dev] [Fuel] [RDO] Volunteers needed

2016-03-30 Thread Aleksandra Fedorova

Hi, Vladimir,

this is a great feature, which can make Fuel truly universal. But i
think it is hard to fully commit to the whole thing at once,
especially for new contributors.

Let's start with splitting it into some observable chunks of work, in
a form of wiki page, blueprint or spec. This way it will become
visible - where to start and how much effort it would take.

Also, do you think it fits into Internship ideas [1] ?

[1] https://wiki.openstack.org/wiki/Internship_ideas


On Tue, Mar 29, 2016 at 3:48 PM, Vladimir Kozhukalov
 wrote:
> Dear all,
>
> Fuel currently supports deployment of OpenStack using DEB packages
> (particularly Ubuntu, and Debian in near future). But we also used to deploy
> OpenStack on CentOS, but at some point we switched our focus on Ubuntu. It
> is not so hard to implement deployment of RDO using Fuel. Volunteers are
> welcome. You can contact Fuel team here in [openstack-dev] maling list or in
> #fuel IRC channel. It would be nice to see more people from different
> backgrounds contributing to Fuel.
>
>
> Vladimir Kozhukalov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Aleksandra Fedorova
CI Team Lead
bookwar

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

Re: [openstack-dev] [Neutron]Relationship between physical networks and segment

2016-03-30 Thread Miguel Lavalle

Bob,

Thanks for your detailed response. In it you "strongly recommend that any
functionality trying to make decisions based on connectivity do so by
calling into the registered mechanism drivers, so they can decide whether
whatever they manage has connectivity". After eading this I went through
the mechanism driver API definition (currently at
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/driver_api.py#n549).
The only method and the API that seems to be useful to implement your
recommendation is  filter_hosts_with_segment_access (currently at line
914). Is this method the right way to go?

Thanks

Miguel

On Tue, Mar 29, 2016 at 4:47 PM, Robert Kukura 
wrote:

> My answers below are from the perspective of normal (non-routed) networks
> implemented in ML2. The support for routed networks should build on this
> without breaking it.
>
> On 3/29/16 3:38 PM, Miguel Lavalle wrote:
>
> Hi,
>
> I am writing a patchset to build a mapping between hosts and network
> segments. The goal of this mapping is to be able to say whether a host has
> access to a given network segment. I am building this mapping assuming that
> if a host A has a bridges mapping containing 'physnet 1' and a segment has
> 'physnet 1' in its 'physical_network' attribute, then the host has access
> to that segment.
>
> 1) Is this assumption correct? Looking at method check_segment_for_agent
> in
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/mech_agent.py#n180
> seems to me to suggest that my assumption is correct?
>
> This is true for certain agent-based mechanism drivers, but cannot be
> assumed to be the case for all mechanism drivers (even all those that use
> agents. Any use of mapping info (i.e. from agents_db or elsewhere) is
> specific to an individual mechanism driver. I'd strongly recommend that any
> functionality trying to make decisions based on connectivity do so by
> calling into the registered mechanism drivers, so they can decide whether
> whatever they manage has connectivity.
>
> Also note that connectivity may involve hierarchical port binding, in
> which case you really need to try to bind a port to determine if you have
> connectivity. I'm not suggesting that there is a requirement to mix HPB and
> routed networks, but please try not to build assumptions into ML2 plugin
> code that don't work with HPB or that are only valid for a subset of
> mechanism drivers.
>
>
> 2) Furthermore, when a segment is mapped to a physical network, is there a
> one to one relationship between segments and physical nets?
>
> Certainly different virtual networks can map to different segments (i.e.
> VLANs) on the same physical network. It is even possible for the same
> virtual network to have multiple segments on the same physical network.
>
> -Bob
>
>
> Thanks
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kloudbuster] authorization failed problem

2016-03-30 Thread Yichen Wang (yicwang)

Hi, Akshay,

From the log you attached, the good news is you got KloudBuster installed and 
running fine! The problem is the image you are using (v5) is outdated for the 
latest KloudBuster main code. ☺

Normally for every version of KloudBuster, it needs certain version of image to 
support the full functionality. In the case when new feature is brought in, we 
tag the main code with a new version, and bump up the image version. Like from 
v5 to v6, we added the capability to support storage testing on cinder volume 
and ephemeral disks as well. We are right in our time for publishing the v6 
image to the OpenStack App Catalog, which may take another day or two. This is 
why you are seeing the connection to the redis agent in KB-Proxy is failing…

In order to unblock you, here is the RC image of v6 we are using right now, 
replace it in your cloud and KloudBuster should be good to go:
https://cisco.box.com/s/xelzx15swjra5qr0ieafyxnbyucnnsa0

Now back to your question.
-Does the server side means the cloud generating the traffic and client side 
means the the cloud on which connections are established? Can you please 
elaborate on client, server and proxy?
[Yichen] It is the other way around. Server is running nginx, and client is 
running the traffic generator (wrk2). It is like the way we normally 
understand. Since there might be lots of servers and clients in the same cloud, 
so KB-Proxy is an additional VM that runs in the clients side to orchestrate 
all client VMs to generate traffic, collect the results from each VM, and send 
them back to the main KloudBuster for processing. KB-Proxy is the where the 
redis server is sitting, and acts as the proxy node to connect all internal VMs 
to the external network. This is why a floating IP is needed for the proxy node.

-while running the kloudbuster, I saw "setting up redis connection". Can you 
please expain to which connection is established and why? Is it KB_PROXY?
[Yichen] As I explained above, KB-Proxy is the bridge between internal VM and 
external world (like the host you are running KloudBuster from). “Setting up 
redis connection” means the KloudBuster is trying to connect to the redis 
server on the KB-Proxy node. You may see some retries because it does take some 
time for the VM to be up running.

Thanks very much!

Regards,
Yichen

From: Akshay Kumar Sanghai [mailto:akshaykumarsang...@gmail.com]
Sent: Wednesday, March 30, 2016 7:31 AM
To: Alec Hothan (ahothan) 
Cc: OpenStack List ; Yichen Wang (yicwang) 

Subject: Re: [openstack-dev] [kloudbuster] authorization failed problem

Hi Alec,
Thanks for clarifying. I didnot have the cinder service previously. It was not 
a complete setup. Now, I did the setup of cinder service.
Output of keystone service list.
[Inline image 1]
I installed the setup of openstack using the installation guide for ubuntu and 
for kloudbuster, its a pypi based installation. So, I am running kloudbuster 
using the CLI option.
kloudbuster --tested-rc keystone-openrc.sh --tested-passwd * --config kb.cfg

contents of kb.cfg:
image_name: 'kloudbuster'

I added the kloudbuster v5 version as glance image with name as kloudbuster.

I don't understand some basic things. If you can help, then that would be great.
-Does the server side means the cloud generating the traffic and client side 
means the the cloud on which connections are established? Can you please 
elaborate on client, server and proxy?
-while running the kloudbuster, I saw "setting up redis connection". Can you 
please expain to which connection is established and why? Is it KB_PROXY?

Please find attached the run of kloudbuster as a file. I have still not 
succeeded in running the kloudbuster, some errors.
I appreciate your help Alec.

Thanks,
Akshay

On Mon, Mar 28, 2016 at 8:59 PM, Alec Hothan (ahothan) 
mailto:ahot...@cisco.com>> wrote:

Can you describe what you mean by "do not have a cinder service"?
Can you provide the output of "keystone service-list"?

We'd have to know a bit more about what you have been doing:
how did you install your openstack, how did you install kloudbuster, which 
kloudbuster qcow2 image version did you use, who did you run kloudbuster (cli 
or REST or web UI), what config file have you been using, complete log of the 
run (including backtrace)...

But the key is - you should really have a fully working openstack deployment 
before using kloudbuster. Nobody has never tried so far to use kloudbuster 
without such basic service as cinder working.

Thanks

  Alec



From: Akshay Kumar Sanghai 
mailto:akshaykumarsang...@gmail.com>>
Date: Monday, March 28, 2016 at 6:51 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>, 
Alec Hothan mailto:ahot...@cisco.com>>
Cc: "Yichen Wang (yicwang)" mailto:yicw...@cisco.com>>
Subject: Re: [openstack-dev] [kloudbuster] authorization failed problem

Hi Alec,
Thanks for the help. I ran into another problem. At present I do not have a 
cinder service. So ,when i am trying to run kloudbus

Re: [openstack-dev] [i18n][horizon][sahara][trove][magnum][murano] dashboard plugin release schedule

2016-03-30 Thread Craig Vyvial

Just an update on this thread that the trove-dashboard RC2 was released
https://review.openstack.org/#/c/298365/

Thanks,
Craig Vyvial

On Wed, Mar 23, 2016 at 11:36 PM Craig Vyvial  wrote:

> The trove-dashboard has its own stable/mitaka branch [1] as well. We have
> an RC1 release already and we can make sure to land the translations and
> cut an RC2 early next week (March 28).
>
> Thanks,
> Craig Vyvial
>
> [1] https://github.com/openstack/trove-dashboard/tree/stable/mitaka
>
>
> On Wed, Mar 23, 2016 at 11:02 PM Akihiro Motoki  wrote:
>
>> Thank you all for your supports.
>> We can see the progress of translations at [0]
>>
>> Shu,
>> Magnum UI adopts the independent release model. Good to know you have
>> stable/mitaka branch :)
>> Once the stable branch is cut, let not only me but also the i18n team
>> know it.
>> openstack-i18n ML is the best place to do it.
>> If so, the i18n team and the infra team will setup required action for
>> Zanata sync.
>>
>> [0]
>> https://translate.openstack.org/version-group/view/mitaka-translation/projects
>>
>> 2016-03-24 12:33 GMT+09:00 Shuu Mutou :
>> > Hi Akihiro,
>> >
>> > Thank you for your announcement.
>> > We will create stable/mitaka branch for Magnum-UI in this week,
>> > and that will freeze strings.
>> >
>> > Thanks,
>> >
>> > Shu Muto
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kloudbuster] authorization failed problem

2016-03-30 Thread Akshay Kumar Sanghai

Hi Yichen,
Thanks a lot . I will try with v6 and reach out to you for further help.

Regards,
Akshay

On Wed, Mar 30, 2016 at 11:35 PM, Yichen Wang (yicwang) 
wrote:

> Hi, Akshay,
>
>
>
> From the log you attached, the good news is you got KloudBuster installed
> and running fine! The problem is the image you are using (v5) is outdated
> for the latest KloudBuster main code. J
>
>
>
> Normally for every version of KloudBuster, it needs certain version of
> image to support the full functionality. In the case when new feature is
> brought in, we tag the main code with a new version, and bump up the image
> version. Like from v5 to v6, we added the capability to support storage
> testing on cinder volume and ephemeral disks as well. We are right in our
> time for publishing the v6 image to the OpenStack App Catalog, which may
> take another day or two. This is why you are seeing the connection to the
> redis agent in KB-Proxy is failing…
>
>
>
> In order to unblock you, here is the RC image of v6 we are using right
> now, replace it in your cloud and KloudBuster should be good to go:
>
> https://cisco.box.com/s/xelzx15swjra5qr0ieafyxnbyucnnsa0
>
>
>
> Now back to your question.
>
> -Does the server side means the cloud generating the traffic and client
> side means the the cloud on which connections are established? Can you
> please elaborate on client, server and proxy?
>
> [Yichen] It is the other way around. Server is running nginx, and client
> is running the traffic generator (wrk2). It is like the way we normally
> understand. Since there might be lots of servers and clients in the same
> cloud, so KB-Proxy is an additional VM that runs in the clients side to
> orchestrate all client VMs to generate traffic, collect the results from
> each VM, and send them back to the main KloudBuster for processing.
> KB-Proxy is the where the redis server is sitting, and acts as the proxy
> node to connect all internal VMs to the external network. This is why a
> floating IP is needed for the proxy node.
>
>
>
> -while running the kloudbuster, I saw "setting up redis connection". Can
> you please expain to which connection is established and why? Is it
> KB_PROXY?
>
> [Yichen] As I explained above, KB-Proxy is the bridge between internal VM
> and external world (like the host you are running KloudBuster from).
> “Setting up redis connection” means the KloudBuster is trying to connect to
> the redis server on the KB-Proxy node. You may see some retries because it
> does take some time for the VM to be up running.
>
>
>
> Thanks very much!
>
>
>
> Regards,
>
> Yichen
>
>
>
> *From:* Akshay Kumar Sanghai [mailto:akshaykumarsang...@gmail.com]
> *Sent:* Wednesday, March 30, 2016 7:31 AM
> *To:* Alec Hothan (ahothan) 
> *Cc:* OpenStack List ; Yichen Wang
> (yicwang) 
>
> *Subject:* Re: [openstack-dev] [kloudbuster] authorization failed problem
>
>
>
> Hi Alec,
>
> Thanks for clarifying. I didnot have the cinder service previously. It was
> not a complete setup. Now, I did the setup of cinder service.
>
> Output of keystone service list.
>
> [image: Inline image 1]
>
> I installed the setup of openstack using the installation guide for ubuntu
> and for kloudbuster, its a pypi based installation. So, I am running
> kloudbuster using the CLI option.
>
> kloudbuster --tested-rc keystone-openrc.sh --tested-passwd * --config
> kb.cfg
>
>
>
> contents of kb.cfg:
>
> image_name: 'kloudbuster'
>
>
>
> I added the kloudbuster v5 version as glance image with name as
> kloudbuster.
>
>
>
> I don't understand some basic things. If you can help, then that would be
> great.
>
> -Does the server side means the cloud generating the traffic and client
> side means the the cloud on which connections are established? Can you
> please elaborate on client, server and proxy?
>
> -while running the kloudbuster, I saw "setting up redis connection". Can
> you please expain to which connection is established and why? Is it
> KB_PROXY?
>
>
>
> Please find attached the run of kloudbuster as a file. I have still not
> succeeded in running the kloudbuster, some errors.
>
> I appreciate your help Alec.
>
>
>
> Thanks,
>
> Akshay
>
>
>
> On Mon, Mar 28, 2016 at 8:59 PM, Alec Hothan (ahothan) 
> wrote:
>
>
>
> Can you describe what you mean by "do not have a cinder service"?
>
> Can you provide the output of "keystone service-list"?
>
>
>
> We'd have to know a bit more about what you have been doing:
>
> how did you install your openstack, how did you install kloudbuster, which
> kloudbuster qcow2 image version did you use, who did you run kloudbuster
> (cli or REST or web UI), what config file have you been using, complete log
> of the run (including backtrace)...
>
>
>
> But the key is - you should really have a fully working openstack
> deployment before using kloudbuster. Nobody has never tried so far to use
> kloudbuster without such basic service as cinder working.
>
>
>
> Thanks
>
>
>
>   Alec
>
>
>
>
>
>
>
> *From: *Akshay Kumar Sanghai 
> *D

Re: [openstack-dev] [TripleO] tripleo-quickstart import

2016-03-30 Thread Paul Belanger

On Tue, Mar 29, 2016 at 08:30:22PM -0400, John Trowbridge wrote:
> Hola,
> 
> With the approval of the tripleo-quickstart spec[1], it is time to
> actually start doing the work. The first work item is moving it to the
> openstack git. The spec talks about moving it as is, and this would
> still be fine.
> 
> However, there are roles in the tripleo-quickstart tree that are not
> directly related to the instack-virt-setup replacement aspect that is
> approved in the spec (image building, deployment). I think these should
> be split into their own ansible-role-* repos, so that they can be
> consumed using ansible-galaxy. It would actually even make sense to do
> that with the libvirt role responsible for setting up the virtual
> environment. The tripleo-quickstart would then be just an integration
> layer making consuming these roles for virtual deployments easy.
> 
> This way if someone wanted to make a different role for say OVB
> deployments, it would be easy to use the other roles on top of a
> differently provisioned undercloud.
> 
> Similarly, if we wanted to adopt ansible to drive tripleo-ci, it would
> be very easy to only consume the roles that make sense for the tripleo
> cloud.
> 
> So the first question is, should we split the roles out of
> tripleo-quickstart?
> 
> If so, should we do that before importing it to the openstack git?
> 
> Also, should the split out roles also be on the openstack git?
> 
So, we actually have a few ansible roles in OpenStack, mostly imported by
myself.  The OpenStack ansible teams has a few too.

I would propose, keep them included in your project for now and maybe start a
different discussion with all the ansible projects (kolla, ansible-openstack,
windmill, etc) to see how to best move forward.  I've discussed with openstack
ansible in the past about moving the roles I have uploaded into their team and
hope to bring it up again at Austin.

> Maybe this all deserves its own spec and we tackle it after completing
> all of the work for the first spec. I put this on the meeting agenda for
> today, but we didn't get to it.
> 
> - trown
> 
> __
> 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][vote] Just make Mitaka deploy Liberty within the Liberty branch

2016-03-30 Thread Michał Jastrzębski

So I made this:
https://review.openstack.org/#/c/299563/

I'm not super fond of reverting commits from the middle of release,
because this will make a lot of mess. I'd rather re-implement keystone
bootstrap logic and make it conditional as it is not that complicated.

On 30 March 2016 at 12:37, Ryan Hallisey  wrote:
> Agreed this needs to happen +1,
>
> - Original Message -
> From: "Jeff Peeler" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Wednesday, March 30, 2016 1:22:31 PM
> Subject: Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty 
> within the Liberty branch
>
> On Wed, Mar 30, 2016 at 3:52 AM, Steven Dake (stdake)  
> wrote:
>>
>>
>> From: Jeffrey Zhang 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Wednesday, March 30, 2016 at 12:29 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty
>> within the Liberty branch
>>
>> +1
>>
>> A lot of changes has been make in Mitaka. Backport is difficult.
>>
>> But using Mitaka deploy Liberty also has *much works*. For example,
>> revert config file change which deprecated in Mitaka and Liberty support.
>>
>> A important one is the `keystone-manage bootstrap` command to create the
>> keystone admin account. This is adderecently and only exist in the Mitaka
>> branch. So when using this method, we should revert some commit and use
>> the old way method.
>>
>>
>> Agreed.
>
> I'm sure there will be some checking and such once all the code has
> been shuffled around, but I think doing this work is better than
> abandoning a branch. So +1 to proposal.
>
> __
> 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] minutes of the Trove meeting 2016-03-30