[openstack-dev] [nova] Vendordata improvements

[Michael Still]

So, https://review.openstack.org/#/c/317739 is basically done I think. I'm
after people's thoughts on:

 - I need to do some more things, as described in the commit message. Are
we ok with them being in later patches to get reviews moving on this?

 - I'm unsure what level of tempest testing makes sense here. How much
would you like to see? Do we need to add a vendordata REST service to
devstack? That might be complicated in the amount of time available...

Michael

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

Re: [openstack-dev] [Kuryr] jenkins failures "POST_FAILURE",

[Vikas Choudhary]

yes, recheck fixed it this time.


Thanks
Vikas

On Tue, Jun 21, 2016 at 11:13 AM, Will Zhou  wrote:

> recheck fix my problem. You can try that. Thanks.
>
> On Tue, Jun 21, 2016 at 1:21 PM Andreas Jaeger  wrote:
>
>> On 06/21/2016 06:35 AM, Vikas Choudhary wrote:
>> > Hi Team,
>> >
>> > Since yesterday, I am observing abnormal jenkins failures on some of
>> > patches while others are fine. Also not able to access logs for
>> failures.
>> >
>> > https://review.openstack.org/#/c/326303/8
>> > Jenkins check Jun 20 12:32 PM
>> > gate-kuryr-docs
>> > 
>> > POST_FAILURE in 13m 00s
>> > gate-kuryr-pep8
>> > 
>> > POST_FAILURE in 7m 53s
>> > gate-kuryr-python27
>> > <
>> http://logs.openstack.org/03/326303/8/check/gate-kuryr-python27/5166951/>
>> > POST_FAILURE in 13m 22s
>> > gate-install-dsvm-kuryr
>> > <
>> http://logs.openstack.org/03/326303/8/check/gate-install-dsvm-kuryr/c743aa5/
>> >
>> > POST_FAILURE in 19m 00s
>> > gate-kuryr-dsvm-fullstack-nv
>> > <
>> http://logs.openstack.org/03/326303/8/check/gate-kuryr-dsvm-fullstack-nv/32ce2de/
>> >
>> > POST_FAILURE in 25m 08s (non-voting)
>> > gate-kuryr-dsvm-rally-nv
>> > <
>> http://logs.openstack.org/03/326303/8/check/gate-kuryr-dsvm-rally-nv/9b4a633/
>> >
>> > POST_FAILURE in 24m 08s (non-voting)
>> > gate-kuryr-python34
>> > <
>> http://logs.openstack.org/03/326303/8/check/gate-kuryr-python34/203c903/>
>> > POST_FAILURE in 13m 41s (non-voting)
>>
>> Those are infra failures, please leave a "recheck" comment. We had
>> yesterday an outtage of our log server, see
>> https://wiki.openstack.org/wiki/Infrastructure_Status, and that one
>> marked jobs as failed like yours above.
>>
>> > Another anomaly is "patch in merge conflict" even after rebasing.
>> >
>> > Anybody any clue?
>>
>> Which change is that? Best to ask on #openstack-infra,
>>
>> Andreas
>>
>> >
>> >
>> > Regards
>> > Vikas
>> >
>> >
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing 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
>>
>
> __
> OpenStack Development Mailing 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] [Kuryr] jenkins failures "POST_FAILURE",

[Will Zhou]

recheck fix my problem. You can try that. Thanks.

On Tue, Jun 21, 2016 at 1:21 PM Andreas Jaeger  wrote:

> On 06/21/2016 06:35 AM, Vikas Choudhary wrote:
> > Hi Team,
> >
> > Since yesterday, I am observing abnormal jenkins failures on some of
> > patches while others are fine. Also not able to access logs for failures.
> >
> > https://review.openstack.org/#/c/326303/8
> > Jenkins check Jun 20 12:32 PM
> > gate-kuryr-docs
> > 
> > POST_FAILURE in 13m 00s
> > gate-kuryr-pep8
> > 
> > POST_FAILURE in 7m 53s
> > gate-kuryr-python27
> > <
> http://logs.openstack.org/03/326303/8/check/gate-kuryr-python27/5166951/>
> > POST_FAILURE in 13m 22s
> > gate-install-dsvm-kuryr
> > <
> http://logs.openstack.org/03/326303/8/check/gate-install-dsvm-kuryr/c743aa5/
> >
> > POST_FAILURE in 19m 00s
> > gate-kuryr-dsvm-fullstack-nv
> > <
> http://logs.openstack.org/03/326303/8/check/gate-kuryr-dsvm-fullstack-nv/32ce2de/
> >
> > POST_FAILURE in 25m 08s (non-voting)
> > gate-kuryr-dsvm-rally-nv
> > <
> http://logs.openstack.org/03/326303/8/check/gate-kuryr-dsvm-rally-nv/9b4a633/
> >
> > POST_FAILURE in 24m 08s (non-voting)
> > gate-kuryr-python34
> > <
> http://logs.openstack.org/03/326303/8/check/gate-kuryr-python34/203c903/>
> > POST_FAILURE in 13m 41s (non-voting)
>
> Those are infra failures, please leave a "recheck" comment. We had
> yesterday an outtage of our log server, see
> https://wiki.openstack.org/wiki/Infrastructure_Status, and that one
> marked jobs as failed like yours above.
>
> > Another anomaly is "patch in merge conflict" even after rebasing.
> >
> > Anybody any clue?
>
> Which change is that? Best to ask on #openstack-infra,
>
> Andreas
>
> >
> >
> > Regards
> > Vikas
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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
>
__
OpenStack Development Mailing 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] [Kuryr] jenkins failures "POST_FAILURE", logs not accessible

[Vikas Choudhary]

It seems to be working now after recheck. Ignore please for now.



Regards
Vikas

On Tue, Jun 21, 2016 at 10:05 AM, Vikas Choudhary <
choudharyvika...@gmail.com> wrote:

> Hi Team,
>
> Since yesterday, I am observing abnormal jenkins failures on some of
> patches while others are fine. Also not able to access logs for failures.
>
> https://review.openstack.org/#/c/326303/8
> Jenkins check Jun 20 12:32 PM
> gate-kuryr-docs
> 
> POST_FAILURE in 13m 00s
> gate-kuryr-pep8
> 
> POST_FAILURE in 7m 53s
> gate-kuryr-python27
> 
> POST_FAILURE in 13m 22s
> gate-install-dsvm-kuryr
> 
> POST_FAILURE in 19m 00s
> gate-kuryr-dsvm-fullstack-nv
> 
> POST_FAILURE in 25m 08s (non-voting)
> gate-kuryr-dsvm-rally-nv
> 
> POST_FAILURE in 24m 08s (non-voting)
> gate-kuryr-python34
> 
> POST_FAILURE in 13m 41s (non-voting)Another anomaly is "patch in merge
> conflict" even after rebasing.
>
> Anybody any clue?
>
>
>
> Regards
> Vikas
>
>
>
__
OpenStack Development Mailing 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] [Kuryr] jenkins failures "POST_FAILURE",

[Andreas Jaeger]

On 06/21/2016 06:35 AM, Vikas Choudhary wrote:
> Hi Team,
> 
> Since yesterday, I am observing abnormal jenkins failures on some of
> patches while others are fine. Also not able to access logs for failures. 
> 
> https://review.openstack.org/#/c/326303/8
> Jenkins check Jun 20 12:32 PM
> gate-kuryr-docs
> 
> POST_FAILURE in 13m 00s
> gate-kuryr-pep8
> 
> POST_FAILURE in 7m 53s
> gate-kuryr-python27
> 
> POST_FAILURE in 13m 22s
> gate-install-dsvm-kuryr
> 
> POST_FAILURE in 19m 00s
> gate-kuryr-dsvm-fullstack-nv
> 
> POST_FAILURE in 25m 08s (non-voting)
> gate-kuryr-dsvm-rally-nv
> 
> POST_FAILURE in 24m 08s (non-voting)
> gate-kuryr-python34
> 
> POST_FAILURE in 13m 41s (non-voting)

Those are infra failures, please leave a "recheck" comment. We had
yesterday an outtage of our log server, see
https://wiki.openstack.org/wiki/Infrastructure_Status, and that one
marked jobs as failed like yours above.

> Another anomaly is "patch in merge conflict" even after rebasing.
>
> Anybody any clue?

Which change is that? Best to ask on #openstack-infra,

Andreas

> 
> 
> Regards
> Vikas
> 
> 
> 
> 
> __
> OpenStack Development Mailing 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

[openstack-dev] [keystone] [stable/mitaka] Error: Discovering versions from the identity service failed when creating the password plugin....

[mohammad shahid]

Hi,

I am getting below error while starting openstack devstack with
stable/mitaka release. can someone look at this problem ?



*Detail Error Logs:*2016-06-21 04:11:49.831 |
++^[[3242muserrc_early:source:11   ^[(B^[[m export
OS_REGION_NAME=RegionOne
2016-06-21 04:11:49.857 |
++^[[3242muserrc_early:source:11   ^[(B^[[m
OS_REGION_NAME=RegionOne
2016-06-21 04:11:49.874 | +^[[3242m./stack.sh:main:1040
^[(B^[[m create_keystone_accounts
2016-06-21 04:11:49.886 |
+^[[3242mlib/keystone:create_keystone_accounts:382 ^[(B^[[m local
admin_project
2016-06-21 04:11:49.922 |
++^[[3242mlib/keystone:create_keystone_accounts:383 ^[(B^[[m openstack
project show admin -f value -c id
2016-06-21 04:11:52.724 |
*Discovering versions from the identity service failed when creating the
password plugin. Attempting to determine version from URL.2016-06-21
04:11:52.724 | Could not determine a suitable URL for the plugin*
2016-06-21 04:11:52.783 |
+^[[3242mlib/keystone:create_keystone_accounts:383 ^[(B^[[m admin_project=
2016-06-21 04:11:52.808 | +^[[3242mlib/keystone:create_keystone_accounts:1
^[(B^[[m exit_trap
2016-06-21 04:11:52.820 | +^[[3242m./stack.sh:exit_trap:480
^[(B^[[m local r=1
2016-06-21 04:11:52.826 |
++^[[3242m./stack.sh:exit_trap:481 ^[(B^[[m jobs -p
2016-06-21 04:11:52.830 | +^[[3242m./stack.sh:exit_trap:481
^[(B^[[m jobs=
2016-06-21 04:11:52.849 | +^[[3242m./stack.sh:exit_trap:484
^[(B^[[m [[ -n '' ]]
2016-06-21 04:11:52.863 | +^[[3242m./stack.sh:exit_trap:490
^[(B^[[m kill_spinner
2016-06-21 04:11:52.888 | +^[[3242m./stack.sh:kill_spinner:376
^[(B^[[m '[' '!' -z '' ']'
2016-06-21 04:11:52.905 | +^[[3242m./stack.sh:exit_trap:492
^[(B^[[m [[ 1 -ne 0 ]]
2016-06-21 04:11:52.928 | +^[[3242m./stack.sh:exit_trap:493
^[(B^[[m echo 'Error on exit'
2016-06-21 04:11:52.928 | Error on exit
2016-06-21 04:11:52.936 | +^[[3242m./stack.sh:exit_trap:494
^[(B^[[m generate-subunit 1466481505 807 fail
2016-06-21 04:11:53.270 | +^[[3242m./stack.sh:exit_trap:495
^[(B^[[m [[ -z /opt/stack/logs/ ]]
2016-06-21 04:11:53.274 | +^[[3242m./stack.sh:exit_trap:498
^[(B^[[m /home/openstack/devstack/tools/worlddump.py -d /opt/stack/logs/
2016-06-21 04:11:53.663 | +^[[3242m./stack.sh:exit_trap:504
^[(B^[[m exit 1




*Local.conf configuration: *#CONTROLLER CONFIG FILE
[[local|localrc]]
FORCE=yes
RECLONE=True
#OFFLINE=True






*HORIZON_BRANCH=stable/mitakaKEYSTONE_BRANCH=stable/mitakaNOVA_BRANCH=stable/mitakaNEUTRON_BRANCH=stable/mitakaGLANCE_BRANCH=stable/mitakaCINDER_BRANCH=stable/mitakaHEAT_BRANCH=stable/mitaka*

MYSQL_PASSWORD=openstack
DATABASE_PASSWORD=openstack
RABBIT_PASSWORD=openstack
ADMIN_PASSWORD=openstack
SERVICE_PASSWORD=openstack
HORIZON_PASSWORD=openstack
SERVICE_TOKEN=openstack
default_store=file

disable_service swift
disable_service cinder
disable_service n-net
enable_service q-svc
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
disable_service q-vpn
disable_service q-metering
disable_service q-lbaas
disable_service q-fwaas
enable_service neutron
disable_service tempest

DEST=/opt/stack
SCREEN_LOGDIR=$DEST/logs/
LOGFILE=${SCREEN_LOGDIR}/xstack.sh.log
LOGDAYS=1
DATABASE_QUERY_LOGGING=False



*Thanks and Regards,*

*Mohammad Shahid*
__
OpenStack Development Mailing 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] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Andre Florath]

Hi!

Before things getting said twice (looks that there is some
public interest here ;-) ):

Can you please rerun and skip the partition part of
the loop device for fdisk -l?
E.g. instead of /dev/loop0p1 just /dev/loop0?
(This was my original intend but maybe not correctly
described.)

Also can you please send the parameters passed to parted?
(When running with trace enabled
this should be written to the logs. Please run something like
   export DIB_DEBUG_TRACE="255"
   disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm | tee o.log
and send the output of
   grep parted o.log
)

===

To be on the same page, here are the other infos Jay send:

> o Can you please provide the DIB version?

ii  python-dib-utils 0.0.6-1
ii  python-diskimage-builder 1.0.0-1

> o Are you using UEFI on the host system?
>(For me your command works and this question is about
> a possible difference: '--target=i386-pc' appears
> not in my logs)

Yes, it's a UEFI-enabled host:

jaypipes@brix-1:~$ sudo efibootmgr
BootCurrent: 
Timeout: 1 seconds
BootOrder: ,0002,0001
Boot* ubuntu
Boot0001* Hard Drive
Boot0002* ubuntu

===

Kind regards

Andre

__
OpenStack Development Mailing 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] [Kuryr] jenkins failures "POST_FAILURE", logs not accessible

[Vikas Choudhary]

Hi Team,

Since yesterday, I am observing abnormal jenkins failures on some of
patches while others are fine. Also not able to access logs for failures.

https://review.openstack.org/#/c/326303/8
Jenkins check Jun 20 12:32 PM
gate-kuryr-docs

POST_FAILURE in 13m 00s
gate-kuryr-pep8

POST_FAILURE in 7m 53s
gate-kuryr-python27

POST_FAILURE in 13m 22s
gate-install-dsvm-kuryr

POST_FAILURE in 19m 00s
gate-kuryr-dsvm-fullstack-nv

POST_FAILURE in 25m 08s (non-voting)
gate-kuryr-dsvm-rally-nv

POST_FAILURE in 24m 08s (non-voting)
gate-kuryr-python34

POST_FAILURE in 13m 41s (non-voting)Another anomaly is "patch in merge
conflict" even after rebasing.

Anybody any clue?



Regards
Vikas
__
OpenStack Development Mailing 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] Placement API WSGI code -- let's just use flask

[Jay Pipes]

Hi Chris, stackers,

OK, so I've been a pretty vocal proponent of Chris' approach to the new 
placement REST API endpoint, which is to use no WSGI frameworks and 
instead just use the selector library (or Routes as a second choice) for 
defining the URI mappings.


However, I had a chat with Doug (cc'd) today and he pulled me around to 
the view that it is better to use one of the WSGI frameworks used by the 
other OpenStack projects instead of going in a completely new direction. 
It will be easier for other OpenStack contributors to become familiar 
with the new placement API endpoint code if it uses Flask.


So, as much as I'm not a fan of any framework for handling WSGI stuff, 
Flask is probably the best choice for the new placement API code. I'd 
suggest Falcon but a) it's been a while since I used Falcon (lots of 
stuff has changed since I last worked with it) and b) it's only used by 
Zaqar and is better suited (IMO) for data plane APIs than control plane 
APIs.


Flask seems to be the most widely used and known WSGI framework so for 
consistency's sake, I'm recommending we just use it and not rock this 
boat. There are more important things to get hung up on than this battle 
right now.


Best,
-jay

__
OpenStack Development Mailing 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] [requirements][all] VOTE to expand the Requirements Team

[Swapnil Kulkarni (coolsvap)]

Thank you all.

On Mon, Jun 20, 2016 at 6:39 PM, Davanum Srinivas  wrote:
> Thanks for the VOTE everyone.
>
> Matthew, Dirk, Swapnil, Tony, Thomas,
> With this VOTE the training wheels come off :) Please be cautious with
> your new super powers!

Dims, yes of course :)

>
> And thanks a Ton to Thierry as well.
>
> Thanks,
> Dims
>
> On Fri, Jun 17, 2016 at 3:59 PM, Robert Collins
>  wrote:
>> Sure. +1
>>
>> On 17 June 2016 at 02:44, Davanum Srinivas  wrote:
>>> Folks,
>>>
>>> At Austin the Release Management team reached a consensus to spin off
>>> with some new volunteers to take care of the requirements process and
>>> repository [1]. The following folks showed up and worked with me on
>>> getting familiar with the issues/problems/tasks (see [1] and [2]) and
>>> help with the day to day work.
>>>
>>> Matthew Thode (prometheanfire)
>>> Dirk Mueller (dirk)
>>> Swapnil Kulkarni (coolsvap)
>>> Tony Breeds (tonyb)
>>> Thomas Bechtold (tbechtold)
>>>
>>> So, please cast your VOTE to grant them +2/core rights on the
>>> requirements repository and keep up the good work w.r.t speeding up
>>> reviews, making sure new requirements don't break etc.
>>>
>>> Also, please note that Thierry has been happy enough with our work to
>>> step down from core responsibilities :) Many thanks Thierry for
>>> helping with this effort and guidance. I'll make all the add/remove to
>>> the requirements-core team when this VOTE passes.
>>>
>>> Thanks,
>>> Dims
>>>
>>> [1] https://etherpad.openstack.org/p/newton-relmgt-plan
>>> [2] https://etherpad.openstack.org/p/requirements-tasks
>>> [3] https://etherpad.openstack.org/p/requirements-cruft
>>>
>>> --
>>> 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
>
>
>
> --
> 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



-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap
me at coolsvap dot net
+91-87960 10622(c)
http://in.linkedin.com/in/coolsvap
"It's better to SHARE"

__
OpenStack Development Mailing 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] Version header for OpenStack microversion support

[Jamie Lennox]

On 21 June 2016 at 11:41, Edward Leafe  wrote:

> On Jun 18, 2016, at 9:03 AM, Clint Byrum  wrote:
>
> > Whatever API version is used behind the compute API is none of the user's
> > business.
>
> Actually, yeah, it is.
>
> If I write an app or a tool that expects to send information in a certain
> format, and receive responses in a certain format, I don't want that to
> change when the cloud operator upgrades their system. I only want things to
> change when I specifically request that they change by specifying a new
> microversion.
>
>
I think the point there was as a user you only get to specify the version
you communicate with the initial service. Talking to nova you can ask for
2.4 (no idea on the actual numbers), but you have no control over the
version nova uses to talk to neutron or glance because that doesn't affect
the output to you as a user.


>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Version header for OpenStack microversion support

[Edward Leafe]

On Jun 18, 2016, at 9:03 AM, Clint Byrum  wrote:

> Whatever API version is used behind the compute API is none of the user's
> business.

Actually, yeah, it is.

If I write an app or a tool that expects to send information in a certain 
format, and receive responses in a certain format, I don't want that to change 
when the cloud operator upgrades their system. I only want things to change 
when I specifically request that they change by specifying a new microversion.


-- Ed Leafe







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] [kolla] Cinder multiple backends

[Carlos Cesario]

Hi Michal and Ryan,

Thank you so much by explanation.

After instructions provide by Michal, I got built the container with additional 
packs.

It folows the report:

1 - It was created a /etc/kolla/config/include_build/cinder-volume.include file 
with the content:
{% if base_distro == 'ubuntu' %}
RUN apt-get -y install --no-install-recommends sysfsutils sg3-utils
{% endif %}

But it did not work, the {% %} block broke the build -> 
http://paste.openstack.org/show/520666/

After remove {% %} the build it worked! But maybe will be needed parser the {% 
%} block, to treat what kind of package will be installed, by example apt or rm 
packs, based on base system.


2 - In my case, I need install multipath-tools and make it enabled on startup 
on compute-node container, due the IBM Storwize Cinder Driver when using FC 
protocol. This too will needed with others drivers.
How to can I make the multipath-tools service it enabled using "automatic mode" 
in container deploy process!!?

Best regards,


- Carlos

- Mensagem original -
De: "Michał Jastrzębski" 
Para: "OpenStack Development Mailing List (not for usage questions)" 

Enviadas: Segunda-feira, 20 de junho de 2016 10:43:36
Assunto: Re: [openstack-dev] [kolla] Cinder multiple backends

Right now you can install it by providing --include-header file during
build. We are working on cleaner mechanism in Newton [1].

[1] https://review.openstack.org/#/q/topic:bp/third-party-plugin-support

On 20 June 2016 at 08:29, Carlos Cesario  wrote:
> Hi folks,
>
> It seems that Kolla does nos provide option to enable multiple backends in 
> Cinder config.
>
> Currently in my deploy/setup I needed enable the Storwize Cinder driver - 
> http://docs.openstack.org/mitaka/config-reference/block-storage/drivers/ibm-storwize-svc-driver.html
>  -
> and to this I added into /etc/kolla/config/cinder.conf my configs
>
>   [DEFAULT]
>   default_volume_type = ibm
>
>   [ibm]
>   
> volume_driver=cinder.volume.drivers.ibm.storwize_svc.storwize_svc_fc.StorwizeSVCFCDriver
>   san_ip=xxx.xx.xx.xx
>   san_login=superuser
>   san_password=mypass
>   san_ssh_port=22
>   storwize_svc_volpool_name=myPool
>   volume_backend_name=ibm
>   verbose = True
>   debug = True
>
>
> And I changed manually the file 
> /var/src/kolla-master/ansible/roles/cinder/templates/cinder.conf.j2 as well.
>
> But for the driver works correctly, it was needed install manually some 
> aditional packs.
>
> $ apt-get install sysfsutils sg3-utils on cinder-volume container
> $ apt-get install multipath-tools sysfsutils on nova-compute container
>
> Is there any doc/spec to create a automatic process for this ? Could someone 
> give us details how is the best way to make it "automatized" !?
>
>
>
> Best regards,
>
> - Carlos
> __
> OpenStack Development Mailing 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] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Gregory Haynes]

On Mon, Jun 20, 2016, at 06:01 PM, Jay Pipes wrote:
> On 06/20/2016 06:41 PM, Paul Belanger wrote:
> > On Mon, Jun 20, 2016 at 04:52:38PM -0400, Jay Pipes wrote:
> >> Hi dib-gurus,
> >>
> >> I'm trying to build a simple ubuntu VM image on a local Gigabyte BRIX with 
> >> a
> >> AMD A8-5557M APU with Ubuntu 16.04 installed and getting an odd error.
> >> Hoping someone has some ideas...
> >>
> >> The command I am running is:
> >>
> >> disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm
> >>
> > Do you have the same issue if you use ubuntu-minimal? I only suggest it 
> > since
> > openstack-infra defaults to -minimal elements now, which is a more tested 
> > code
> > path IMO.
> 
> Hmm, unfortunately same error...
> 
> I've been working with Andre Florath on a private thread. He asked me to 
> drop dib into a debug shell and output the contents of:
> 
> /sbin/fdisk -l /dev/loop0p1
> 
> That returned some nastysauce:
> 
> root@brix-1:/# echo $IMAGE_BLOCK_DEVICE
> /dev/loop0p1
> root@brix-1:/# /sbin/fdisk -l /dev/loop0p1
> 
> Disk /dev/loop0p1: 1743 MB, 1743584768 bytes
> 255 heads, 63 sectors/track, 211 cylinders, total 3405439 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x
> 
> Disk /dev/loop0p1 doesn't contain a valid partition table
> 
> The quest continues... :)
> 
> -jay

Ah, the plot thickens.

Partition creation happens here:
http://git.openstack.org/cgit/openstack/diskimage-builder/tree/elements/vm/block-device.d/10-partition#n22

It might be worth dropping a bash right afterward to see whether that is
actually succeeding. Its possible that parted is failing but we aren't
catching that failure for some reason, or when we dd the image back on
to the block device we are failing horribly and writing over the
partition table (that would be a totally new bug to me though).

Alternatively, if you could paste a complete log of you image build
somewhere so we can dig through maybe we can spot something interesting.

Cheers,
Greg

__
OpenStack Development Mailing 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] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Jay Pipes]

On 06/20/2016 06:41 PM, Paul Belanger wrote:

On Mon, Jun 20, 2016 at 04:52:38PM -0400, Jay Pipes wrote:

Hi dib-gurus,

I'm trying to build a simple ubuntu VM image on a local Gigabyte BRIX with a
AMD A8-5557M APU with Ubuntu 16.04 installed and getting an odd error.
Hoping someone has some ideas...

The command I am running is:

disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm


Do you have the same issue if you use ubuntu-minimal? I only suggest it since
openstack-infra defaults to -minimal elements now, which is a more tested code
path IMO.


Hmm, unfortunately same error...

I've been working with Andre Florath on a private thread. He asked me to 
drop dib into a debug shell and output the contents of:


/sbin/fdisk -l /dev/loop0p1

That returned some nastysauce:

root@brix-1:/# echo $IMAGE_BLOCK_DEVICE
/dev/loop0p1
root@brix-1:/# /sbin/fdisk -l /dev/loop0p1

Disk /dev/loop0p1: 1743 MB, 1743584768 bytes
255 heads, 63 sectors/track, 211 cylinders, total 3405439 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x

Disk /dev/loop0p1 doesn't contain a valid partition table

The quest continues... :)

-jay

__
OpenStack Development Mailing 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 idea of manually managing the bay nodes

[Hongbin Lu]

Hi all,

During the discussion in this ML and team meetings, it seems most of us 
accepted the idea of supporting heterogeneous cluster. What we didn't agree 
well is how to implement it. To move it forward, I am going to summarize 
various implementation options so that we can debate each options thoughtfully.

* Goal:
Add support for provisioning and managing a COE cluster with nodes of various 
types. For example, a k8s cluster with N groups of nodes: the first group of 
nodes have flavor A, the second group of nodes have flavor B, and so on.

* Option 1:
Implement it in Heat templates declaratively. For example, if users want to 
create a cluster with 5 nodes, Magnum will generate a set of mappings of 
parameters for each node. For example:

  $ heat stack-create -f cluster.yaml \
  -P count=5 \
  -P az_map='{"0":"az1",...,"4":"az4"}' \
  -P flavor_map='{"0":"m1.foo",...,"4":"m1.bar"}'

Inside the top-level template, it contains a single resource group. The trick 
is passing %index% to the nested template.

  $ cat cluster.yaml
  heat_template_version: 2015-04-30
  parameters:
count:
  type: integer
az_map:
  type: json
flavor_map:
  type: json
  resources:
   AGroup:
  type: OS::Heat::ResourceGroup
  properties:
count: {get_param: count}
resource_def:
  type: server.yaml
  properties:
availability_zone_map: {get_param: az_map}
flavor_map: {get_param: flavor_map}
index: '%index%'

In the nested template, use 'index' to retrieve the parameters.

  $ cat server.yaml
  heat_template_version: 2015-04-30
  parameters:
availability_zone_map:
  type: json
flavor_map:
  type: json
index:
  type: string
  resources:
   server:
  type: OS::Nova::Server
  properties:
image: the_image
flavor: {get_param: [flavor_map, {get_param: index}]}
availability_zone: {get_param: [availability_zone_map, {get_param: 
index}]}

This approach has a critical drawback. As pointed out by Zane [1], we cannot 
remove member from the middle of the list. Therefore, the usage of resource 
group was not recommended.

* Option 2:
Generate Heat template by using the generator [2]. The code to generate the 
Heat template will be something like below:

  $ cat generator.py
  from os_hotgen import composer
  from os_hotgen import heat

  tmpl_a = heat.Template(description="...")
  ...

  for group in rsr_groups:
  # parameters
  param_name = group.name + '_flavor'
  param_type = 'string'
  param_flavor = heat.Parameter(name=param_name, type=param_type)
  tmpl_a.add_parameter(param_flavor)
  param_name = group.name + '_az'
  param_type = 'string'
  param_az = heat.Parameter(name=param_name, type=param_type)
  tmpl_a.add_parameter(param_az)
  ...

  # resources
  rsc = heat.Resource(group.name, 'OS::Heat::ResourceGroup')
  resource_def = {
  'type': 'server.yaml',
  'properties': {
  'availability_zone': heat.FnGetParam(param_az.name),
  'flavor': heat.FnGetParam(param_flavor.flavor),
  ...
  }
  }
  resource_def_prp = heat.ResourceProperty('resource_def', resource_def)
  rsc.add_property(resource_def_prp)
  count_prp = heat.ResourceProperty('count', group.count)
  rsc.add_property(count_prp)
  tmpl_a.add_resource(rsc)
  ...

  print composer.compose_template(tmpl_a)

* Option 3:
Remove the usage of ResourceGroup and manually manage Heat stacks for each bay 
node. For example, for a cluster with 5 nodes, Magnum is going to create 5 Heat 
stacks:

  for node in nodes:
  fields = {
  'stack_name': node.name,
  'parameters': {
  'flavor': node.flavor,
  'availability_zone': node.availability_zone,
  ...
  },
  'template': 'server.yaml',
  ...
  }
  osc.heat().stacks.create(**fields)

The major change is to have Magnum manage multiple Heat stacks instead of one 
big stack. The main advantage is that Magnum can update stack freely and the 
codebase is relatively simple. I guess the main disadvantage is performance, as 
Magnum need to iterate all Heat stacks to compute the state of the cluster. An 
optimization is to combine this approach with ResourceGroup. For example, for a 
cluster with 2 nodes in flavor A and 3 nodes with flavor B, Magnum will create 
2 Heat stacks: the first Heat stack contains a resource group with flavor A, 
the second Heat stack contains a resource group of flavor B.

Thoughts?

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-June/097522.html
[2] https://review.openstack.org/#/c/328822/

Best regards,
Hongbin

> -Original Message-
> From: Ricardo Rocha [mailto:rocha.po...@gmail.com]
> Sent: June-07-16 3:02 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] 

[openstack-dev] [Infra] Meeting Tuesday June 21st at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday June 21st, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-06-14-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-06-14-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-06-14-19.02.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing 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] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Clint Byrum]

Excerpts from Gregory Haynes's message of 2016-06-20 17:24:28 -0500:
> On Mon, Jun 20, 2016, at 03:52 PM, Jay Pipes wrote:
> > Hi dib-gurus,
> > 
> > I'm trying to build a simple ubuntu VM image on a local Gigabyte BRIX 
> > with a AMD A8-5557M APU with Ubuntu 16.04 installed and getting an odd 
> > error. Hoping someone has some ideas...
> > 
> > The command I am running is:
> > 
> > disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm
> > 
> > Everything goes smoothly until trying to write the MBR, at which point I 
> > get the following error:
> > 
> > + /usr/sbin/grub-install '--modules=biosdisk part_msdos' 
> > --target=i386-pc /dev/loop0
> > Installing for i386-pc platform.
> > /usr/sbin/grub-install: warning: this msdos-style partition label has no 
> > post-MBR gap; embedding won't be possible.
> > /usr/sbin/grub-install: error: embedding is not possible, but this is 
> > required for cross-disk install.
> > /dev/loop0: [0047]:3 (/tmp/image.hk8wiFJe/image.raw)
> > 
> > Anybody got any ideas?
> > 
> > Thanks in advance!
> > -jay
> 
> Hey Jay,
> 
> I just tried to reproduce this on my 14.04 box and wasn't able to so I
> am betting there's some kind of new bug with us on 16.04. Do you get the
> same error if you run without --image-size=10? Last time we had an issue
> like this a new grub version changed the default behavior, so I'd
> suspect something along those lines.
> 
> I am trying out a new run on a 16.04 box but its going to be a bit
> before the cloud image downloads (cloud-image.ubuntu.com is pretty
> slow)...

I just completed a run on 16.04, so it's not that.

I wonder if it might be sensitive to disk geometry accidentally.

__
OpenStack Development Mailing 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] Elevating context to remove subnets created by admin

[Carl Baldwin]

Somehow, this thread hid from me for a couple of weeks.  I just
reviewed something relevant to this here [1].  It proposes adding
tenant id to segment.  But, it also enforces that tenant id is the
same as that of the network owning the segment.  So, I say why store
it at all?

I would argue that subnet should also not have a tenant_id and should
just inherit it from the network.

Carl

[1] https://review.openstack.org/#/c/331497/2/neutron/db/segments_db.py

On Fri, Jun 3, 2016 at 3:05 PM, Henry Gessau  wrote:
> Carl Baldwin  wrote:
>> On Fri, Jun 3, 2016 at 2:26 PM, Henry Gessau  wrote:
>>> Darek Smigiel  wrote:
 strange, that owner is not able to just get rid of *his* network and 
 subnets.
>>>
>>> But not all the subnets are his, and consequently the network is partially 
>>> not
>>> his.
>>
>> To me, this is a nonsensical outcome and tells me that subnets
>> probably shouldn't really have owners distinct from the network's.
>
> Right. So are you saying we should prevent that?
>
>
>
> __
> OpenStack Development Mailing 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] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Clint Byrum]

Ahh derp, that's not an ARM CPU. I read "A8" and "APU" and my brain
immediately lept to that. Ignore me.

Excerpts from Clint Byrum's message of 2016-06-20 15:12:23 -0700:
> Excerpts from Jay Pipes's message of 2016-06-20 16:52:38 -0400:
> > Hi dib-gurus,
> > 
> > I'm trying to build a simple ubuntu VM image on a local Gigabyte BRIX 
> > with a AMD A8-5557M APU with Ubuntu 16.04 installed and getting an odd 
> > error. Hoping someone has some ideas...
> > 
> > The command I am running is:
> > 
> > disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm
> > 
> > Everything goes smoothly until trying to write the MBR, at which point I 
> > get the following error:
> > 
> > + /usr/sbin/grub-install '--modules=biosdisk part_msdos' 
> > --target=i386-pc /dev/loop0
> > Installing for i386-pc platform.
> > /usr/sbin/grub-install: warning: this msdos-style partition label has no 
> > post-MBR gap; embedding won't be possible.
> > /usr/sbin/grub-install: error: embedding is not possible, but this is 
> > required for cross-disk install.
> > /dev/loop0: [0047]:3 (/tmp/image.hk8wiFJe/image.raw)
> 
> I think you found a bug. The ARCH should be armhf, but
> elements/bootloader/finalise.d/50-bootloader doesn't know what to do with
> armhf, so it falls back to x86_64/amd64. Also, grub-pc is the package
> that bootloader claims to need in its pkg-map file, but you really need
> grub-efi-arm on arm boxes.
> 
> We may need to add the ability for pkg-map's to differentiate based on
> ARCH.
> 
> If you intended to build an amd64 image, you need to set ARCH=amd64
> before running disk-image-create, so it won't detect it by running
> 'dpkg --print-architecture'.
> 

__
OpenStack Development Mailing 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] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Jay Pipes]

On 06/20/2016 06:24 PM, Gregory Haynes wrote:

On Mon, Jun 20, 2016, at 03:52 PM, Jay Pipes wrote:

Hi dib-gurus,

I'm trying to build a simple ubuntu VM image on a local Gigabyte BRIX
with a AMD A8-5557M APU with Ubuntu 16.04 installed and getting an odd
error. Hoping someone has some ideas...

The command I am running is:

disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm

Everything goes smoothly until trying to write the MBR, at which point I
get the following error:

+ /usr/sbin/grub-install '--modules=biosdisk part_msdos'
--target=i386-pc /dev/loop0
Installing for i386-pc platform.
/usr/sbin/grub-install: warning: this msdos-style partition label has no
post-MBR gap; embedding won't be possible.
/usr/sbin/grub-install: error: embedding is not possible, but this is
required for cross-disk install.
/dev/loop0: [0047]:3 (/tmp/image.hk8wiFJe/image.raw)

Anybody got any ideas?

Thanks in advance!
-jay


Hey Jay,

I just tried to reproduce this on my 14.04 box and wasn't able to so I
am betting there's some kind of new bug with us on 16.04. Do you get the
same error if you run without --image-size=10? Last time we had an issue
like this a new grub version changed the default behavior, so I'd
suspect something along those lines.

I am trying out a new run on a 16.04 box but its going to be a bit
before the cloud image downloads (cloud-image.ubuntu.com is pretty
slow)...


Thanks, Greg! Yeah, I guessed it might be something to do with the 
target image size maybe being too small or something, so I retried 
without the --image-size and got the same result. So, must be something 
different...


Best,
-jay

__
OpenStack Development Mailing 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] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Jay Pipes]

On 06/20/2016 06:12 PM, Clint Byrum wrote:

Excerpts from Jay Pipes's message of 2016-06-20 16:52:38 -0400:

Hi dib-gurus,

I'm trying to build a simple ubuntu VM image on a local Gigabyte BRIX
with a AMD A8-5557M APU with Ubuntu 16.04 installed and getting an odd
error. Hoping someone has some ideas...

The command I am running is:

disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm

Everything goes smoothly until trying to write the MBR, at which point I
get the following error:

+ /usr/sbin/grub-install '--modules=biosdisk part_msdos'
--target=i386-pc /dev/loop0
Installing for i386-pc platform.
/usr/sbin/grub-install: warning: this msdos-style partition label has no
post-MBR gap; embedding won't be possible.
/usr/sbin/grub-install: error: embedding is not possible, but this is
required for cross-disk install.
/dev/loop0: [0047]:3 (/tmp/image.hk8wiFJe/image.raw)


I think you found a bug. The ARCH should be armhf, but
elements/bootloader/finalise.d/50-bootloader doesn't know what to do with
armhf, so it falls back to x86_64/amd64. Also, grub-pc is the package
that bootloader claims to need in its pkg-map file, but you really need
grub-efi-arm on arm boxes.

We may need to add the ability for pkg-map's to differentiate based on
ARCH.

If you intended to build an amd64 image, you need to set ARCH=amd64
before running disk-image-create, so it won't detect it by running
'dpkg --print-architecture'.


AMD A8 APU is actually amd64, AFAIK, Clint :) `dpkg 
--print-architecture` correctly returns 'amd64'.


Best,
-jay



__
OpenStack Development Mailing 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] Version header for OpenStack microversion support

[D'Angelo, Scott]

FYI, Cinder implemented using the style recommended by the API-wg:

https://review.openstack.org/#/c/224910


From: Sean Dague 
Sent: Monday, June 20, 2016 6:32:10 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Version header for OpenStack microversion support

On 06/18/2016 06:32 AM, Jamie Lennox wrote:
> Quick question: why do we need the service type or name in there? You
> really should know what API you're talking to already and it's just
> something that makes it more difficult to handle all the different APIs
> in a common way.

It is also extremely useful in wire interactions to be explicit so that
you know for sure you are interacting with the thing you think you are.
There was also the potential question of compound API operations (a Nova
call that calls other microversioned services that may impact
representation) and whether that may need to be surfaced to the user.
For instance network portions of the 'servers' object may get impacted
by Neutron.

With all those possibilities, putting in the extra ~8 bytes to handle
contingencies seemed prudent.

-Sean

--
Sean Dague
http://dague.net

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

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

Re: [openstack-dev] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Gregory Haynes]

On Mon, Jun 20, 2016, at 03:52 PM, Jay Pipes wrote:
> Hi dib-gurus,
> 
> I'm trying to build a simple ubuntu VM image on a local Gigabyte BRIX 
> with a AMD A8-5557M APU with Ubuntu 16.04 installed and getting an odd 
> error. Hoping someone has some ideas...
> 
> The command I am running is:
> 
> disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm
> 
> Everything goes smoothly until trying to write the MBR, at which point I 
> get the following error:
> 
> + /usr/sbin/grub-install '--modules=biosdisk part_msdos' 
> --target=i386-pc /dev/loop0
> Installing for i386-pc platform.
> /usr/sbin/grub-install: warning: this msdos-style partition label has no 
> post-MBR gap; embedding won't be possible.
> /usr/sbin/grub-install: error: embedding is not possible, but this is 
> required for cross-disk install.
> /dev/loop0: [0047]:3 (/tmp/image.hk8wiFJe/image.raw)
> 
> Anybody got any ideas?
> 
> Thanks in advance!
> -jay

Hey Jay,

I just tried to reproduce this on my 14.04 box and wasn't able to so I
am betting there's some kind of new bug with us on 16.04. Do you get the
same error if you run without --image-size=10? Last time we had an issue
like this a new grub version changed the default behavior, so I'd
suspect something along those lines.

I am trying out a new run on a 16.04 box but its going to be a bit
before the cloud image downloads (cloud-image.ubuntu.com is pretty
slow)...

Cheers,
Greg

__
OpenStack Development Mailing 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] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Clint Byrum]

Excerpts from Jay Pipes's message of 2016-06-20 16:52:38 -0400:
> Hi dib-gurus,
> 
> I'm trying to build a simple ubuntu VM image on a local Gigabyte BRIX 
> with a AMD A8-5557M APU with Ubuntu 16.04 installed and getting an odd 
> error. Hoping someone has some ideas...
> 
> The command I am running is:
> 
> disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm
> 
> Everything goes smoothly until trying to write the MBR, at which point I 
> get the following error:
> 
> + /usr/sbin/grub-install '--modules=biosdisk part_msdos' 
> --target=i386-pc /dev/loop0
> Installing for i386-pc platform.
> /usr/sbin/grub-install: warning: this msdos-style partition label has no 
> post-MBR gap; embedding won't be possible.
> /usr/sbin/grub-install: error: embedding is not possible, but this is 
> required for cross-disk install.
> /dev/loop0: [0047]:3 (/tmp/image.hk8wiFJe/image.raw)

I think you found a bug. The ARCH should be armhf, but
elements/bootloader/finalise.d/50-bootloader doesn't know what to do with
armhf, so it falls back to x86_64/amd64. Also, grub-pc is the package
that bootloader claims to need in its pkg-map file, but you really need
grub-efi-arm on arm boxes.

We may need to add the ability for pkg-map's to differentiate based on
ARCH.

If you intended to build an amd64 image, you need to set ARCH=amd64
before running disk-image-create, so it won't detect it by running
'dpkg --print-architecture'.

__
OpenStack Development Mailing 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] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Jay Pipes]

Hi dib-gurus,

I'm trying to build a simple ubuntu VM image on a local Gigabyte BRIX 
with a AMD A8-5557M APU with Ubuntu 16.04 installed and getting an odd 
error. Hoping someone has some ideas...


The command I am running is:

disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm

Everything goes smoothly until trying to write the MBR, at which point I 
get the following error:


+ /usr/sbin/grub-install '--modules=biosdisk part_msdos' 
--target=i386-pc /dev/loop0

Installing for i386-pc platform.
/usr/sbin/grub-install: warning: this msdos-style partition label has no 
post-MBR gap; embedding won't be possible.
/usr/sbin/grub-install: error: embedding is not possible, but this is 
required for cross-disk install.

/dev/loop0: [0047]:3 (/tmp/image.hk8wiFJe/image.raw)

Anybody got any ideas?

Thanks in advance!
-jay

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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Fox, Kevin M]

Some other topics:

* Rolling upgrades - For example, I haven't figured out a way to safely drain 
an rpc based service rather then just shooting it and hoping things go well... 
Is it safe? This safety code should be built into them all consistently.

 * How to get events to users in a usable way. OpenStack Service X event -> 
Some system that duplicates the event stream based on requests from users -> 
Multiple Zaqar Queues? -> User? Can this co-exist with Horizon using it for 
updating its UI without polling?

 * The state of guest agents is abysmal. Each service uses a different way to 
talk between controller and vm, and each has its own problems and operators 
need to figure out workarounds for all. Its really painful. We need something 
like a unified guest agent that gets the logic right, and is plugable.

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Monday, June 20, 2016 11:31 AM
To: openstack-dev
Subject: Re: [openstack-dev] [all] Proposal: Architecture Working Group

Excerpts from Joshua Harlow's message of 2016-06-17 15:33:25 -0700:
> Thanks for getting this started Clint,
>
> I'm happy and excited to be involved in helping try to guide the whole
> ecosystem together (it's also why I like being in oslo) to a
> architecture that is more cohesive (and is more of something that we can
> say to our current or future children that we were all involved and
> proud to be involved in creating/maturing...).
>
> At a start, for said first meeting, any kind of agenda come to mind, or
> will it be more a informal gathering to start (either is fine with me)?
>

I've been hesitant to fill this in too much as I'm still forming the
idea, but here are the items I think are most compelling to begin with:

* DLM's across OpenStack -- This is already under way[1], but it seems to
  have fizzled out. IMO that is because there's no working group who
  owns it. We need to actually write some plans.

* Messaging patterns -- There was a recent discussion about nuances in
  oslo.messaging's implementation that vary driver to driver. I'd like to
  make sure we have all of the ways messaging is used written down and
  make sure groups have guidance on how each one should (or shouldn't)
  be used, including documentation of anti-patterns, and a plan for
  simplifying communication between processes in OpenStack where
  possible.

* True Microservices -- OpenStack's services are heavily
  interdependent. It makes it hard for an engineer to make an impact
  without becoming an expert on all of them, and it also leads to a heavy
  burden on operators and QA as they end up having to debug the system
  as a whole. We should write down how the system is intertwined now, and
  develop plans for unwinding that and allowing each service to stand on
  its own, including having stronger testing in isolation. (This includes
  exploring the thought that nova-compute could become its own project
  that all of the other things communicate with over well defined APIs).

These could keep a small group of architects and engineers busy for a
year or more. I'm sure others have things they'd like to design and
improve in OpenStack at this level.

Once we have broad agreement on such a group, and perhaps some guidance
from the TC, we can propose an agenda and prioritize efforts as part of
the first few meetings.

[1] 
http://specs.openstack.org/openstack/openstack-specs/specs/chronicles-of-a-dlm.html
> -Josh
>
> Clint Byrum wrote:
> > ar·chi·tec·ture
> > ˈärkəˌtek(t)SHər/
> > noun
> > noun: architecture
> >
> >  1.
> >
> >  the art or practice of designing and constructing buildings.
> >
> >  synonyms:building design, building style, planning, building, 
> > construction;
> >
> >  formalarchitectonics
> >
> >  "modern architecture"
> >
> >  the style in which a building is designed or constructed, especially 
> > with regard to a specific period, place, or culture.
> >
> >  plural noun: architectures
> >
> >  "Victorian architecture"
> >
> >  2.
> >
> >  the complex or carefully designed structure of something.
> >
> >  "the chemical architecture of the human brain"
> >
> >  the conceptual structure and logical organization of a computer or 
> > computer-based system.
> >
> >  "a client/server architecture"
> >
> >  synonyms:structure, construction, organization, layout, design, build, 
> > anatomy, makeup;
> >
> >  informalsetup
> >
> >  "the architecture of a computer system"
> >
> >
> > Introduction
> > =
> >
> > OpenStack is a big system. We have debated what it actually is [1],
> > and there are even t-shirts to poke fun at the fact that we don't have
> > good answers.
> >
> > But this isn't what any of us wants. We'd like to be able to point
> > at something and proudly tell people "This is what we designed and
> > implemented."
> >
> > And for each individual project, that is a possibility. Neutron can
> > tell 

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Fox, Kevin M]

+1

From: Clint Byrum [cl...@fewbar.com]
Sent: Monday, June 20, 2016 10:27 AM
To: openstack-dev
Subject: Re: [openstack-dev] [all] Proposal: Architecture Working Group

Excerpts from Doug Wiegley's message of 2016-06-20 10:40:56 -0600:
> So, it sounds like you’ve just described the job of the TC. And they have so 
> far refused to define OpenStack, leading to a series of derivative decisions 
> that seem … inconsistent over time.
>
> How is this body going to be different?
>
> How will it have any teeth, and not just end up with the standard entrenched 
> projects ignoring it?
>

Hi Doug, thanks for your candid reply. I understand that there is a
concern and I want to address it. However, I feel like answering this
directly will start this working group out on the wrong foot.

We shouldn't need teeth. This isn't an adversarial working group that
will be challenging engineers any more than an architect of a building
challenges the builders while they work. An architect that ignores their
engineers is not going to complete many projects. Of course, engineers
may disagree on the cost of an architectural decision. But to disagree,
first we need to actually _make_ a decision on a design.

The goal of this group would be to provide a detailed architecture and
plans for the way the system should work and fit together as a whole. Like
any complex system, during implementation, things that architects weren't
aware of come to light. Something that seems simple turns out to be
complex. Something that seemed absolutely necessary can be factored out.

Nobody is suggesting designing OpenStack from the ground up, just that
where there isn't an agreed upon design, let's write down how the system
works now, and then make a design and a plan to actually improve it.

Engineers have no effective place to turn to right now when there is
a lack of design. The TC could of course do it, but what I want to do
is have a more open and free-flowing group that are laser focused on
providing support for the design of the system. I want to work out with
the community at large how we add weight to the designs we choose, and
one good option is for the Architecture Working Group to make proposals
to the openstack-specs repo, which the TC would ultimately approve.
That's not a new process, we already have it:

http://docs.openstack.org/project-team-guide/cross-project.html

I'm just suggesting a group that actually _focuses_ on the design
aspects of that process.

Without this, we are designing in real time and taking the shortest path
to achieve short term goals. This has positive and negative effects. I
think we've reached a point in OpenStack's evolution where the positive
effects of that are mostly realized, and now we should work to pay
down some of the negative effects by adopting some designs and beginning
refactoring of the system. It's not a fast process, so the longer we wait,
the longer we pay interest on that debt.

__
OpenStack Development Mailing 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] [Magnum] Midcycle location and date

[Hongbin Lu]

Hi all,

This is a reminder that there are doodle pools for midcycle participants to 
select the location and time:

Location: http://doodle.com/poll/2x9utspir7vk8ter
Date: http://doodle.com/poll/5tbcyc37yb7ckiec

If you are able to attend the midcycle, I encourage you to vote for your 
preferred location and date. We will try to finalize everything in the team 
meeting tomorrow.

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

Re: [openstack-dev] [TripleO] Consolidating TripleO validations with Browbeat validations

[Assaf Muller]

On Mon, Jun 20, 2016 at 12:43 PM, Joe Talerico  wrote:
> On Mon, Jun 20, 2016 at 12:41 PM, Ihar Hrachyshka  wrote:
>>
>>> On 20 Jun 2016, at 18:37, Joe Talerico  wrote:
>>>
>>> Hello - It would seem there is a little bit of overlap with TripleO
>>> validations ( clapper validations ) and Browbeat *Checks*. I would
>>> like to see these two come together, and I wanted to get some feedback
>>> on this.
>>>
>>> For reference here are the Browbeat checks :
>>> https://github.com/openstack/browbeat/tree/master/ansible/check
>>>
>>> We check for common deployment mistakes, possible deployment
>>> performance issues and some bugs that could impact the scale and
>>> performance of your cloud... At the end we build a report of found
>>> issues with the cloud, like :
>>> https://github.com/openstack/browbeat/blob/master/ansible/check/browbeat-example-bug_report.log
>>>
>>> We eventually wanted to take these findings and push them to
>>> ElasticSearch as metadata for our result data (just so we would be
>>> aware of any BZs or possibly missed tuning).
>>>
>>> Anyhoo, I just would like to get feedback on consolidating these
>>> checks into TripleO Validations if that makes sense. If this does make
>>> sense, who could I work with to see that this happens?
>>
>> Sorry for hijacking the thread somewhat, but it seems that 
>> neutron-sanity-check would cover for some common deployment issues, if 
>> utilized by projects like browbeat. Has anyone considered the tool?
>>
>> http://docs.openstack.org/cli-reference/neutron-sanity-check.html
>>
>> If there are projects that are interested in integrating checks that are 
>> implemented by neutron community, we would be glad to give some guidance.
>>
>> Ihar
>
> Hey Ihar - the TripleO validations are using this :
> https://github.com/rthallisey/clapper/blob/0881300a815f8b801a38d117b8d01b42a00c7f7b/ansible-tests/validations/neutron-sanity-check.yaml

Oops, that's missing a bunch of configuration files. Here's the
configuration values it expects:
https://github.com/openstack/neutron/blob/master/neutron/cmd/sanity_check.py#L32

And here's how the tool uses them:
https://github.com/openstack/neutron/blob/master/neutron/cmd/sanity_check.py#L272

It runs specific checks according to configuration file values. Is
ipset enabled in the OVS agent configuration file? Great, let's check
we can use it and report back if there's any errors.

>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing 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] Proposal: Architecture Working Group

[Clint Byrum]

Excerpts from Joshua Harlow's message of 2016-06-17 15:33:25 -0700:
> Thanks for getting this started Clint,
> 
> I'm happy and excited to be involved in helping try to guide the whole 
> ecosystem together (it's also why I like being in oslo) to a 
> architecture that is more cohesive (and is more of something that we can 
> say to our current or future children that we were all involved and 
> proud to be involved in creating/maturing...).
> 
> At a start, for said first meeting, any kind of agenda come to mind, or 
> will it be more a informal gathering to start (either is fine with me)?
> 

I've been hesitant to fill this in too much as I'm still forming the
idea, but here are the items I think are most compelling to begin with:

* DLM's across OpenStack -- This is already under way[1], but it seems to
  have fizzled out. IMO that is because there's no working group who
  owns it. We need to actually write some plans.

* Messaging patterns -- There was a recent discussion about nuances in
  oslo.messaging's implementation that vary driver to driver. I'd like to
  make sure we have all of the ways messaging is used written down and
  make sure groups have guidance on how each one should (or shouldn't)
  be used, including documentation of anti-patterns, and a plan for
  simplifying communication between processes in OpenStack where
  possible.

* True Microservices -- OpenStack's services are heavily
  interdependent. It makes it hard for an engineer to make an impact
  without becoming an expert on all of them, and it also leads to a heavy
  burden on operators and QA as they end up having to debug the system
  as a whole. We should write down how the system is intertwined now, and
  develop plans for unwinding that and allowing each service to stand on
  its own, including having stronger testing in isolation. (This includes
  exploring the thought that nova-compute could become its own project
  that all of the other things communicate with over well defined APIs).

These could keep a small group of architects and engineers busy for a
year or more. I'm sure others have things they'd like to design and
improve in OpenStack at this level.

Once we have broad agreement on such a group, and perhaps some guidance
from the TC, we can propose an agenda and prioritize efforts as part of
the first few meetings.

[1] 
http://specs.openstack.org/openstack/openstack-specs/specs/chronicles-of-a-dlm.html
> -Josh
> 
> Clint Byrum wrote:
> > ar·chi·tec·ture
> > ˈärkəˌtek(t)SHər/
> > noun
> > noun: architecture
> >
> >  1.
> >
> >  the art or practice of designing and constructing buildings.
> >
> >  synonyms:building design, building style, planning, building, 
> > construction;
> >
> >  formalarchitectonics
> >
> >  "modern architecture"
> >
> >  the style in which a building is designed or constructed, especially 
> > with regard to a specific period, place, or culture.
> >
> >  plural noun: architectures
> >
> >  "Victorian architecture"
> >
> >  2.
> >
> >  the complex or carefully designed structure of something.
> >
> >  "the chemical architecture of the human brain"
> >
> >  the conceptual structure and logical organization of a computer or 
> > computer-based system.
> >
> >  "a client/server architecture"
> >
> >  synonyms:structure, construction, organization, layout, design, build, 
> > anatomy, makeup;
> >
> >  informalsetup
> >
> >  "the architecture of a computer system"
> >
> >
> > Introduction
> > =
> >
> > OpenStack is a big system. We have debated what it actually is [1],
> > and there are even t-shirts to poke fun at the fact that we don't have
> > good answers.
> >
> > But this isn't what any of us wants. We'd like to be able to point
> > at something and proudly tell people "This is what we designed and
> > implemented."
> >
> > And for each individual project, that is a possibility. Neutron can
> > tell you they designed how their agents and drivers work. Nova can
> > tell you that they designed the way conductors handle communication
> > with API nodes and compute nodes. But when we start talking about how
> > they interact with each other, it's clearly just a coincidental mash of
> > de-facto standards and specs that don't help anyone make decisions when
> > refactoring or adding on to the system.
> >
> > Oslo and cross-project initiatives have brought some peace and order
> > to the implementation and engineering processes, but not to the design
> > process. New ideas still start largely in the project where they are
> > needed most, and often conflict with similar decisions and ideas in other
> > projects [dlm, taskflow, tooz, service discovery, state machines, glance
> > tasks, messaging patterns, database patterns, etc. etc.]. Often times this
> > creates a log jam where none of the projects adopt a solution that would
> > align with others. Most of the time when things finally come to a head
> > these things get 

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Clint Byrum]

Excerpts from Jesse Cook's message of 2016-06-20 16:58:48 +:
> +1
> 
> The points about the PWG and TC are worth some consideration.
> 
> From my perspective, I think it would make sense for the PWG to define the
> expected behaviors of the system, which would be an input to the
> architecture group. The architecture group would define both prescriptive
> (where we'd like to be) and descriptive (where we actually are...roughly)
> architectures. This would provide both the vision for the future state and
> understanding of current state that is necessary for us to all swim in the
> same general direction instead of constantly running into each other. I
> don't see the architecture as something you push down, but rather something
> that helps each contributor ask, "Does that get us closer to where we are
> trying to go?" I absolutely think this is something that would provide a
> huge benefit to the organization.
> 

That sounds about right Jesse. Thanks for bringing up the PWG. I
definitely don't think an Architecture WG would want to answer "what
is OpenStack" alone. More like "What should the OpenStack we described
actually look like?".

__
OpenStack Development Mailing 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] [api] [placement] strategy for placement api structure

[Jay Pipes]

On 06/20/2016 12:47 PM, Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2016-06-20 10:04:06 -0400:

On 06/17/2016 11:23 AM, Sylvain Bauza wrote:

+1000 yes to that. Now the devil could be in the details, in particular
how we implement the WSGI server, the corresponding WSGI app and the
associated routing, and that's exactly the problem below.


We shouldn't be implementing a WSGI server *at all*. The fact that one
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, uwsgi,
etc) is a bad thing.


I certainly understand the concerns of adding yet another library. To be
honest, I tend to even agree with the statement that we could possibly
use Routes without explicitly use nova.wsgi, right ?

In the review, you explain why you don't trust Routes and I respect
that. That said, are those issues logged as real problems for our API
consumers, which are mostly client libraries that we own and other
projects we know, like Horizon ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken
in a framework-less implementation with nothing other than the (tiny)
selector library as a dependency. I'd like to see the work move forward.

Best,
-jay



It seems like choosing to avoid an existing framework is just going
to eventually result in another new framework evolving organically
as things like common aspects like error handling and transactions
are refactored out of of individual handlers.


WSGI frameworks shouldn't be handling transactions, IMHO. That's a ba d 
coupling problem.


And no, I don't believe this will result in a new framework being 
created, precisely for the reason that no such framework is needed...



Is it really so bad to just pick a tool already being used in some
portion of the rest of the community?


As I said, I'm OK with using Routes since it's already in g-r, but I 
just don't see a need for a WSGI framework, especially one that includes 
things like a WSGI server.


Best,
-jay

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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Clint Byrum]

Excerpts from Michael Krotscheck's message of 2016-06-20 15:26:20 +:
> I like the idea in principle, but am bullish on the implementation.
> 

As you should be, and we all must be. It's not going to happen if we
just dream it. That's kind of the point. Let's write down a design _for
the group that writes down designs_.

> For example: we have the API-WG which fulfills part of an Architectural
> mission, as well as the Cross-Project WG which fulfills a different part.
> Yet there's no incentive, carrot or stick, that drives adoption of the
> approved specs, other than "Well if you want to do the work, have fun". In
> several cases, I've run into the excuses of "That's Hard/That breaks
> backwards compatibility/That's not profitable/I'm not paid to do that".
> 

If we write a bunch of specs which are too much of a burden to implement,
we're doing it wrong. The idea isn't to rip everything out.  It's to
acknowledge where there is a complete lack of design, write one that
is practical, and organize work to get it done.

> What's going to prevent [Insert Project Here] from coming along and saying
> "Oh, well, we don't like those decisions, so are going to ignore them."
> What provides the incentive for a project to adopt these recommendations?
> 

Absolutely nothing will prevent that, and I don't think putting any kind
of hard requirements for following this group's designs would be
productive until it has proven that it can actually improve OpenStack.
Perhaps if we do succeed in designing parts of the system, and some
teams find that useful, we can look at adding some of the parts of the
design to our more stringent requirements (like "use python or C"). But
that's not something I'd seek from day 1. That's just a recipe for
revolt.

__
OpenStack Development Mailing 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] IRC meeting for VLAN-aware VM's

[Tidwell, Ryan]

At one point early during the Mitaka cycle we had a weekly IRC meeting on this 
topic going.  I got side-tracked by other work at the time and I stopped 
attending, so my apologies if these are still happening.  I'm wondering if it 
would be useful to get these going again if this is not currently happening.  
Thoughts?

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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Clint Byrum]

Excerpts from Doug Wiegley's message of 2016-06-20 10:40:56 -0600:
> So, it sounds like you’ve just described the job of the TC. And they have so 
> far refused to define OpenStack, leading to a series of derivative decisions 
> that seem … inconsistent over time.
> 
> How is this body going to be different?
> 
> How will it have any teeth, and not just end up with the standard entrenched 
> projects ignoring it?
> 

Hi Doug, thanks for your candid reply. I understand that there is a
concern and I want to address it. However, I feel like answering this
directly will start this working group out on the wrong foot.

We shouldn't need teeth. This isn't an adversarial working group that
will be challenging engineers any more than an architect of a building
challenges the builders while they work. An architect that ignores their
engineers is not going to complete many projects. Of course, engineers
may disagree on the cost of an architectural decision. But to disagree,
first we need to actually _make_ a decision on a design.

The goal of this group would be to provide a detailed architecture and
plans for the way the system should work and fit together as a whole. Like
any complex system, during implementation, things that architects weren't
aware of come to light. Something that seems simple turns out to be
complex. Something that seemed absolutely necessary can be factored out.

Nobody is suggesting designing OpenStack from the ground up, just that
where there isn't an agreed upon design, let's write down how the system
works now, and then make a design and a plan to actually improve it.

Engineers have no effective place to turn to right now when there is
a lack of design. The TC could of course do it, but what I want to do
is have a more open and free-flowing group that are laser focused on
providing support for the design of the system. I want to work out with
the community at large how we add weight to the designs we choose, and
one good option is for the Architecture Working Group to make proposals
to the openstack-specs repo, which the TC would ultimately approve.
That's not a new process, we already have it:

http://docs.openstack.org/project-team-guide/cross-project.html

I'm just suggesting a group that actually _focuses_ on the design
aspects of that process.

Without this, we are designing in real time and taking the shortest path
to achieve short term goals. This has positive and negative effects. I
think we've reached a point in OpenStack's evolution where the positive
effects of that are mostly realized, and now we should work to pay
down some of the negative effects by adopting some designs and beginning
refactoring of the system. It's not a fast process, so the longer we wait,
the longer we pay interest on that debt.

__
OpenStack Development Mailing 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] Initial oslo.privsep conversion?

[Maxim Nestratov]

17.06.2016 17:13, Matt Riedemann пишет:


On 6/9/2016 6:51 PM, Tony Breeds wrote:

On Fri, Jun 10, 2016 at 08:24:34AM +1000, Michael Still wrote:

On Fri, Jun 10, 2016 at 7:18 AM, Tony Breeds 
wrote:


On Wed, Jun 08, 2016 at 08:10:47PM -0500, Matt Riedemann wrote:


Agreed, but it's the worked example part that we don't have yet,
chicken/egg. So we can drop the hammer on all new things until 
someone

does

it, which sucks, or hope that someone volunteers to work the first

example.

I'll work with gus to find a good example in nova and have patches up
before
the mid-cycle.  We can discuss next steps then.



Sorry to be a pain, but I'd really like that example to be 
non-trivial if
possible. One of the advantages of privsep is that we can push the 
logic
down closer to the privileged code, instead of just doing something 
"close"

and then parsing. I think reinforcing that idea in the sample code is
important.


I think *any* change will show that.  I wanted to pick something 
achievable in

the short timeframe.

The example I'm thinking of is nova/virt/libvirt/utils.py:update_mtime()

 * It will provide a lot of the boiler plate
 * Show that we can now now replace an exec with pure python code.
 * Show how you need to retrieve data from a trusted source on the 
priviledged

   side
 * Migrate testing
 * Remove an entry from compute.filters

Once that's implace chown() in the same file is probably a quick fix.

Is it super helpful? does it have a measurable impact on performance, 
security?

The answer is probably "no"

I still think it has value.

Handling qemu-img is probably best done by creating os-qemu (or 
similar) and
designing from the ground up with provsep in mind.  Glance and Cinder 
would

benefit from that also.  That howveer is waaay to big for this cycle.

Yours Tony.



__ 


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

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



So I know we didn't want to block the virtuozzo resize patch for 
oslo.privsep conversion, but there is another vz package for their 
libvirt volume driver that's adding a new rootwrap filter:


https://review.openstack.org/#/c/190843/

We definitely don't want that one using rootwrap filters because it's 
going to couple os-brick / cinder / nova during upgrades, which is the 
reason we wanted to get oslo.privsep support into os-brick in the 
first place.


So I think we're going to have to convert that one to use 
oslo.privsep. I might be mistaken though.


Given where this is, however, it's going to run into the issue we have 
with sorting out upgrades from mitaka (see Sean's thread) so that nova 
can register the root helper early with oslo.privsep when nova-compute 
starts up.




Looks like we don't need a new rootwrap filter for the mentioned patch. 
It isn't necessary with upstream os-brick, so we can easily remove it 
from the change.


Maxim

__
OpenStack Development Mailing 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] [mistral] Team meeting minutes - 06/20/2016

[Renat Akhmerov]

Thanks for joining our meeting today!

In case you didn’t attend here are the meeting minutes and log:
http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-06-20-16.01.html
 

http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-06-20-16.01.log.html
 


See you next time on June 27th.

Renat Akhmerov
@Nokia

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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Jesse Cook]

+1

The points about the PWG and TC are worth some consideration.

>From my perspective, I think it would make sense for the PWG to define the
expected behaviors of the system, which would be an input to the
architecture group. The architecture group would define both prescriptive
(where we'd like to be) and descriptive (where we actually are...roughly)
architectures. This would provide both the vision for the future state and
understanding of current state that is necessary for us to all swim in the
same general direction instead of constantly running into each other. I
don't see the architecture as something you push down, but rather something
that helps each contributor ask, "Does that get us closer to where we are
trying to go?" I absolutely think this is something that would provide a
huge benefit to the organization.

On Mon, Jun 20, 2016 at 4:40 PM, Doug Wiegley 
wrote:

> So, it sounds like you’ve just described the job of the TC. And they have
> so far refused to define OpenStack, leading to a series of derivative
> decisions that seem … inconsistent over time.
>
> How is this body going to be different?
>
> How will it have any teeth, and not just end up with the standard
> entrenched projects ignoring it?
>
> Thanks,
> doug
>
>
> > On Jun 17, 2016, at 3:52 PM, Clint Byrum  wrote:
> >
> > ar·chi·tec·ture
> > ˈärkəˌtek(t)SHər/
> > noun
> > noun: architecture
> >
> >1.
> >
> >the art or practice of designing and constructing buildings.
> >
> >synonyms:building design, building style, planning, building,
> construction;
> >
> >formalarchitectonics
> >
> >"modern architecture"
> >
> >the style in which a building is designed or constructed, especially
> with regard to a specific period, place, or culture.
> >
> >plural noun: architectures
> >
> >"Victorian architecture"
> >
> >2.
> >
> >the complex or carefully designed structure of something.
> >
> >"the chemical architecture of the human brain"
> >
> >the conceptual structure and logical organization of a computer or
> computer-based system.
> >
> >"a client/server architecture"
> >
> >synonyms:structure, construction, organization, layout, design,
> build, anatomy, makeup;
> >
> >informalsetup
> >
> >"the architecture of a computer system"
> >
> >
> > Introduction
> > =
> >
> > OpenStack is a big system. We have debated what it actually is [1],
> > and there are even t-shirts to poke fun at the fact that we don't have
> > good answers.
> >
> > But this isn't what any of us wants. We'd like to be able to point
> > at something and proudly tell people "This is what we designed and
> > implemented."
> >
> > And for each individual project, that is a possibility. Neutron can
> > tell you they designed how their agents and drivers work. Nova can
> > tell you that they designed the way conductors handle communication
> > with API nodes and compute nodes. But when we start talking about how
> > they interact with each other, it's clearly just a coincidental mash of
> > de-facto standards and specs that don't help anyone make decisions when
> > refactoring or adding on to the system.
> >
> > Oslo and cross-project initiatives have brought some peace and order
> > to the implementation and engineering processes, but not to the design
> > process. New ideas still start largely in the project where they are
> > needed most, and often conflict with similar decisions and ideas in other
> > projects [dlm, taskflow, tooz, service discovery, state machines, glance
> > tasks, messaging patterns, database patterns, etc. etc.]. Often times
> this
> > creates a log jam where none of the projects adopt a solution that would
> > align with others. Most of the time when things finally come to a head
> > these things get done in a piecemeal fashion, where it's half done here,
> > 1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
> > looks like  chaos, because that's precisely what it is.
> >
> > And this isn't always a technical design problem. OpenStack, for
> instance,
> > isn't really a micro service architecture. Of course, it might look like
> > that in diagrams [2], but we all know it really isn't. The compute node
> is
> > home to agents for every single concern, and the API interactions between
> > the services is too tightly woven to consider many of them functional
> > without the same lockstep version of other services together. A game to
> > play is ask yourself what would happen if a service was isolated on its
> > own island, how functional would its API be, if at all. Is this something
> > that we want? No. But there doesn't seem to be a place where we can go
> > to actually design, discuss, debate, and ratify changes that would help
> > us get to the point of gathering the necessary will and capability to
> > enact these efforts.
> >
> > Maybe nova-compute should be isolated from nova, with an API that
> > nova, 

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Jeremy Stanley]

On 2016-06-20 18:43:44 +0200 (+0200), Zane Bitter wrote:
> The binaries are free-as-in-beer - IIUC you can't redistribute them. The
> source code, of course, remains free-as-in-speech as it has always been.
> (It's easy to forget the distinction when you work in Python all day and
> there are no binaries, but it's the source code that counts.) And of course
> there are freely-distributable binaries built from that source available in
> the form of CentOS.
[...]

Not to go too far down this rabbit hole, but as a
long-time-away-from-Red-Hat user my (possibly quite outdated)
experience was that RHEL included some non-free/proprietary software
distributed alongside other free-as-in-speech software. If this is
still true, it would be a significant mischaracterization to claim
that the "source code" for RHEL as a whole is consistently free. If
_all_ software provided by RHEL is also now included under free and
open licenses, then I'm thrilled and may be more inclined to give it
a try again in the future.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

[Doug Hellmann]

Excerpts from Jay Pipes's message of 2016-06-20 10:04:06 -0400:
> On 06/17/2016 11:23 AM, Sylvain Bauza wrote:
> > +1000 yes to that. Now the devil could be in the details, in particular
> > how we implement the WSGI server, the corresponding WSGI app and the
> > associated routing, and that's exactly the problem below.
> 
> We shouldn't be implementing a WSGI server *at all*. The fact that one 
> cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, uwsgi, 
> etc) is a bad thing.
> 
> > I certainly understand the concerns of adding yet another library. To be
> > honest, I tend to even agree with the statement that we could possibly
> > use Routes without explicitly use nova.wsgi, right ?
> >
> > In the review, you explain why you don't trust Routes and I respect
> > that. That said, are those issues logged as real problems for our API
> > consumers, which are mostly client libraries that we own and other
> > projects we know, like Horizon ?
> >
> > If that is a problem for those, is there something we could improve,
> > instead of just getting rid of it ?
> 
> For the record, I'm very much in favor of the approach Chris has taken 
> in a framework-less implementation with nothing other than the (tiny) 
> selector library as a dependency. I'd like to see the work move forward.
> 
> Best,
> -jay
> 

It seems like choosing to avoid an existing framework is just going
to eventually result in another new framework evolving organically
as things like common aspects like error handling and transactions
are refactored out of of individual handlers.

Is it really so bad to just pick a tool already being used in some
portion of the rest of the community?

Doug

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

Re: [openstack-dev] [TripleO] Consolidating TripleO validations with Browbeat validations

[Joe Talerico]

On Mon, Jun 20, 2016 at 12:41 PM, Ihar Hrachyshka  wrote:
>
>> On 20 Jun 2016, at 18:37, Joe Talerico  wrote:
>>
>> Hello - It would seem there is a little bit of overlap with TripleO
>> validations ( clapper validations ) and Browbeat *Checks*. I would
>> like to see these two come together, and I wanted to get some feedback
>> on this.
>>
>> For reference here are the Browbeat checks :
>> https://github.com/openstack/browbeat/tree/master/ansible/check
>>
>> We check for common deployment mistakes, possible deployment
>> performance issues and some bugs that could impact the scale and
>> performance of your cloud... At the end we build a report of found
>> issues with the cloud, like :
>> https://github.com/openstack/browbeat/blob/master/ansible/check/browbeat-example-bug_report.log
>>
>> We eventually wanted to take these findings and push them to
>> ElasticSearch as metadata for our result data (just so we would be
>> aware of any BZs or possibly missed tuning).
>>
>> Anyhoo, I just would like to get feedback on consolidating these
>> checks into TripleO Validations if that makes sense. If this does make
>> sense, who could I work with to see that this happens?
>
> Sorry for hijacking the thread somewhat, but it seems that 
> neutron-sanity-check would cover for some common deployment issues, if 
> utilized by projects like browbeat. Has anyone considered the tool?
>
> http://docs.openstack.org/cli-reference/neutron-sanity-check.html
>
> If there are projects that are interested in integrating checks that are 
> implemented by neutron community, we would be glad to give some guidance.
>
> Ihar

Hey Ihar - the TripleO validations are using this :
https://github.com/rthallisey/clapper/blob/0881300a815f8b801a38d117b8d01b42a00c7f7b/ansible-tests/validations/neutron-sanity-check.yaml

> __
> OpenStack Development Mailing 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][tc] Require a level playing field for OpenStack projects

[Zane Bitter]

On 16/06/16 23:04, Jeremy Stanley wrote:

On 2016-06-16 16:04:28 -0400 (-0400), Steve Gordon wrote:
[...]

This is definitely a point worth clarifying in the general case,
but tangentially for the specific case of the RHEL operating
system please note that RHEL is available to developers for free:

 http://developers.redhat.com/products/rhel/get-started/
 http://developers.redhat.com/articles/no-cost-rhel-faq/

This is a *relatively* recent advancement so I though I would
mention it as folks may not be aware.


Just to clarify, this is free-as-in-beer (gratis) and not
free-as-in-speech (libre)? If so, that's still proprietary so I'm
curious how that changes the situation. Would OpenStack welcome a
project built exclusively around a "free for developer use" product
into the tent?


The binaries are free-as-in-beer - IIUC you can't redistribute them. The 
source code, of course, remains free-as-in-speech as it has always been. 
(It's easy to forget the distinction when you work in Python all day and 
there are no binaries, but it's the source code that counts.) And of 
course there are freely-distributable binaries built from that source 
available in the form of CentOS.


So the question is mostly moot - we should *almost* never encounter a 
dependency on RHEL in particular (as opposed to EL builds in general - 
RHEL/CentOS/Scientific Linux/that Oracle thing/whatever). However in the 
tiny number of cases where there is one, I think it's entirely 
reasonable for the OpenStack community to require (a) that it not be a 
*hard* dependency; and (b) that a "level playing field" exists - i.e. 
the team must have no objection in principle to somebody using similar 
mechanisms to implement equivalent functionality for other operating 
systems.


(I should clarify that this is my personal opinion; I don't speak for 
Red Hat.)


I believe we follow that policy already anyway. e.g. TripleO never uses 
RHEL in the gate, only CentOS AFAIK.


cheers,
Zane.

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

Re: [openstack-dev] [TripleO] Consolidating TripleO validations with Browbeat validations

[Ihar Hrachyshka]

> On 20 Jun 2016, at 18:37, Joe Talerico  wrote:
> 
> Hello - It would seem there is a little bit of overlap with TripleO
> validations ( clapper validations ) and Browbeat *Checks*. I would
> like to see these two come together, and I wanted to get some feedback
> on this.
> 
> For reference here are the Browbeat checks :
> https://github.com/openstack/browbeat/tree/master/ansible/check
> 
> We check for common deployment mistakes, possible deployment
> performance issues and some bugs that could impact the scale and
> performance of your cloud... At the end we build a report of found
> issues with the cloud, like :
> https://github.com/openstack/browbeat/blob/master/ansible/check/browbeat-example-bug_report.log
> 
> We eventually wanted to take these findings and push them to
> ElasticSearch as metadata for our result data (just so we would be
> aware of any BZs or possibly missed tuning).
> 
> Anyhoo, I just would like to get feedback on consolidating these
> checks into TripleO Validations if that makes sense. If this does make
> sense, who could I work with to see that this happens?

Sorry for hijacking the thread somewhat, but it seems that neutron-sanity-check 
would cover for some common deployment issues, if utilized by projects like 
browbeat. Has anyone considered the tool?

http://docs.openstack.org/cli-reference/neutron-sanity-check.html

If there are projects that are interested in integrating checks that are 
implemented by neutron community, we would be glad to give some guidance.

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

[Doug Wiegley]

So, it sounds like you’ve just described the job of the TC. And they have so 
far refused to define OpenStack, leading to a series of derivative decisions 
that seem … inconsistent over time.

How is this body going to be different?

How will it have any teeth, and not just end up with the standard entrenched 
projects ignoring it?

Thanks,
doug


> On Jun 17, 2016, at 3:52 PM, Clint Byrum  wrote:
> 
> ar·chi·tec·ture
> ˈärkəˌtek(t)SHər/
> noun
> noun: architecture
> 
>1. 
> 
>the art or practice of designing and constructing buildings.
> 
>synonyms:building design, building style, planning, building, 
> construction; 
> 
>formalarchitectonics 
> 
>"modern architecture"
> 
>the style in which a building is designed or constructed, especially with 
> regard to a specific period, place, or culture.
> 
>plural noun: architectures
> 
>"Victorian architecture"
> 
>2. 
> 
>the complex or carefully designed structure of something.
> 
>"the chemical architecture of the human brain"
> 
>the conceptual structure and logical organization of a computer or 
> computer-based system.
> 
>"a client/server architecture"
> 
>synonyms:structure, construction, organization, layout, design, build, 
> anatomy, makeup; 
> 
>informalsetup 
> 
>"the architecture of a computer system"
> 
> 
> Introduction
> =
> 
> OpenStack is a big system. We have debated what it actually is [1],
> and there are even t-shirts to poke fun at the fact that we don't have
> good answers.
> 
> But this isn't what any of us wants. We'd like to be able to point
> at something and proudly tell people "This is what we designed and
> implemented."
> 
> And for each individual project, that is a possibility. Neutron can
> tell you they designed how their agents and drivers work. Nova can
> tell you that they designed the way conductors handle communication
> with API nodes and compute nodes. But when we start talking about how
> they interact with each other, it's clearly just a coincidental mash of
> de-facto standards and specs that don't help anyone make decisions when
> refactoring or adding on to the system.
> 
> Oslo and cross-project initiatives have brought some peace and order
> to the implementation and engineering processes, but not to the design
> process. New ideas still start largely in the project where they are
> needed most, and often conflict with similar decisions and ideas in other
> projects [dlm, taskflow, tooz, service discovery, state machines, glance
> tasks, messaging patterns, database patterns, etc. etc.]. Often times this
> creates a log jam where none of the projects adopt a solution that would
> align with others. Most of the time when things finally come to a head
> these things get done in a piecemeal fashion, where it's half done here,
> 1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
> looks like  chaos, because that's precisely what it is.
> 
> And this isn't always a technical design problem. OpenStack, for instance,
> isn't really a micro service architecture. Of course, it might look like
> that in diagrams [2], but we all know it really isn't. The compute node is
> home to agents for every single concern, and the API interactions between
> the services is too tightly woven to consider many of them functional
> without the same lockstep version of other services together. A game to
> play is ask yourself what would happen if a service was isolated on its
> own island, how functional would its API be, if at all. Is this something
> that we want? No. But there doesn't seem to be a place where we can go
> to actually design, discuss, debate, and ratify changes that would help
> us get to the point of gathering the necessary will and capability to
> enact these efforts.
> 
> Maybe nova-compute should be isolated from nova, with an API that
> nova, cinder and neutron talk to. Maybe we should make the scheduler
> cross-project aware and capable of scheduling more than just nova
> instances. Maybe we should have experimental groups that can look at how
> some of this functionality could perhaps be delegated to non-openstack
> projects. We hear that Mesos, for example to help with the scheduling
> aspects, but how do we discuss these outside hijacking threads on the
> mailing list? These are things that we all discuss in the hallways
> and bars and parties at the summit, but because they cross projects at
> the design level, and are inherently a lot of social and technical and
> exploratory work, Many of us fear we never get to a place of turning
> our dreams into reality.
> 
> So, with that, I'd like to propose the creation of an Architecture Working
> Group. This group's charge would not be design by committee, but a place
> for architects to share their designs and gain support across projects
> to move forward with and ratify architectural decisions. That includes
> coordinating exploratory work that may turn 

[openstack-dev] [TripleO] Consolidating TripleO validations with Browbeat validations

[Joe Talerico]

Hello - It would seem there is a little bit of overlap with TripleO
validations ( clapper validations ) and Browbeat *Checks*. I would
like to see these two come together, and I wanted to get some feedback
on this.

For reference here are the Browbeat checks :
https://github.com/openstack/browbeat/tree/master/ansible/check

We check for common deployment mistakes, possible deployment
performance issues and some bugs that could impact the scale and
performance of your cloud... At the end we build a report of found
issues with the cloud, like :
https://github.com/openstack/browbeat/blob/master/ansible/check/browbeat-example-bug_report.log

We eventually wanted to take these findings and push them to
ElasticSearch as metadata for our result data (just so we would be
aware of any BZs or possibly missed tuning).

Anyhoo, I just would like to get feedback on consolidating these
checks into TripleO Validations if that makes sense. If this does make
sense, who could I work with to see that this happens?

Thanks
Joe

__
OpenStack Development Mailing 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 trunk port - Kilo

[Ihar Hrachyshka]

> On 20 Jun 2016, at 18:23, KHAN, RAO ADNAN  wrote:
> 
> Hi,
>  
> I couldn’t see neutron neutron trunk-create --.. (as suggested at 
> https://wiki.openstack.org/wiki/Neutron/TrunkPort#neutron_trunk) supported in 
> neutron agent 2.4.
>  
> Can someone tell as to how to create trunk port in Kilo?
>  

There is no way to have it in Kilo, since the feature is currently in 
development for Newton. The feature will also not find its way into any 
previous releases because we don’t generally allow to backport new features.

Your best bet is trying out the code from current master branch of Neutron. 
Even then you probably won’t get much because most patches for the feature are 
still in progress and hasn’t landed Neutron tree.

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

[openstack-dev] Neutron trunk port - Kilo

[KHAN, RAO ADNAN]

Hi,

I couldn't see neutron neutron trunk-create --.. (as suggested at 
https://wiki.openstack.org/wiki/Neutron/TrunkPort#neutron_trunk) supported in 
neutron agent 2.4.

Can someone tell as to how to create trunk port in Kilo?

Thanks much!

Rao Adnan Khan
AT Integrated Cloud (AIC) Development | SE
Software Development & Engineering (SD)
Emai: rk2...@att.com
Cell phone: 972-342-5638

RESTRICTED - PROPRIETARY INFORMATION
This email is the property of AT and intended solely for the use of the 
addressee. If you have reason to believe you have received this in error, 
please delete this immediately; any other use, retention, dissemination, 
copying or printing of this email is strictly prohibited.


__
OpenStack Development Mailing 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] [tricircle]this weekly meeting

[joehuang]

Hello,



I am on the trip to attend the OPNFV Berlin summit, would like to know if 
someone can chair the weekly meeting of Tricircle. If no volunteer before Jun. 
22, we may have to skip this weekly meeting.



Best Regards

Chaoyi Huang ( joehuang )
__
OpenStack Development Mailing 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] [tricircle]Pypi job works, and tagging leads to a package publish

[joehuang]

Hello, team,



After the pypi job configuration and help from the community, the first package 
of Tricircle is published automatically after tagging the version 2.0.1 in 
stable/mitaka branch.



https://pypi.python.org/pypi/tricircle



The package verified the release publish process, and still suggest you to play 
2.0.1 through DevStack installation according to the README.md. For 
configuration guide through pip installlation is not provided yet.



Best Regards

Chaoyi Huang (joehuang)
__
OpenStack Development Mailing 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] libvirt driver: who should create the libvirt.xml file?

[Markus Zoeller]

White working on the change series to implement the virtlogd feature I
got feedback [1] to move code which creates parts of the libvirt.xml
file from the "driver" module into the "guest" module. I'm a bit
hesitant to do so as the responsibility of creating a valid libvirt.xml
file is then spread across 3 modules:
* driver.py
* guest.py
* designer.py
I'm only looking for a guideline here (The "driver" module is humongous
and I think it would be a good thing to have the "libvirt.xml" creation
code outside of it). Thoughts?


References:
[1]
https://review.openstack.org/#/c/323761/2/nova/virt/libvirt/driver.py@4190

-- 
Regards, Markus Zoeller (markus_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] Cinder multiple backends

[Fox, Kevin M]

In the mean time, the package list you have listed below is rather small. 
Easiest thing might be to just add them all to the docker/base/Dockerfile 

Thanks,
Kevin

From: Ryan Hallisey [rhall...@redhat.com]
Sent: Monday, June 20, 2016 6:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla]  Cinder multiple backends

Hey Carlos,

The work to enable you to do this is in progress.  Kolla needs to refactor the 
way the Dockerfiles
are templated in order to create additional flexibility.

You can follow the work here: 
https://blueprints.launchpad.net/kolla/+spec/third-party-plugin-support

Thanks,
Ryan

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

Sent: Monday, June 20, 2016 9:29:27 AM
Subject: [openstack-dev]  [kolla]  Cinder multiple backends

Hi folks,

It seems that Kolla does nos provide option to enable multiple backends in 
Cinder config.

Currently in my deploy/setup I needed enable the Storwize Cinder driver - 
http://docs.openstack.org/mitaka/config-reference/block-storage/drivers/ibm-storwize-svc-driver.html
 -
and to this I added into /etc/kolla/config/cinder.conf my configs

  [DEFAULT]
  default_volume_type = ibm

  [ibm]
  
volume_driver=cinder.volume.drivers.ibm.storwize_svc.storwize_svc_fc.StorwizeSVCFCDriver
  san_ip=xxx.xx.xx.xx
  san_login=superuser
  san_password=mypass
  san_ssh_port=22
  storwize_svc_volpool_name=myPool
  volume_backend_name=ibm
  verbose = True
  debug = True


And I changed manually the file 
/var/src/kolla-master/ansible/roles/cinder/templates/cinder.conf.j2 as well.

But for the driver works correctly, it was needed install manually some 
aditional packs.

$ apt-get install sysfsutils sg3-utils on cinder-volume container
$ apt-get install multipath-tools sysfsutils on nova-compute container

Is there any doc/spec to create a automatic process for this ? Could someone 
give us details how is the best way to make it "automatized" !?



Best regards,

- Carlos
__
OpenStack Development Mailing 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] Recommended ways to find compute node's bandwidth (physical NIC)

[KHAN, RAO ADNAN]

Thanks Sudipto for pointing out the tool; another light weight tool I am 
thinking is 'ethtool', in order to collect basic NIC info, including "speed". 

Rao Adnan Khan
AT Integrated Cloud (AIC) Development | SE
Software Development & Engineering (SD)
Emai: rk2...@att.com
Cell phone: 972-342-5638

RESTRICTED - PROPRIETARY INFORMATION
This email is the property of AT and intended solely for the use of the 
addressee. If you have reason to believe you have received this in error, 
please delete this immediately; any other use, retention, dissemination, 
copying or printing of this email is strictly prohibited.


-Original Message-
From: Sudipto Biswas [mailto:sbisw...@linux.vnet.ibm.com] 
Sent: Monday, June 20, 2016 12:12 AM
To: openstack-dev@lists.openstack.org; sbisw...@in.ibm.com
Subject: Re: [openstack-dev] Recommended ways to find compute node's bandwidth 
(physical NIC)

Thanks Jay for pointing this out.

Adnan,

Yeah - you could use PcP - if that module gets integrated with Nova.

For your benefit, here are some of the metrics that PcP can provide 
related to the physical NIC:

pminfo | grep network.interface  <== Listing the available metrics.
network.interface.collisions
network.interface.mtu
network.interface.speed
network.interface.baudrate
network.interface.duplex
network.interface.up
network.interface.running
network.interface.inet_addr
network.interface.ipv6_addr
network.interface.ipv6_scope
network.interface.hw_addr
network.interface.in.bytes
network.interface.in.packets
network.interface.in.errors
network.interface.in.drops
network.interface.in.fifo
network.interface.in.frame
network.interface.in.compressed
network.interface.in.mcasts
network.interface.out.bytes
network.interface.out.packets
network.interface.out.errors
network.interface.out.drops
network.interface.out.fifo
network.interface.out.carrier
network.interface.out.compressed
network.interface.total.bytes
network.interface.total.packets
network.interface.total.errors
network.interface.total.drops
network.interface.total.mcasts


# pmval network.interface.out.bytes <== A sample metric value.
metric:network.interface.out.bytes
host:  
semantics: cumulative counter (converting to rate)
units: byte (converting to byte / sec)
samples:   all
 wlp3s0lo virbr0   
wc0   em1 virbr0-nic
0.0   0.0 0.0   
0.0   0.0 0.0
   85.96  0.0 0.0   
0.0   0.0 0.0
0.0   0.0 0.0   
0.0   0.0 0.0
0.0   0.0 0.0   
0.0   0.0 0.0
 1588. 4031. 0.0 
787.6   0.0 0.0
  492.7   0.0 0.0 
155.9   0.0 0.0


As you might observe, there's a plenty for you to draw inferences.

Hope this helps!

Cheers,
Sudipto

On Monday 20 June 2016 09:07 AM, Jay Pipes wrote:
> On 06/16/2016 04:16 PM, KHAN, RAO ADNAN wrote:
>> I am writing a nova filter that will check for the compute node (max,
>> avg) bandwidth, before instantiating an instance. What are some of the
>> recommended tools that can provide this info in real time? Does any
>> openstack component hold this info already?
>
> You may want to chat with Sudipta Biswas (cc'd). The PCP module (yes, 
> it's an awkward name for a performance profiling module...) does some 
> of what you're looking for and Sudipta has been attempting to 
> integrate it with Nova for this express purpose.
>
> Best,
> -jay
>
> __ 
>
> OpenStack Development Mailing 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] Proposal: Architecture Working Group

[Nikhil Komawar]

+1 , great idea.

if we can add a mission/objective based on the nice definitions you
added, will help a long way in cross-project architecture evolution.
moreover, I'd like this to be a integration point for openstack projects
(and not a silo) so that we can build the shared understanding we really
need to build.

On 6/17/16 5:52 PM, Clint Byrum wrote:
> ar·chi·tec·ture
> ˈärkəˌtek(t)SHər/
> noun
> noun: architecture
>
> 1. 
>
> the art or practice of designing and constructing buildings.
>
> synonyms:building design, building style, planning, building, 
> construction; 
>
> formalarchitectonics 
>
> "modern architecture"
>
> the style in which a building is designed or constructed, especially with 
> regard to a specific period, place, or culture.
>
> plural noun: architectures
>
> "Victorian architecture"
>
> 2. 
>
> the complex or carefully designed structure of something.
>
> "the chemical architecture of the human brain"
>
> the conceptual structure and logical organization of a computer or 
> computer-based system.
>
> "a client/server architecture"
>
> synonyms:structure, construction, organization, layout, design, build, 
> anatomy, makeup; 
>
> informalsetup 
>
> "the architecture of a computer system"
>
>
> Introduction
> =
>
> OpenStack is a big system. We have debated what it actually is [1],
> and there are even t-shirts to poke fun at the fact that we don't have
> good answers.
>
> But this isn't what any of us wants. We'd like to be able to point
> at something and proudly tell people "This is what we designed and
> implemented."
>
> And for each individual project, that is a possibility. Neutron can
> tell you they designed how their agents and drivers work. Nova can
> tell you that they designed the way conductors handle communication
> with API nodes and compute nodes. But when we start talking about how
> they interact with each other, it's clearly just a coincidental mash of
> de-facto standards and specs that don't help anyone make decisions when
> refactoring or adding on to the system.
>
> Oslo and cross-project initiatives have brought some peace and order
> to the implementation and engineering processes, but not to the design
> process. New ideas still start largely in the project where they are
> needed most, and often conflict with similar decisions and ideas in other
> projects [dlm, taskflow, tooz, service discovery, state machines, glance
> tasks, messaging patterns, database patterns, etc. etc.]. Often times this
> creates a log jam where none of the projects adopt a solution that would
> align with others. Most of the time when things finally come to a head
> these things get done in a piecemeal fashion, where it's half done here,
> 1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
> looks like  chaos, because that's precisely what it is.
>
> And this isn't always a technical design problem. OpenStack, for instance,
> isn't really a micro service architecture. Of course, it might look like
> that in diagrams [2], but we all know it really isn't. The compute node is
> home to agents for every single concern, and the API interactions between
> the services is too tightly woven to consider many of them functional
> without the same lockstep version of other services together. A game to
> play is ask yourself what would happen if a service was isolated on its
> own island, how functional would its API be, if at all. Is this something
> that we want? No. But there doesn't seem to be a place where we can go
> to actually design, discuss, debate, and ratify changes that would help
> us get to the point of gathering the necessary will and capability to
> enact these efforts.
>
> Maybe nova-compute should be isolated from nova, with an API that
> nova, cinder and neutron talk to. Maybe we should make the scheduler
> cross-project aware and capable of scheduling more than just nova
> instances. Maybe we should have experimental groups that can look at how
> some of this functionality could perhaps be delegated to non-openstack
> projects. We hear that Mesos, for example to help with the scheduling
> aspects, but how do we discuss these outside hijacking threads on the
> mailing list? These are things that we all discuss in the hallways
> and bars and parties at the summit, but because they cross projects at
> the design level, and are inherently a lot of social and technical and
> exploratory work, Many of us fear we never get to a place of turning
> our dreams into reality.
>
> So, with that, I'd like to propose the creation of an Architecture Working
> Group. This group's charge would not be design by committee, but a place
> for architects to share their designs and gain support across projects
> to move forward with and ratify architectural decisions. That includes
> coordinating exploratory work that may turn into being the base of further
> architectural decisions for OpenStack. I 

Re: [openstack-dev] [magnum] Need helps to implement the full baremetals support

[Spyros Trigazis]

Hi Yuanying,

I tested your patch [2] with the image that Ton created [1] and it worked.

For me devicemapper as docker-storage-driver didn't work but this is
unrelated to this patch, I'll update devicemapper. I used overlay and
it was ok.

I'll sum up what I did here, for others to test.

On a fresh install of Ubuntu 14.04.3

0-
setup environment as in:
http://docs.openstack.org/developer/magnum/dev/dev-quickstart.html#dev-quickstart

1-
I used a local.conf with less configuration and I added magnum.
https://stikked.web.cern.ch/stikked/view/35816b1d

2-
Update subnets with dns-nameserver
neutron subnet-update private-subnet --dns-nameserver 8.8.8.8
neutron subnet-update public-subnet --dns-nameserver 8.8.8.8

3-
Modify ironic.nodes table
alter table ironic.nodes modify instance_info LONGTEXT;

4-
download images [1] and register as in:
https://review.openstack.org/#/c/320968/10/magnum/elements/kubernetes/README.md

5-
update iptables as in our devstack script:
https://github.com/openstack/magnum/blob/master/devstack/lib/magnum#L326

6-
magnum baymodel-create --name k8s-ironic-baymodel \
   --keypair-id testkey \
   --server-type bm \
   --external-network-id public \
   --fixed-network private \
   --image-id fedora-k8s \
   --flavor-id baremetal \
   --network-driver flannel \
   --dns 8.8.8.8 \
   --coe kubernetes \
   --docker-storage-driver overlay

7-
create bay
magnum bay-create --name k8s-ironbay --baymodel k8s-ironic-baymodel
--node-count
1

It took a few minutes to get CREATE_COMPLETE on my 4-core desktop.

Thanks Yuanying and Ton!

Cheers,
Spyros


[1] https://fedorapeople.org/groups/magnum/fedora-23-kubernetes*
[2] https://review.openstack.org/#/c/320968/


On 14 June 2016 at 03:26, Yuanying OTSUKA  wrote:

> Hi, Spyros
>
> I updated ironic heat template, and succeeded booting k8s bay with Ironic.
> Could you test it?
>
> Unfortunately there are some problem and requirement to test.
> I describe below.
>
> * subnet which belongs to private network should be set up with
> dns_nameservers like following.
>
> $ neutron subnet-update private-subnet —dns-nameserver 8.8.8.8
>
> * modify ironic.nodes table
>
> $ alter table ironic.nodes modify instance_info LONGTEXT;
>
> * baymodel
>
> $ magnum baymodel-create —name kubernetes —keypair-id default \
>--server-type bm \
>--external-network-id public \
>--fixed-network private \
>--image-id fedora-k8s \
>--flavor-id baremetal \
>--network-driver flannel \
>--coe kubernetes
>
> * Fedora image
> Following procedure depends on diskimage-builder fix:
> https://review.openstack.org/#/c/247296/
>
> https://review.openstack.org/#/c/320968/10/magnum/elements/kubernetes/README.md
>
> * my local.conf to setup ironic env
> http://paste.openstack.org/show/515877/
>
>
> Thanks
> -yuanying
>
>
> 2016年5月25日(水) 22:00 Yuanying OTSUKA :
>
>> Hi, Spyros
>>
>> I fixed a conflicts and upload following patch.
>> * https://review.openstack.org/#/c/320968/
>>
>> But it isn’t tested yet, maybe it doesn’t work..
>> If you have a question, please feel free to ask.
>>
>>
>> Thanks
>> -yuanying
>>
>>
>>
>> 2016年5月25日(水) 17:56 Spyros Trigazis :
>>
>>> Hi Yuanying,
>>>
>>> please upload your workaround. I can test it and try to fix the
>>> conflicts.
>>> Even if it conflicts we can have some iterations on it.
>>>
>>> I'll upload later what worked for me on devstack.
>>>
>>> Thanks,
>>> Spyros
>>>
>>> On 25 May 2016 at 05:13, Yuanying OTSUKA  wrote:
>>>
 Hi, Hongbin, Spyros.

 I’m also interesting this work.
 I have workaround patch to support ironic.
 (but currently conflict with master.
 Is it helpful to upload it for initial step of the implementation?

 Thanks
 -yuanying

 2016年5月25日(水) 6:52 Hongbin Lu :

> Hi all,
>
>
>
> One of the most important feature that Magnum team wants to deliver in
> Newton is the full baremetal support. There is a blueprint [1] created for
> that and the blueprint was marked as “essential” (that is the highest
> priority). Spyros is the owner of the blueprint and he is looking for 
> helps
> from other contributors. For now, we immediately needs help to fix the
> existing Ironic templates [2][3][4] that are used to provision a 
> Kubernetes
> cluster on top of baremetal instances. These templates were used to work,
> but they become outdated right now. We need help to fix those Heat 
> template
> as an initial step of the implementation. Contributors are 

Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to Tacker core team

[Kanagaraj Manickam]

Sridhar,
Thank you for nominating me as tacker core-reviewer.

Tacker Core team,
Thanks for appreciating my contributions in tacker and It's my pleasure to
be part of the core-team.

Regards
Kanagaraj M


On Mon, Jun 20, 2016 at 4:51 PM, Sridhar Ramaswamy 
wrote:

> Thanks for the responses, I'm closing the vote.
>
> Kanagaraj - welcome to the Tacker core team!
>
> On Sun, Jun 19, 2016 at 7:25 PM, bharath thiruveedula <
> bharath_...@hotmail.com> wrote:
>
>> +1
>> --
>> To: openstack-dev@lists.openstack.org
>> From: bob.haddle...@nokia.com
>> Date: Fri, 17 Jun 2016 12:12:13 -0500
>>
>> Subject: Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to
>> Tacker core team
>>
>> +1.  Kanagaraj will be a great addition to the team.
>>
>> Bob
>>
>> On 6/16/2016 1:45 PM, Karthik Natarajan wrote:
>>
>> +1. Thanks Kanagaraj for making such a great impact during the Newton
>> cycle.
>>
>>
>>
>> *From:* Sripriya Seetharam [mailto:ssee...@brocade.com
>> ]
>> *Sent:* Thursday, June 16, 2016 10:35 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>>  
>> *Subject:* Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to
>> Tacker core team
>>
>>
>>
>> +1
>>
>>
>>
>>
>>
>> -Sripriya
>>
>>
>>
>>
>>
>> *From:* Sridhar Ramaswamy [mailto:sric...@gmail.com ]
>> *Sent:* Wednesday, June 15, 2016 6:32 PM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* [openstack-dev] [tacker] Proposing Kanagaraj Manickam to
>> Tacker core team
>>
>>
>>
>> Tackers,
>>
>> It gives me great pleasure to propose Kanagaraj Manickam to join the
>> Tacker core team. In a short time, Kanagaraj has grown into a key member of
>> the Tacker team. His enthusiasm and dedication to get Tacker code base on
>> par with other leading OpenStack projects is very much appreciated. He is
>> already working on two important specs in Newton cycle and many more fixes
>> and RFEs [1]. Kanagaraj is also a core member in the Heat project and this
>> lends well as we heavily use Heat for many Tacker features.
>>
>> Please provide your +1/-1 votes.
>>
>> - Sridhar
>>
>> [1]
>> http://stackalytics.com/?module=tacker-group_id=kanagaraj-manickam=marks
>> 
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions) Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing 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] Proposal: Architecture Working Group

[Michael Krotscheck]

I like the idea in principle, but am bullish on the implementation.

For example: we have the API-WG which fulfills part of an Architectural
mission, as well as the Cross-Project WG which fulfills a different part.
Yet there's no incentive, carrot or stick, that drives adoption of the
approved specs, other than "Well if you want to do the work, have fun". In
several cases, I've run into the excuses of "That's Hard/That breaks
backwards compatibility/That's not profitable/I'm not paid to do that".

What's going to prevent [Insert Project Here] from coming along and saying
"Oh, well, we don't like those decisions, so are going to ignore them."
What provides the incentive for a project to adopt these recommendations?

Michael

On Mon, Jun 20, 2016 at 2:25 AM Denis Makogon  wrote:

> Hello Clint.
>
> I'd like to take part as well, so count me in.
>
> Kind regards,
> Denys Makogon
>
>
> 2016-06-20 10:23 GMT+03:00 Ghe Rivero :
>
>> Hi all!
>> I really like the idea of the group, so count me in!
>>
>> Ghe Rivero
>>
>> Quoting Clint Byrum (2016-06-17 23:52:43)
>> > ar·chi·tec·ture
>> > ˈärkəˌtek(t)SHər/
>> > noun
>> > noun: architecture
>> >
>> > 1.
>> >
>> > the art or practice of designing and constructing buildings.
>> >
>> > synonyms:building design, building style, planning, building,
>> construction;
>> >
>> > formalarchitectonics
>> >
>> > "modern architecture"
>> >
>> > the style in which a building is designed or constructed,
>> especially with regard to a specific period, place, or culture.
>> >
>> > plural noun: architectures
>> >
>> > "Victorian architecture"
>> >
>> > 2.
>> >
>> > the complex or carefully designed structure of something.
>> >
>> > "the chemical architecture of the human brain"
>> >
>> > the conceptual structure and logical organization of a computer or
>> computer-based system.
>> >
>> > "a client/server architecture"
>> >
>> > synonyms:structure, construction, organization, layout, design,
>> build, anatomy, makeup;
>> >
>> > informalsetup
>> >
>> > "the architecture of a computer system"
>> >
>> >
>> > Introduction
>> > =
>> >
>> > OpenStack is a big system. We have debated what it actually is [1],
>> > and there are even t-shirts to poke fun at the fact that we don't have
>> > good answers.
>> >
>> > But this isn't what any of us wants. We'd like to be able to point
>> > at something and proudly tell people "This is what we designed and
>> > implemented."
>> >
>> > And for each individual project, that is a possibility. Neutron can
>> > tell you they designed how their agents and drivers work. Nova can
>> > tell you that they designed the way conductors handle communication
>> > with API nodes and compute nodes. But when we start talking about how
>> > they interact with each other, it's clearly just a coincidental mash of
>> > de-facto standards and specs that don't help anyone make decisions when
>> > refactoring or adding on to the system.
>> >
>> > Oslo and cross-project initiatives have brought some peace and order
>> > to the implementation and engineering processes, but not to the design
>> > process. New ideas still start largely in the project where they are
>> > needed most, and often conflict with similar decisions and ideas in
>> other
>> > projects [dlm, taskflow, tooz, service discovery, state machines, glance
>> > tasks, messaging patterns, database patterns, etc. etc.]. Often times
>> this
>> > creates a log jam where none of the projects adopt a solution that would
>> > align with others. Most of the time when things finally come to a head
>> > these things get done in a piecemeal fashion, where it's half done here,
>> > 1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
>> > looks like  chaos, because that's precisely what it is.
>> >
>> > And this isn't always a technical design problem. OpenStack, for
>> instance,
>> > isn't really a micro service architecture. Of course, it might look like
>> > that in diagrams [2], but we all know it really isn't. The compute node
>> is
>> > home to agents for every single concern, and the API interactions
>> between
>> > the services is too tightly woven to consider many of them functional
>> > without the same lockstep version of other services together. A game to
>> > play is ask yourself what would happen if a service was isolated on its
>> > own island, how functional would its API be, if at all. Is this
>> something
>> > that we want? No. But there doesn't seem to be a place where we can go
>> > to actually design, discuss, debate, and ratify changes that would help
>> > us get to the point of gathering the necessary will and capability to
>> > enact these efforts.
>> >
>> > Maybe nova-compute should be isolated from nova, with an API that
>> > nova, cinder and neutron talk to. Maybe we should make the scheduler
>> > cross-project aware and capable of scheduling more than just nova

[openstack-dev] [new][oslo] oslo.privsep 1.9.0 release (newton)

[no-reply]

We are eager to announce the release of:

oslo.privsep 1.9.0: OpenStack library for privilege separation

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.privsep

With package available at:

https://pypi.python.org/pypi/oslo.privsep

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.privsep

For more details, please see below.

Changes in oslo.privsep 1.8.0..1.9.0


9bf6063 Provide way to "initialise" oslo.privsep
ecabeaf PrivContext: Sets client_mode to False on Windows
595b759 Imported Translations from Zanata

Diffstat (except docs and test files)
-

oslo_privsep/daemon.py | 48 +
oslo_privsep/locale/de/LC_MESSAGES/oslo_privsep.po |  9 ++-
.../en_GB/LC_MESSAGES/oslo_privsep-log-error.po| 26 
.../en_GB/LC_MESSAGES/oslo_privsep-log-info.po | 41 
.../en_GB/LC_MESSAGES/oslo_privsep-log-warning.po  | 18 +
.../locale/en_GB/LC_MESSAGES/oslo_privsep.po   | 66 ++
oslo_privsep/locale/oslo_privsep-log-warning.pot   | 24 ---
oslo_privsep/locale/oslo_privsep.pot   | 78 --
oslo_privsep/priv_context.py   | 78 +-
11 files changed, 302 insertions(+), 193 deletions(-)




__
OpenStack Development Mailing 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][calico] New networking-calico IRC meeting

[Neil Jerram]

Calling everyone interested in networking-calico ...!  networking-calico
has been around in the Neutron stadium for a while now, and it's way past
time that we had a proper forum for discussing and evolving it - so I'm
happy to be finally proposing a regular IRC meeting slot for it: [1].  A
strawman initial agenda is up at [2].

[1] https://review.openstack.org/#/c/331689/
[2] https://wiki.openstack.org/wiki/Meetings/NetworkingCalico

Please do take a look and

   - let me know your views on the timing, either here or on the review
   - feel free to add items to the agenda.


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

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

[Jay Pipes]

On 06/20/2016 10:21 AM, Sylvain Bauza wrote:

Le 20/06/2016 16:04, Jay Pipes a écrit :

On 06/17/2016 11:23 AM, Sylvain Bauza wrote:

+1000 yes to that. Now the devil could be in the details, in particular
how we implement the WSGI server, the corresponding WSGI app and the
associated routing, and that's exactly the problem below.


We shouldn't be implementing a WSGI server *at all*. The fact that one
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi,
uwsgi, etc) is a bad thing.



Okay, fair point :-)
That still leaves the routing question up, tho :-)

I certainly understand the concerns of adding yet another library. To be
honest, I tend to even agree with the statement that we could possibly
use Routes without explicitly use nova.wsgi, right ?

In the review, you explain why you don't trust Routes and I respect
that. That said, are those issues logged as real problems for our API
consumers, which are mostly client libraries that we own and other
projects we know, like Horizon ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken
in a framework-less implementation with nothing other than the (tiny)
selector library as a dependency. I'd like to see the work move forward.



Okay, my open question (because I'm not expert in that) was rather to
understand why Routes was not possible to be something usable for the
new placement API, if that's something we use in Nova too.


Routes would indeed be possible to use. And I wouldn't have an issue 
using Routes, though I prefer selector due to its simplicity and 
documentation readability and that controllers are specified as actual 
callables, not strings.


-jay

__
OpenStack Development Mailing 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] [StoryBoard] [OpenStack-Infra] StoryBoard Bug Squash 22nd-23rd June

[Zara Zaimeche]

Hi everyone!

For one week only*, the StoryBoard bug squash is coming to an OpenStack 
community near you! That's right; from 11:00 UTC 22nd June, to 11:00 UTC 
23rd June THIS week, the StoryBoard team will be making a 
critically-acclaimed appearance in #openstack-sprint. We'll be setting 
time aside to help new contributors and to smoosh as many pesky little 
bugs as possible. So come one, come all, and let's squash some bugs! As 
always, you can also catch us in #storyboard. You can also help with the 
effort by tagging smaller tasks as low-hanging-fruit in 
storyboard.openstack.org. We have a worklist-in-progress listing all 
such StoryBoard stories here:


https://storyboard.openstack.org/#!/worklist/76

Feel free to ask any questions in #storyboard, and we hope to see you there!

Best Wishes,

Zara



*every week, really, we just don't use #openstack-sprint most weeks.

__
OpenStack Development Mailing 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] [api] [placement] strategy for placement api structure

[Sylvain Bauza]

Le 20/06/2016 16:04, Jay Pipes a écrit :

On 06/17/2016 11:23 AM, Sylvain Bauza wrote:

+1000 yes to that. Now the devil could be in the details, in particular
how we implement the WSGI server, the corresponding WSGI app and the
associated routing, and that's exactly the problem below.


We shouldn't be implementing a WSGI server *at all*. The fact that one 
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, 
uwsgi, etc) is a bad thing.




Okay, fair point :-)
That still leaves the routing question up, tho :-)

I certainly understand the concerns of adding yet another library. To be
honest, I tend to even agree with the statement that we could possibly
use Routes without explicitly use nova.wsgi, right ?

In the review, you explain why you don't trust Routes and I respect
that. That said, are those issues logged as real problems for our API
consumers, which are mostly client libraries that we own and other
projects we know, like Horizon ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken 
in a framework-less implementation with nothing other than the (tiny) 
selector library as a dependency. I'd like to see the work move forward.




Okay, my open question (because I'm not expert in that) was rather to 
understand why Routes was not possible to be something usable for the 
new placement API, if that's something we use in Nova too.


-S


Best,
-jay

__ 


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

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



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

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

[Jay Pipes]

On 06/17/2016 11:23 AM, Sylvain Bauza wrote:

+1000 yes to that. Now the devil could be in the details, in particular
how we implement the WSGI server, the corresponding WSGI app and the
associated routing, and that's exactly the problem below.


We shouldn't be implementing a WSGI server *at all*. The fact that one 
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, uwsgi, 
etc) is a bad thing.



I certainly understand the concerns of adding yet another library. To be
honest, I tend to even agree with the statement that we could possibly
use Routes without explicitly use nova.wsgi, right ?

In the review, you explain why you don't trust Routes and I respect
that. That said, are those issues logged as real problems for our API
consumers, which are mostly client libraries that we own and other
projects we know, like Horizon ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken 
in a framework-less implementation with nothing other than the (tiny) 
selector library as a dependency. I'd like to see the work move forward.


Best,
-jay

__
OpenStack Development Mailing 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][upgrades] Bi-weekly upgrades work status. 6/20/2016

[Ihar Hrachyshka]

Hi all,

(It’s not really bi-weekly since I missed it the previous week. This report is 
for the last 3 weeks. I will try to keep a more regular schedule for those 
updates in the future.)

OK. What’s new in neutron upgrades since last update?

1. For the most part, the team works on migrating existing code base to using 
versioned objects.

What landed:

- base db plugin switched to objects for subnetpools: 
https://review.openstack.org/300056
- get_object(s) API now allows to pass renamed fields as filters: 
https://review.openstack.org/327249

What’s in the queue:
- utilizing DNSNameServer object in the code: 
https://review.openstack.org/326477
- security groups object: https://review.openstack.org/284738
- *PortSecurity objects: https://review.openstack.org/327257

There are things still crafting worth mentioning:
- subnet adoption in db code: https://review.openstack.org/321001
- subnet object adjustments: https://review.openstack.org/331009
- address scope adoption: https://review.openstack.org/#/c/308005/

A lot of api test coverage for sorting and pagination happened. That is 
something that we push for before we switch resources to using objects to avoid 
potential regressions. Things that landed:
- next/prev href links tests: https://review.openstack.org/318270
- subnet tests: https://review.openstack.org/329340
- subnetpools tests: https://review.openstack.org/327081

We have a lot more related patches though, including test coverage as well as 
enabling sorting/pagination for all installations. All those are tracked under:

https://review.openstack.org/#/q/status:open++(topic:bug/1566514+OR+topic:bug/1591981)

Reviews for ^ are highly welcome!

There were other related changes that landed in master:
- migrated code from using private ._context attributes to .obj_context: 
https://review.openstack.org/283616
- added type information to ObjectNotFound exception: 
https://review.openstack.org/327582
- NetworkDhcpAgentBinding model moved to a separate module: 
https://review.openstack.org/328452
- get_object() switched to using _query_model to support RBAC filtering: 
https://review.openstack.org/#/c/326361/
- query filter hook added to objects: https://review.openstack.org/328304
- qos policy filtering by ‘shared’ field is fixed by utilizing ^: 
https://review.openstack.org/328313

2. As for multinode grenade testing, there was little progress on getting 
voting for the DVR job. This is something that I plan to tackle in the near 
future.

===

Team info:
Upgrades Subteam has the weekly meetings on Mondays, 2PM UTC, wiki page: 
https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam

New patches are generally tracked under the following topic: 
https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db

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] [nova] [api] [placement] strategy for placement api structure

[Sean Dague]

On 06/17/2016 12:14 PM, Chris Dent wrote:
> On Fri, 17 Jun 2016, Sylvain Bauza wrote:
> 
>> In the review, you explain why you don't trust Routes and I respect
>> that. That said, are those issues logged as real problems for our API
>> consumers, which are mostly client libraries that we own and other
>> projects we know, like Horizon ?
> 
> The implication of your question here is that it is okay to do HTTP
> incorrectly if people don't report problems with that lack of
> correctness?
>
>> If that is a problem for those, is there something we could improve,
>> instead of just getting rid of it ?
> 
> When I found the initial problem with Routes, it was because I was
> doing some intial nova testing (with gabbi-tempest[1]) and
> discovered it wasn't returning a 405 when it should. I made a bug
> 
> https://bugs.launchpad.net/nova/+bug/1567970
> 
> and tried to fix it but Routes fought me. If someone else can figure
> it out more power to them.
> 
> In any case selector's behavior in this case is just better. Better
> is better, right?

That's a Nova bug, is there an upstream Routes bug for that? I didn't
see one in looking around. While Routes isn't a super quick upstream,
they have merged our fixes in the past.

Better on what axis? This does add another way that people need to learn
to do this thing that they've all been doing another way. Largely to
address a set of issues that are theoretical to our consumers.
http://mcfunley.com/choose-boring-technology

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

[Doug Hellmann]

Excerpts from Mark Voelker's message of 2016-06-20 13:24:46 +:
> 
> > On Jun 20, 2016, at 8:46 AM, Doug Hellmann  wrote:
> > 
> > Excerpts from Mark Voelker's message of 2016-06-16 20:33:36 +:
> > 
> >> On Tue, Jun 14, 2016 at 05:42:16PM -0400, Doug Hellmann wrote:
> >> 
> >> 
> >>> I don't think DefCore actually needs to change old versions of Tempest,
> >>> but maybe Chris or Mark can verify that?
> >> 
> >> So if I’m groking this correctly, there’s kind of two scenarios
> >> being painted here.  One is the “LCD” approach where we use the
> >> $osversion-eol version of Tempest, where $osversion matches the
> >> oldest version covered in a Guideline.  The other is to use the
> >> start-of-$osversion version of Tempest where $osversion is the
> >> OpenStack version after the most recent one in the Guideline.  The
> >> former may result in some fairly long-lived flags, and the latter
> >> is actually not terribly different than what we do today I think.
> >> Let me try to talk through both...
> >> 
> >> In some cases, tests get flagged in the Guidelines because of
> >> bugs in the test or because the test needs refactoring.  The
> >> underlying Capabilities the those tests are testing actually work
> >> fine.  Once we identify such an issue, the test can be fixed…in
> >> master.  Under the first scenario, this potentially creates some
> >> very long-lived flags:
> >> 
> >> 2016.01 is the most current Guideline right now covers Juno, Kilo,
> >> Liberty (and Mitaka after it was released).  It’s one of the two
> >> Guidelines that you can use if you want an OpenStack Powered license
> >> from he Foundation, $vendor wants to run it against their shiny new
> >> Mitaka cloud.  They run the Juno EOL version of Tempest (tag=8),
> >> they find a test issue, and we flag it.  A few weeks later, a fix
> >> lands in Tempest.  Several months later the next Guideline rolls
> >> around: the oldest covered release is Kilo and we start telling
> >> people to use the Kilo-EOL version of Tempest.  That doesn’t have
> >> the fix, so the flag stays.  Another six months goes by and we get
> >> a Guideline and we’re up to the Liberty-EOL version of Tempest.  No
> >> fix, flag stays.  Six more months, and now we’re at Mitaka-EOL, and
> >> that's the first version that includes the fix.
> >> 
> >> Generally speaking long lived flags aren’t so great because it
> >> means the tests are not required…which means there’s less or no
> >> assurance that the capabilities they test for actually work in the
> >> clouds that adhere to those Guidelines.  So, the worst-case scenario
> >> here looks kind of ugly.
> >> 
> >> As Matt correctly pointed out though, the capabilities DefCore
> >> selects for are generally pretty stable API’s that are long-lived
> >> across many releases, so we haven’t run into a lot of issues running
> >> pretty new versions of Tempest against older clouds to date.  In
> >> fact I’m struggling to think of a time we’ve flagged something
> >> because someone complained the test wasn’t runnable against an older
> >> release covered by the Guideline in question.  I can think of plenty
> >> of times where we’ve flagged something due to a test issue though…keep
> >> in mind we’re still in pretty formative times with DefCore here
> >> where these tests are starting to be used in a new way for the first
> >> time.  Anyway, as Matt points out we could potentially use a much
> >> newer Tempest tag: tag=11 (which is the start of Newton development
> >> and is a roughly 2 month old version of Tempest).  Next Guideline
> >> rolls around, we use the tag for start-of-ocata, and we get the fix
> >> and can drop the flag.
> >> 
> >> Today, RefStack client by default checks out a specific SHA of
> >> Tempest [1] (it actually did use a tag at some point in the past,
> >> and still can).  When we see a fix for a flagged test go in, we or
> >> the Refstack folks can do a quick test to make sure everything’s
> >> in order and then update that SHA to match the version with the
> >> fix.  That way we’re relatively sure we have a version that works
> >> today, and will work when we drop the flag in the next Guideline
> >> too.  When we finalize that next Guideline, we also update the
> >> test-repositories section of the new Guideline that Matt pointed
> >> to earlier to reflect the best-known version on the day the Guideline
> >> was sent to the Board for approval.  One added benefit of this
> >> approach is that people running the tests today may get a version
> >> of Tempest that includes a fix for a flagged test.  A flagged test
> >> isn’t required, but it does get run—and now will show a passing
> >> result, so we have data that says “this provider actually does
> >> support this capability (even though it’s flagged), and the test
> >> does indeed seem to be working."
> >> 
> >> 
> >> So, that’s actually not hugely different from the second scenario
> >> I think?  Or did I miss something there?
> > 
> > 

Re: [openstack-dev] [kolla] Cinder multiple backends

[Ryan Hallisey]

Hey Carlos,

The work to enable you to do this is in progress.  Kolla needs to refactor the 
way the Dockerfiles
are templated in order to create additional flexibility.

You can follow the work here: 
https://blueprints.launchpad.net/kolla/+spec/third-party-plugin-support

Thanks,
Ryan

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

Sent: Monday, June 20, 2016 9:29:27 AM
Subject: [openstack-dev]  [kolla]  Cinder multiple backends

Hi folks, 

It seems that Kolla does nos provide option to enable multiple backends in 
Cinder config. 

Currently in my deploy/setup I needed enable the Storwize Cinder driver - 
http://docs.openstack.org/mitaka/config-reference/block-storage/drivers/ibm-storwize-svc-driver.html
 - 
and to this I added into /etc/kolla/config/cinder.conf my configs 

  [DEFAULT] 
  default_volume_type = ibm 

  [ibm] 
  
volume_driver=cinder.volume.drivers.ibm.storwize_svc.storwize_svc_fc.StorwizeSVCFCDriver
 
  san_ip=xxx.xx.xx.xx 
  san_login=superuser 
  san_password=mypass 
  san_ssh_port=22 
  storwize_svc_volpool_name=myPool 
  volume_backend_name=ibm 
  verbose = True 
  debug = True 


And I changed manually the file 
/var/src/kolla-master/ansible/roles/cinder/templates/cinder.conf.j2 as well. 

But for the driver works correctly, it was needed install manually some 
aditional packs. 

$ apt-get install sysfsutils sg3-utils on cinder-volume container 
$ apt-get install multipath-tools sysfsutils on nova-compute container

Is there any doc/spec to create a automatic process for this ? Could someone 
give us details how is the best way to make it "automatized" !? 



Best regards, 

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

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

[openstack-dev] [puppet] weekly meeting #86

[Emilien Macchi]

Hi Puppeteers!

We'll have our weekly meeting tomorrow at 3pm UTC on
#openstack-meeting-4.

Here's a first agenda:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160621

Feel free to add more topics, and any outstanding bug and patch.

See you tomorrow!
Thanks,
-- 
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] [kolla] Cinder multiple backends

[Michał Jastrzębski]

Right now you can install it by providing --include-header file during
build. We are working on cleaner mechanism in Newton [1].

[1] https://review.openstack.org/#/q/topic:bp/third-party-plugin-support

On 20 June 2016 at 08:29, Carlos Cesario  wrote:
> Hi folks,
>
> It seems that Kolla does nos provide option to enable multiple backends in 
> Cinder config.
>
> Currently in my deploy/setup I needed enable the Storwize Cinder driver - 
> http://docs.openstack.org/mitaka/config-reference/block-storage/drivers/ibm-storwize-svc-driver.html
>  -
> and to this I added into /etc/kolla/config/cinder.conf my configs
>
>   [DEFAULT]
>   default_volume_type = ibm
>
>   [ibm]
>   
> volume_driver=cinder.volume.drivers.ibm.storwize_svc.storwize_svc_fc.StorwizeSVCFCDriver
>   san_ip=xxx.xx.xx.xx
>   san_login=superuser
>   san_password=mypass
>   san_ssh_port=22
>   storwize_svc_volpool_name=myPool
>   volume_backend_name=ibm
>   verbose = True
>   debug = True
>
>
> And I changed manually the file 
> /var/src/kolla-master/ansible/roles/cinder/templates/cinder.conf.j2 as well.
>
> But for the driver works correctly, it was needed install manually some 
> aditional packs.
>
> $ apt-get install sysfsutils sg3-utils on cinder-volume container
> $ apt-get install multipath-tools sysfsutils on nova-compute container
>
> Is there any doc/spec to create a automatic process for this ? Could someone 
> give us details how is the best way to make it "automatized" !?
>
>
>
> Best regards,
>
> - Carlos
> __
> OpenStack Development Mailing 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] next notification subteam meeting

[Balázs Gibizer]

Hi, 

The next notification subteam meeting will be held on 2016.06.21 17:00 UTC [1] 
on #openstack-meeting-4.

Cheers,
Gibi

[1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20160621T17

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

[openstack-dev] [kolla] Cinder multiple backends

[Carlos Cesario]

Hi folks, 

It seems that Kolla does nos provide option to enable multiple backends in 
Cinder config. 

Currently in my deploy/setup I needed enable the Storwize Cinder driver - 
http://docs.openstack.org/mitaka/config-reference/block-storage/drivers/ibm-storwize-svc-driver.html
 - 
and to this I added into /etc/kolla/config/cinder.conf my configs 

  [DEFAULT] 
  default_volume_type = ibm 

  [ibm] 
  
volume_driver=cinder.volume.drivers.ibm.storwize_svc.storwize_svc_fc.StorwizeSVCFCDriver
 
  san_ip=xxx.xx.xx.xx 
  san_login=superuser 
  san_password=mypass 
  san_ssh_port=22 
  storwize_svc_volpool_name=myPool 
  volume_backend_name=ibm 
  verbose = True 
  debug = True 


And I changed manually the file 
/var/src/kolla-master/ansible/roles/cinder/templates/cinder.conf.j2 as well. 

But for the driver works correctly, it was needed install manually some 
aditional packs. 

$ apt-get install sysfsutils sg3-utils on cinder-volume container 
$ apt-get install multipath-tools sysfsutils on nova-compute container

Is there any doc/spec to create a automatic process for this ? Could someone 
give us details how is the best way to make it "automatized" !? 



Best regards, 

- Carlos__
OpenStack Development Mailing 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] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

[Mark Voelker]

> On Jun 20, 2016, at 8:46 AM, Doug Hellmann  wrote:
> 
> Excerpts from Mark Voelker's message of 2016-06-16 20:33:36 +:
> 
>> On Tue, Jun 14, 2016 at 05:42:16PM -0400, Doug Hellmann wrote:
>> 
>> 
>>> I don't think DefCore actually needs to change old versions of Tempest,
>>> but maybe Chris or Mark can verify that?
>> 
>> So if I’m groking this correctly, there’s kind of two scenarios
>> being painted here.  One is the “LCD” approach where we use the
>> $osversion-eol version of Tempest, where $osversion matches the
>> oldest version covered in a Guideline.  The other is to use the
>> start-of-$osversion version of Tempest where $osversion is the
>> OpenStack version after the most recent one in the Guideline.  The
>> former may result in some fairly long-lived flags, and the latter
>> is actually not terribly different than what we do today I think.
>> Let me try to talk through both...
>> 
>> In some cases, tests get flagged in the Guidelines because of
>> bugs in the test or because the test needs refactoring.  The
>> underlying Capabilities the those tests are testing actually work
>> fine.  Once we identify such an issue, the test can be fixed…in
>> master.  Under the first scenario, this potentially creates some
>> very long-lived flags:
>> 
>> 2016.01 is the most current Guideline right now covers Juno, Kilo,
>> Liberty (and Mitaka after it was released).  It’s one of the two
>> Guidelines that you can use if you want an OpenStack Powered license
>> from he Foundation, $vendor wants to run it against their shiny new
>> Mitaka cloud.  They run the Juno EOL version of Tempest (tag=8),
>> they find a test issue, and we flag it.  A few weeks later, a fix
>> lands in Tempest.  Several months later the next Guideline rolls
>> around: the oldest covered release is Kilo and we start telling
>> people to use the Kilo-EOL version of Tempest.  That doesn’t have
>> the fix, so the flag stays.  Another six months goes by and we get
>> a Guideline and we’re up to the Liberty-EOL version of Tempest.  No
>> fix, flag stays.  Six more months, and now we’re at Mitaka-EOL, and
>> that's the first version that includes the fix.
>> 
>> Generally speaking long lived flags aren’t so great because it
>> means the tests are not required…which means there’s less or no
>> assurance that the capabilities they test for actually work in the
>> clouds that adhere to those Guidelines.  So, the worst-case scenario
>> here looks kind of ugly.
>> 
>> As Matt correctly pointed out though, the capabilities DefCore
>> selects for are generally pretty stable API’s that are long-lived
>> across many releases, so we haven’t run into a lot of issues running
>> pretty new versions of Tempest against older clouds to date.  In
>> fact I’m struggling to think of a time we’ve flagged something
>> because someone complained the test wasn’t runnable against an older
>> release covered by the Guideline in question.  I can think of plenty
>> of times where we’ve flagged something due to a test issue though…keep
>> in mind we’re still in pretty formative times with DefCore here
>> where these tests are starting to be used in a new way for the first
>> time.  Anyway, as Matt points out we could potentially use a much
>> newer Tempest tag: tag=11 (which is the start of Newton development
>> and is a roughly 2 month old version of Tempest).  Next Guideline
>> rolls around, we use the tag for start-of-ocata, and we get the fix
>> and can drop the flag.
>> 
>> Today, RefStack client by default checks out a specific SHA of
>> Tempest [1] (it actually did use a tag at some point in the past,
>> and still can).  When we see a fix for a flagged test go in, we or
>> the Refstack folks can do a quick test to make sure everything’s
>> in order and then update that SHA to match the version with the
>> fix.  That way we’re relatively sure we have a version that works
>> today, and will work when we drop the flag in the next Guideline
>> too.  When we finalize that next Guideline, we also update the
>> test-repositories section of the new Guideline that Matt pointed
>> to earlier to reflect the best-known version on the day the Guideline
>> was sent to the Board for approval.  One added benefit of this
>> approach is that people running the tests today may get a version
>> of Tempest that includes a fix for a flagged test.  A flagged test
>> isn’t required, but it does get run—and now will show a passing
>> result, so we have data that says “this provider actually does
>> support this capability (even though it’s flagged), and the test
>> does indeed seem to be working."
>> 
>> 
>> So, that’s actually not hugely different from the second scenario
>> I think?  Or did I miss something there?
> 
> What I was proposing is that we keep the certification rules in
> sync with OpenStack versions. If a vendor stays on an old version
> of OpenStack, they can keep using the old (matching) version of
> Tempest to certify.  It's not clear from 

Re: [openstack-dev] [requirements][all] VOTE to expand the Requirements Team

[Davanum Srinivas]

Thanks for the VOTE everyone.

Matthew, Dirk, Swapnil, Tony, Thomas,
With this VOTE the training wheels come off :) Please be cautious with
your new super powers!

And thanks a Ton to Thierry as well.

Thanks,
Dims

On Fri, Jun 17, 2016 at 3:59 PM, Robert Collins
 wrote:
> Sure. +1
>
> On 17 June 2016 at 02:44, Davanum Srinivas  wrote:
>> Folks,
>>
>> At Austin the Release Management team reached a consensus to spin off
>> with some new volunteers to take care of the requirements process and
>> repository [1]. The following folks showed up and worked with me on
>> getting familiar with the issues/problems/tasks (see [1] and [2]) and
>> help with the day to day work.
>>
>> Matthew Thode (prometheanfire)
>> Dirk Mueller (dirk)
>> Swapnil Kulkarni (coolsvap)
>> Tony Breeds (tonyb)
>> Thomas Bechtold (tbechtold)
>>
>> So, please cast your VOTE to grant them +2/core rights on the
>> requirements repository and keep up the good work w.r.t speeding up
>> reviews, making sure new requirements don't break etc.
>>
>> Also, please note that Thierry has been happy enough with our work to
>> step down from core responsibilities :) Many thanks Thierry for
>> helping with this effort and guidance. I'll make all the add/remove to
>> the requirements-core team when this VOTE passes.
>>
>> Thanks,
>> Dims
>>
>> [1] https://etherpad.openstack.org/p/newton-relmgt-plan
>> [2] https://etherpad.openstack.org/p/requirements-tasks
>> [3] https://etherpad.openstack.org/p/requirements-cruft
>>
>> --
>> 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



-- 
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] [requirements][all] VOTE to expand the Requirements Team

[Sean Dague]

On 06/16/2016 10:44 AM, Davanum Srinivas wrote:
> Folks,
> 
> At Austin the Release Management team reached a consensus to spin off
> with some new volunteers to take care of the requirements process and
> repository [1]. The following folks showed up and worked with me on
> getting familiar with the issues/problems/tasks (see [1] and [2]) and
> help with the day to day work.
> 
> Matthew Thode (prometheanfire)
> Dirk Mueller (dirk)
> Swapnil Kulkarni (coolsvap)
> Tony Breeds (tonyb)
> Thomas Bechtold (tbechtold)
> 
> So, please cast your VOTE to grant them +2/core rights on the
> requirements repository and keep up the good work w.r.t speeding up
> reviews, making sure new requirements don't break etc.
> 
> Also, please note that Thierry has been happy enough with our work to
> step down from core responsibilities :) Many thanks Thierry for
> helping with this effort and guidance. I'll make all the add/remove to
> the requirements-core team when this VOTE passes.

+1



-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [OpenStack-Infra] There is no Jenkins, only Zuul

[Monty Taylor]

On 06/20/2016 06:47 AM, Marek Zawadzki wrote:
> Are 3d party CIs affected by this change and if yes how?
> What's the recommendation for newly created 3rd party CIs - should they
> use new zuul only or it's fine to use existing (and tested) jenkins+zuul
> configuration?

3rd party should not be affected. Gerrit event stream and reporting
interface remain the same. People should continue using jenkins+zuul as
they currently do. We'll have a full zuul v3 release coming in a few
months where we'll start suggesting 3rd party folks migrate - but even
then it'll be an option as you decide you'd like to.

> Second question - if jobs are to be launched by zuul+ansible, how will
> the worker host be chosen, by ansible-launcher? (normally as I
> understand Jenkins master takes care of deciding which hosts are free to
> run jobs)
> Are there any specs about way of managing workers (adding/removing,
> setting # of executors)?

Yes, ansible-launcher takes care of this. We haven't spent too much time
on more advanced worker management for this release, that should also
come in zuul v3. For right now we're just managing ansible-launcher
nodes as we did jenkins masters before.


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

Re: [openstack-dev] [OpenStack-Infra] There is no Jenkins, only Zuul

[Paul Belanger]

On Mon, Jun 20, 2016 at 01:47:24PM +0200, Marek Zawadzki wrote:
> Are 3d party CIs affected by this change and if yes how?
> What's the recommendation for newly created 3rd party CIs - should they use
> new zuul only or it's fine to use existing (and tested) jenkins+zuul
> configuration?
> 
3rd party CI should not be affected by recent changes. As there interface to our
CI system is gerrit (review.openstack.org). Zuulv25 is really only meant to be
consumed by openstack-infra as a stepping stone to zuulv3. At this time I would
not recommend people update their CI systems to consume it.

> Second question - if jobs are to be launched by zuul+ansible, how will the
> worker host be chosen, by ansible-launcher? (normally as I understand
> Jenkins master takes care of deciding which hosts are free to run jobs)
> Are there any specs about way of managing workers (adding/removing, setting
> # of executors)?
> 
This was and still is controlled by nodepool[1]. Even when we used jenkins,
nodepool was responsible for creating our jenkins slaves. Under zuulv25, this is
still the case except they are called zuul workers now.

[1] http://docs.openstack.org/infra/nodepool/

> Thank you.
> 
> -marek
> 
> -- 
> Marek Zawadzki
> Mirantis Containerized Control Plane Team
> 
> 
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

__
OpenStack Development Mailing 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] Question about redundant API samples tests for microversions

[Jay Pipes]

On 06/20/2016 08:24 AM, Sean Dague wrote:

Honestly, I feel like subclassing tests is almost always an
anti-pattern. It looks like you are saving code up front, but it
massively couples things in ways that become super hard to deal with in
the future.

Test code doesn't need to be normalized to within an inch of it's life.


Amen.

-jay

__
OpenStack Development Mailing 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] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

[Doug Hellmann]

Excerpts from Mark Voelker's message of 2016-06-16 20:33:36 +:

> On Tue, Jun 14, 2016 at 05:42:16PM -0400, Doug Hellmann wrote:
> 
> 
> > I don't think DefCore actually needs to change old versions of Tempest,
> > but maybe Chris or Mark can verify that?
> 
> So if I’m groking this correctly, there’s kind of two scenarios
> being painted here.  One is the “LCD” approach where we use the
> $osversion-eol version of Tempest, where $osversion matches the
> oldest version covered in a Guideline.  The other is to use the
> start-of-$osversion version of Tempest where $osversion is the
> OpenStack version after the most recent one in the Guideline.  The
> former may result in some fairly long-lived flags, and the latter
> is actually not terribly different than what we do today I think.
> Let me try to talk through both...
> 
> In some cases, tests get flagged in the Guidelines because of
> bugs in the test or because the test needs refactoring.  The
> underlying Capabilities the those tests are testing actually work
> fine.  Once we identify such an issue, the test can be fixed…in
> master.  Under the first scenario, this potentially creates some
> very long-lived flags:
> 
> 2016.01 is the most current Guideline right now covers Juno, Kilo,
> Liberty (and Mitaka after it was released).  It’s one of the two
> Guidelines that you can use if you want an OpenStack Powered license
> from he Foundation, $vendor wants to run it against their shiny new
> Mitaka cloud.  They run the Juno EOL version of Tempest (tag=8),
> they find a test issue, and we flag it.  A few weeks later, a fix
> lands in Tempest.  Several months later the next Guideline rolls
> around: the oldest covered release is Kilo and we start telling
> people to use the Kilo-EOL version of Tempest.  That doesn’t have
> the fix, so the flag stays.  Another six months goes by and we get
> a Guideline and we’re up to the Liberty-EOL version of Tempest.  No
> fix, flag stays.  Six more months, and now we’re at Mitaka-EOL, and
> that's the first version that includes the fix.
>
> Generally speaking long lived flags aren’t so great because it
> means the tests are not required…which means there’s less or no
> assurance that the capabilities they test for actually work in the
> clouds that adhere to those Guidelines.  So, the worst-case scenario
> here looks kind of ugly.
> 
> As Matt correctly pointed out though, the capabilities DefCore
> selects for are generally pretty stable API’s that are long-lived
> across many releases, so we haven’t run into a lot of issues running
> pretty new versions of Tempest against older clouds to date.  In
> fact I’m struggling to think of a time we’ve flagged something
> because someone complained the test wasn’t runnable against an older
> release covered by the Guideline in question.  I can think of plenty
> of times where we’ve flagged something due to a test issue though…keep
> in mind we’re still in pretty formative times with DefCore here
> where these tests are starting to be used in a new way for the first
> time.  Anyway, as Matt points out we could potentially use a much
> newer Tempest tag: tag=11 (which is the start of Newton development
> and is a roughly 2 month old version of Tempest).  Next Guideline
> rolls around, we use the tag for start-of-ocata, and we get the fix
> and can drop the flag.
> 
> Today, RefStack client by default checks out a specific SHA of
> Tempest [1] (it actually did use a tag at some point in the past,
> and still can).  When we see a fix for a flagged test go in, we or
> the Refstack folks can do a quick test to make sure everything’s
> in order and then update that SHA to match the version with the
> fix.  That way we’re relatively sure we have a version that works
> today, and will work when we drop the flag in the next Guideline
> too.  When we finalize that next Guideline, we also update the
> test-repositories section of the new Guideline that Matt pointed
> to earlier to reflect the best-known version on the day the Guideline
> was sent to the Board for approval.  One added benefit of this
> approach is that people running the tests today may get a version
> of Tempest that includes a fix for a flagged test.  A flagged test
> isn’t required, but it does get run—and now will show a passing
> result, so we have data that says “this provider actually does
> support this capability (even though it’s flagged), and the test
> does indeed seem to be working."
> 
> 
> So, that’s actually not hugely different from the second scenario
> I think?  Or did I miss something there?

What I was proposing is that we keep the certification rules in
sync with OpenStack versions. If a vendor stays on an old version
of OpenStack, they can keep using the old (matching) version of
Tempest to certify.  It's not clear from your description if that's
allowed now.

We would want to expose the version of OpenStack, the version of
Tempest, any flagged tests, and any configuration settings that
change 

Re: [openstack-dev] Version header for OpenStack microversion support

[Sean Dague]

On 06/18/2016 06:32 AM, Jamie Lennox wrote:
> Quick question: why do we need the service type or name in there? You
> really should know what API you're talking to already and it's just
> something that makes it more difficult to handle all the different APIs
> in a common way.

It is also extremely useful in wire interactions to be explicit so that
you know for sure you are interacting with the thing you think you are.
There was also the potential question of compound API operations (a Nova
call that calls other microversioned services that may impact
representation) and whether that may need to be surfaced to the user.
For instance network portions of the 'servers' object may get impacted
by Neutron.

With all those possibilities, putting in the extra ~8 bytes to handle
contingencies seemed prudent.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [smaug] Smaug Weekly IRC Meeting - Tuesday May 21st

[Yuval Brik]

Hello all,


Our weekly IRC meeting will take place tomorrow (Tuesday, May 21st) at 09:00 
UTC in #openstack-meeting

Please review the proposed meeting agenda here: 
https://wiki.openstack.org/wiki/Meetings/smaug

Feel free to add to the agenda any subject you would like to discuss.


--Yuval
-
This email and any files transmitted and/or attachments with it are 
confidential and proprietary information of
Toga Networks Ltd., and intended solely for the use of the individual or entity 
to whom they are addressed.
If you have received this email in error please notify the system manager. This 
message contains confidential
information of Toga Networks Ltd., and is intended only for the individual 
named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on
the contents of this information is strictly prohibited.



__
OpenStack Development Mailing 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][ovs] The way we deal with MTU

[Ihar Hrachyshka]

> On 15 Jun 2016, at 17:27, Ihar Hrachyshka  wrote:
> 
> First, some context: we talked it thru with Eugene on IRC, and Eugene 
> reported that he cannot reproduce the issue on his setup using Ubuntu 
> hypervisor with ovs 2.4:
> 
> http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-06-13.log.html#t2016-06-13T19:45:22
> 
> So I went and did some testing with the functional test I have implemented. I 
> validated the following setups:
> 
> - ubuntu 14.04 + ovs 2.0.x
> - centos 7 + ovs 2.4
> - centos 7 + ovs 2.5
> 
> All of them fail to pass the test. I also pushed the test without the fix 
> into gate, and it failed too:
> 
> https://review.openstack.org/329558
> 
> So we definitely have some sort of issue that is independent of underlying 
> distribution or Open vSwitch.
> 
> With that, I believe we should go forward with the fix as a short term 
> solution: https://review.openstack.org/327651 (I removed WIP from it.)

The patch landed in master, and I seek to backport it to Liberty/Mitaka 
(backports proposed).

> 
> I will also reach ovs developers on the matter to see if they can somehow 
> allow us to disable the mtu curtailing, and still stay supported.

I dropped an email to d...@openvswitch.org just now: 
http://openvswitch.org/pipermail/dev/2016-June/073190.html to seek their 
guidance.

> 
> Ihar
> 
>> On 13 Jun 2016, at 19:43, Eugene Nikanorov  wrote:
>> 
>> That's interesting.
>> 
>> 
>> In our deployments we do something like br-ex (linux bridge, mtu 9000) - 
>> OVSIntPort (mtu 65000) - br-floating (ovs bridge, mtu 1500) - br-int (ovs 
>> bridge, mtu 1500).
>> qgs then are getting created in br-int, traffic goes all the way and that 
>> altogether allows jumbo frames over external network.
>> 
>> For that reason I thought that mtu inside OVS doesn't really matter. 
>> This, however is for ovs 2.4.1
>> 
>> I wonder if that behavior has changed and if the description is available 
>> anywhere.
>> 
>> Thanks,
>> Eugene.
>> 
>> On Mon, Jun 13, 2016 at 9:49 AM, Ihar Hrachyshka  wrote:
>> Hi all,
>> 
>> in Mitaka, we introduced a bunch of changes to the way we handle MTU in 
>> Neutron/Nova, making sure that the whole instance data path, starting from 
>> instance internal interface, thru hybrid bridge, into the br-int; as well as 
>> router data path (qr) have proper MTU value set on all participating 
>> devices. On hypervisor side, both Nova and Neutron take part in it, setting 
>> it with ip-link tool based on what Neutron plugin calculates for us. So far 
>> so good.
>> 
>> Turns out that for OVS, it does not work as expected in regards to br-int. 
>> There was a bug reported lately: https://launchpad.net/bugs/1590397
>> 
>> Briefly, when we try to set MTU on a device that is plugged into a bridge, 
>> and if the bridge already has another port with lower MTU, the bridge itself 
>> inherits MTU from that latter port, and Linux kernel (?) does not allow to 
>> set MTU on the first device at all, making ip link calls ineffective.
>> 
>> AFAIU this behaviour is consistent with Linux bridging rules: you can’t have 
>> ports of different MTU plugged into the same bridge.
>> 
>> Now, that’s a huge problem for Neutron, because we plug ports that belong to 
>> different networks (and that hence may have different MTUs) into the same 
>> br-int bridge.
>> 
>> So I played with the code locally a bit and spotted that currently, we set 
>> MTU for router ports before we move their devices into router namespaces. 
>> And once the device is in a namespace, ip-link actually works. So I wrote a 
>> fix with a functional test that proves the point: 
>> https://review.openstack.org/#/c/327651/ The fix was validated by the 
>> reporter of the original bug and seems to fix the issue for him.
>> 
>> It’s suspicious that it works from inside a namespace but not when the 
>> device is still in the root namespace. So I reached out to Jiri Benc from 
>> our local Open vSwitch team, and here is a quote:
>> 
>> ===
>> 
>> "It's a bug in ovs-vswitchd. It doesn't see the interface that's in
>> other netns and thus cannot enforce the correct MTU.
>> 
>> We'll hopefully fix it and disallow incorrect MTU setting even across
>> namespaces. However, it requires significant effort and rework of ovs
>> name space handling.
>> 
>> You should not depend on the current buggy behavior. Don't set MTU of
>> the internal interfaces higher than the rest of the bridge, it's not
>> supported. Hacking this around by moving the interface to a netns is
>> exploiting of a bug.
>> 
>> We can certainly discuss whether this limitation could be relaxed.
>> Honestly, I don't know, it's for a discussion upstream. But as of now,
>> it's not supported and you should not do it.”
>> 
>> So basically, as long as we try to plug ports with different MTUs into the 
>> same bridge, we are utilizing a bug in Open vSwitch, that may break us any 
>> time.
>> 

Re: [openstack-dev] [nova] Question about redundant API samples tests for microversions

[Sean Dague]

On 06/17/2016 04:16 PM, Matt Riedemann wrote:
> I was reviewing this today:
> 
> https://review.openstack.org/#/c/326940/
> 
> And I said to myself, 'self, do we really need to subclass the API
> samples functional tests for this microversion given this change doesn't
> modify the request/response body, it's only adding paging support?'.
> 
> https://review.openstack.org/#/c/326940/6/nova/tests/functional/api_sample_tests/test_hypervisors.py
> 
> 
> The only change here is listing hypervisors, and being able to page on
> those if the microversion is high enough. So the API samples don't
> change at all, they are just running against a different microversion.

Agree. If the samples are the same, I think we shouldn't have that extra
set of tests, and just test the interesting surface. I think part of the
confusion in the code is also that the subclassing to run tests with
different scenarios pattern exists a lot of places, and we use
testscenarios explicitly other places.

> 
> The same goes for the REST API unit tests really:
> 
> https://review.openstack.org/#/c/326940/6/nova/tests/unit/api/openstack/compute/test_hypervisors.py
> 
> 
> I'm not sure if the test subclassing is just done like this for new
> microversions because it's convenient or if it's because of regression
> testing - knowing that we aren't changing a bunch of other REST methods
> in the process, so the subclassed tests aren't testing anything
> different from the microversion that came before them.
> 
> The thing I don't like about the test subclassing is all of the
> redundant testing that goes on, and people might add tests to the parent
> class not realizing it's subclassed and thus duplicating test cases with
> no functional change.
> 
> Am I just having some Friday crazies? Ultimately this doesn't hurt
> anything really but thought I'd ask.

Honestly, I feel like subclassing tests is almost always an
anti-pattern. It looks like you are saving code up front, but it
massively couples things in ways that become super hard to deal with in
the future.

Test code doesn't need to be normalized to within an inch of it's life.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

[Sean Dague]

On 06/14/2016 07:19 PM, Chris Hoge wrote:
> 
>> On Jun 14, 2016, at 3:59 PM, Edward Leafe  wrote:
>>
>> On Jun 14, 2016, at 5:50 PM, Matthew Treinish  wrote:
>>
>>> But, if we add another possible state on the defcore side like conditional 
>>> pass,
>>> warning, yellow, etc. (the name doesn't matter) which is used to indicate 
>>> that
>>> things on product X could only pass when strict validation was disabled (and
>>> be clear about where and why) then my concerns would be alleviated. I just 
>>> do
>>> not want this to end up not being visible to end users trying to evaluate
>>> interoperability of different clouds using the test results.
>>
>> +1
>>
>> Don't fail them, but don't cover up their incompatibility, either.
>> -- Ed Leafe
> 
> That’s not my proposal. My requirement is that vendors who want to do this
> state exactly which APIs are sending back additional data, and that this
> information be published.
> 
> There are different levels of incompatibility. A response with additional data
> that can be safely ignored is different from a changed response that would
> cause a client to fail.

It's actually not different. It's really not.

This idea that it's safe to add response data is based on an assumption
that software versions only move forward. If you have a single deploy of
software, that's fine.

However as noted, we've got production clouds on Juno <-> Mitaka in the
wild. Which means if we want to support horizontal transfer between
clouds, the user experienced timeline might be start on a Mitaka cloud,
then try to move to Juno. So anything added from Juno -> Mitaka without
signaling has exactly the same client breaking behavior as removing
attributes.

Which is why microversions are needed for attribute adds.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [ironic] Proposing two new cores

[Sam Betts (sambetts)]

Thanks everyone, I¹m super excited to continue my contribute to Ironic!

Sam

On 18/06/2016 16:25, "Jim Rollenhagen"  wrote:

>On Thu, Jun 16, 2016 at 11:12:31AM -0400, Jim Rollenhagen wrote:
>> Hi all,
>> 
>> I'd like to propose Jay Faulkner (JayF) and Sam Betts (sambetts) for the
>> ironic-core team.
>> 
>> Jay has been in the community as long as I have, has been IPA and
>> ironic-specs core for quite some time. His background is operations, and
>> he's getting good with Python. He's given great reviews for quite a
>> while now, and the number is steadily increasing. I think it's a
>> no-brainer.
>> 
>> Sam has been in the ironic community for quite some time as well, with
>> close ties to the neutron community as well. His background seems to be
>> in networking, he's got great python skills as well. His reviews are
>> super useful. He doesn't have quite as many as some people, but they are
>> always thoughtful, and he often catches things others don't. I do hope
>> to see more of his reviews.
>> 
>> Both Sam and Jay are to the point where I consider their +1 or -1 as
>> highly as any other core, so I think it's past time to allow them to +2
>> as well.
>> 
>> Current cores, please reply with your vote.
>
>9 out of 11 sounds like consensus to me. Welcome to the team, Jay and
>Sam! :)
>
>ironic-core membership:
>https://review.openstack.org/#/admin/groups/165,members
>
>As a note, the IPA core team was ironic-core plus Jay and Josh. We
>apparently forgot to remove Josh's core rights from IPA when he stopped
>working on ironic, so I've done that. Now that Jay is in ironic-core,
>I've consolidated things such that ironic-core is the review team for
>IPA.
>
>Patch for the IPA change is here: https://review.openstack.org/331425
>
>ironic-python-agent-core membership:
>https://review.openstack.org/#/admin/groups/307,members
>
>// jim
>
>> 
>> // jim
>> 
>> 
>>_
>>_
>> OpenStack Development Mailing 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] [OpenStack-Infra] There is no Jenkins, only Zuul

[Marek Zawadzki]

Are 3d party CIs affected by this change and if yes how?
What's the recommendation for newly created 3rd party CIs - should they 
use new zuul only or it's fine to use existing (and tested) jenkins+zuul 
configuration?


Second question - if jobs are to be launched by zuul+ansible, how will 
the worker host be chosen, by ansible-launcher? (normally as I 
understand Jenkins master takes care of deciding which hosts are free to 
run jobs)
Are there any specs about way of managing workers (adding/removing, 
setting # of executors)?


Thank you.

-marek

--
Marek Zawadzki
Mirantis Containerized Control Plane Team


__
OpenStack Development Mailing 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] [tacker] Proposing Kanagaraj Manickam to Tacker core team

[Sridhar Ramaswamy]

Thanks for the responses, I'm closing the vote.

Kanagaraj - welcome to the Tacker core team!

On Sun, Jun 19, 2016 at 7:25 PM, bharath thiruveedula <
bharath_...@hotmail.com> wrote:

> +1
> --
> To: openstack-dev@lists.openstack.org
> From: bob.haddle...@nokia.com
> Date: Fri, 17 Jun 2016 12:12:13 -0500
>
> Subject: Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to
> Tacker core team
>
> +1.  Kanagaraj will be a great addition to the team.
>
> Bob
>
> On 6/16/2016 1:45 PM, Karthik Natarajan wrote:
>
> +1. Thanks Kanagaraj for making such a great impact during the Newton
> cycle.
>
>
>
> *From:* Sripriya Seetharam [mailto:ssee...@brocade.com
> ]
> *Sent:* Thursday, June 16, 2016 10:35 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
>  
> *Subject:* Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to
> Tacker core team
>
>
>
> +1
>
>
>
>
>
> -Sripriya
>
>
>
>
>
> *From:* Sridhar Ramaswamy [mailto:sric...@gmail.com ]
> *Sent:* Wednesday, June 15, 2016 6:32 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [tacker] Proposing Kanagaraj Manickam to
> Tacker core team
>
>
>
> Tackers,
>
> It gives me great pleasure to propose Kanagaraj Manickam to join the
> Tacker core team. In a short time, Kanagaraj has grown into a key member of
> the Tacker team. His enthusiasm and dedication to get Tacker code base on
> par with other leading OpenStack projects is very much appreciated. He is
> already working on two important specs in Newton cycle and many more fixes
> and RFEs [1]. Kanagaraj is also a core member in the Heat project and this
> lends well as we heavily use Heat for many Tacker features.
>
> Please provide your +1/-1 votes.
>
> - Sridhar
>
> [1]
> http://stackalytics.com/?module=tacker-group_id=kanagaraj-manickam=marks
> 
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions) Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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][taas] making a taas release for mitaka or not

[Takashi Yamamoto]

hi,

we tap-as-a-service project had a plan to make a release compatible with mitaka.
however,
- it's a bit late for mitaka already
- the reference implementation needs to be adapted to l2 agent
extension but no much progress yet

so, a question is, if we still want to make a release for mitaka,
or it's better for the project to re-target to newton.
how do you think?

note: this topic was briefly discussed in the recent weekly meetings
but moved to ML due to the lack of quorum.

note: networking-midonet still wants to have the taas functionality for mitaka.
but it involves a non-trivial change in taas. [1]

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

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

Re: [openstack-dev] [manila]: questions on update-access() changes

[Ramana Raja]

On June 18, 2016 1:47:10 AM Ben Swartzlander  wrote:

> Ramana, I think your questions got answered in a channel discussion last
> week, but I just wanted to double check that you weren't still expecting
> any answers here. If you were, please reply and we'll keep this thread going.

Thanks, Ben. Are you referring to this discussion,
http://eavesdrop.openstack.org/irclogs/%23openstack-manila/%23openstack-manila.2016-06-06.log.html#t2016-06-06T17:15:43,
among John, Tom and you? Yes, I followed the above one, and
it concluded that I can proceed with my work and need not worry about
the approaches of changes a) and c).

-Ramana

> 
> 
> On June 2, 2016 9:30:39 AM Ramana Raja  wrote:
> 
> > Hi,
> >
> > There are a few changes that seem to be lined up for Newton to make
> > manila's
> > share access control, update_access(), workflow better [1] --
> > reduce races in DB updates, avoid non-atomic state transitions, and
> > possibly enable the workflow fit in a HA active-active manila
> > configuration (if not already possible).
> >
> > The proposed changes ...
> >
> > a) Switch back to per rule access state (from per share access state) to
> >avoid non-atomic state transition.
> >
> >Understood problem, but no spec or BP yet.
> >
> >
> > b) Use Tooz [2] (with Zookeeper?) for distributed lock management [3]
> >in the access control workflow.
> >
> >Still under investigation and for now fits the share replication
> >workflow [4].
> >
> >
> > c) Allow drivers to update DB models in a restricted manner (only certain
> >fields can be updated by a driver API).
> >
> >This topic is being actively discussed in the community, and there
> >should be
> >a consensus soon on figuring out the right approach, following which
> >there
> >might be a BP/spec targeted for Newton.
> >
> >
> > Besides these changes, there's a update_access() change that I'd like to
> > revive
> > (started in Mitaka), storing access keys (auth secrets) generated by a
> > storage
> > backend when providing share access, i.e.  during update_access(), in the
> > ``share_access_map`` table [5]. This change as you might have figured is a
> > smaller and a simpler change than the rest, but seems to depend on the
> > approaches
> > that might be adopted by a) and c).
> >
> > For now, I'm thinking of allowing a driver's update access()  to return a
> > dictionary of {access_id: access_key, ...} to (ShareManager)access_helper's
> > update_access(), which would then update the DB iteratively with access_key
> > per access_id. Would this approach be valid with changes a) and c) in
> > Newton? change a) would make the driver report access status per rule via
> > the access_helper, during which an 'access_key' can also be returned,
> > change c) might allow the driver to directly update the `access_key` in the
> > DB.
> >
> > For now, should I proceed with implementing the approach currently outlined
> > in my spec [5], have the driver's update_access() return a dictionary of
> > {access_id: access_key, ...} or wait for approaches for changes a) and c)
> > to be outlined better?
> >
> > Thanks,
> > Ramana
> >
> > [1] https://etherpad.openstack.org/p/newton-manila-update-access
> >
> > [2]
> > https://blueprints.launchpad.net/openstack/?searchtext=distributed-locking-with-tooz
> >
> > [3]
> > https://review.openstack.org/#/c/209661/38/specs/chronicles-of-a-dlm.rst
> >
> > [4] https://review.openstack.org/#/c/318336/
> >
> > [5] https://review.openstack.org/#/c/322971/
> > 
> > http://lists.openstack.org/pipermail/openstack-dev/2015-October/077602.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
> 
> 
> 

__
OpenStack Development Mailing 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] Netconfig tasks changes

[Aleksandr Didenko]

Hi folks,

it turned out that one change has to be made in your plugins though. If
you're reusing 'netconfig' task for your custom roles, you need to remove
'configure_default_route' task from your roles (if you have it) and add
'hiera_default_route'. This is needed for proper default gateway
configuration for cases when public network is assigned on controllers
only. Here's an example of patch for plugin [0] and bug about it [1]

Regards,
Alex

[0] https://review.openstack.org/#/c/328225/2/deployment_tasks.yaml
[1] https://bugs.launchpad.net/fuel-plugins/+bug/1591117

On Tue, Jun 7, 2016 at 11:46 AM, Aleksandr Didenko 
wrote:

> Hi,
>
> you don't need to change anything in your plugin, we still have the same
> netconfig.pp task on all nodes even after bugfix.
>
> Regards,
> Alex
>
> On Tue, Jun 7, 2016 at 8:21 AM, Igor Zinovik 
> wrote:
>
>>   Hello,
>>
>> Aleksandr, one simple question: do I as a plugin developer for upcoming
>> Fuel 9.0 have
>> to worry about these network-related changes or not? HCF is approaching,
>> but patch
>> that you mentioned (342307 )
>> is still not merged. Do I need to spend time on understanding
>> it and change plugins deployment tasks
>> 
>> according to the netconfig.pp refactoring?
>>
>>
>> On 6 June 2016 at 11:12, Aleksandr Didenko  wrote:
>>
>>> Hi,
>>>
>>> a bit different patch is on review now [0]. Instead of silently
>>> replacing default gateway on the fly in netconfig.pp task it's putting new
>>> default gateway into Hiera. Thus we'll have idempotency for subsequent
>>> netconfig.pp runs even on Mongo roles. Also we'll have consistent network
>>> configuration data in Hiera which any plugin can rely on.
>>>
>>> I've built a custom ISO with this patch and run a set of custom tests on
>>> it to cover multi-role and multi-rack cases [1] plus BVT - everything
>>> worked fine.
>>>
>>> Please feel free to review and comment the patch [0].
>>>
>>> Regards,
>>> Alex
>>>
>>> [0] https://review.openstack.org/324307
>>> [1] http://paste.openstack.org/show/508319/
>>>
>>> On Wed, Jun 1, 2016 at 4:47 PM, Aleksandr Didenko >> > wrote:
>>>
 Hi,

 YAQL expressions support for task dependencies has been added to
 Nailgun [0]. So now it's possible to fix network configuration idempotency
 issue without introducing new 'netconfig' task [1]. There will be no
 problems with loops in task graph in such case (tested on multiroles,
 worked fine). When we deprecate role-based deployment (even emulated), then
 we'll be able to remove all those additional conditions from manifests and
 remove 'configure_default_route' task completely. Please feel free to
 review and comment the patch [1].

 Regards,
 Alex

 [0] https://review.openstack.org/#/c/320861/
 [1] https://review.openstack.org/#/c/322872/

 On Wed, May 25, 2016 at 10:39 AM, Simon Pasquier <
 spasqu...@mirantis.com> wrote:

> Hi Adam,
> Maybe you want to look into network templates [1]? Although the
> documentation is a bit sparse, it allows you to define flexible network
> mappings.
> BR,
> Simon
> [1]
> https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates
>
> On Wed, May 25, 2016 at 10:26 AM, Adam Heczko 
> wrote:
>
>> Thanks Alex, will experiment with it once again although AFAIR it
>> doesn't solve thing I'd like to do.
>> I'll come later to you in case of any questions.
>>
>>
>> On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko <
>> adide...@mirantis.com> wrote:
>>
>>> Hey Adam,
>>>
>>> in Fuel we have the following option (checkbox) on Network Setting
>>> tab:
>>>
>>> Assign public network to all nodes
>>> When disabled, public network will be assigned to controllers only
>>>
>>> So if you uncheck it (by default it's unchecked) then public network
>>> and 'br-ex' will exist on controllers only. Other nodes won't even have
>>> "Public" network on node interface configuration UI.
>>>
>>> Regards,
>>> Alex
>>>
>>> On Wed, May 25, 2016 at 9:43 AM, Adam Heczko 
>>> wrote:
>>>
 Hello Alex,
 I have a question about the proposed changes.
 Is it possible to introduce new vlan and associated bridge only for
 controllers?
 I think about DMZ use case and possibility to expose public IPs/VIP
 and API endpoints on controllers on a completely separate L2 network
 (segment vlan/bridge) not present on any other nodes than controllers.
 Thanks.

 On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko <

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

[Henry Nash]

Hi

So following discussion on this, I have modified the spec to try and take 
account of the various concerns etc. See: 
https://review.openstack.org/#/c/318605/

For reference, here is an extract from this spec that summarizes the level of 
compatibility being proposed (A “3.6 client” refers to a Mitaka or earlier 
client speaking either directly to keystone server, or via our client 
libraries):

Summary of Compatibility Impacts
-

Here is a summary of the impact on clients when the server they are talking to
is upgraded to Newton:

* For a 3.6 client the names of project entities created before the server
  upgrade will not change (i.e. they will not contain the path).
* For either a 3.6 or a 3.7 client, any projects entities after the server is
  upgraded will be returned with names including the path.
* A 3.6 client will continue to be able to scope an auth to a project that
  existed before the upgrade without specifying a path, wherever that project
  exists in the hierarchy. To scope to a project created after the upgrade then
  the name (by definition) includes the path.
* Code written that extracts the project name from any of the project APIs that
  returns project entities, and then plugs that name into an auth scope will
  continue to work unmodifed, irrespective of the version of the client or
  server
* A 3.7 client will always see project names that include the path,
  irrespective of whether those projects were created before or after the
  server was upgraded. The implication of this is that once a client has
  upgraded to 3.7, then if the name of the project is being entered by a user
  (say for auth scope), then this name must always contain the path. While,
  technically, we could try to maintain the ability to access projects created
  before the server upgrade via their non-path name, it would get very
  confusing for users having to remember which projects you could or couldn't
  access this way.

Feel free to raise any concerns you have about the above.

Henry

> On 14 Jun 2016, at 16:22, Morgan Fainberg  wrote:
> 
> On Jun 14, 2016 00:46, "Henry Nash"  > wrote:
> 
> 
>> On 14 Jun 2016, at 07:34, Morgan Fainberg > > wrote:
>> 
>> 
>> 
>> On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash > > wrote:
>> So, I think it depends what level of compatibility we are aiming at. Let me 
>> articulate them, and we can agree which we want:
>> 
>> C1) In all version of the our APIs today (v2 and v3.0 to v3.6), you have 
>> been able to issue an auth request which used project/tenant name as the 
>> scoping directive (with v3 you need a domain component as well, but that’s 
>> not relevant for this discussion). In these APIs, we absolutely expect that 
>> if you could issue an auth request to. say project “test”, in, say, v3.X, 
>> then you could absolutely issue the exact same command at V3.(X+1). This has 
>> remained true, even when we introduced project hierarchies, i.e.: if I 
>> create:
>> 
>> /development/myproject/test
>> 
>> ...then I can still scope directly to the test project by simply specifying 
>> “test” as the project name (since, of course, all project names must still 
>> be unique in the domain). We never want to break this for so long as we 
>> formally support any APIs that once allowed this.
>> 
>> C2) To aid you issuing an auth request scoped by project (either name or 
>> id), we support a special API as part of the auth url (GET/auth/projects) 
>> that lists the projects the caller *could* scope to (i.e. those they have 
>> any kind of role on). You can take the “name” or “id” returned by this API 
>> and plug it directly into the auth request. Again for any API we currently 
>> support, we can’t break this.
>> 
>> C3) The name attribute of a project is its node-name in the hierarchy. If we 
>> decide to change this in a future API, we would not want a client using the 
>> existing API to get surprised and suddenly receive a path instead of the 
>> just the node-name (e.g. what if this was a UI of some type). 
>> 
>> Given all the above, there is no solution that can keep the above all true 
>> and allow more than one project of the same name in, say, v3.7 of the API. 
>> Even if we relaxed C2 and C2 -  C1 can never be guaranteed to be still 
>> supported. Neither of the original proposed solutions can address this 
>> (since it is a data modelling problem, not an API problem).
>> 
>> However, given that we will have, for the first time, the ability to 
>> microversion the Identity API starting with 3.7, there are things we can do 
>> to start us down this path. Let me re-articulate the options I am proposing:
>> 
>> Option 1A) In v3.7 we add a ‘path_name' attribute to a project entity, which 
>> is hence returned by any API that returns a project 

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Denis Makogon]

Hello Clint.

I'd like to take part as well, so count me in.

Kind regards,
Denys Makogon


2016-06-20 10:23 GMT+03:00 Ghe Rivero :

> Hi all!
> I really like the idea of the group, so count me in!
>
> Ghe Rivero
>
> Quoting Clint Byrum (2016-06-17 23:52:43)
> > ar·chi·tec·ture
> > ˈärkəˌtek(t)SHər/
> > noun
> > noun: architecture
> >
> > 1.
> >
> > the art or practice of designing and constructing buildings.
> >
> > synonyms:building design, building style, planning, building,
> construction;
> >
> > formalarchitectonics
> >
> > "modern architecture"
> >
> > the style in which a building is designed or constructed, especially
> with regard to a specific period, place, or culture.
> >
> > plural noun: architectures
> >
> > "Victorian architecture"
> >
> > 2.
> >
> > the complex or carefully designed structure of something.
> >
> > "the chemical architecture of the human brain"
> >
> > the conceptual structure and logical organization of a computer or
> computer-based system.
> >
> > "a client/server architecture"
> >
> > synonyms:structure, construction, organization, layout, design,
> build, anatomy, makeup;
> >
> > informalsetup
> >
> > "the architecture of a computer system"
> >
> >
> > Introduction
> > =
> >
> > OpenStack is a big system. We have debated what it actually is [1],
> > and there are even t-shirts to poke fun at the fact that we don't have
> > good answers.
> >
> > But this isn't what any of us wants. We'd like to be able to point
> > at something and proudly tell people "This is what we designed and
> > implemented."
> >
> > And for each individual project, that is a possibility. Neutron can
> > tell you they designed how their agents and drivers work. Nova can
> > tell you that they designed the way conductors handle communication
> > with API nodes and compute nodes. But when we start talking about how
> > they interact with each other, it's clearly just a coincidental mash of
> > de-facto standards and specs that don't help anyone make decisions when
> > refactoring or adding on to the system.
> >
> > Oslo and cross-project initiatives have brought some peace and order
> > to the implementation and engineering processes, but not to the design
> > process. New ideas still start largely in the project where they are
> > needed most, and often conflict with similar decisions and ideas in other
> > projects [dlm, taskflow, tooz, service discovery, state machines, glance
> > tasks, messaging patterns, database patterns, etc. etc.]. Often times
> this
> > creates a log jam where none of the projects adopt a solution that would
> > align with others. Most of the time when things finally come to a head
> > these things get done in a piecemeal fashion, where it's half done here,
> > 1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
> > looks like  chaos, because that's precisely what it is.
> >
> > And this isn't always a technical design problem. OpenStack, for
> instance,
> > isn't really a micro service architecture. Of course, it might look like
> > that in diagrams [2], but we all know it really isn't. The compute node
> is
> > home to agents for every single concern, and the API interactions between
> > the services is too tightly woven to consider many of them functional
> > without the same lockstep version of other services together. A game to
> > play is ask yourself what would happen if a service was isolated on its
> > own island, how functional would its API be, if at all. Is this something
> > that we want? No. But there doesn't seem to be a place where we can go
> > to actually design, discuss, debate, and ratify changes that would help
> > us get to the point of gathering the necessary will and capability to
> > enact these efforts.
> >
> > Maybe nova-compute should be isolated from nova, with an API that
> > nova, cinder and neutron talk to. Maybe we should make the scheduler
> > cross-project aware and capable of scheduling more than just nova
> > instances. Maybe we should have experimental groups that can look at how
> > some of this functionality could perhaps be delegated to non-openstack
> > projects. We hear that Mesos, for example to help with the scheduling
> > aspects, but how do we discuss these outside hijacking threads on the
> > mailing list? These are things that we all discuss in the hallways
> > and bars and parties at the summit, but because they cross projects at
> > the design level, and are inherently a lot of social and technical and
> > exploratory work, Many of us fear we never get to a place of turning
> > our dreams into reality.
> >
> > So, with that, I'd like to propose the creation of an Architecture
> Working
> > Group. This group's charge would not be design by committee, but a place
> > for architects to share their designs and gain support across projects
> > to move forward with and ratify architectural decisions. That 

Re: [openstack-dev] [nova] Do we need a config option for use_usb_tablet/pointer_model?

[Sahid Orentino Ferdjaoui]

On Fri, Jun 17, 2016 at 03:36:53PM -0500, Matt Riedemann wrote:
> I was reviewing the last change in this blueprint series today:
> 
> https://review.openstack.org/#/c/174854/
> 
> And started to question why we even have a config option for this anymore.
> The blueprint didn't have a spec but there are some details in the
> description about the use cases:
> 
> https://blueprints.launchpad.net/nova/+spec/virt-configure-usb-tablet-from-image
> 
> From the code and help text for the option I realize that there is some
> per-compute enablement required for this to work (VNC or SPICE enabled and
> the SPICE agent disabled). But otherwise it seems totally image-specific,
> which is why the blueprint is adding support for calculating whether or not
> to enable USB support in the guest based on the image metadata properties.
> 
> But do we still need the configuration option then?
> 
> The tricky scenario I have in mind is I create my Windows instance on a host
> that has use_usb_table=True and I can use my USB pointer mouse and I'm
> happy, yay! Then that host goes under maintenance, the admin migrates it to
> another host that has use_usb_tablet=False and now I can't use my USB mouse
> anymore. I guess the chance of this happening are pretty slim given
> use_usb_tablet defaults to True.
> 
> However, in https://review.openstack.org/#/c/176242/ use_usb_table is
> deprecated in favor of the new 'pointer_model' config option which defaults
> to None, so it's not backward compatible with use_usb_tablet and when we
> remove use_usb_tablet as an option in Ocata, the default behavior has
> changed.

We did not wanted set a default value for pointer_model, as you
indicated before it's something more related to the guest images, we
only want give to operators ability to set a default behavior.

Also operators who use the option 'usbtablet' will be warn for an
entire release to update to pointer_model option.

> Anyway, my point is, why do we even need a config option for this at all if
> the image metadata can tell us what to do now?

I don't see any problem to let operators decide what is the hosts
default behavior.

s.

> -- 
> 
> 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] [Fuel] Nominate Ilya Kutukov for the fuel-web-core team

[Bulat Gaifullin]

Well, the agreement is reached. I added Ilya to fuel-web-core group. 

Ilya, congratulations! Will be happy to see even more thorough reviews from you!

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 08 Jun 2016, at 20:52, Bulat Gaifullin  wrote:
> 
> Hey Fuelers,
> 
> I'd like to nominate Ilya Kutukov for the fuel-web-core team.
> Ilya`s doing good reviews with detailed feedback [1],
> and has implemented custom graph execution engine for Fuel.
> Also Ilya`s implemented new database models for storing deployment tasks in 
> Fuel.
> 
> 
> Fuel Cores, please reply back with +1/-1.
> 
> [1] http://stackalytics.com/report/contribution/fuel-web/90 
> 
> 
> 
> Regards,
> Bulat Gaifullin
> 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] [nova] bugs team meeting of 2016-06-21 is cancelled

[Markus Zoeller]

Due to a conflict with a company internal appointment I have to cancel
tomorrows (2016-06-21) nova bugs team meeting. If you want to take over
the bug skimming duty for this week, please add your name in the table
at [1].

References:
[1] https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty

-- 
Regards, Markus Zoeller (markus_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

[openstack-dev] [mistral] Team meeting reminder - 06/20/2016

[Renat Akhmerov]

Hi,

This is a reminder that we’ll have a team meeting today at #openstack-meeting 
at 16.00 UTC.

Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Custom Actions API spec
Volunteers to continue?
Automated testing for OpenStack actions
How can test automatically the whole bunch of actions?
Open discussion

Feel free to join and bring up your own topics.

Renat Akhmerov
@Nokia

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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Ghe Rivero]

Hi all!
I really like the idea of the group, so count me in!

Ghe Rivero

Quoting Clint Byrum (2016-06-17 23:52:43)
> ar·chi·tec·ture
> ˈärkəˌtek(t)SHər/
> noun
> noun: architecture
> 
> 1. 
> 
> the art or practice of designing and constructing buildings.
> 
> synonyms:building design, building style, planning, building, 
> construction; 
> 
> formalarchitectonics 
> 
> "modern architecture"
> 
> the style in which a building is designed or constructed, especially with 
> regard to a specific period, place, or culture.
> 
> plural noun: architectures
> 
> "Victorian architecture"
> 
> 2. 
> 
> the complex or carefully designed structure of something.
> 
> "the chemical architecture of the human brain"
> 
> the conceptual structure and logical organization of a computer or 
> computer-based system.
> 
> "a client/server architecture"
> 
> synonyms:structure, construction, organization, layout, design, build, 
> anatomy, makeup; 
> 
> informalsetup 
> 
> "the architecture of a computer system"
> 
> 
> Introduction
> =
> 
> OpenStack is a big system. We have debated what it actually is [1],
> and there are even t-shirts to poke fun at the fact that we don't have
> good answers.
> 
> But this isn't what any of us wants. We'd like to be able to point
> at something and proudly tell people "This is what we designed and
> implemented."
> 
> And for each individual project, that is a possibility. Neutron can
> tell you they designed how their agents and drivers work. Nova can
> tell you that they designed the way conductors handle communication
> with API nodes and compute nodes. But when we start talking about how
> they interact with each other, it's clearly just a coincidental mash of
> de-facto standards and specs that don't help anyone make decisions when
> refactoring or adding on to the system.
> 
> Oslo and cross-project initiatives have brought some peace and order
> to the implementation and engineering processes, but not to the design
> process. New ideas still start largely in the project where they are
> needed most, and often conflict with similar decisions and ideas in other
> projects [dlm, taskflow, tooz, service discovery, state machines, glance
> tasks, messaging patterns, database patterns, etc. etc.]. Often times this
> creates a log jam where none of the projects adopt a solution that would
> align with others. Most of the time when things finally come to a head
> these things get done in a piecemeal fashion, where it's half done here,
> 1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
> looks like  chaos, because that's precisely what it is.
> 
> And this isn't always a technical design problem. OpenStack, for instance,
> isn't really a micro service architecture. Of course, it might look like
> that in diagrams [2], but we all know it really isn't. The compute node is
> home to agents for every single concern, and the API interactions between
> the services is too tightly woven to consider many of them functional
> without the same lockstep version of other services together. A game to
> play is ask yourself what would happen if a service was isolated on its
> own island, how functional would its API be, if at all. Is this something
> that we want? No. But there doesn't seem to be a place where we can go
> to actually design, discuss, debate, and ratify changes that would help
> us get to the point of gathering the necessary will and capability to
> enact these efforts.
> 
> Maybe nova-compute should be isolated from nova, with an API that
> nova, cinder and neutron talk to. Maybe we should make the scheduler
> cross-project aware and capable of scheduling more than just nova
> instances. Maybe we should have experimental groups that can look at how
> some of this functionality could perhaps be delegated to non-openstack
> projects. We hear that Mesos, for example to help with the scheduling
> aspects, but how do we discuss these outside hijacking threads on the
> mailing list? These are things that we all discuss in the hallways
> and bars and parties at the summit, but because they cross projects at
> the design level, and are inherently a lot of social and technical and
> exploratory work, Many of us fear we never get to a place of turning
> our dreams into reality.
> 
> So, with that, I'd like to propose the creation of an Architecture Working
> Group. This group's charge would not be design by committee, but a place
> for architects to share their designs and gain support across projects
> to move forward with and ratify architectural decisions. That includes
> coordinating exploratory work that may turn into being the base of further
> architectural decisions for OpenStack. I would expect that the people
> in this group would largely be senior at the companies involved and,
> if done correctly, they can help prioritize this work by advocating for
> people/fellow engineers to actually 

Re: [openstack-dev] [magnum] Stable/liberty functional tests

[Tony Breeds]

On Tue, Jun 14, 2016 at 01:25:14PM +, Bunting, Niall wrote:
> Hi,
> 
> 
> There was work on a patch [1] to fix the liberty stable branch. However, we 
> are running into problems with the functional tests, because the functional 
> tests were set up differently in liberty eg. The current [2] magnum.yaml 
> compared to the old one [3].
> 
> This leads us with two options to try and get stable/liberty passing the gate 
> again.
> 1. To create a 'new' test that will have the same test setup as used in 
> liberty.
> 2. To back port all the necessary changes for the tests to run successfully.
> 
> I think option one would be the better route, as that well be less likely to 
> break any stable rules. It would also have the affect of future proofing the 
> tests against any changes in the future.
> 
> I'm wondering what the rest of you think would be the best way to approach 
> this problem?

There are several jobs that do different things based on the ZUUL_BRANCH
environment variable.  Can't you do somethig like [1] to detect that you're on
liberty anc configuer things appropriately.

Yours Tony.

[1] 
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/ceilometer.yaml#L102


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