Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core

[Oleg Bondarev]

+1

On Wed, Dec 14, 2016 at 8:48 AM, Brandon Logan 
wrote:

> +1
>
> On Wed, 2016-12-14 at 02:22 +0100, Armando M. wrote:
>
> Hi folks,
>
> Abhishek Raut's recent involvement in OSC and python-neutronclient has
> helped moving a few efforts along in the right direction. I would like to
> suggest we double down on core firepower for the neutronclient repo
> alongside Akihiro [1].
>
> This not only will help speed up our transition to OSC CLI, but also
> improve the number of folks who can effectively liasion with the OSC team,
> and look after the needs of neutron's client repo.
>
> Many thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/410485/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle]agenda of weekly meeting Dec.14

[joehuang]

Hello, team,

Agenda of Dec.14 weekly meeting:

  1.  VxLAN L2 networking across Neutron feature
  2.  Ocata feature development review
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

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

Re: [openstack-dev] [Release-job-failures] Release of openstack/glance failed

[Tony Breeds]

On Mon, Dec 12, 2016 at 09:46:54AM -0600, Ian Cordasco wrote:
>  
> 
> -Original Message-
> From: Andreas Jaeger 
> Reply: OpenStack Development Mailing List (not for usage questions) 
> 
> Date: December 12, 2016 at 01:39:17
> To: openstack-dev@lists.openstack.org 
> Subject:  Re: [openstack-dev] [Release-job-failures] Release of 
> openstack/glance failed
> 
> > On 2016-12-12 08:34, Andreas Jaeger wrote:
> > > On 2016-12-12 06:20, Tony Breeds wrote:
> > >> On Mon, Dec 12, 2016 at 04:44:18AM +, jenk...@openstack.org wrote:
> > >>> Build failed.
> > >>>
> > >>> - glance-docs-ubuntu-xenial 
> > >>> http://logs.openstack.org/38/38f199507aff8bfcaf81ad9ea58ea326224faf5f/release/glance-docs-ubuntu-xenial/de7d73e/
> > >>>   
> > : FAILURE in 1m 44s
> > >>
> > >> This boils down to [1] which is a known problem with newer cryptography 
> > >> (and
> > >> the interaction with openssl). What I don't understand is how we got 
> > >> there
> > >> with constratints working[2]. Perhaps it's the openssl on the release 
> > >> sigining
> > >> node is "newer" than general nodepool nodes?
> > >
> > > glance does not use constraints in venv environment.
> > >
> > > It can be used since a few months. I'll send a change for master,
> >  
> > I expect this needs backporting to stable branches - stable or glance
> > team, please review and backport yourself:
> >  
> > https://review.openstack.org/409642
> 
> 
> Thank you Andreas!

https://review.openstack.org/#/c/410536 is the backport but it's still failing 
with the same
issue with cryptography and openssl[1] :(

Yours Tony.
[1] 
http://logs.openstack.org/36/410536/1/check/gate-glance-releasenotes/46c2615/console.html#_2016-12-14_05_13_53_002878


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

Re: [openstack-dev] [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

[Steve Gordon]

- Original Message -
> From: "Steve Gordon" 
> To: "David Moreau Simard" 
> Cc: "OpenStack Development Mailing List (not for usage questions)" 
> , "OpenStack
> Operators" 
> Sent: Tuesday, December 13, 2016 11:06:48 PM
> Subject: Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and  
> qemu-kvm(-ev) 2.6.0
> 
> - Original Message -
> > From: "David Moreau Simard" 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > , "OpenStack
> > Operators" 
> > Sent: Tuesday, December 13, 2016 6:13:12 PM
> > Subject: [Openstack-operators] [all] Known issue with CentOS 7.3 and
> > qemu-kvm(-ev) 2.6.0
> > 
> > Hi,
> > 
> > CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
> > was shipped as part of this release if you have the CentOS
> > Virtualization SIG repositories enabled.
> 
> Isn't the issue that the newer version of qemu-kvm-ev (2.6.0) *hasn't*
> shipped yet? E.g. it's not in:
> 
> http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/
> 
> Hence the mismatch is created because the CentOS repos contain Libvirt 2.0.0
> but not a matching qemu-kvm-ev build (yet).
> 
> Thanks,
> 
> Steve

Just to elaborate on the above, for there are two potential scenarios where you 
will potentially hit "qemu-kvm: CPU feature arat not found":

1) When using virt_type="qemu", CentOS 7 1611 (Libvirt 2.0.0). In this case the 
corrective action for now appears to be as David noted, this is the scenario 
that is most likely hitting the noted CI jobs.

2) When using virt_type="kvm", CentOS 7 1611 (Libvirt 2.0.0) with qemu-kvm-ev < 
2.6.0. In this case the corrective action based on 
https://bugzilla.redhat.com/show_bug.cgi?id=1371617 is actually to install 
qemu-kvm-ev 2.6.0, this is the scenario most likely to hit users.

I wanted to highlight this because David is (quite rightly) focusing on 
resolving (1) to get the CI jobs impacted moving, but it's quite possible many 
users will actually be hitting (2).

Thanks,

Steve

> > If you're using RDO >= Newton, you will have this repository enabled.
> > It was not yet enforced in the Mitaka release so you might or might
> > not have it, depending on your deployment.
> > Older releases of OpenStack may also be affected but they are not
> > proactively tested anymore due to EOL.
> > 
> > There is currently a known issue when using the following
> > configuration in nova for compute:
> > ==
> > virt_type=qemu
> > cpu_mode=host-model
> > ==
> > 
> > This combination will yield in failed attempts at creating instances
> > and you will see errors like these in nova-compute.log [1] or the
> > libvirt logs [2].
> > The problem boils down to libvirt trying to pass a cpu extension that
> > is unknown to qemu:
> > ==
> > qemu-kvm: CPU feature arat not found
> > ==
> > 
> > There is a bugzilla [3] for this issue but in the meantime users are
> > encouraged to work around the issue by setting "cpu_mode=none" if they
> > are using the qemu (not KVM) hypervisor.
> > Please note that Nova defaults the 'cpu_mode' parameter to
> > 'host-model' [4] if 'cpu_mode' is not explicitely configured and
> > 'virt_type' is 'qemu' so if you're running into this issue, you will
> > need to explicitely configure it.
> > 
> > [1]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
> > [2]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
> > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
> > [4]:
> > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411
> > 
> > David Moreau Simard
> > Senior Software Engineer | Openstack RDO
> > 
> > dmsimard = [irc, github, twitter]
> > 
> > ___
> > OpenStack-operators mailing list
> > openstack-operat...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> > 
> 
> 

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform

__
OpenStack Development Mailing 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] [oslo][monasca] Can we uncap python-kafka ?

[Tony Breeds]

On Mon, Dec 05, 2016 at 04:03:13AM +, Keen, Joe wrote:

> I don’t know, yet, that we can.  Unless we can find an answer to the
> questions I had above I’m not sure that this new library will be
> performant and durable enough for the use cases Monasca has.  I’m fairly
> confident that we can make it work but the performance issues with
> previous versions prevented us from even trying to integrate so it will
> take us some time.  If you need an answer more quickly than a week or so,
> and if anyone in the community is willing, I can walk them through the
> testing I’d expect to happen to validate the new library.

Any updates Joe?  It's been 10 days and we're running close to Christamas so
at this rate it'll be next year before we know if this is workable.

Yours Tony.


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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Samuel Cassiba]

> On Dec 13, 2016, at 19:43, Ed Leafe  wrote:
> 
> On Dec 12, 2016, at 10:30 PM, Steven Dake (stdake)  wrote:
> 
>> The issue raised is they violate the 4 opens.
> 
> Not necessarily. If you have regular planning meetings and discussions in an 
> open manner as prescribed, an occasional conference to discuss a particular 
> matter is not a "violation". What if someone in your office is working on 
> OpenStack too, and you meet in the hallway and discuss something technical? 
> Does that violate the 4 Opens?
> 
> I think we have to balance realism with idealism.

It wouldn’t be the first time video chats were shot down. As I recall, one of 
the conditions for the OpenStack Chef cookbooks to become an official OpenStack 
project was that we gave up our weekly Hangouts meetings in favor of weekly IRC 
meetings. As it was, when the cookbooks were still considered StackForge, links 
were sent out to the mailing list and channel prior to the meeting starting, to 
give people a time to get coffee, comb their hair and put on a shirt (pants 
optional).

Today, we do not hold weekly meetings as the cores are either west coast US or 
Europe, so pretty much every time is bad, as we have minimal overlap. It used 
to be pretty easy to point at a video call and say “I’m doing that right 
there”. Not so much to get an hour dedicated to IRC, because of the very nature 
of IRC, so we lost folks to the winds of change. At some point in the Newton 
cycle, we did not see much value in holding weekly IRC meetings, as we were 
just echoing what we said in our dedicated channel, so we gave up our scheduled 
slot. From the founding team, only two members remain.To date, one core has 
joined, bringing us up to three, down from eight, spread across two continents. 
The picture I paint is not good eats.

As PTL and direct consumer of the output of the cookbooks, I feel that 
eliminating the option to hold our meetings via video chat was a detrimental 
blow to the project's trajectory, as a result of becoming an OpenStack project. 
Given the cookbooks’ complexity and the ability to get shit done that came from 
having that virtual face-to-face time, it made sense to sit down and “uhm" and 
“hrm" about things with a like-minded individual, obligatory link in the 
channel for those playing along on IRC.

Since giving up Hangouts, we have had minimal auditory/visual interaction in 
the effort of “transparency” and being “open” on IRC. I recall that we had 
exactly one video chat since becoming an official project, and it was immensely 
useful for the few minutes we talked, and got more across than a day’s worth of 
IRC meetings.  Beyond that, our face time has involved meeting up at a given 
Summit that we all happen to attend, which is entirely too long to go between 
seeing teammates IMHO. The PTG isn’t of much benefit to the cookbooks, either, 
as it’s a non-trivial distance and expense for all of the cores for not much 
gain, when one of us can just shift hours for a video call.

-sc

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



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

Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core

[Brandon Logan]

+1

On Wed, 2016-12-14 at 02:22 +0100, Armando M. wrote:
Hi folks,

Abhishek Raut's recent involvement in OSC and python-neutronclient has helped 
moving a few efforts along in the right direction. I would like to suggest we 
double down on core firepower for the neutronclient repo alongside Akihiro [1].

This not only will help speed up our transition to OSC CLI, but also improve 
the number of folks who can effectively liasion with the OSC team, and look 
after the needs of neutron's client repo.

Many thanks,
Armando

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

__
OpenStack Development Mailing 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-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

[Steve Gordon]

- Original Message -
> From: "David Moreau Simard" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> , "OpenStack
> Operators" 
> Sent: Tuesday, December 13, 2016 6:13:12 PM
> Subject: [Openstack-operators] [all] Known issue with CentOS 7.3 and  
> qemu-kvm(-ev) 2.6.0
> 
> Hi,
> 
> CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
> was shipped as part of this release if you have the CentOS
> Virtualization SIG repositories enabled.

Isn't the issue that the newer version of qemu-kvm-ev (2.6.0) *hasn't* shipped 
yet? E.g. it's not in:

http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/

Hence the mismatch is created because the CentOS repos contain Libvirt 2.0.0 
but not a matching qemu-kvm-ev build (yet).

Thanks,

Steve

> If you're using RDO >= Newton, you will have this repository enabled.
> It was not yet enforced in the Mitaka release so you might or might
> not have it, depending on your deployment.
> Older releases of OpenStack may also be affected but they are not
> proactively tested anymore due to EOL.
> 
> There is currently a known issue when using the following
> configuration in nova for compute:
> ==
> virt_type=qemu
> cpu_mode=host-model
> ==
> 
> This combination will yield in failed attempts at creating instances
> and you will see errors like these in nova-compute.log [1] or the
> libvirt logs [2].
> The problem boils down to libvirt trying to pass a cpu extension that
> is unknown to qemu:
> ==
> qemu-kvm: CPU feature arat not found
> ==
> 
> There is a bugzilla [3] for this issue but in the meantime users are
> encouraged to work around the issue by setting "cpu_mode=none" if they
> are using the qemu (not KVM) hypervisor.
> Please note that Nova defaults the 'cpu_mode' parameter to
> 'host-model' [4] if 'cpu_mode' is not explicitely configured and
> 'virt_type' is 'qemu' so if you're running into this issue, you will
> need to explicitely configure it.
> 
> [1]:
> http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
> [2]:
> http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
> [4]:
> http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411
> 
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
> 
> dmsimard = [irc, github, twitter]
> 
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 


__
OpenStack Development Mailing 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] Proposing Abhishek Raut as neutronclient core

[Vasudevan, Swaminathan (PNB Roseville)]

+1

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Tuesday, December 13, 2016 6:57 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient 
core

+1

On Dec 13, 2016 17:27, "Armando M." 
> wrote:
Hi folks,

Abhishek Raut's recent involvement in OSC and python-neutronclient has helped 
moving a few efforts along in the right direction. I would like to suggest we 
double down on core firepower for the neutronclient repo alongside Akihiro [1].

This not only will help speed up our transition to OSC CLI, but also improve 
the number of folks who can effectively liasion with the OSC team, and look 
after the needs of neutron's client repo.

Many thanks,
Armando

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

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

Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core

[Hirofumi Ichihara]

+1

On 2016/12/14 11:56, Kevin Benton wrote:

+1

On Dec 13, 2016 17:27, "Armando M." > wrote:


Hi folks,

Abhishek Raut's recent involvement in OSC and python-neutronclient
has helped moving a few efforts along in the right direction. I
would like to suggest we double down on core firepower for the
neutronclient repo alongside Akihiro [1].

This not only will help speed up our transition to OSC CLI, but
also improve the number of folks who can effectively liasion with
the OSC team, and look after the needs of neutron's client repo.

Many thanks,
Armando

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


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

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




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


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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Ed Leafe]

On Dec 12, 2016, at 10:30 PM, Steven Dake (stdake)  wrote:

> The issue raised is they violate the 4 opens.

Not necessarily. If you have regular planning meetings and discussions in an 
open manner as prescribed, an occasional conference to discuss a particular 
matter is not a "violation". What if someone in your office is working on 
OpenStack too, and you meet in the hallway and discuss something technical? 
Does that violate the 4 Opens?

I think we have to balance realism with idealism.


-- Ed Leafe






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

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Sat, Dec 3, 2016 at 4:07 PM, Lingxian Kong  wrote:
> Hi, Takashi,
>
> Thanks for working on this project, we (Catalyst Cloud) also provide VPNaaS
> in our OpenStack based public cloud, so maybe we can also provide help from
> our side.

which driver are you using?

>
>
> Cheers,
> Lingxian Kong (Larry)
>
> On Mon, Nov 28, 2016 at 5:50 PM, Takashi Yamamoto 
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.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
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Swapnil Kulkarni]

On Tue, Dec 13, 2016 at 8:33 PM, Michał Jastrzębski  wrote:
> I really fail to see how add hoc meetings, if link will be posted openly on
> IRC, notes made public and invitation extended to everyone would violate 4
> opens. It's virtuality impossible in globally distributed project to have
> everyone interested around at all times. All decisions made will be
> reflected in gerrit when first code his it, etherpad or summary on IRC
> afterwards will allow those not present to get up to speed.
>
> I think we need to trust our fellow cores to have best interest of project
> in mind even when we are not around. Any issues can be dealt with later as
> well.
>
> Cheers,
> Michał
>

+1

> On Dec 13, 2016 5:12 AM, "Sean Dague"  wrote:
>
> On 12/13/2016 08:02 AM, Thierry Carrez wrote:
>> Ed Leafe wrote:
>>> On Dec 12, 2016, at 11:16 AM, Jeffrey Zhang 
>>> wrote:
>>>
 Some contributors in kolla have had unscheduled video meetings. This has
 resulted in complaints about inclusiveness. Some contributors can’t even
 make
 the meeting we have, and another scheduled video meeting might produce a
 situation in which there is no any record of decisions made during the
 video
 meeting. At least with IRC meetings there is always a log.
>>>
>>> Occasionally a quick Google hangout is necessary in Nova in order to
>>> quickly settle an outstanding issue so we can continue to make progress.
>>> When that happens, the link is posted in the #openstack-nova channel, and
>>> anyone who is interested can join. So while it’s not logged like an IRC
>>> meeting, it’s no excluding anyone, and we can quickly remove roadblocks that
>>> are harder to do in IRC.
>>
>> Last time I checked, Google Hangouts were not accessible from China...
>> So it *is* excluding some contributors ?
>>
>> I think it's fine to use Hangouts or phone calls to quickly go through
>> an issue. But if those become routine and if contributors express that
>> those are making them feel (or be) excluded, then it is important to
>> reassess your usage of them before it starts threatening our "open
>> development" and "open community" pillars.
>>
>> And in all cases, regular team meetings (or decision-making meetings)
>> should happen on IRC in logged channels.
>
> There is definitely a reality that there are circumstances where
> collaboration happens, and happens quickly, in some setting where not
> everyone was around. Be it at a conference, randomly finding people in a
> coffee shop, on a google hangout, a telephone call, etc.
>
> I think the most important thing is to take the time to take whatever
> happened there and put it out in open memory afterwards. For instance, a
> write up to the mailing list with the notes of what about the issue, the
> discussion, the resolution. This isn't only helpful for the people not
> in the room, it's also really helpful even for those in the room 6 or 12
> months later to try to recall why a particular course of action was taken.
>
> -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
>



-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap
coolsvap at gmail dot com
+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] [neutron] Proposing Abhishek Raut as neutronclient core

[Kevin Benton]

+1

On Dec 13, 2016 17:27, "Armando M."  wrote:

> Hi folks,
>
> Abhishek Raut's recent involvement in OSC and python-neutronclient has
> helped moving a few efforts along in the right direction. I would like to
> suggest we double down on core firepower for the neutronclient repo
> alongside Akihiro [1].
>
> This not only will help speed up our transition to OSC CLI, but also
> improve the number of folks who can effectively liasion with the OSC team,
> and look after the needs of neutron's client repo.
>
> Many thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/410485/
>
> __
> OpenStack Development Mailing 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] [openstack][nova][nova-api] index() method in InstanceUsageAuditLogController return an object rather than a list

[int32bit]

Hi, all. As we know, the "index()" method usually return object list and
the "show()" method return an object for detail in api's controller. But I
found in our InstanceUsageAuditLogController[1], the 'index' method return
an object, I'm really not sure that index() is buggy, and I wonder what it
is intended to do and what might be needed to fix it.

Some discussion about this topic: https://review.openstack.org/#/c/409413/
.

Thanks for your attention.


[1]
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/instance_usage_audit_log.py#L43
__
OpenStack Development Mailing 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] Proposing Abhishek Raut as neutronclient core

[Armando M.]

Hi folks,

Abhishek Raut's recent involvement in OSC and python-neutronclient has
helped moving a few efforts along in the right direction. I would like to
suggest we double down on core firepower for the neutronclient repo
alongside Akihiro [1].

This not only will help speed up our transition to OSC CLI, but also
improve the number of folks who can effectively liasion with the OSC team,
and look after the needs of neutron's client repo.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/410485/
__
OpenStack Development Mailing 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] Feedback requested on Lwood

[Hugh Blemings]

Hi,

I’m grateful that Lwood [1] still generates positive commentary from 
across the OpenStack Community, but figure as the year draws to a close, 
it’s a good time to gather some feedback.


To that end I’ve put together a survey;

https://www.surveymonkey.com/r/3FQX2YR

It will probably take no more than five minutes to complete and I would 
be very grateful if you’d take some time to fill it out.


Thank you in anticipation, my thanks also to those who have already 
responded :)


Kind Regards,
Hugh


[1] http://hugh.blemings.id.au/openstack/lwood/

__
OpenStack Development Mailing 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] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

[David Moreau Simard]

Hi,

CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
was shipped as part of this release if you have the CentOS
Virtualization SIG repositories enabled.

If you're using RDO >= Newton, you will have this repository enabled.
It was not yet enforced in the Mitaka release so you might or might
not have it, depending on your deployment.
Older releases of OpenStack may also be affected but they are not
proactively tested anymore due to EOL.

There is currently a known issue when using the following
configuration in nova for compute:
==
virt_type=qemu
cpu_mode=host-model
==

This combination will yield in failed attempts at creating instances
and you will see errors like these in nova-compute.log [1] or the
libvirt logs [2].
The problem boils down to libvirt trying to pass a cpu extension that
is unknown to qemu:
==
qemu-kvm: CPU feature arat not found
==

There is a bugzilla [3] for this issue but in the meantime users are
encouraged to work around the issue by setting "cpu_mode=none" if they
are using the qemu (not KVM) hypervisor.
Please note that Nova defaults the 'cpu_mode' parameter to
'host-model' [4] if 'cpu_mode' is not explicitely configured and
'virt_type' is 'qemu' so if you're running into this issue, you will
need to explicitely configure it.

[1]: 
http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
[2]: 
http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
[4]: 
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

__
OpenStack Development Mailing 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] [tacker] Weekly meeting agenda - Dec 14, 2016

[Sridhar Ramaswamy]

Here is the agenda for today's tacker weekly meeting,

https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Dec_14th.2C_2016


   - Announcements
   - Spec-less blueprints rundown
  -
  
https://blueprints.launchpad.net/tacker/+spec/deprecate-legacy-template-dsl
(need
  owner)
  - https://blueprints.launchpad.net/tacker/+spec/switch-to-keystoneauth
  - https://blueprints.launchpad.net/tacker/+spec/vnffgd-param-support
  - https://blueprints.launchpad.net/tacker/+spec/hot-template-support
   - Refactor openstack driver (Haiwei) -
   https://review.openstack.org/405276
   - Tacker-Senlin integration spec (Haiwei / Xuan) -
   https://review.openstack.org/#/c/352943/



*Again, please note the new meeting time,*

*Dec 14th, Wednesday 05:30 UTC @ #openstack-meeting.*

- Sridhar
__
OpenStack Development Mailing 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] Golang technical requirements

[Dean Troyer]

On Tue, Dec 13, 2016 at 4:26 PM, Jay Pipes  wrote:
> Not sure if it's already been brought up, but I really like govendor:

Govendor and glide are the two most promising candidates at this
point.  I just read today's summary of the Package Management
Committee [0] and that sounds _really_ promising, if further out than
we can wait on, but there will be migration paths from many of the
existing tools.  Both govendor and glide have devs in the Advisory
Group to the committee.

> More than the decision between dependency management toolkits, though, is
> the decision over whether to have *any* vendored source code in the primary
> project's source tree itself (as opposed to only storing the
> vendor.json/glide.yaml|lock file that lists dependent library versions and
> locations). Please let's have a policy of keeping vendored source code *out*
> of the primary project source tree.

This is the intention and I see no reason why it is not achievable.
It totally depends (ha!) on having better (any!) dependency management
in place.

One thing that I have been pondering is resurrecting the old technique
of embedding version info into binaries so they can be examined to
discover which library versions were used in its build.  This was
totally a thing when I was using rcs ($Id$ and ident(1) FTW) but that
particular technique is messy with distributed version control, and
may not be needed at all in a packaged distro environment.  This may,
however, help ease the concerns many have around static linking of
libs.

dt

[0] https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] Golang technical requirements

[Jay Pipes]

On 12/13/2016 03:17 PM, Monty Taylor wrote:

On 12/13/2016 12:45 PM, Dean Troyer wrote:

I am working on scoping the tasks required for the technical pieces of
Golang adoption in OpenStack.  This work has been informed somewhat by
flaper87's reference doc proposal[0] for new language additions and is
(mostly) compatible with it, pending that proposal's final approval by
the TC.

As a first step, I proposed a Common Testing Interface (CTI)
document[1] for Go.  There is, of course, much more than this,
including a number of significant decisions that still need to be
made.  At this point I want to focus on identifying those decisions
and other tasks rather than solving them immediately.

Some of the previous work done around using Golang in OpenStack has
been collected in an Etherpad[2] and summarized into major categories.
I am confident that I have not found everything that has been done and
would appreciate pointers to whatever resources you may have.  Here
are some highlights of areas that still require discussion and
decisions:


Common Libraries

flaper87's reference doc touches on project requirements for new
languages and Oslo-compatible implementations.  At the time of this
writing this is not yet finalized, with some discussion around how
much to require, and if the first project to utilize a new language
should shoulder all of the burden of also implementing those
libraries.


Dependency Management

There are a number of tools available for Golang to manage
dependencies.  A number have been evaluated already with a couple of
strong contenders identified.  Once a tool is selected, process needs
to be set up to track dependencies and versions tested.


Figuring out how to get from that to pre-cached git repos in gate nodes
is another important task. Actually cloning from github during CI jobs
leads to wailing and gnashing of teeth pretty quickly. That said - godep
and glide both lend themselves well towards doing such a thing.


Not sure if it's already been brought up, but I really like govendor:

https://github.com/kardianos/govendor

for Golang dependency management.

More than the decision between dependency management toolkits, though, 
is the decision over whether to have *any* vendored source code in the 
primary project's source tree itself (as opposed to only storing the 
vendor.json/glide.yaml|lock file that lists dependent library versions 
and locations). Please let's have a policy of keeping vendored source 
code *out* of the primary project source tree.


Perhaps this is just me, but honestly, I don't see why some in the 
Golang community seem to just want to throw away decades of best 
practices from the development community that advises not to bundle all 
your dependent library source code in your own project's source tree.


Basically... *don't mix your build artifacts with your source files*.

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] [tripleo] Requesting files from the overcloud from the undercloud

[Zane Bitter]

On 12/12/16 09:09, Steven Hardy wrote:

On Wed, Nov 30, 2016 at 01:54:34PM -0700, Alex Schultz wrote:

Hey folks,

So I'm in the process of evaluating options for implementing the
capture-environment-status-and-logs[0] blueprint.  At the moment my
current plan is to implement a mistral workflow to execute the
sosreport to bundle the status and logs up on the requested nodes.
I'm leveraging a similar concept to the the remote execution[1] method
we current expose via 'openstack overcloud execute'.  The issue I'm
currently running into is getting the files off the overcloud node(s)
so that they can be returned to the tripleoclient.  The files can be
large so I don't think they are something that can just be returned as
output from Heat.  So I wanted to ask for some input on the best path
forward.

IDEA 1: Write something (script or utility) to be executed via Heat on
the nodes to push the result files to a container on the undercloud.
Pros:
- The swift container can be used by the mistral workflow for other
actions as part of this bundling
- The tripleoclient will be able to just pull the result files
straight from swift
- No additional user access needs to be created to perform operations
against the overcloud from the undercloud
Cons:
- Swift credentials (or token) need to be passed to the script being
executed by Heat on the overcloud nodes which could lead to undercloud
credentials being leaked to the overcloud


I think we can just use a swift tempurl?  That's in alignment for what we
already do both for polling metadata from heat (which is put into swift,
then we give a tempurl to the nodes, see /etc/os-collect-config.conf on the
overcloud nodes.


+1, was about to say exactly the same thing.


It's also well aligned with what we do for the DeployArtifactURLs
interface.

I guess the main difference here is we're only allowing GET access for
those cases, but here there's probably more scope for abuse, e.g POSTing
giant files from the overcloud nodes could impact e.g disk space on the
undercloud?


- I'm not sure if all overcloud nodes would have access to the
undercloud swift endpoint


I think they will, or the tempurl transport we use for heat won't work.


IDEA 2: Write additional features into undercloud deployment for ssh
key generation and inclusion into the deployment specifically for this
functionality to be able to reach into the nodes and pull files out
(via ssh).
Pros:
- We would be able to leverage these 'support' credentials for future
support features (day 2 operations?)
- ansible (or similar tooling) could be used to perform operations
against the overcloud from the undercloud nodes
Cons:
- Complexity and issues around additional user access
- Depending on where the ssh file transfer occurs (client vs mistral),
additional network access might be needed.

IDEA 2a: Leverage the validations ssh key to pull files off of the
overcloud nodes
Pros:
- ssh keys already exist when enable_validations = true so we can
leverage existing
Cons:
- Validations can be disabled, possibly preventing 'support' features
from working
- Probably should not leverage the same key for multiple functions.

I'm leaning towards idea 1, but wanted to see if there was some other
form of existing functionality I'm not aware of.


Yeah I think (1) is probably the way to go, although cases could be argued
for all approaches you mention.

My main reason for preferring (1) is I think we'll want the data to end up
in swift anyway, e.g so UI users can access it (which won't be possible if
we e.g scp some tarball from overcloud nodes into the undercloud filesystem
directly, so we may as well just push it into swift from the nodes?)

Steve

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




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

[openstack-dev] [glance] Propose Steve Lewis for Glance core

[Brian Rosmaita]

I'd like to propose Steve Lewis (stevelle on IRC) for Glance core.  Take
a look at any of his reviews, and you can see that he's thorough and
comprehensive in his reviewing.  He's knowledgeable about Python,
Glance, and software engineering in general.  He's gained a lot of
experience in various OpenStack projects (including experience as a core
reviewer), and will be a great addition to the Glance core reviewers team.

If you have any concerns, please let me know.  I plan to add Steve to
the core list after this week's Glance meeting.

thanks,
brian

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

[openstack-dev] [tripleo] release status

[Emilien Macchi]

I thought it would be useful to share our roadmap for TripleO releases.
As a reminder, this is the official source of trust for OpenStack
releases schedule:
https://releases.openstack.org/ocata/schedule.html

Over the last weeks, we discussed about how TripleO project would
produce better releases without stressing people at pushing for
features late in cycles.

- tripleo-specs for Ocata need to be merged by ocata-2 or will be
postponed to Pike.
- blueprints scheduled for ocata-2 with good progress will be
postponed to ocata-3.
- blueprints scheduled for ocata-2 with zero or low progress will be
postponed to pike-1.
- we'll release ocata-2 end of this week.
- we'll release a new Newton release next week.
- by the end of ocata-3, we'll stop pushing for features except
Composable Upgrades which is our critical thing during this cycle.
Anything else will be frozen and postponed to Pike.
- we'll threat FFE case by case but if the FFE is not related to a
blueprint that was targeted for ocata-3, no need to ask, it will be
rejected.
- between end of ocata-3 and final ocata release, we have 5 weeks. We
might want to spend time on stabilization, bug fixing (we currently
have more than 100 bugs open, just for ocata-2) and keep CI stable
until final release. The last thing we want is to push for last
features and stress people because it breaks all the things.

Please provide any feedback, it's highly welcome.
-- 
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] Golang technical requirements

[Monty Taylor]

On 12/13/2016 12:45 PM, Dean Troyer wrote:
> I am working on scoping the tasks required for the technical pieces of
> Golang adoption in OpenStack.  This work has been informed somewhat by
> flaper87's reference doc proposal[0] for new language additions and is
> (mostly) compatible with it, pending that proposal's final approval by
> the TC.
> 
> As a first step, I proposed a Common Testing Interface (CTI)
> document[1] for Go.  There is, of course, much more than this,
> including a number of significant decisions that still need to be
> made.  At this point I want to focus on identifying those decisions
> and other tasks rather than solving them immediately.
> 
> Some of the previous work done around using Golang in OpenStack has
> been collected in an Etherpad[2] and summarized into major categories.
> I am confident that I have not found everything that has been done and
> would appreciate pointers to whatever resources you may have.  Here
> are some highlights of areas that still require discussion and
> decisions:
> 
> 
> Common Libraries
> 
> flaper87's reference doc touches on project requirements for new
> languages and Oslo-compatible implementations.  At the time of this
> writing this is not yet finalized, with some discussion around how
> much to require, and if the first project to utilize a new language
> should shoulder all of the burden of also implementing those
> libraries.
> 
> 
> Dependency Management
> 
> There are a number of tools available for Golang to manage
> dependencies.  A number have been evaluated already with a couple of
> strong contenders identified.  Once a tool is selected, process needs
> to be set up to track dependencies and versions tested.

Figuring out how to get from that to pre-cached git repos in gate nodes
is another important task. Actually cloning from github during CI jobs
leads to wailing and gnashing of teeth pretty quickly. That said - godep
and glide both lend themselves well towards doing such a thing.

We also need to rework how zuul clones git repos a little bit so that
intra-OpenStack cross-repo dependencies work properly. In short, we
should have zuul clone to $BASE/src/git.openstack.org/openstack/nova
instead of $BASE/openstack/nova so that we can just point $GOPATH at
$BASE and have things just work. That obviously involves a change to
zuul to do the cloning, and to devstack to start grokking another level
of source repo organization. On the plus-side though, I think it'll be
nicer even for non-go related things, so is well worth doing.

Finally- (and this one is easy) - we need to put a pointer files at the
root of git.o.o and review.o.o to mark git.o.o/${repo}.git as the
canonical location of repositories.

https://golang.org/cmd/go/#hdr-Relative_import_paths

has instructions on this.

> Release Deliverables
> 
> OpenStack still officially considers the tarballs generated during the
> release rpocess to be our official deliverable.  Many downstream
> consumers, however, bypass those and go directly to the tagged
> releases in the Git repos.  The Golang community has no real culture
> of using tarballs at all, given the 'go get' functionality bult in to
> the tooling directly for checking out remote repos.  One obvious
> shortcoming in just defining the release to be Git repo tags is our
> use of generated files.

Indeed. On the other hand - our use of git tags to drive our
deliverables (and pbr's use of them instead of content in a file in the
source repo) actually has us more closely aligned with this than other
projects might be.

> 
> If you have an interest in seeing Golang support implemented for
> OpenStack, please jump in here and help us nail down how to accomplish
> that "right".
> 
> dt
> 
> [0] https://review.openstack.org/#/c/398875/
> [1] https://review.openstack.org/410355
> [2] https://etherpad.openstack.org/p/golang-infra-work-plan
> 


__
OpenStack Development Mailing 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][bugs] Useful metrics?

[Sean Dague]

On 12/13/2016 01:45 PM, Monty Taylor wrote:
> On 12/13/2016 12:36 PM, Sean Dague wrote:
>> On 12/13/2016 01:29 PM, Augustina Ragwitz wrote:
>>> Previously Markus Z. did some great work in putting together a dashboard
>>> we've been using for bug queue maintenance. Are there additional reports
>>> or visualizations of the bug queue that might be interesting or useful
>>> for the team? Is there some information that might make bug skimming,
>>> triaging, or even bug searching easier?
>>
>> The thing I'd really like to see is trend lines for bugs in all open
>> states over time (preferably in graphite) and the same thing for every
>> official tag in the Nova bug pile. I find seeing a graph you can active
>> work to burn down by closing artifacts is motivating to trying to chew
>> through the outstanding issues.
> 
> In talking about Markus' script in Infra (and how/where we could run it)
> - fungi pointed out:
> 
> http://status.openstack.org/bugday/
> 
> While the data isn't in graphite, perhaps it's a good starting point for
> producing such graphs - and would perhaps also be a good place to put
> the bug dashboard too?

As a public home, sure. Those existing data sets are in an odd format
(and only 48hours long IIRC), and pretty restricted right now. If there
was a good public pattern for pumping bug data into graphite (like
hourly), that would be ideal, it would let us see some longer trends.

-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] [nova][bugs] Useful metrics?

[Monty Taylor]

On 12/13/2016 12:36 PM, Sean Dague wrote:
> On 12/13/2016 01:29 PM, Augustina Ragwitz wrote:
>> Previously Markus Z. did some great work in putting together a dashboard
>> we've been using for bug queue maintenance. Are there additional reports
>> or visualizations of the bug queue that might be interesting or useful
>> for the team? Is there some information that might make bug skimming,
>> triaging, or even bug searching easier?
> 
> The thing I'd really like to see is trend lines for bugs in all open
> states over time (preferably in graphite) and the same thing for every
> official tag in the Nova bug pile. I find seeing a graph you can active
> work to burn down by closing artifacts is motivating to trying to chew
> through the outstanding issues.

In talking about Markus' script in Infra (and how/where we could run it)
- fungi pointed out:

http://status.openstack.org/bugday/

While the data isn't in graphite, perhaps it's a good starting point for
producing such graphs - and would perhaps also be a good place to put
the bug dashboard too?

__
OpenStack Development Mailing 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] Golang technical requirements

[Dean Troyer]

I am working on scoping the tasks required for the technical pieces of
Golang adoption in OpenStack.  This work has been informed somewhat by
flaper87's reference doc proposal[0] for new language additions and is
(mostly) compatible with it, pending that proposal's final approval by
the TC.

As a first step, I proposed a Common Testing Interface (CTI)
document[1] for Go.  There is, of course, much more than this,
including a number of significant decisions that still need to be
made.  At this point I want to focus on identifying those decisions
and other tasks rather than solving them immediately.

Some of the previous work done around using Golang in OpenStack has
been collected in an Etherpad[2] and summarized into major categories.
I am confident that I have not found everything that has been done and
would appreciate pointers to whatever resources you may have.  Here
are some highlights of areas that still require discussion and
decisions:


Common Libraries

flaper87's reference doc touches on project requirements for new
languages and Oslo-compatible implementations.  At the time of this
writing this is not yet finalized, with some discussion around how
much to require, and if the first project to utilize a new language
should shoulder all of the burden of also implementing those
libraries.


Dependency Management

There are a number of tools available for Golang to manage
dependencies.  A number have been evaluated already with a couple of
strong contenders identified.  Once a tool is selected, process needs
to be set up to track dependencies and versions tested.


Release Deliverables

OpenStack still officially considers the tarballs generated during the
release rpocess to be our official deliverable.  Many downstream
consumers, however, bypass those and go directly to the tagged
releases in the Git repos.  The Golang community has no real culture
of using tarballs at all, given the 'go get' functionality bult in to
the tooling directly for checking out remote repos.  One obvious
shortcoming in just defining the release to be Git repo tags is our
use of generated files.


If you have an interest in seeing Golang support implemented for
OpenStack, please jump in here and help us nail down how to accomplish
that "right".

dt

[0] https://review.openstack.org/#/c/398875/
[1] https://review.openstack.org/410355
[2] https://etherpad.openstack.org/p/golang-infra-work-plan

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [nova][bugs] Useful metrics?

[Sean Dague]

On 12/13/2016 01:29 PM, Augustina Ragwitz wrote:
> Previously Markus Z. did some great work in putting together a dashboard
> we've been using for bug queue maintenance. Are there additional reports
> or visualizations of the bug queue that might be interesting or useful
> for the team? Is there some information that might make bug skimming,
> triaging, or even bug searching easier?

The thing I'd really like to see is trend lines for bugs in all open
states over time (preferably in graphite) and the same thing for every
official tag in the Nova bug pile. I find seeing a graph you can active
work to burn down by closing artifacts is motivating to trying to chew
through the outstanding issues.

-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] [nova][bugs] Useful metrics?

[Augustina Ragwitz]

Previously Markus Z. did some great work in putting together a dashboard
we've been using for bug queue maintenance. Are there additional reports
or visualizations of the bug queue that might be interesting or useful
for the team? Is there some information that might make bug skimming,
triaging, or even bug searching easier?

-- 
Augustina Ragwitz
Señora Software Engineer
---
Waiting for your change to get through the gate? Clean up some Nova
bugs!
http://45.55.105.55:8082/bugs-dashboard.html
---
email: aragwitz+n...@pobox.com
irc: auggy

__
OpenStack Development Mailing 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] [infra][neutron] RADWARE CI voting permission in Neutron

[Izik Penso]

Hi Neutron, Infra Cores,

Radware CI  would like to acquire voting (+/-1 Verified) permission.

We voted before but we had to install a new CI and also changed our old gerrit 
user with a new user because ssh key issues.

We are triggered by neutron-lbaas changes.
https://wiki.openstack.org/wiki/ThirdPartySystems/Radware_CI

Old user: radware3rdpartytesting
New user: radware3rdparty
email : openstack3rdpartytest...@radware.com

See our comments :
https://review.openstack.org/#/c/343963/
https://review.openstack.org/#/c/28/
https://review.openstack.org/#/c/408534/
https://review.openstack.org/#/c/408105/

Thanks,
Izik P.
Radware.


__
OpenStack Development Mailing 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] Deep dive session about the UI - January 12

[Miles Gould]

On 13/12/16 14:07, Ana Krivokapic wrote:

If you'd like a calendar invite for this deep dive, email me and I'll
add you to the meeting invite.


Yes please!

Miles

__
OpenStack Development Mailing 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] Barcelona Summit - Speaker slide upload problem

[Jimmy Mcarthur]

The issue with file size uploads is resolved. Should be all good to go 
now. Thanks for your patience!


Jimmy


Jimmy Mcarthur 
December 13, 2016 at 10:46 AM
Hi all -

A quick note for those of you that have had trouble uploading slides 
for your Barcelona presentation.  We are working on the file size 
issue, which is throwing some errors on the site. Hope to have a fix 
up shortly, and apologies for the trouble.


Thank you,
Jimmy McArthur


__
OpenStack Development Mailing 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] [keystone][nova]Quotas: Store resources and limits in the Keystone

[Jay Pipes]

On 12/13/2016 11:27 AM, Sajeesh Cimson Sasi wrote:

Hi,
There was an ongoing project of delimiter for Cross Project Quota 
Management.
But I don't know the current status.
Kindly have a look at it.
https://review.openstack.org/#/c/284454/
More discussions are required on this.As more and more  projects or 
services are having the concept ofquotas,Quota as a service can also be 
thought of.Anyway more discussions are required on this topic.


I raised objections to having a separate endpoint process quota *usages* 
when the Delimiter project was proposed:


http://openstack.markmail.org/message/7ixvezcsj3uyiro6

I stand by those objections for the reasons stated in the above ML thread.

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] [TripleO] Network Configuration in TripleO UI

[Dan Sneddon]

On 12/08/2016 08:10 PM, Jason Rist wrote:
> On 12/08/2016 05:28 PM, Dan Sneddon wrote:
>> On 12/08/2016 06:05 AM, Jiri Tomasek wrote:
>>> Hi all,
>>>
>>> I've been investigating how to implement TripleO network configuration
>>> in TripleO UI. Based on my findings I'd like to propose a solution.
>>>
>>> tl;dr proposal: Slightly refactor Network environment files to match
>>> GUI usage, Use Jinja Templating to generate dynamic parts of the
>>> templates/environments
>>>
>>>
>>> # Overview
>>>
>>> I've used Ben Nemec's amazing Network template generator as a reference
>>> to help me understand how the network configuration works [1]. In
>>> general the process of configuring the network in TripleO is:
>>>
>>> Define which Networks we intend to use -> Assign Roles to the Networks
>>> (+ Assign Role Services to the Network) -> Generate NIC config
>>> templates based on previous information
>>>
>>>
>>> # Deeper dive into templates
>>>
>>> We currently have 2 environment files in THT [2] which define network
>>> configuration:
>>>
>>> network-environment.yaml [3] - holds the information on NIC
>>> configuration for each Role using
>>> OS::TripleONet::SoftwareConfig resource + related
>>> parameter configuration
>>>
>>> network-isolation.yaml [4]
>>> - defines the list of networks using
>>> OS::TripleO::Network:: resource
>>> - defines ports configuration for each network using
>>> OS::TripleO::Network::Ports::VipPort (note that both
>>> resources point to the static templates - those templates don't require
>>> any manual modification)
>>> - holds  Roles - Networks assignment using
>>> OS::TripleOPorts::Port for each role and
>>> storage (again, templates referenced by those resources don't require
>>> any modification)
>>>
>>> User is intended to go ahead and modify those environments and provide
>>> NIC config templates to achieve a network configuration that matches
>>> his needs.
>>>
>>>
>>> # How GUI works
>>>
>>> Before proceeding to proposed changes I need to describe briefly how
>>> TripleO UI works. TripleO UI is using THT as a source of truth, which
>>> means that it is trying not to add any additional business logic or
>>> manipulate templates. Rather it uses environment files as a 'features'
>>> which user can enable or disable depending on the needs of the
>>> deployment. The information about inter-environment relationships is
>>> tracked in capabilities-map.yaml which is also part of the THT. Based
>>> on these choices, UI allows user to configure parameters for those
>>> features. The parameter values and information about which environments
>>> are selected is stored in mistral environment. This approach leaves the
>>> plan templates intact. Huge benefit of this approach is that UI (or
>>> tripleo-common) does not need to hold explicit business logic related
>>> to certain deployment features as it is purely driven by THT. Also
>>> Adding a new feature involves only providing the templates/environments
>>> and it automatically appears as an option in UI.
>>>
>>> To achieve best user experience while using this approach, the
>>> environment files need to be defined in a granular manner, so they
>>> don't require user to modify them and each describe an isolated 'feature'.
>>>
>>> Roles and Network Configuration are exceptions to this concept as they
>>> require modification/generation of the templates/environments and
>>> therefore they use Jinja templating to achieve that.
>>>
>>>
>>> # The proposal
>>>
>>> So having described previous, here is the approach I think we should
>>> use to achieve network configuration using TripleO UI:
>>>
>>> 1. Put networks definitions into separate environment for each network:
>>> - this way GUI can provide a list of networks available to use and let
>>> user select which of them he wants to use. These environments are not
>>> dynamic and if user wants to add a new network, he does so by creating
>>> new templates and environment for it. UI also provides means to
>>> configure parameters for each network at this point (if needed).
>>>
>>> For example the environment for a Storage Network looks like this:
>>>
>>> resource_registry:
>>>   OS::TripleO::Network::Storage: ../network/storage.yaml
>>>   OS::TripleO::Network::Ports::StorageVipPort:
>>> ../network/ports/storage.yaml
>>>
>>> 2. Assign Roles to Networks
>>> Having the Networks selected as well as Roles defined, TripleO UI
>>> provides user with means to assign Roles to Networks. This step
>>> involves generating the network-environment.yaml file. So TripleO UI
>>> sends the mapping of roles to network in json format to tripleo-common
>>> which in turn uses network-isolation.j2.yaml Jinja template to generate
>>> the environment file. I expect that pre-defined network-isolation.yaml
>>> will be included in default plan so the user does not need to start
>>> from scratch. Tripleo-common also provides an action to fetch
>>> network-roles assignment data by parsing the network-isolation.yaml
>>>
>>> 

[openstack-dev] Barcelona Summit - Speaker slide upload problem

[Jimmy Mcarthur]

Hi all -

A quick note for those of you that have had trouble uploading slides for 
your Barcelona presentation.  We are working on the file size issue, 
which is throwing some errors on the site. Hope to have a fix up 
shortly, and apologies for the trouble.


Thank you,
Jimmy McArthur

__
OpenStack Development Mailing 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] [keystone][nova]Quotas: Store resources and limits in the Keystone

[Sajeesh Cimson Sasi]

Hi,
There was an ongoing project of delimiter for Cross Project Quota 
Management.
But I don't know the current status.
Kindly have a look at it.
https://review.openstack.org/#/c/284454/
More discussions are required on this.As more and more  projects or 
services are having the concept ofquotas,Quota as a service can also be 
thought of.Anyway more discussions are required on this topic.
   best regards,
sajeesh

From: Jay Pipes [jaypi...@gmail.com]
Sent: 13 December 2016 18:55:14
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits 
in the Keystone

On 12/13/2016 08:09 AM, Kseniya Tychkova wrote:
> Hi,
> I would like to share a spec [1] with you.
> The main idea of this spec is to start a discussion about quota
> management in the OpenStack.
>
> Quotas are scattered across OpenStack services. Each service defines
> it's own model and API for
> managing resource's limits. Because of that, there are several problems:
>
>   * Names of the resources and resource-service mapping  are hardcoded.
> They are hardcoded in the service code (Nova, for example) and it
> should be hardcoded in the client code (Horizon, for example).
>
>   * There is no centralized quota management for OpenStack projects.
>   * Cinder, Nova and Neutron support (or going to support) hierarchical
> quotas in different ways.
>
> There should be a single point of managing quotas in OpenStack.
> Keystone looks like a proper place to store resource's limits because:
>
>   * Keystone stores projects
>   * Limits are belong to project.

Another excellent reason to store quota limits in Keystone is because
virtually all non-list operations require some interaction with quota
limits, and requiring Nova (or Cinder or Neutron) to call out to yet
another service each time the user makes one of those non-list
operations is sub-optimal when Nova is already making a call to Keystone
for authentication.

The alternative is to have a separate REST API service just for storing
and returning the quota limits and have Nova, Cinder and Neutron call
this new service each time a non-list operation is made. While this is
possible, it's just yet another service that needs to be managed and
deployed by all installations of OpenStack.

Best,
-jay

> There are a lot of possible issues with “store limits in Keystone”
> approach. But all of them can be discussed
> and such discussion should lead to the good solution for quotas
> management  in Openstack.
>
> Please take a look at the spec when you have time and share your ideas
> or concerns.
>
> [1] https://review.openstack.org/#/c/363765/
>
>
> Kind regards,
> Kseniya
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

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

Re: [openstack-dev] [neutron][lbaas] New extensions for HAProxy driver based LBaaSv2

[Kosnik, Lubosz]

This features are supported by default in Octavia. So like keeping HAProxy 
namespace driver up and running is really loosing the whole value added which 
Octavia delivers. You can still work on NLBaaS v2 project but you need to 
remember that by default octavia will be used in cloud as LBaaS and NLBaaS will 
be deprecated starting with P release - right now we’re merging API into 
Octavia to provide backward compatibility - and in this project just bugs will 
be fixed.
Michael any thoughts about what I just said?

Regards,
Lubosz Kosnik
Cloud Software Engineer OSIC
lubosz.kos...@intel.com

On Dec 13, 2016, at 9:47 AM, Bartek Żurawski 
> wrote:

Hello,

Just to be sure about adding new feature to lbaas, should we still
proposing new features like this proposed by Zhi to neutron/lbaas
or already to Octavia ?

@Zhi, yep I like those two extensions it will be very helpful for LB.
Have you already do something with that, or for now you just asking
for opinion ?

Bartek

On 8 December 2016 at 05:33, Brandon Logan 
> wrote:
On Wed, 2016-12-07 at 06:50 -0800, Michael Johnson wrote:
> Lubosz,
>
> I would word that very differently.  We are not dropping LBaaSv2
> support.  It is not going away.  I don't want there to be confusion
> on
> this point.
>
> We are however, moving/merging the API from neutron into Octavia.
> So, during this work the code will be transitioning repositories and
> you will need to carefully synchronize and/or manage the changes in
> both places.
> Currently the API changes have patchsets up in the Octavia
> repository.
> However, the old namespace driver has not yet been migrated over.
I know I've talked about using the namespace driver as a guinea pig for
the nlbaas to octavia shim driver layer, but I didn't know it would be
fully supported in octavia.  This will require a bit more work because
of the callbacks the agent expects to be able to call.

>
> Michael
>
>
> On Tue, Dec 6, 2016 at 8:46 AM, Kosnik, Lubosz 
> 
> om> wrote:
> > Hello Zhi,
> > So currently we’re working on dropping LBasSv2 support.
> > Octavia is a big-tent project providing lbass in OpenStack and
> > after merging
> > LBasS v2 API in Octavia we will deprecate that project and in next
> > 2
> > releases we’re planning to completely wipe out that code
> > repository. If you
> > would like to help with LBasS in OpenStack you’re more than welcome
> > to start
> > working with us on Octavia.
> >
> > Cheers,
> > Lubosz Kosnik
> > Cloud Software Engineer OSIC
> >
> > On Dec 6, 2016, at 6:04 AM, Gary Kotton 
> > > wrote:
> >
> > Hi,
> > I think that there is a move to Octavia. I suggest reaching out to
> > that
> > community and see how these changes can be added. Sounds like a
> > nice
> > addition
> > Thanks
> > Gary
> >
> > From: zhi >
> > Reply-To: OpenStack List 
> > >
> > Date: Tuesday, December 6, 2016 at 11:06 AM
> > To: OpenStack List 
> > >
> > Subject: [openstack-dev] [neutron][lbaas] New extensions for
> > HAProxy driver
> > based LBaaSv2
> >
> > Hi, all
> >
> > I am considering add some new extensions for HAProxy driver based
> > Neutron
> > LBaaSv2.
> >
> > Extension 1, multi subprocesses supported. By following this
> > document[1], I
> > think we can let our HAProxy based LBaaSv2 support this feature. By
> > adding
> > this feature, we can enhance loadbalancers performance.
> >
> > Extension 2, http keep-alive supported. By following this
> > document[2], we
> > can make our loadbalancers more effective.
> >
> >
> > Any comments are welcome!
> >
> > Thanks
> > Zhi Chang
> >
> >
> > [1]: http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#c
> > pu-map
> > [2]:
> > http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#option
> > %20http-keep-alive
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> > openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > 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:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> 

Re: [openstack-dev] [Zun][Glare][Glance] Building Docker images

[Hongbin Lu]

Denis,

Per my understanding, container image building is out of the scope of the Zun 
project. Zun assumes an image has been built and uploaded to a image repository 
(i.e. Glance, docker registry), then the image will be pulled down from the 
repo to host. However, feel free to let us know if anything else we can do.

Best regards,
Hongbin

From: Denis Makogon [mailto:lildee1...@gmail.com]
Sent: December-12-16 4:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Zun][Glare][Glance] Building Docker images


Hello to All.


I’d like to get initial feedback on the idea of building Docker images through 
Zun involving Glare as artifactory for all static components required for image.

  So, the idea here is in being capable to build a Docker image through 
Zun API with storing all static data required for docker image building in 
Glare or Swift. In order to keep the same UX from using Docker it would be 
better to use Dockerfile as description format for image building.

  In image creation process Glare could take role of artifactory, where 
users stores, let’s say source code of his applications that would run in 
containers, static data, etc. And those artifacts will be pulled during image 
creation and used to inject into image (similar process of context creation 
during Docker image building using native CLI). Please note that artifacts are 
completely optional for images, but would give a capability to keep artifacts 
in dedicated storage instead of transferring all data through Zun API (the 
opposite concept to Docker build context).


  Once image is created, it can be stored in underlying Docker in Zun 
or can be published into Glance or Swift for further consumption (if user will 
need to save image, he’ll use Glance image download API). I’ve mentioned Swift 
VS Glance because Swift has concept of temp URLs that can be accessed without 
being authorized. Such feature allows to use Swift as storage from where 
possible to export image to Docker using Import API [1].



Any feedback on the idea is appreciated.


Kind regards,

Denis Makogon


[1] https://docs.docker.com/engine/reference/commandline/import/
__
OpenStack Development Mailing 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] Rechecking, gate breakages, the whiteboard, and you

[Jay Faulkner]

My client munged the link :(.

http://bit.ly/ironic-whiteboard is a correct link.

Thanks,
Jay

> On Dec 13, 2016, at 8:08 AM, Jay Faulkner  wrote:
> 
> Hi all,
> 
> I’ve noticed on several patches over the last few weeks, during various gate 
> outages, that some folks are blindly rechecking their patches even when the 
> gate is hard broken. Just a reminder that if you see a gate failure, and you 
> aren’t sure it’s related to your change, to please check the ironic 
> whiteboard (http://bit.ly/ironic-whiteboard— as listed in /topic in IRC). The 
> whiteboard will tell you if we expect CI to be broken, and if so, what’s 
> going on.
> 
> Blindly and repeatedly rechecking patches just uses up CI resources that 
> could be used to land patches that aren’t being held up by the broken gate, 
> so please avoid doing that.
> 
> Thanks,
> Jay Faulkner
> OSIC
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [ironic] Rechecking, gate breakages, the whiteboard, and you

[Jay Faulkner]

Hi all,

I’ve noticed on several patches over the last few weeks, during various gate 
outages, that some folks are blindly rechecking their patches even when the 
gate is hard broken. Just a reminder that if you see a gate failure, and you 
aren’t sure it’s related to your change, to please check the ironic whiteboard 
(http://bit.ly/ironic-whiteboard— as listed in /topic in IRC). The whiteboard 
will tell you if we expect CI to be broken, and if so, what’s going on.

Blindly and repeatedly rechecking patches just uses up CI resources that could 
be used to land patches that aren’t being held up by the broken gate, so please 
avoid doing that.

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

Re: [openstack-dev] [TripleO][Upgrade Squad syncup]

[Emilien Macchi]

On Tue, Dec 13, 2016 at 10:58 AM, Marios Andreou  wrote:
> Hi OOOs o/ as discussed on this week's upstream weekly irc meeting [1]
> lets schedule a syncup on the Ocata composable upgrades work and how we
> will build on Steve Hardy's base ansible driven implementation.
>
> IMO a call would be the best format (I propose to schedule a bluejeans
> call, though I am open to any other suggestions). For now I've setup a
> doodle poll at http://doodle.com/poll/rp8ck6tstaagftqr - please vote if
> you'd like to participate. Assuming we go with bluejeans (unless I hear
> strong pushback/other suggestions) then I'll try and make a recording
> available to address the concerns expressed at
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108780.html
> (thanks shardy for pointing that out).
>
> Moving forward we should probably switch to an irc based syncup,

As long as:
- we have zero pushbash from our community members
- anyone can join the call
- our design and discussions stay open (mailing-list, tripleo-specs, IRC)
- a nice summary is sent to openstack-dev
- we keep tripleo meeting on IRC every week

I don't see any blocker to do video-conference between folks that work
together on a same topic.

> I'll close the poll at 10UTC tomorrow morning (sorry for short notice :(
> ) and schedule the meeting accordingly with a followup mail here,
>
>
> thanks, marios
>
>
> [1]
> http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-12-13-14.00.log.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



-- 
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] [tripleo] Deep dive session about the UI - January 12

[Emilien Macchi]

On Mon, Dec 12, 2016 at 1:30 PM, Ana Krivokapic  wrote:
> Hi Everyone,
>
> On the 12th of January 2017, I'll lead a TripleO deep dive[1] session on how
> to contribute to the TripleO UI. Hope to see many of you there!

That's awesome! Thanks for this work.
Is there some requirements that we should prepare? (e.g. having an
undercloud ready, etc).
Is it a presentation or/and Hands-On?

Also, I propose that we record it as we did for the previous sessions,
so anyone can watch it again.

Thanks again.

>
> [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics
>
> --
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.
>
-- 
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

[openstack-dev] [TripleO][Upgrade Squad syncup]

[Marios Andreou]

Hi OOOs o/ as discussed on this week's upstream weekly irc meeting [1]
lets schedule a syncup on the Ocata composable upgrades work and how we
will build on Steve Hardy's base ansible driven implementation.

IMO a call would be the best format (I propose to schedule a bluejeans
call, though I am open to any other suggestions). For now I've setup a
doodle poll at http://doodle.com/poll/rp8ck6tstaagftqr - please vote if
you'd like to participate. Assuming we go with bluejeans (unless I hear
strong pushback/other suggestions) then I'll try and make a recording
available to address the concerns expressed at
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108780.html
(thanks shardy for pointing that out).

Moving forward we should probably switch to an irc based syncup,

I'll close the poll at 10UTC tomorrow morning (sorry for short notice :(
) and schedule the meeting accordingly with a followup mail here,


thanks, marios


[1]
http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-12-13-14.00.log.html

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

Re: [openstack-dev] [TripleO] Re-defining network templates/isolation

[Emilien Macchi]

On Mon, Dec 12, 2016 at 4:21 PM, Steven Hardy  wrote:
> On Mon, Dec 12, 2016 at 12:12:30PM -0500, Tim Rozet wrote:
>> Hello,
>> I wanted to get thoughts about re-thinking how users configure and create 
>> new networks with OOO.  The current way to configure network settings for a 
>> deployment requires creating nic + network environment templates, and 
>> updating the network isolation resource registry.  I think a better approach 
>> could consolidate all of the network settings for a deployment into a single 
>> yaml file, and then parse that information to create the appropriate nic and 
>> network env templates.  We do that in OPNFV Apex with a combination of 
>> python and jinja2 using this unified template format:
>>
>> https://github.com/opnfv/apex/blob/master/config/network/network_settings.yaml
>
> Thanks for sharing, and for raising this issue Tim.
>
> Strangely enough I was thinking along similar lines recently and I started
> hacking on some prototype code, just pushed here:
>
>
> https://review.openstack.org/#/c/409920
> https://review.openstack.org/#/c/409921
>
> That was originally related to fixing this bug where network isolation is
> a little inconvenient to use when defining custom roles:
>
> https://bugs.launchpad.net/tripleo/+bug/1633090
>
> Basically I agree we need some way to define per-network data that can then
> be consumed by jinja2 when we render templates for each role.
>
>> Furthermore consider cdefining new networks in OOO.  Think about how much is 
>> involved in creating a new network, subnet, port definition + net_ip_map for 
>> that network, VIP. If you look at the tht/network directory, almost all of 
>> the templates for ports and networks have the exact same format.  I think 
>> you could make the example above dynamic so that a user could define any new 
>> network there and the corresponding port, network + subnet template files 
>> could be created on the fly.
>
> Yes, I agree, this could be the next step after enabling the current
> networks for custom roles.  If we do the j2 implementation right for fixing
> the bug above, I think enabling arbitrary additional networks e.g via some
> j2 loops shouldn't be too much additional work.
>
>> I think this creates a much more simple interface for users by exposing 
>> networking configuration they need, but also hiding redundant OOO/heat 
>> template syntax they don't necessarily care about.  Thoughts?
>
> So, yeah basically I agree - we should reduce the duplication between
> templates e.g for nic configuration, and j2 render them where possible for
> each role/network.
>
> The trick here will be doing it so that we maintain backwards compatibility
> - if we're careful that's probably possible, but we'll have to figure out
>   ways to test that ensure we don't break existing users.
>
> My suggestion would be to refactor things to resolve the bug above, and
> possibly also https://bugs.launchpad.net/tripleo/+bug/1625558 which I think
> should really be fixed by generating the nic configs, not adding even more
> example templates.
>
> If we can do some of that during the Ocata timefram, I expect fully
> composable/custom networks may be possible during Pike?

Thanks Steve for your inputs, it sounds like we have a plan.
Tim, would you mind to draft a tripleo-specs that we would target for pike?
So we could start early discussions and make sure we can make it on
time by end of Pike cycle.

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] [cinder] [ceilometer]

[gordon chung]

On 12/12/16 10:13 PM, Li, Xiaoyan wrote:
> The new notification reports kinds of capacity information, includes total, 
> free, allocated, provisioned, visual_free.

that's cool. just for reference, you can easily add support to generate 
metrics from this by editing the meters.yaml file[1]. alternatively, 
just paste the notification format here and someone can build it for you.

[1] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/data/meters.yaml

-- 
gord

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

Re: [openstack-dev] [neutron][lbaas] New extensions for HAProxy driver based LBaaSv2

[Bartek Żurawski]

Hello,

Just to be sure about adding new feature to lbaas, should we still
proposing new features like this proposed by Zhi to neutron/lbaas
or already to Octavia ?

@Zhi, yep I like those two extensions it will be very helpful for LB.
Have you already do something with that, or for now you just asking
for opinion ?

Bartek

On 8 December 2016 at 05:33, Brandon Logan 
wrote:

> On Wed, 2016-12-07 at 06:50 -0800, Michael Johnson wrote:
> > Lubosz,
> >
> > I would word that very differently.  We are not dropping LBaaSv2
> > support.  It is not going away.  I don't want there to be confusion
> > on
> > this point.
> >
> > We are however, moving/merging the API from neutron into Octavia.
> > So, during this work the code will be transitioning repositories and
> > you will need to carefully synchronize and/or manage the changes in
> > both places.
> > Currently the API changes have patchsets up in the Octavia
> > repository.
> > However, the old namespace driver has not yet been migrated over.
> I know I've talked about using the namespace driver as a guinea pig for
> the nlbaas to octavia shim driver layer, but I didn't know it would be
> fully supported in octavia.  This will require a bit more work because
> of the callbacks the agent expects to be able to call.
>
> >
> > Michael
> >
> >
> > On Tue, Dec 6, 2016 at 8:46 AM, Kosnik, Lubosz  > om> wrote:
> > > Hello Zhi,
> > > So currently we’re working on dropping LBasSv2 support.
> > > Octavia is a big-tent project providing lbass in OpenStack and
> > > after merging
> > > LBasS v2 API in Octavia we will deprecate that project and in next
> > > 2
> > > releases we’re planning to completely wipe out that code
> > > repository. If you
> > > would like to help with LBasS in OpenStack you’re more than welcome
> > > to start
> > > working with us on Octavia.
> > >
> > > Cheers,
> > > Lubosz Kosnik
> > > Cloud Software Engineer OSIC
> > >
> > > On Dec 6, 2016, at 6:04 AM, Gary Kotton  wrote:
> > >
> > > Hi,
> > > I think that there is a move to Octavia. I suggest reaching out to
> > > that
> > > community and see how these changes can be added. Sounds like a
> > > nice
> > > addition
> > > Thanks
> > > Gary
> > >
> > > From: zhi 
> > > Reply-To: OpenStack List 
> > > Date: Tuesday, December 6, 2016 at 11:06 AM
> > > To: OpenStack List 
> > > Subject: [openstack-dev] [neutron][lbaas] New extensions for
> > > HAProxy driver
> > > based LBaaSv2
> > >
> > > Hi, all
> > >
> > > I am considering add some new extensions for HAProxy driver based
> > > Neutron
> > > LBaaSv2.
> > >
> > > Extension 1, multi subprocesses supported. By following this
> > > document[1], I
> > > think we can let our HAProxy based LBaaSv2 support this feature. By
> > > adding
> > > this feature, we can enhance loadbalancers performance.
> > >
> > > Extension 2, http keep-alive supported. By following this
> > > document[2], we
> > > can make our loadbalancers more effective.
> > >
> > >
> > > Any comments are welcome!
> > >
> > > Thanks
> > > Zhi Chang
> > >
> > >
> > > [1]: http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#c
> > > pu-map
> > > [2]:
> > > http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#option
> > > %20http-keep-alive
> > > ___
> > > ___
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > > bscribe
> > > 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:unsu
> > > bscribe
> > > 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:unsubs
> > cribe
> > 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] [ironic] [inspector] RFC: deprecating "set IPMI credentials" feature in ironic-inspector

[Jay Faulkner]

> On Dec 13, 2016, at 4:40 AM, Dmitry Tantsur  wrote:
> 
> Hi folks!
> 
> Since nearly its beginning, ironic-inspector has had a controversial feature: 
> we allow a user to request changing IPMI credentials of the node after 
> introspection. The new credentials are passed back from inspector to the 
> ramdisk, and the ramdisk calls "ipmitool" to set them.
> 
> Now I realize that the feature has quite a few substantial drawbacks:
> 1. It's a special case in ironic-inspector. It's the only thing that runs 
> after introspection, and it requires special state machine states and actions.
> 2. There is no way to signal errors back from the ramdisk. We can only poll 
> the nodes to see if the new credentials match.
> 3. This is the only place where ironic-inspector modifies physical nodes (as 
> opposed to modifying the ironic database). This feels like a violation of our 
> goal.
> 4. It depends on ipmitool actually being able to update credentials from 
> within the node without knowing the current ones. I'm not sure how wildly 
> it's supported. I'm pretty sure some hardware does not support it.
> 5. It's not and never will be tested by any CI. It's not possible to test on 
> VMs at all.
> 6. Due to its dangerous nature, this feature is hidden behind a configuration 
> option, and is disabled by default.
> 
> The upside I see is that it may play nicely with node autodiscovery. I'm not 
> sure they work together today, though. We didn't end up using this feature in 
> our products, and I don't recall being approached by people using it.
> 
> I suggest deprecating this feature and removing it in Pike. The rough plan is 
> as follows:
> 
> I. Ocata:
> * Deprecate the configuration option enabling this feature.
> * Create an API version that returns HTTP 400 when this feature is requested.
> * Deprecate the associated arguments in CLI.
> * Issue a deprecating warning in IPA when this feature is used.
> 
> II. Pike:
> * Remove the feature from IPA and ironic-inspector.
> * Remove the feature from CLI.
> 
> Please respond with your comments and/or objects to this thread. I'll soon 
> prepare a patch on which you'll also be able to comment.
> 

I agree with deprecating this version of this feature. I do see the potential 
for credential rotation as a thing Ironic could handle in the future, but it 
would need to be handled in a periodic fashion vs being done once at startup.

I’m +2 to what’s proposed.

-Jay

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

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

Re: [openstack-dev] [TripleO] Cheatsheets for FOSDEM and devconf

[Jason Rist]

On 12/13/2016 07:32 AM, Carlos Camacho Gonzalez wrote:
> Hi TripleOers!
> 
> We are working preparing some cheatsheets for people jumping into TripleO.
> 
> So there is an early WIP version for a few cheatsheets that we want to share:
> 
> -TripleO manual installation  (Just a copy/paste step-wise process to
> install TripleO)
> - Deployments debugging tips (Relevant commands to know what's
> happening with the deployment)
> - CI (URL's and resource to check our CI status)
> - OOOQ (Also a step-wise recipe to install OOOQ, does not exist yet)
> 
> We already have some drafts available in
> https://github.com/ccamacho/tripleo-cheatsheet
> 
> So, we will like to have some feedback from the community and make a
> stable version for the cheatsheets in the next week.
> 
> Feedback for adding/removing content and general reviews about all of
> them is welcomed.
> 
> Thanks!,
> 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
> 


It would be really great if you had a note about turning on the UI (edit
undercloud.conf, enable_mistral; enable_ui) as well.

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
OpenStack Development Mailing 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][tc] Video Meetings - input requested

[Michał Jastrzębski]

I really fail to see how add hoc meetings, if link will be posted openly on
IRC, notes made public and invitation extended to everyone would violate 4
opens. It's virtuality impossible in globally distributed project to have
everyone interested around at all times. All decisions made will be
reflected in gerrit when first code his it, etherpad or summary on IRC
afterwards will allow those not present to get up to speed.

I think we need to trust our fellow cores to have best interest of project
in mind even when we are not around. Any issues can be dealt with later as
well.

Cheers,
Michał

On Dec 13, 2016 5:12 AM, "Sean Dague"  wrote:

On 12/13/2016 08:02 AM, Thierry Carrez wrote:
> Ed Leafe wrote:
>> On Dec 12, 2016, at 11:16 AM, Jeffrey Zhang 
wrote:
>>
>>> Some contributors in kolla have had unscheduled video meetings. This has
>>> resulted in complaints about inclusiveness. Some contributors can’t
even make
>>> the meeting we have, and another scheduled video meeting might produce a
>>> situation in which there is no any record of decisions made during the
video
>>> meeting. At least with IRC meetings there is always a log.
>>
>> Occasionally a quick Google hangout is necessary in Nova in order to
quickly settle an outstanding issue so we can continue to make progress.
When that happens, the link is posted in the #openstack-nova channel, and
anyone who is interested can join. So while it’s not logged like an IRC
meeting, it’s no excluding anyone, and we can quickly remove roadblocks
that are harder to do in IRC.
>
> Last time I checked, Google Hangouts were not accessible from China...
> So it *is* excluding some contributors ?
>
> I think it's fine to use Hangouts or phone calls to quickly go through
> an issue. But if those become routine and if contributors express that
> those are making them feel (or be) excluded, then it is important to
> reassess your usage of them before it starts threatening our "open
> development" and "open community" pillars.
>
> And in all cases, regular team meetings (or decision-making meetings)
> should happen on IRC in logged channels.

There is definitely a reality that there are circumstances where
collaboration happens, and happens quickly, in some setting where not
everyone was around. Be it at a conference, randomly finding people in a
coffee shop, on a google hangout, a telephone call, etc.

I think the most important thing is to take the time to take whatever
happened there and put it out in open memory afterwards. For instance, a
write up to the mailing list with the notes of what about the issue, the
discussion, the resolution. This isn't only helpful for the people not
in the room, it's also really helpful even for those in the room 6 or 12
months later to try to recall why a particular course of action was taken.

-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

[openstack-dev] [TripleO] Cheatsheets for FOSDEM and devconf

[Carlos Camacho Gonzalez]

Hi TripleOers!

We are working preparing some cheatsheets for people jumping into TripleO.

So there is an early WIP version for a few cheatsheets that we want to share:

-TripleO manual installation  (Just a copy/paste step-wise process to
install TripleO)
- Deployments debugging tips (Relevant commands to know what's
happening with the deployment)
- CI (URL's and resource to check our CI status)
- OOOQ (Also a step-wise recipe to install OOOQ, does not exist yet)

We already have some drafts available in
https://github.com/ccamacho/tripleo-cheatsheet

So, we will like to have some feedback from the community and make a
stable version for the cheatsheets in the next week.

Feedback for adding/removing content and general reviews about all of
them is welcomed.

Thanks!,
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] [ironic] [inspector] RFC: deprecating "set IPMI credentials" feature in ironic-inspector

[Mario Villaplana]

Given that this seems to be a special case outside of what
ironic-inspector normally handles, I'd be +1 to removing it.

Perhaps this feature, if needed, is best implemented as a vendor
passthru in ironic itself.

Mario

On Tue, Dec 13, 2016 at 7:40 AM, Dmitry Tantsur  wrote:
> Hi folks!
>
> Since nearly its beginning, ironic-inspector has had a controversial
> feature: we allow a user to request changing IPMI credentials of the node
> after introspection. The new credentials are passed back from inspector to
> the ramdisk, and the ramdisk calls "ipmitool" to set them.
>
> Now I realize that the feature has quite a few substantial drawbacks:
> 1. It's a special case in ironic-inspector. It's the only thing that runs
> after introspection, and it requires special state machine states and
> actions.
> 2. There is no way to signal errors back from the ramdisk. We can only poll
> the nodes to see if the new credentials match.
> 3. This is the only place where ironic-inspector modifies physical nodes (as
> opposed to modifying the ironic database). This feels like a violation of
> our goal.
> 4. It depends on ipmitool actually being able to update credentials from
> within the node without knowing the current ones. I'm not sure how wildly
> it's supported. I'm pretty sure some hardware does not support it.
> 5. It's not and never will be tested by any CI. It's not possible to test on
> VMs at all.
> 6. Due to its dangerous nature, this feature is hidden behind a
> configuration option, and is disabled by default.
>
> The upside I see is that it may play nicely with node autodiscovery. I'm not
> sure they work together today, though. We didn't end up using this feature
> in our products, and I don't recall being approached by people using it.
>
> I suggest deprecating this feature and removing it in Pike. The rough plan
> is as follows:
>
> I. Ocata:
>  * Deprecate the configuration option enabling this feature.
>  * Create an API version that returns HTTP 400 when this feature is
> requested.
>  * Deprecate the associated arguments in CLI.
>  * Issue a deprecating warning in IPA when this feature is used.
>
> II. Pike:
>  * Remove the feature from IPA and ironic-inspector.
>  * Remove the feature from CLI.
>
> Please respond with your comments and/or objects to this thread. I'll soon
> prepare a patch on which you'll also be able to comment.
>
> Dmitry.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tripleo] Deep dive session about the UI - January 12

[Ana Krivokapic]

On Mon, Dec 12, 2016 at 7:30 PM, Ana Krivokapic  wrote:

> Hi Everyone,
>
> On the 12th of January 2017, I'll lead a TripleO deep dive[1] session on
> how to contribute to the TripleO UI. Hope to see many of you there!
>
>
> [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics
>
> --
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.
>

If you'd like a calendar invite for this deep dive, email me and I'll add
you to the meeting invite.


-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone

[Jay Pipes]

On 12/13/2016 08:09 AM, Kseniya Tychkova wrote:

Hi,
I would like to share a spec [1] with you.
The main idea of this spec is to start a discussion about quota
management in the OpenStack.

Quotas are scattered across OpenStack services. Each service defines
it's own model and API for
managing resource's limits. Because of that, there are several problems:

  * Names of the resources and resource-service mapping  are hardcoded.
They are hardcoded in the service code (Nova, for example) and it
should be hardcoded in the client code (Horizon, for example).

  * There is no centralized quota management for OpenStack projects.
  * Cinder, Nova and Neutron support (or going to support) hierarchical
quotas in different ways.

There should be a single point of managing quotas in OpenStack.
Keystone looks like a proper place to store resource's limits because:

  * Keystone stores projects
  * Limits are belong to project.


Another excellent reason to store quota limits in Keystone is because 
virtually all non-list operations require some interaction with quota 
limits, and requiring Nova (or Cinder or Neutron) to call out to yet 
another service each time the user makes one of those non-list 
operations is sub-optimal when Nova is already making a call to Keystone 
for authentication.


The alternative is to have a separate REST API service just for storing 
and returning the quota limits and have Nova, Cinder and Neutron call 
this new service each time a non-list operation is made. While this is 
possible, it's just yet another service that needs to be managed and 
deployed by all installations of OpenStack.


Best,
-jay


There are a lot of possible issues with “store limits in Keystone”
approach. But all of them can be discussed
and such discussion should lead to the good solution for quotas
management  in Openstack.

Please take a look at the spec when you have time and share your ideas
or concerns.

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


Kind regards,
Kseniya






__
OpenStack Development Mailing 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] [keystone][nova]Quotas: Store resources and limits in the Keystone

[Kseniya Tychkova]

Hi,
I would like to share a spec [1] with you.
The main idea of this spec is to start a discussion about quota management
in the OpenStack.

Quotas are scattered across OpenStack services. Each service defines it's
own model and API for
managing resource's limits. Because of that, there are several problems:

   - Names of the resources and resource-service mapping  are hardcoded.
   They are hardcoded in the service code (Nova, for example) and it should be
   hardcoded in the client code (Horizon, for example).


   - There is no centralized quota management for OpenStack projects.
   - Cinder, Nova and Neutron support (or going to support) hierarchical
   quotas in different ways.

There should be a single point of managing quotas in OpenStack.
Keystone looks like a proper place to store resource's limits because:

   - Keystone stores projects
   - Limits are belong to project.


There are a lot of possible issues with “store limits in Keystone”
approach. But all of them can be discussed
and such discussion should lead to the good solution for quotas management
 in Openstack.

Please take a look at the spec when you have time and share your ideas or
concerns.

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


Kind regards,
Kseniya
__
OpenStack Development Mailing 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][tc] Video Meetings - input requested

[Sean Dague]

On 12/13/2016 08:02 AM, Thierry Carrez wrote:
> Ed Leafe wrote:
>> On Dec 12, 2016, at 11:16 AM, Jeffrey Zhang  wrote:
>>
>>> Some contributors in kolla have had unscheduled video meetings. This has
>>> resulted in complaints about inclusiveness. Some contributors can’t even 
>>> make
>>> the meeting we have, and another scheduled video meeting might produce a
>>> situation in which there is no any record of decisions made during the video
>>> meeting. At least with IRC meetings there is always a log.
>>
>> Occasionally a quick Google hangout is necessary in Nova in order to quickly 
>> settle an outstanding issue so we can continue to make progress. When that 
>> happens, the link is posted in the #openstack-nova channel, and anyone who 
>> is interested can join. So while it’s not logged like an IRC meeting, it’s 
>> no excluding anyone, and we can quickly remove roadblocks that are harder to 
>> do in IRC.
> 
> Last time I checked, Google Hangouts were not accessible from China...
> So it *is* excluding some contributors ?
> 
> I think it's fine to use Hangouts or phone calls to quickly go through
> an issue. But if those become routine and if contributors express that
> those are making them feel (or be) excluded, then it is important to
> reassess your usage of them before it starts threatening our "open
> development" and "open community" pillars.
> 
> And in all cases, regular team meetings (or decision-making meetings)
> should happen on IRC in logged channels.

There is definitely a reality that there are circumstances where
collaboration happens, and happens quickly, in some setting where not
everyone was around. Be it at a conference, randomly finding people in a
coffee shop, on a google hangout, a telephone call, etc.

I think the most important thing is to take the time to take whatever
happened there and put it out in open memory afterwards. For instance, a
write up to the mailing list with the notes of what about the issue, the
discussion, the resolution. This isn't only helpful for the people not
in the room, it's also really helpful even for those in the room 6 or 12
months later to try to recall why a particular course of action was taken.

-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] [kolla][tc] Video Meetings - input requested

[Thierry Carrez]

Ed Leafe wrote:
> On Dec 12, 2016, at 11:16 AM, Jeffrey Zhang  wrote:
> 
>> Some contributors in kolla have had unscheduled video meetings. This has
>> resulted in complaints about inclusiveness. Some contributors can’t even make
>> the meeting we have, and another scheduled video meeting might produce a
>> situation in which there is no any record of decisions made during the video
>> meeting. At least with IRC meetings there is always a log.
> 
> Occasionally a quick Google hangout is necessary in Nova in order to quickly 
> settle an outstanding issue so we can continue to make progress. When that 
> happens, the link is posted in the #openstack-nova channel, and anyone who is 
> interested can join. So while it’s not logged like an IRC meeting, it’s no 
> excluding anyone, and we can quickly remove roadblocks that are harder to do 
> in IRC.

Last time I checked, Google Hangouts were not accessible from China...
So it *is* excluding some contributors ?

I think it's fine to use Hangouts or phone calls to quickly go through
an issue. But if those become routine and if contributors express that
those are making them feel (or be) excluded, then it is important to
reassess your usage of them before it starts threatening our "open
development" and "open community" pillars.

And in all cases, regular team meetings (or decision-making meetings)
should happen on IRC in logged channels.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [cinder] drbdmanage is no more GPL2

[Thierry Carrez]

Jeremy Stanley wrote:
> On 2016-12-12 16:44:53 + (+), Duncan Thomas wrote:
> [...]
>> Having read the Openstack rules linked to earlier in the thread
>> ( https://governance.openstack.org/tc/reference/licensing.html )
>> we're clearly violating that.
> [...]
> 
> Keep in mind that those guidelines were drafted in collaboration
> with legal counsel for the foundation, and so do not merely
> represent community ideals we strive to meet but actual legal
> obligations to avoid license incompatibilities where driver
> interfaces can imply derivative works. There's been some
> cross-project review of driver commonalities/differences underway to
> inform a more structured legal discussion. It's not complete yet as
> far as I know, but expect the broader discussion on it to resume
> fairly soon.

We also wanted to make progress on the driver-teams discussion (see
[1]), so that we know what options we can offer to driver developers
before we settle on where the non-FOSS lib/CLI/interface line lies for
in-tree, out-tree but in-openstack, and out-openstack.

I hope the driver teams discussion can be settled at the TC meeting
today, so hopefully the broader discussion can resume soon.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-November/108074.html

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [ironic] [inspector] RFC: deprecating "set IPMI credentials" feature in ironic-inspector

[Dmitry Tantsur]

Hi folks!

Since nearly its beginning, ironic-inspector has had a controversial feature: we 
allow a user to request changing IPMI credentials of the node after 
introspection. The new credentials are passed back from inspector to the 
ramdisk, and the ramdisk calls "ipmitool" to set them.


Now I realize that the feature has quite a few substantial drawbacks:
1. It's a special case in ironic-inspector. It's the only thing that runs after 
introspection, and it requires special state machine states and actions.
2. There is no way to signal errors back from the ramdisk. We can only poll the 
nodes to see if the new credentials match.
3. This is the only place where ironic-inspector modifies physical nodes (as 
opposed to modifying the ironic database). This feels like a violation of our goal.
4. It depends on ipmitool actually being able to update credentials from within 
the node without knowing the current ones. I'm not sure how wildly it's 
supported. I'm pretty sure some hardware does not support it.
5. It's not and never will be tested by any CI. It's not possible to test on VMs 
at all.
6. Due to its dangerous nature, this feature is hidden behind a configuration 
option, and is disabled by default.


The upside I see is that it may play nicely with node autodiscovery. I'm not 
sure they work together today, though. We didn't end up using this feature in 
our products, and I don't recall being approached by people using it.


I suggest deprecating this feature and removing it in Pike. The rough plan is as 
follows:


I. Ocata:
 * Deprecate the configuration option enabling this feature.
 * Create an API version that returns HTTP 400 when this feature is requested.
 * Deprecate the associated arguments in CLI.
 * Issue a deprecating warning in IPA when this feature is used.

II. Pike:
 * Remove the feature from IPA and ironic-inspector.
 * Remove the feature from CLI.

Please respond with your comments and/or objects to this thread. I'll soon 
prepare a patch on which you'll also be able to comment.


Dmitry.

__
OpenStack Development Mailing 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] [charms] bug squash thursdays

[James Page]

Hi Team

Our last (and only) bug day was quite popular/successful, so lets try and
have one focus day on bugs a month.

So from January, the first Thursday of the month will officially be 'Charm
Bug Squash Day'.

The objective of the day is to triage any untouched bugs, sift through
triaged bugs in priority order and fix any long standing niggles and issues
in the charm set!

See you all on #openstack-charms on the 5th January for some bug triage and
fixing fun!

Cheers

James

P.S. please also continue to look at bugs on days other than the first
Thursday of the month!
__
OpenStack Development Mailing 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] [charms] irc meetings for next few weeks

[James Page]

Hi All

As we're approaching a period where quite a few people will be having time
off, I'm cancelling the IRC meetings on Mondays (1000 and 1700 on alternate
weeks) until the 9th January at 1700 UTC - at which point we'll resume
normal service, with the next meeting after that at 1000 UTC on the 16th.

Have a nice break if you're taking some time out!

Cheers

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

[openstack-dev] Stuart McLaren stepping down from Glance core

[Brian Rosmaita]

Stuart McLaren has communicated to me that he's no longer able to commit
time to working on Glance, and he's stepping down from the core
reviewers' team.  I'd like to thank Stuart for all his past service to
Glance, which has been substantial ... he'll be much missed.  I'd
particularly like to thank him for his last review on [0], which was an
announced Glance priority for Ocata - Stuart was seriously fulfilling
his duties as a core reviewer right until the end.

I'm really sorry to see Stuart move on, and hope that at some point in
the future he'll find time to work on Glance again.  We can always use
someone with his technical acumen and collegial attitude!

(Hopefully Stuart will be able to send his own note soon, but he's
having some problems with his emails being rejected from the ML at the
moment.)

[0] https://review.openstack.org/#/c/331489/



__
OpenStack Development Mailing 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] iscsi-deploy vs agent-deploy comparison

[Lucas Alvares Gomes]

Hi Pavlo,

On Tue, Dec 13, 2016 at 11:52 AM, Pavlo Shchelokovskyy
 wrote:
> Hi all,
>
> recent comments in some of my patches hinted me that I might be missing some
> understanding of ironic workings, so I'd like to ask the following question:
>
> What features/possibilities the iscsi-deploy currently has that agent-deploy
> has not (for example comparing pxe_ipmitool and agent_ipmitool drivers)?
>
> The only thing I'm aware of is that agent-deploy requires user images to be
> accessible over clean no-auth HTTP from inside provisioning network (and in
> integrated deployment that means swift as glance backend) while iscsi-deploy
> does not need this (works with arbitrary glance backend / not reachable from
> provisioning network).
>
> Are there other advantages of iscsi-deploy compared to agent-deploy?
>

Very few that I can think of: Deploying with ISCSI requires less RAM
because IPA won't need to convert the user image in-band before
copying it to the disk device*, the ironic-conductor will do the
conversion and writing onto the iSCSI device. And, the iSCSI code may
also help as a base to the boot from volume work.

So, thanks for this email. I think it might be a good time to start
discussing whether we should get rid of the iSCSI approach or not
since it has very little to offer overall.

* If memory is a problem, the agent driver could stream a raw image
directly onto the disk as well.

Cheers,
Lucas

__
OpenStack Development Mailing 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] [ironic] iscsi-deploy vs agent-deploy comparison

[Pavlo Shchelokovskyy]

Hi all,

recent comments in some of my patches hinted me that I might be missing
some understanding of ironic workings, so I'd like to ask the following
question:

What features/possibilities the iscsi-deploy currently has that
agent-deploy has not (for example comparing pxe_ipmitool and agent_ipmitool
drivers)?

The only thing I'm aware of is that agent-deploy requires user images to be
accessible over clean no-auth HTTP from inside provisioning network (and in
integrated deployment that means swift as glance backend) while
iscsi-deploy does not need this (works with arbitrary glance backend / not
reachable from provisioning network).

Are there other advantages of iscsi-deploy compared to agent-deploy?

Best regards,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

Yep, what Saravanan said is fine.
The idea i had on mind, is to drop the config on /etc/default/grub, so when
ironic deploys the image and installs grub, the parameters are applied
properly. We did some POCs with that in the past, and Ironic was booting
the images with the right kernel params.
The documentation you talk about is how to do it now, but we have the hope
it can change, because reboots can be problematic under some environments
in production.

On Tue, Dec 13, 2016 at 12:28 PM, Oliver Walsh  wrote:

> Hi Saravanan,
>
> Ah, ok. I'd assumed ironic didn't touch the bootloader as the docs
> show a mkconfig & reboot to customize grub for localboot:
> http://docs.openstack.org/project-install-guide/
> baremetal/draft/advanced.html#appending-kernel-parameters-
> to-boot-instances.
>
> Thanks,
> Ollie
>
> On 13 December 2016 at 11:03, Saravanan KR  wrote:
> > Hi Oliver,
> >
> > During the deployment, Ironic will start the node with IPA ramdisk,
> > which will copy the overcloud image to the node's disk, then configure
> > the grub cfg [1], set the node to local boot and reboot the node.
> > After which the node will be boot with the overcloud image. So no
> > reboot required in the overcloud image, as the "deploy steps" will be
> > run by the IPA itself.
> >
> > Regards,
> > Saravanan KR
> >
> > [1] https://github.com/openstack/ironic-python-agent/blob/
> master/ironic_python_agent/extensions/image.py#L136
> >
> >
> > On Tue, Dec 13, 2016 at 4:18 PM, Oliver Walsh  wrote:
> >> Hi Yolanda,
> >>
> >>> these changes will be created by ironic before the image is deployed
> >>
> >> The question I'm asking is how are the changed created without a reboot?
> >>
> >> Typically when setting this via a manual change or via tuned the
> >> process is to modify /etc/default/grub, run grub2-mkconfig, and then
> >> reboot. Are you suggesting we drop in a pre-build grub cfg before
> >> deployment?
> >>
> >> Thanks,
> >> Ollie
> >>
> >> On 13 December 2016 at 10:33, Yolanda Robla Mota 
> wrote:
> >>> It won't need a reboot, because these changes will be created by ironic
> >>> before the image is deployed. So it will boot with the right
> parameters. The
> >>> alternative of doing with puppet after the image was deployed, needed a
> >>> reboot, because the changes were done post-deploy.
> >>> So ironic build steps are pre-deploy without reboot, puppet changes are
> >>> post-deploy with a reboot.
> >>>
> >>> On Tue, Dec 13, 2016 at 11:24 AM, Oliver Walsh 
> wrote:
> 
>  Hi,
> 
>  Saravanan wrote:
>  > If ironic "deploy steps" can configure this "tuned" setting and run
> the
>  > command
> 
>  How does this avoid the reboot?
> 
>  Yolanda wrote:
>  > The idea will be to define custom deployment steps for ironic, like
>  > including the kernel boot parameters.
> 
>  Again, is this avoiding the reboot or just moving it?
> 
>  Thanks,
>  Ollie
> 
>  On 13 December 2016 at 09:02, Saravanan KR 
> wrote:
>  > Hi Yolanda,
>  >
>  > The flow for "tuned" will be like set the "tuned" configuration
> files,
>  > and then activate the profile by running the command "tuned-adm
>  > tuned-profile-nfv". This command will actually write the required
>  > configuration files for tuning the host. If ironic "deploy steps"
> can
>  > configure this "tuned" setting and run the command, then it is good
>  > enough.
>  >
>  > Regards,
>  > Saravanan KR
>  >
>  > On Tue, Dec 13, 2016 at 1:04 PM, Yolanda Robla Mota
>  >  wrote:
>  >> Hi Saravanan
>  >> Thanks for your comments. With this new module, I guess a reboot is
>  >> still
>  >> needed after os-host-config ?
>  >> Right now we have been guided by TripleO and Ironic people to start
>  >> using
>  >> what in Ironic is called "custom deployment steps". An initial
> spec is
>  >> reflected here:
>  >> https://review.openstack.org/#/c/382091
>  >>
>  >> The idea will be to define custom deployment steps for ironic, like
>  >> including the kernel boot parameters. Can that be a solution for
> your
>  >> "tuned" needs as well?
>  >>
>  >> Best
>  >> Yolanda
>  >>
>  >> On Tue, Dec 13, 2016 at 7:59 AM, Saravanan KR  >
>  >> wrote:
>  >>>
>  >>> Hello,
>  >>>
>  >>> Thanks Yolanda for starting the thread. The list of requirements
> in
>  >>> the host configuration, related to boot parameters and reboot are:
>  >>>
>  >>> * DPDK - For vfio-pci driver binding, iommu support on kernel
> args is
>  >>> mandatory, which has to be configured before os-net-config runs
>  >>> * DPDK & RealTime - Enabling "tuned" profile for nfv or rt, will
>  >>> update the boot parameters and a reboot is required
> 

Re: [openstack-dev] OpenStack New Years Resolutions

[Boris Pavlovic]

Jean-Philippe,


> s/COBOL/go/g and it makes your comment even funnier.


It makes it scary =)

Best regards,
Boris Pavlovic

On Tue, Dec 13, 2016 at 2:24 AM, Jean-Philippe Evrard <
jean-philippe.evr...@rackspace.co.uk> wrote:

> s/COBOL/go/g and it makes your comment even funnier.
>
> Best regards,
> JP
>
> On 13/12/2016, 00:00, "Jay Pipes"  wrote:
>
> On 12/12/2016 06:40 PM, Nick Chase wrote:
> > OK, so if you were putting together New Year's Resolutions for
> OpenStack
> > development for 2017, what would they be?
>
> My resolution will be to rewrite Nova in COBOL. Oh wait, no, that's for
> April 1st, not New Years...
>
> 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
>
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Oliver Walsh]

Hi Saravanan,

Ah, ok. I'd assumed ironic didn't touch the bootloader as the docs
show a mkconfig & reboot to customize grub for localboot:
http://docs.openstack.org/project-install-guide/baremetal/draft/advanced.html#appending-kernel-parameters-to-boot-instances.

Thanks,
Ollie

On 13 December 2016 at 11:03, Saravanan KR  wrote:
> Hi Oliver,
>
> During the deployment, Ironic will start the node with IPA ramdisk,
> which will copy the overcloud image to the node's disk, then configure
> the grub cfg [1], set the node to local boot and reboot the node.
> After which the node will be boot with the overcloud image. So no
> reboot required in the overcloud image, as the "deploy steps" will be
> run by the IPA itself.
>
> Regards,
> Saravanan KR
>
> [1] 
> https://github.com/openstack/ironic-python-agent/blob/master/ironic_python_agent/extensions/image.py#L136
>
>
> On Tue, Dec 13, 2016 at 4:18 PM, Oliver Walsh  wrote:
>> Hi Yolanda,
>>
>>> these changes will be created by ironic before the image is deployed
>>
>> The question I'm asking is how are the changed created without a reboot?
>>
>> Typically when setting this via a manual change or via tuned the
>> process is to modify /etc/default/grub, run grub2-mkconfig, and then
>> reboot. Are you suggesting we drop in a pre-build grub cfg before
>> deployment?
>>
>> Thanks,
>> Ollie
>>
>> On 13 December 2016 at 10:33, Yolanda Robla Mota  wrote:
>>> It won't need a reboot, because these changes will be created by ironic
>>> before the image is deployed. So it will boot with the right parameters. The
>>> alternative of doing with puppet after the image was deployed, needed a
>>> reboot, because the changes were done post-deploy.
>>> So ironic build steps are pre-deploy without reboot, puppet changes are
>>> post-deploy with a reboot.
>>>
>>> On Tue, Dec 13, 2016 at 11:24 AM, Oliver Walsh  wrote:

 Hi,

 Saravanan wrote:
 > If ironic "deploy steps" can configure this "tuned" setting and run the
 > command

 How does this avoid the reboot?

 Yolanda wrote:
 > The idea will be to define custom deployment steps for ironic, like
 > including the kernel boot parameters.

 Again, is this avoiding the reboot or just moving it?

 Thanks,
 Ollie

 On 13 December 2016 at 09:02, Saravanan KR  wrote:
 > Hi Yolanda,
 >
 > The flow for "tuned" will be like set the "tuned" configuration files,
 > and then activate the profile by running the command "tuned-adm
 > tuned-profile-nfv". This command will actually write the required
 > configuration files for tuning the host. If ironic "deploy steps" can
 > configure this "tuned" setting and run the command, then it is good
 > enough.
 >
 > Regards,
 > Saravanan KR
 >
 > On Tue, Dec 13, 2016 at 1:04 PM, Yolanda Robla Mota
 >  wrote:
 >> Hi Saravanan
 >> Thanks for your comments. With this new module, I guess a reboot is
 >> still
 >> needed after os-host-config ?
 >> Right now we have been guided by TripleO and Ironic people to start
 >> using
 >> what in Ironic is called "custom deployment steps". An initial spec is
 >> reflected here:
 >> https://review.openstack.org/#/c/382091
 >>
 >> The idea will be to define custom deployment steps for ironic, like
 >> including the kernel boot parameters. Can that be a solution for your
 >> "tuned" needs as well?
 >>
 >> Best
 >> Yolanda
 >>
 >> On Tue, Dec 13, 2016 at 7:59 AM, Saravanan KR 
 >> wrote:
 >>>
 >>> Hello,
 >>>
 >>> Thanks Yolanda for starting the thread. The list of requirements in
 >>> the host configuration, related to boot parameters and reboot are:
 >>>
 >>> * DPDK - For vfio-pci driver binding, iommu support on kernel args is
 >>> mandatory, which has to be configured before os-net-config runs
 >>> * DPDK & RealTime - Enabling "tuned" profile for nfv or rt, will
 >>> update the boot parameters and a reboot is required
 >>> * Other items mentioned by Yolanda
 >>>
 >>> If it is configuring only, the boot parameters, then ironic's deploy
 >>> feature may help, but there are other requirement to enable the
 >>> "tuned" profile which tunes the host for the required configuration,
 >>> which also requires reboot, as it will alter the boot parameters. If
 >>> we can collate the all the configurations which requires reboot
 >>> together, we will improve the reboot time. And if we reboot before the
 >>> actual openstack services are started, then the reboot time _may_
 >>> improve.
 >>>
 >>> Can I propose a *new* module for TripleO deployments, like >
 >>> os-host-config <, which will run after os-collect-config and before
 >>> os-net-config, then 

[openstack-dev] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting tomorrow. The meeting is being held
Wednesday UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

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

[openstack-dev] [Blazar] Meeting in PTG

[Masahito MUROI]

Hi Blazar folks,

Blazar team is thinking of whether having a meeting in PTG or not. IIRC,  
most of the team members is also a member of another team. So if  
someones are in PTG and has free time slot, we could have blazar team  
meeting in PTG.


Of cause, we don't have official rooms and time slots in PTG. So the  
meeting would be short and like ad-hock meeting style. But we could have  
good progress in there.


Does anyone in the team plan to go PTG? And should we have meeting in  
PTG?  Please let me know your ideas.


best regards,
Masahito



__
OpenStack Development Mailing 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] [ironic] Need to update kernel parameters on local boot

[Saravanan KR]

Hi Oliver,

During the deployment, Ironic will start the node with IPA ramdisk,
which will copy the overcloud image to the node's disk, then configure
the grub cfg [1], set the node to local boot and reboot the node.
After which the node will be boot with the overcloud image. So no
reboot required in the overcloud image, as the "deploy steps" will be
run by the IPA itself.

Regards,
Saravanan KR

[1] 
https://github.com/openstack/ironic-python-agent/blob/master/ironic_python_agent/extensions/image.py#L136


On Tue, Dec 13, 2016 at 4:18 PM, Oliver Walsh  wrote:
> Hi Yolanda,
>
>> these changes will be created by ironic before the image is deployed
>
> The question I'm asking is how are the changed created without a reboot?
>
> Typically when setting this via a manual change or via tuned the
> process is to modify /etc/default/grub, run grub2-mkconfig, and then
> reboot. Are you suggesting we drop in a pre-build grub cfg before
> deployment?
>
> Thanks,
> Ollie
>
> On 13 December 2016 at 10:33, Yolanda Robla Mota  wrote:
>> It won't need a reboot, because these changes will be created by ironic
>> before the image is deployed. So it will boot with the right parameters. The
>> alternative of doing with puppet after the image was deployed, needed a
>> reboot, because the changes were done post-deploy.
>> So ironic build steps are pre-deploy without reboot, puppet changes are
>> post-deploy with a reboot.
>>
>> On Tue, Dec 13, 2016 at 11:24 AM, Oliver Walsh  wrote:
>>>
>>> Hi,
>>>
>>> Saravanan wrote:
>>> > If ironic "deploy steps" can configure this "tuned" setting and run the
>>> > command
>>>
>>> How does this avoid the reboot?
>>>
>>> Yolanda wrote:
>>> > The idea will be to define custom deployment steps for ironic, like
>>> > including the kernel boot parameters.
>>>
>>> Again, is this avoiding the reboot or just moving it?
>>>
>>> Thanks,
>>> Ollie
>>>
>>> On 13 December 2016 at 09:02, Saravanan KR  wrote:
>>> > Hi Yolanda,
>>> >
>>> > The flow for "tuned" will be like set the "tuned" configuration files,
>>> > and then activate the profile by running the command "tuned-adm
>>> > tuned-profile-nfv". This command will actually write the required
>>> > configuration files for tuning the host. If ironic "deploy steps" can
>>> > configure this "tuned" setting and run the command, then it is good
>>> > enough.
>>> >
>>> > Regards,
>>> > Saravanan KR
>>> >
>>> > On Tue, Dec 13, 2016 at 1:04 PM, Yolanda Robla Mota
>>> >  wrote:
>>> >> Hi Saravanan
>>> >> Thanks for your comments. With this new module, I guess a reboot is
>>> >> still
>>> >> needed after os-host-config ?
>>> >> Right now we have been guided by TripleO and Ironic people to start
>>> >> using
>>> >> what in Ironic is called "custom deployment steps". An initial spec is
>>> >> reflected here:
>>> >> https://review.openstack.org/#/c/382091
>>> >>
>>> >> The idea will be to define custom deployment steps for ironic, like
>>> >> including the kernel boot parameters. Can that be a solution for your
>>> >> "tuned" needs as well?
>>> >>
>>> >> Best
>>> >> Yolanda
>>> >>
>>> >> On Tue, Dec 13, 2016 at 7:59 AM, Saravanan KR 
>>> >> wrote:
>>> >>>
>>> >>> Hello,
>>> >>>
>>> >>> Thanks Yolanda for starting the thread. The list of requirements in
>>> >>> the host configuration, related to boot parameters and reboot are:
>>> >>>
>>> >>> * DPDK - For vfio-pci driver binding, iommu support on kernel args is
>>> >>> mandatory, which has to be configured before os-net-config runs
>>> >>> * DPDK & RealTime - Enabling "tuned" profile for nfv or rt, will
>>> >>> update the boot parameters and a reboot is required
>>> >>> * Other items mentioned by Yolanda
>>> >>>
>>> >>> If it is configuring only, the boot parameters, then ironic's deploy
>>> >>> feature may help, but there are other requirement to enable the
>>> >>> "tuned" profile which tunes the host for the required configuration,
>>> >>> which also requires reboot, as it will alter the boot parameters. If
>>> >>> we can collate the all the configurations which requires reboot
>>> >>> together, we will improve the reboot time. And if we reboot before the
>>> >>> actual openstack services are started, then the reboot time _may_
>>> >>> improve.
>>> >>>
>>> >>> Can I propose a *new* module for TripleO deployments, like >
>>> >>> os-host-config <, which will run after os-collect-config and before
>>> >>> os-net-config, then we can collate all the host specific configuration
>>> >>> inside this module. This module can be a set of ansible scripts, which
>>> >>> will only configure the host. Ofcource the parameter to this module
>>> >>> should be provided via os-collect-config. Separating the host
>>> >>> configuration will help in the containerized TripleO deployment also.
>>> >>>
>>> >>> Or any other better alternatives are welcome.
>>> >>>
>>> >>> Please pour in your views if you think 

Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Oliver Walsh]

Hi Yolanda,

> these changes will be created by ironic before the image is deployed

The question I'm asking is how are the changed created without a reboot?

Typically when setting this via a manual change or via tuned the
process is to modify /etc/default/grub, run grub2-mkconfig, and then
reboot. Are you suggesting we drop in a pre-build grub cfg before
deployment?

Thanks,
Ollie

On 13 December 2016 at 10:33, Yolanda Robla Mota  wrote:
> It won't need a reboot, because these changes will be created by ironic
> before the image is deployed. So it will boot with the right parameters. The
> alternative of doing with puppet after the image was deployed, needed a
> reboot, because the changes were done post-deploy.
> So ironic build steps are pre-deploy without reboot, puppet changes are
> post-deploy with a reboot.
>
> On Tue, Dec 13, 2016 at 11:24 AM, Oliver Walsh  wrote:
>>
>> Hi,
>>
>> Saravanan wrote:
>> > If ironic "deploy steps" can configure this "tuned" setting and run the
>> > command
>>
>> How does this avoid the reboot?
>>
>> Yolanda wrote:
>> > The idea will be to define custom deployment steps for ironic, like
>> > including the kernel boot parameters.
>>
>> Again, is this avoiding the reboot or just moving it?
>>
>> Thanks,
>> Ollie
>>
>> On 13 December 2016 at 09:02, Saravanan KR  wrote:
>> > Hi Yolanda,
>> >
>> > The flow for "tuned" will be like set the "tuned" configuration files,
>> > and then activate the profile by running the command "tuned-adm
>> > tuned-profile-nfv". This command will actually write the required
>> > configuration files for tuning the host. If ironic "deploy steps" can
>> > configure this "tuned" setting and run the command, then it is good
>> > enough.
>> >
>> > Regards,
>> > Saravanan KR
>> >
>> > On Tue, Dec 13, 2016 at 1:04 PM, Yolanda Robla Mota
>> >  wrote:
>> >> Hi Saravanan
>> >> Thanks for your comments. With this new module, I guess a reboot is
>> >> still
>> >> needed after os-host-config ?
>> >> Right now we have been guided by TripleO and Ironic people to start
>> >> using
>> >> what in Ironic is called "custom deployment steps". An initial spec is
>> >> reflected here:
>> >> https://review.openstack.org/#/c/382091
>> >>
>> >> The idea will be to define custom deployment steps for ironic, like
>> >> including the kernel boot parameters. Can that be a solution for your
>> >> "tuned" needs as well?
>> >>
>> >> Best
>> >> Yolanda
>> >>
>> >> On Tue, Dec 13, 2016 at 7:59 AM, Saravanan KR 
>> >> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> Thanks Yolanda for starting the thread. The list of requirements in
>> >>> the host configuration, related to boot parameters and reboot are:
>> >>>
>> >>> * DPDK - For vfio-pci driver binding, iommu support on kernel args is
>> >>> mandatory, which has to be configured before os-net-config runs
>> >>> * DPDK & RealTime - Enabling "tuned" profile for nfv or rt, will
>> >>> update the boot parameters and a reboot is required
>> >>> * Other items mentioned by Yolanda
>> >>>
>> >>> If it is configuring only, the boot parameters, then ironic's deploy
>> >>> feature may help, but there are other requirement to enable the
>> >>> "tuned" profile which tunes the host for the required configuration,
>> >>> which also requires reboot, as it will alter the boot parameters. If
>> >>> we can collate the all the configurations which requires reboot
>> >>> together, we will improve the reboot time. And if we reboot before the
>> >>> actual openstack services are started, then the reboot time _may_
>> >>> improve.
>> >>>
>> >>> Can I propose a *new* module for TripleO deployments, like >
>> >>> os-host-config <, which will run after os-collect-config and before
>> >>> os-net-config, then we can collate all the host specific configuration
>> >>> inside this module. This module can be a set of ansible scripts, which
>> >>> will only configure the host. Ofcource the parameter to this module
>> >>> should be provided via os-collect-config. Separating the host
>> >>> configuration will help in the containerized TripleO deployment also.
>> >>>
>> >>> Or any other better alternatives are welcome.
>> >>>
>> >>> Please pour in your views if you think for/against it.
>> >>>
>> >>> Regards,
>> >>> Saravanan KR
>> >>>
>> >>>
>> >>> On Fri, Dec 2, 2016 at 9:31 PM, Yolanda Robla Mota
>> >>> 
>> >>> wrote:
>> >>> > Hi , Dmitry
>> >>> > That's what i didn't get very clear. If all the deployment steps are
>> >>> > pre-imaging as that statement says, or every deploy step could be
>> >>> > isolated
>> >>> > and configured somehow.
>> >>> > I'm also a bit confused with that spec, because it mixes the concept
>> >>> > of
>> >>> > "deployment steps", will all the changes needed for runtime RAID.
>> >>> > Could it
>> >>> > be possible to separate into two separate ones?
>> >>> >
>> >>> > - Original Message -
>> >>> > From: "Dmitry 

Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

It won't need a reboot, because these changes will be created by ironic
before the image is deployed. So it will boot with the right parameters.
The alternative of doing with puppet after the image was deployed, needed a
reboot, because the changes were done post-deploy.
So ironic build steps are pre-deploy without reboot, puppet changes are
post-deploy with a reboot.

On Tue, Dec 13, 2016 at 11:24 AM, Oliver Walsh  wrote:

> Hi,
>
> Saravanan wrote:
> > If ironic "deploy steps" can configure this "tuned" setting and run the
> command
>
> How does this avoid the reboot?
>
> Yolanda wrote:
> > The idea will be to define custom deployment steps for ironic, like
> including the kernel boot parameters.
>
> Again, is this avoiding the reboot or just moving it?
>
> Thanks,
> Ollie
>
> On 13 December 2016 at 09:02, Saravanan KR  wrote:
> > Hi Yolanda,
> >
> > The flow for "tuned" will be like set the "tuned" configuration files,
> > and then activate the profile by running the command "tuned-adm
> > tuned-profile-nfv". This command will actually write the required
> > configuration files for tuning the host. If ironic "deploy steps" can
> > configure this "tuned" setting and run the command, then it is good
> > enough.
> >
> > Regards,
> > Saravanan KR
> >
> > On Tue, Dec 13, 2016 at 1:04 PM, Yolanda Robla Mota 
> wrote:
> >> Hi Saravanan
> >> Thanks for your comments. With this new module, I guess a reboot is
> still
> >> needed after os-host-config ?
> >> Right now we have been guided by TripleO and Ironic people to start
> using
> >> what in Ironic is called "custom deployment steps". An initial spec is
> >> reflected here:
> >> https://review.openstack.org/#/c/382091
> >>
> >> The idea will be to define custom deployment steps for ironic, like
> >> including the kernel boot parameters. Can that be a solution for your
> >> "tuned" needs as well?
> >>
> >> Best
> >> Yolanda
> >>
> >> On Tue, Dec 13, 2016 at 7:59 AM, Saravanan KR 
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> Thanks Yolanda for starting the thread. The list of requirements in
> >>> the host configuration, related to boot parameters and reboot are:
> >>>
> >>> * DPDK - For vfio-pci driver binding, iommu support on kernel args is
> >>> mandatory, which has to be configured before os-net-config runs
> >>> * DPDK & RealTime - Enabling "tuned" profile for nfv or rt, will
> >>> update the boot parameters and a reboot is required
> >>> * Other items mentioned by Yolanda
> >>>
> >>> If it is configuring only, the boot parameters, then ironic's deploy
> >>> feature may help, but there are other requirement to enable the
> >>> "tuned" profile which tunes the host for the required configuration,
> >>> which also requires reboot, as it will alter the boot parameters. If
> >>> we can collate the all the configurations which requires reboot
> >>> together, we will improve the reboot time. And if we reboot before the
> >>> actual openstack services are started, then the reboot time _may_
> >>> improve.
> >>>
> >>> Can I propose a *new* module for TripleO deployments, like >
> >>> os-host-config <, which will run after os-collect-config and before
> >>> os-net-config, then we can collate all the host specific configuration
> >>> inside this module. This module can be a set of ansible scripts, which
> >>> will only configure the host. Ofcource the parameter to this module
> >>> should be provided via os-collect-config. Separating the host
> >>> configuration will help in the containerized TripleO deployment also.
> >>>
> >>> Or any other better alternatives are welcome.
> >>>
> >>> Please pour in your views if you think for/against it.
> >>>
> >>> Regards,
> >>> Saravanan KR
> >>>
> >>>
> >>> On Fri, Dec 2, 2016 at 9:31 PM, Yolanda Robla Mota <
> yrobl...@redhat.com>
> >>> wrote:
> >>> > Hi , Dmitry
> >>> > That's what i didn't get very clear. If all the deployment steps are
> >>> > pre-imaging as that statement says, or every deploy step could be
> isolated
> >>> > and configured somehow.
> >>> > I'm also a bit confused with that spec, because it mixes the concept
> of
> >>> > "deployment steps", will all the changes needed for runtime RAID.
> Could it
> >>> > be possible to separate into two separate ones?
> >>> >
> >>> > - Original Message -
> >>> > From: "Dmitry Tantsur" 
> >>> > To: openstack-dev@lists.openstack.org
> >>> > Sent: Friday, December 2, 2016 3:51:30 PM
> >>> > Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel
> >>> > parameters on local boot
> >>> >
> >>> > On 12/02/2016 01:28 PM, Yolanda Robla Mota wrote:
> >>> >> Hi Dmitry
> >>> >>
> >>> >> So we've been looking at that spec you suggested, but we are
> wondering
> >>> >> if that will be useful for our use case. As the text says:
> >>> >>
> >>> >> The ``ironic-python-agent`` project and ``agent`` driver will be
> >>> >> adjusted to
> >>> >> support ``get_deploy_steps``. 

Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Oliver Walsh]

Hi,

Saravanan wrote:
> If ironic "deploy steps" can configure this "tuned" setting and run the 
> command

How does this avoid the reboot?

Yolanda wrote:
> The idea will be to define custom deployment steps for ironic, like including 
> the kernel boot parameters.

Again, is this avoiding the reboot or just moving it?

Thanks,
Ollie

On 13 December 2016 at 09:02, Saravanan KR  wrote:
> Hi Yolanda,
>
> The flow for "tuned" will be like set the "tuned" configuration files,
> and then activate the profile by running the command "tuned-adm
> tuned-profile-nfv". This command will actually write the required
> configuration files for tuning the host. If ironic "deploy steps" can
> configure this "tuned" setting and run the command, then it is good
> enough.
>
> Regards,
> Saravanan KR
>
> On Tue, Dec 13, 2016 at 1:04 PM, Yolanda Robla Mota  
> wrote:
>> Hi Saravanan
>> Thanks for your comments. With this new module, I guess a reboot is still
>> needed after os-host-config ?
>> Right now we have been guided by TripleO and Ironic people to start using
>> what in Ironic is called "custom deployment steps". An initial spec is
>> reflected here:
>> https://review.openstack.org/#/c/382091
>>
>> The idea will be to define custom deployment steps for ironic, like
>> including the kernel boot parameters. Can that be a solution for your
>> "tuned" needs as well?
>>
>> Best
>> Yolanda
>>
>> On Tue, Dec 13, 2016 at 7:59 AM, Saravanan KR  wrote:
>>>
>>> Hello,
>>>
>>> Thanks Yolanda for starting the thread. The list of requirements in
>>> the host configuration, related to boot parameters and reboot are:
>>>
>>> * DPDK - For vfio-pci driver binding, iommu support on kernel args is
>>> mandatory, which has to be configured before os-net-config runs
>>> * DPDK & RealTime - Enabling "tuned" profile for nfv or rt, will
>>> update the boot parameters and a reboot is required
>>> * Other items mentioned by Yolanda
>>>
>>> If it is configuring only, the boot parameters, then ironic's deploy
>>> feature may help, but there are other requirement to enable the
>>> "tuned" profile which tunes the host for the required configuration,
>>> which also requires reboot, as it will alter the boot parameters. If
>>> we can collate the all the configurations which requires reboot
>>> together, we will improve the reboot time. And if we reboot before the
>>> actual openstack services are started, then the reboot time _may_
>>> improve.
>>>
>>> Can I propose a *new* module for TripleO deployments, like >
>>> os-host-config <, which will run after os-collect-config and before
>>> os-net-config, then we can collate all the host specific configuration
>>> inside this module. This module can be a set of ansible scripts, which
>>> will only configure the host. Ofcource the parameter to this module
>>> should be provided via os-collect-config. Separating the host
>>> configuration will help in the containerized TripleO deployment also.
>>>
>>> Or any other better alternatives are welcome.
>>>
>>> Please pour in your views if you think for/against it.
>>>
>>> Regards,
>>> Saravanan KR
>>>
>>>
>>> On Fri, Dec 2, 2016 at 9:31 PM, Yolanda Robla Mota 
>>> wrote:
>>> > Hi , Dmitry
>>> > That's what i didn't get very clear. If all the deployment steps are
>>> > pre-imaging as that statement says, or every deploy step could be isolated
>>> > and configured somehow.
>>> > I'm also a bit confused with that spec, because it mixes the concept of
>>> > "deployment steps", will all the changes needed for runtime RAID. Could it
>>> > be possible to separate into two separate ones?
>>> >
>>> > - Original Message -
>>> > From: "Dmitry Tantsur" 
>>> > To: openstack-dev@lists.openstack.org
>>> > Sent: Friday, December 2, 2016 3:51:30 PM
>>> > Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel
>>> > parameters on local boot
>>> >
>>> > On 12/02/2016 01:28 PM, Yolanda Robla Mota wrote:
>>> >> Hi Dmitry
>>> >>
>>> >> So we've been looking at that spec you suggested, but we are wondering
>>> >> if that will be useful for our use case. As the text says:
>>> >>
>>> >> The ``ironic-python-agent`` project and ``agent`` driver will be
>>> >> adjusted to
>>> >> support ``get_deploy_steps``. That way, ``ironic-python-agent`` will be
>>> >> able
>>> >> to declare deploy steps to run prior to disk imaging, and operators
>>> >> will be
>>> >> able to extend ``ironic-python-agent`` to add any custom step.
>>> >>
>>> >> Our needs are different, actually we need to create a deployment step
>>> >> after imaging. We'd need an step that drops config on /etc/default/grub ,
>>> >> and updates it. This is a post-imaging deploy step, that modifies the 
>>> >> base
>>> >> image. Could ironic support these kind of steps, if there is a base 
>>> >> system
>>> >> to just define per-user steps?
>>> >
>>> > I thought that all deployment operations are converted to 

Re: [openstack-dev] OpenStack New Years Resolutions

[Jean-Philippe Evrard]

s/COBOL/go/g and it makes your comment even funnier.

Best regards,
JP

On 13/12/2016, 00:00, "Jay Pipes"  wrote:

On 12/12/2016 06:40 PM, Nick Chase wrote:
> OK, so if you were putting together New Year's Resolutions for OpenStack
> development for 2017, what would they be?

My resolution will be to rewrite Nova in COBOL. Oh wait, no, that's for
April 1st, not New Years...

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




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kuryr] Dec 14th kuryr-kubernetes syncup

[Antoni Segura Puimedon]

On Mon, Dec 12, 2016 at 6:49 PM, Antoni Segura Puimedon 
wrote:

> Hi fellow kuryrs!
>
> December 14th at 11:00 UTC we'll be having a video meeting [1] to sync
> about the current Kubernetes integration.
>

We're moving the meeting to bluejeans [3] so that we can have a recording


> There is an etherpad for the topics that we'll be covering [2]. Feel free
> to add topics and +1 the topics that you want to have discussion on.
>
> The objective of the meeting is to come to decision about short term
> design and implementation. If there is time, we'll also kick off design
> talk on some longer term items.
>
> Regards,
>
> Toni
>
>
> [1] https://plus.google.com/hangouts/_/calendar/
> aXJlbmFiLmRldkBnbWFpbC5jb20.2kstghq4tavlmnhkfpnrjqd3j4
> [2] https://etherpad.openstack.org/p/kuryr-kubernetes-dec14-syncup
>

[3] https://bluejeans.com/5508709975/
__
OpenStack Development Mailing 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] [ironic] Need to update kernel parameters on local boot

[Saravanan KR]

Hi Yolanda,

The flow for "tuned" will be like set the "tuned" configuration files,
and then activate the profile by running the command "tuned-adm
tuned-profile-nfv". This command will actually write the required
configuration files for tuning the host. If ironic "deploy steps" can
configure this "tuned" setting and run the command, then it is good
enough.

Regards,
Saravanan KR

On Tue, Dec 13, 2016 at 1:04 PM, Yolanda Robla Mota  wrote:
> Hi Saravanan
> Thanks for your comments. With this new module, I guess a reboot is still
> needed after os-host-config ?
> Right now we have been guided by TripleO and Ironic people to start using
> what in Ironic is called "custom deployment steps". An initial spec is
> reflected here:
> https://review.openstack.org/#/c/382091
>
> The idea will be to define custom deployment steps for ironic, like
> including the kernel boot parameters. Can that be a solution for your
> "tuned" needs as well?
>
> Best
> Yolanda
>
> On Tue, Dec 13, 2016 at 7:59 AM, Saravanan KR  wrote:
>>
>> Hello,
>>
>> Thanks Yolanda for starting the thread. The list of requirements in
>> the host configuration, related to boot parameters and reboot are:
>>
>> * DPDK - For vfio-pci driver binding, iommu support on kernel args is
>> mandatory, which has to be configured before os-net-config runs
>> * DPDK & RealTime - Enabling "tuned" profile for nfv or rt, will
>> update the boot parameters and a reboot is required
>> * Other items mentioned by Yolanda
>>
>> If it is configuring only, the boot parameters, then ironic's deploy
>> feature may help, but there are other requirement to enable the
>> "tuned" profile which tunes the host for the required configuration,
>> which also requires reboot, as it will alter the boot parameters. If
>> we can collate the all the configurations which requires reboot
>> together, we will improve the reboot time. And if we reboot before the
>> actual openstack services are started, then the reboot time _may_
>> improve.
>>
>> Can I propose a *new* module for TripleO deployments, like >
>> os-host-config <, which will run after os-collect-config and before
>> os-net-config, then we can collate all the host specific configuration
>> inside this module. This module can be a set of ansible scripts, which
>> will only configure the host. Ofcource the parameter to this module
>> should be provided via os-collect-config. Separating the host
>> configuration will help in the containerized TripleO deployment also.
>>
>> Or any other better alternatives are welcome.
>>
>> Please pour in your views if you think for/against it.
>>
>> Regards,
>> Saravanan KR
>>
>>
>> On Fri, Dec 2, 2016 at 9:31 PM, Yolanda Robla Mota 
>> wrote:
>> > Hi , Dmitry
>> > That's what i didn't get very clear. If all the deployment steps are
>> > pre-imaging as that statement says, or every deploy step could be isolated
>> > and configured somehow.
>> > I'm also a bit confused with that spec, because it mixes the concept of
>> > "deployment steps", will all the changes needed for runtime RAID. Could it
>> > be possible to separate into two separate ones?
>> >
>> > - Original Message -
>> > From: "Dmitry Tantsur" 
>> > To: openstack-dev@lists.openstack.org
>> > Sent: Friday, December 2, 2016 3:51:30 PM
>> > Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel
>> > parameters on local boot
>> >
>> > On 12/02/2016 01:28 PM, Yolanda Robla Mota wrote:
>> >> Hi Dmitry
>> >>
>> >> So we've been looking at that spec you suggested, but we are wondering
>> >> if that will be useful for our use case. As the text says:
>> >>
>> >> The ``ironic-python-agent`` project and ``agent`` driver will be
>> >> adjusted to
>> >> support ``get_deploy_steps``. That way, ``ironic-python-agent`` will be
>> >> able
>> >> to declare deploy steps to run prior to disk imaging, and operators
>> >> will be
>> >> able to extend ``ironic-python-agent`` to add any custom step.
>> >>
>> >> Our needs are different, actually we need to create a deployment step
>> >> after imaging. We'd need an step that drops config on /etc/default/grub ,
>> >> and updates it. This is a post-imaging deploy step, that modifies the base
>> >> image. Could ironic support these kind of steps, if there is a base system
>> >> to just define per-user steps?
>> >
>> > I thought that all deployment operations are converted to steps, with
>> > partitioning, writing the image, writing the configdrive and installing
>> > the boot
>> > loader being four default ones (as you see, two steps actually happen
>> > after the
>> > image is written).
>> >
>> >>
>> >> The idea we had on mind is:
>> >> - from tripleo, add a property to each flavor, that defines the boot
>> >> parameters:  openstack flavor set compute --property
>> >> os:kernel_boot_params='abc'
>> >> - define a "ironic post-imaging deploy step", that will grab this
>> >> property from the flavor, drop it on 

Re: [openstack-dev] [ceilometer] lxml gate issues

[Julien Danjou]

On Mon, Dec 12 2016, gordon chung wrote:

> this is just a headsup, i'm fast approving my own magic[1] to fix gate 
> of the error 'fatal error: libxml/xpath.h: No such file or directory'[2].
>
> some notes:
> - i don't know why it doesn't affect aodh (so far) even though aodh has 
> the same lxml requirement

That might be because Aodh has no bindep.txt file so the common base of
packages configured in infra is installed instead.

> - there was a new lxml lib release recently and no changes to gate 
> images but i didn't look any further to validate if lxml is real reason
> - i copied the bindep entries from Nova's bindep.
>
> now that you realise i'm 75% guessing. feel free to revert or adjust 
> accordingly for potential future breakage in aodh (i really have no idea 
> why it's cool over there).

That looks like the good fix, so thanks Gordon. :)

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

You meant: https://review.openstack.org/#/c/409925/

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


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

Re: [openstack-dev] [vitrage] how to use mock driver

[Yujun Zhang]

Understood now.

It could be less confusing if we give a better variable name (without
`_re`) or put some comments after removing `exrex` :-)

On Tue, Dec 13, 2016 at 4:03 PM Rosensweig, Elisha (Nokia - IL) <
elisha.rosensw...@nokia.com> wrote:

> Yes. We actually had to remove the regex generation support a few months
> ago, since the python package we were using – exrex – was not one that
> OpenStack supported.
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Tuesday, December 13, 2016 8:32 AM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
>
> *Subject:* Re: [openstack-dev] [vitrage] how to use mock driver
>
>
>
> Elisha, thanks for the explanation. The difference is clear to me now.
>
>
>
> If I understand it correctly, the regular expression in spec JSON is for
> information only. It is never compiled into a `re` object.
>
>
>
> The actual values are generated in `static_info_parsers` from the
> `mapping`. The regular expression is neither used as a value template nor
> for value validation.
>
>
>
> Is that right?
>
>
>
> On Mon, Dec 12, 2016 at 8:47 PM Rosensweig, Elisha (Nokia - IL) <
> elisha.rosensw...@nokia.com> wrote:
>
> Hi,
>
>
>
> · In Vitrage Datasources, we can have a different input format
> for snapshots and updates. Thus, we need a different JSON file for each.
>
> · Also, as part of the Mock feature, we need to support (for each
> resource) things that will be static, such as it’s name, and things that
> change over time, such as timestamps. We support this partially via
> different JSON files. In general, the dynamic file (marked with “D”)
> *overwrites* the static one (marked with “S”).
>
> · In the code you can further inject specific fields you want to
> have for a specific test, in addition to the JSON files. See examples in
> test_scenario_evaluator.py.
>
>
>
> Elisha
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Monday, December 12, 2016 8:23 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [vitrage] how to use mock driver
>
>
>
> Is there any documentation on how to use mock driver for unit testing?
>
>
>
> It seems it generates fake events from json spec but what is the different
> between
>
>
>
> - `xxx_snapshot_X.json` and `xxx_dynamic_X.json`
>
> - `xxx_S` and `xxx_D`
>
>
>
> __
> OpenStack Development Mailing 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] [vitrage] how to use mock driver

[Rosensweig, Elisha (Nokia - IL)]

Yes. We actually had to remove the regex generation support a few months ago, 
since the python package we were using – exrex – was not one that OpenStack 
supported.

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Tuesday, December 13, 2016 8:32 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [vitrage] how to use mock driver

Elisha, thanks for the explanation. The difference is clear to me now.

If I understand it correctly, the regular expression in spec JSON is for 
information only. It is never compiled into a `re` object.

The actual values are generated in `static_info_parsers` from the `mapping`. 
The regular expression is neither used as a value template nor for value 
validation.

Is that right?

On Mon, Dec 12, 2016 at 8:47 PM Rosensweig, Elisha (Nokia - IL) 
> wrote:
Hi,


• In Vitrage Datasources, we can have a different input format for 
snapshots and updates. Thus, we need a different JSON file for each.

• Also, as part of the Mock feature, we need to support (for each 
resource) things that will be static, such as it’s name, and things that change 
over time, such as timestamps. We support this partially via different JSON 
files. In general, the dynamic file (marked with “D”) overwrites the static one 
(marked with “S”).

• In the code you can further inject specific fields you want to have 
for a specific test, in addition to the JSON files. See examples in 
test_scenario_evaluator.py.

Elisha

From: Yujun Zhang 
[mailto:zhangyujun+...@gmail.com]
Sent: Monday, December 12, 2016 8:23 AM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: [openstack-dev] [vitrage] how to use mock driver

Is there any documentation on how to use mock driver for unit testing?

It seems it generates fake events from json spec but what is the different 
between

- `xxx_snapshot_X.json` and `xxx_dynamic_X.json`
- `xxx_S` and `xxx_D`

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