Re: [openstack-dev] [monasca] New Team Meeting Time doodle

[Bedyk, Witold]

Hello,

I'm sorry for the late notice. I have moved the meeting one hour later. The new 
meeting time is:

Wednesday, 1500 UTC
#openstack-meeting-3


See you there,
Witek



> -Original Message-
> From: Bedyk, Witold
> Sent: Mittwoch, 15. November 2017 17:16
> To: 'OpenStack Development Mailing List (not for usage questions)'
> 
> Subject: [monasca] New Team Meeting Time doodle
> 
> Hello everyone,
> 
> We would like to choose the optimal time for our Team Meeting. I have
> created a doodle [1] for that. Please put your preferences until Monday 1200
> UTC if you want to attend the meeting.
> 
> Cheers
> Witek
> 
> [1] https://doodle.com/poll/s5fwqtu7ik898p57

__
OpenStack Development Mailing 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] Need opinion: request zero root disk for boot-from-volume instances

[Shewale, Bhagyashri]

Hi nova devs,

Just wanted to ask regarding request zero root disk for boot-from-volume 
instances patches [2] [3].

When user boot instance using bootable volume and flavor having non-zero disk_gb
then in that case it considers flavor disk_gb which is incorrect the 
calculation of host
disk space.

Request:

What are reconditions from the community to resolve the LP bug Reference: [1]?

Through multiple discussion on the patches there are two options to address 
this issue:

Option 1:

Merging of patches Reference: [2] and [3]

Option 2:

Operators will need to create new flavor with root_disk=0 for BFV
and ask users to use this new flavor if they want to boot the instance from 
volume.
(Release note may need to be updated in this case)

Could you please give opinion above two options.

Reference:

[1]: https://bugs.launchpad.net/nova/+bug/1469179
[2]: https://review.openstack.org/#/c/428481
[3]: https://review.openstack.org/#/c/428505


Regards,
Bhagyashri Shewale

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing 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/tripleo-ui failed

[Emilien Macchi]

Indeed, adding Jason in copy.

Do we actually need release-openstack-javascript job?

On Tue, Nov 21, 2017 at 8:27 PM, Tony Breeds  wrote:
> On Wed, Nov 22, 2017 at 03:07:33AM +, z...@openstack.org wrote:
>> Build failed.
>>
>> - publish-openstack-javascript-tarball 
>> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/publish-openstack-javascript-tarball/9908482/
>>  : SUCCESS in 4m 58s
>> - release-openstack-javascript 
>> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/
>>  : POST_FAILURE in 6m 37s
>> - announce-release announce-release : SKIPPED
>
> I'm not certain what went wrong here but [1] looks problematic
>
> Yours Tony.
>
> [1] 
> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/job-output.txt.gz#_2017-11-22_03_01_48_750499
>
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures



-- 
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] Request for input: scaling the number of Ceph clusters deployed in the overcloud

[Saravanan KR]

We had a similar kind of requirement to differentiate parameters
between overcloud compute nodes, like a cluster having DELL and HP
machines have different hardware layout, but DPDK requires the
specific CPU information of a hardware layout to function effectively.

We addressed it  by using different roles and role-specific[1]
parameters. There will be 2 roles for compute: ComputeOvsDpdkHP and
ComputeOvsDpdkDell. And using role-specific parameters, the parameters
are targeted to the specific role of a service. The dpdk service files
[2] uses this format to merge the parameters.

Regards,
Saravanan KR

[1] 
https://docs.openstack.org/tripleo-docs/latest/install/advanced_deployment/role_specific_parameters.html
[2] 
https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/neutron-ovs-dpdk-agent.yaml#L59

On Tue, Nov 21, 2017 at 4:46 PM, Giulio Fidente  wrote:
> Hi,
>
> we're currently exploring ways to deploy multiple Ceph clusters in the
> overcloud.
>
> Given Ceph is now managed by a ceph-ansible playbook, we can "easily"
> deploy multiple Ceph clusters running multiple times the playbook with
> different parameters and inventory.
>
>
> The initial idea to make this consumable in TripleO has been to have
> jinja add a prefix to the Ceph service names and its parameters, and let
> the user build custom roles (deploying on each a different instance of
> the Ceph service) to distribute the Ceph services as needed on any
> arbitrary role.
>
> The benefits of the above approach are that daemons of different Ceph
> clusters can be colocated on the same node and that operators continue
> to customize any Ceph parameter using heat environment files as they
> used to (they just add the jinja prefix to the parameter name).
>
> The cons are that we'd need to scale (hence use jinja) also for other
> services, like Cinder or Nova because the Ceph parameters can be
> consumed by those too.
>
>
> An alternate proposal has been to tag the roles, bound the Ceph cluster
> to a tag to build the inventory and use role-specific settings so that
> instances of the Ceph services deployed on a role would get different
> parameters based on the role they run on.
>
> The most important benefit that I can see of the above approach is that
> it is a lot less intrusive as it does not require jinja processing of
> the templates but I think I do not understand fully how the
> implementation would look like so I was curious if there are examples in
> tree of anything similar?
>
> I would also like to know if other people is interested in this same
> functionality so that we can come up with a more generalized solution?
>
> Last but not least, I would like to hear more input, ideas and feedback
> to see if there are more ways of doing this!
>
> Thanks for the feedback
> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
> __
> OpenStack Development Mailing 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] Composable role OVS-DPDK compute node with single NIC

[Saravanan KR]

On Wed, Nov 22, 2017 at 2:29 AM, Ben Nemec  wrote:
> Thanks.  Unfortunately I don't see anything obviously wrong with that, but
> I'm not a DPDK expert either.  Hopefully one of our networking gurus can
> chime in and comment on whether this should work.
>
> On 11/21/2017 02:01 PM, Samuel Monderer wrote:
>>
>> http://paste.openstack.org/show/626557/
>>
>> On Tue, Nov 21, 2017 at 8:22 PM Ben Nemec > > wrote:
>>
>> Your configuration lost all of its indentation, which makes it
>> extremely
>> difficult to read.  Can you try sending it a different way, maybe
>> paste.openstack.org ?
>>
>>
>> On 11/16/2017 02:43 AM, Samuel Monderer wrote:
>>  > Hi,
>>  >
>>  > I managed to deploy a compute node with ovs-dpdk using two NICs.
>> The
>>  > first for the provisioning network and control plane, the other
>> NIC is
>>  > used tenant network over ovs-dpdk.
>>  >
>>  > I then tried to use only a single nic for provisioning and
>> ovs-dpdk.
This is not a recommended way of using DPDK.

>>  > I used the nic configuration below for the compute nodes running
>>  > ovs-dpdk but encountered two problems.
>>  > First the tenant network was working (wasn't able to get DHCP
>> running
>>  > and even when I manually configured it wasn't able to reach the
>> router)
I am assuming that your dpdk ports are active (verified by ovs-vsctl
show command). The only usecases that we have validated is using DPDK
as provider network and DPDK as Tenant network [1] which will have the
tenant and vlan configured directly on the bridge (this configuration
was recommended from the ovs team).

>>  > Second the default route on control plane is not set even though
>> it is
>>  > configured in /etc/sysconfig/network-scripts/route-br-ex
>>  >
I am not sure if there is any difference between system and netdev
bridges in setting the routes, but you could validate by adding logs
to the ifup scripts and trace it out why the route is not invoked.

Regards,
Saravanan KR

[1] http://paste.openstack.org/show/627030/

>>  > Samuel
>>  >
>>  > OsNetConfigImpl:
>>  > type: OS::Heat::StructuredConfig
>>  > properties:
>>  > group: os-apply-config
>>  > config:
>>  > os_net_config:
>>  > network_config:
>>  > -
>>  > type: ovs_user_bridge
>>  > name: {get_input: bridge_name}
>>  > use_dhcp: false
>>  > dns_servers: {get_param: DnsServers}
>>  > addresses:
>>  > -
>>  > ip_netmask:
>>  > list_join:
>>  > - '/'
>>  > - - {get_param: ControlPlaneIp}
>>  > - {get_param: ControlPlaneSubnetCidr}
>>  > routes:
>>  > -
>>  > ip_netmask: 169.254.169.254/32 
>> 
>>  > next_hop: {get_param: EC2MetadataIp}
>>  > -
>>  > default: true
>>  > next_hop: {get_param: ControlPlaneDefaultRoute}
>>  > members:
>>  > -
>>  > type: ovs_dpdk_port
>>  > name: dpdk0
>>  > members:
>>  > -
>>  > type: interface
>>  > name: nic1
>>  > -
>>  > type: vlan
>>  > vlan_id: {get_param: InternalApiNetworkVlanID}
>>  > addresses:
>>  > -
>>  > ip_netmask: {get_param: InternalApiIpSubnet}
>>  > -
>>  > type: vlan
>>  > vlan_id: {get_param: TenantNetworkVlanID}
>>  > addresses:
>>  > -
>>  > ip_netmask: {get_param: TenantIpSubnet}
>>  >
>>  >
>>  >
>>  >
>>
>> __
>>  > OpenStack Development Mailing 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] [glance] nominating Nikhil Komawar for glance core

[Nikhil Komawar]

Thank you all for the support. I intend to help the Glance community
flourish, again.

cheers

On Tue, Nov 21, 2017 at 10:07 AM, Brian Rosmaita  wrote:

> Having heard only positive responses, I'm happy to reinstate Nikhil
> Komawar as a glance core, with all the rights and privileges
> pertaining thereto.
>
> Welcome back, Nikhil!
>
> cheers,
> brian
>
> On Thu, Nov 16, 2017 at 8:20 PM, Abhishek Kekane 
> wrote:
> > Big +2
> > Glad you are back :)
> >
> > Abhishek
> >
> > On 17-Nov-2017 4:59 AM, "Brian Rosmaita" 
> wrote:
> >>
> >> I'm sure I don't need to introduce Nikhil Komawar (nikhil in IRC), who
> >> was Glance PTL for the Kilo, Liberty, and Newton releases and who was
> >> a long time Glance core until he stepped down at the end of June this
> >> year.  Nikhil has informed me that he now has time to do Glance code
> >> reviews again, and I will be happy to have his experience and
> >> knowledge of the Glance code base available to inform our code
> >> reviews, and I propose to reinstate him as a member of the glance core
> >> team.
> >>
> >> I discussed this with the other cores present at today's weekly Glance
> >> meeting, and they support reinstating Nikhil, so I don't see any
> >> reason to have a long waiting period.  I'd like to add Nikhil to the
> >> core list on Monday, November 20, so if anyone has any comments or
> >> concerns, please let me know before then.
> >>
> >> 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 Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>



-- 
--
Thanks,
Nikhil
__
OpenStack Development Mailing 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/tripleo-ui failed

[Tony Breeds]

On Wed, Nov 22, 2017 at 03:07:33AM +, z...@openstack.org wrote:
> Build failed.
> 
> - publish-openstack-javascript-tarball 
> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/publish-openstack-javascript-tarball/9908482/
>  : SUCCESS in 4m 58s
> - release-openstack-javascript 
> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/
>  : POST_FAILURE in 6m 37s
> - announce-release announce-release : SKIPPED

I'm not certain what went wrong here but [1] looks problematic

Yours Tony.

[1] 
http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/job-output.txt.gz#_2017-11-22_03_01_48_750499

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

[openstack-dev] [magnum] Questions about Caas with Magnum

[Sergio Morales Acuña]

I'm using Openstack Ocata and trying Magnum.

I encountered a lot of problems but I been able to solved many of them.

Now I'm curious about some aspects of Magnum:

¿Do I need a newer version of Magnum to run K8S 1.7? ¿Or I just need to
create a custom fedora-atomic-27? What about RBAC?

¿Any one here using Magnum on daily basis? If yes, What version are you
using?

¿What driver is, in your opinion, better: Atomic or CoreOS? ¿Do I need to
upgrade Magnum to follow K8S's crazy changes?

¿Any tips on the CaaS problem?¿It's Magnum Ocata too old for this world?

¿Where I can found updated articles about the state of Magnum and it's
future?

Cheers
__
OpenStack Development Mailing 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] [Zun] Change in Zun core team

[Shuu Mutou]

+1 for them, includes the new voting schema.

Best regards,
Shu


> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@gmail.com]
> Sent: Wednesday, November 22, 2017 8:16 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Cc: miao.hong...@zte.com.cn
> Subject: [openstack-dev] [Zun] Change in Zun core team
> 
> Hi all,
> 
> I would like to announce the following change to the Zun core reviewers
> team.
> 
> + miaohb (miao-hongbao)
> - Sheel Rana (ranasheel2000)
> 
> Miaohb has been consistently contributed to Zun for a few months. So far,
> he has 60 commits in Zun, which ranked on top 3 in the commit metric. I
> think his hard work justified his qualification as a core reviewer in Zun.
> 
> This change was approved unanimously by the existing core team. Below are
> the core team members who supported this change:
> 
> Hongbin Lu
> Shunli Zhou
> Kien Nguyen
> Kevin Zhao
> Madhuri Kumari
> Namrata Sitlani
> Shubham Sharma
> 
> Best regards,
> Hongbin
> 
> [1] http://stackalytics.com/?metric=commits=zun-group
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][api] POST /api-sig/news

[Gilles Dubreuil]

Hi,

Any chance the meeting this week to be moved on the Thursday instead?

Cheers,
Gilles


On 17/11/17 03:12, Ed Leafe wrote:

Greetings OpenStack community,

No meeting this week, as people are still straggling back after the Sydney 
summit. There will also be no meeting next week, due to the US Thanksgiving 
holiday. So I guess we'll see you all again in December!

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
   Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
   https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the OpenStack 
developer mailing list[1] with the tag "[api]" in the subject. In your email, 
you should include any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



__
OpenStack Development Mailing 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] [Zun] Change in Zun core team

[Hongbin Lu]

Hi all,

I would like to announce the following change to the Zun core reviewers
team.

+ miaohb (miao-hongbao)
- Sheel Rana (ranasheel2000)

Miaohb has been consistently contributed to Zun for a few months. So far,
he has 60 commits in Zun, which ranked on top 3 in the commit metric. I
think his hard work justified his qualification as a core reviewer in Zun.

This change was approved unanimously by the existing core team. Below are
the core team members who supported this change:

Hongbin Lu
Shunli Zhou
Kien Nguyen
Kevin Zhao
Madhuri Kumari
Namrata Sitlani
Shubham Sharma

Best regards,
Hongbin

[1] http://stackalytics.com/?metric=commits=zun-group
__
OpenStack Development Mailing 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] Removing internet access from unit test gates

[Jeremy Stanley]

On 2017-11-21 13:11:36 -0800 (-0800), James E. Blair wrote:
[...]
> If something like this is desirable, I think tox.ini may be the best
> place for it, as it will cause local test runs to behave the same way as
> in Zuul.

This is a great point, any workarounds which need root privileges
(e.g., adjusting packet filtering) are really only a fix on the CI
side and won't be replicated for local runs by developers.
-- 
Jeremy Stanley


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

[openstack-dev] [Neutron][Drivers-team] Weekly IRC meeting cancelled on November 24th

[Miguel Lavalle]

Dear Neutron team,

Due to the Thanksgiving Holiday in the US, we will cancel our weekly
meeting on November 24th. We will resume normally on the 30th

Regards
__
OpenStack Development Mailing 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] Removing internet access from unit test gates

[James E. Blair]

Jeremy Stanley  writes:

> On 2017-11-21 17:46:14 +0100 (+0100), Thomas Goirand wrote:
> [...]
>> Doing this kind of a patch at first on a few project's tox.ini,
>> absolutely! I might even start with Horizon and PBR (yes, there's a
>> problem there as well... which I haven't reported yet). Though
>> generalizing it to 300+ patches, I'm really not sure. Your thoughts?
>
> As Paul suggested we might be able to take advantage of the fact
> that we pull distro and Python packages from a mirror server which
> is identified in the build's Ansible variables, to disallow stateful
> egress except to that server but continue allowing stateful ingress
> from our control plane and whatever else gets access to the job
> nodes now.

If something like this is desirable, I think tox.ini may be the best
place for it, as it will cause local test runs to behave the same way as
in Zuul.

-Jim

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

Re: [openstack-dev] [Tripleo] Composable role OVS-DPDK compute node with single NIC

[Ben Nemec]

Thanks.  Unfortunately I don't see anything obviously wrong with that, 
but I'm not a DPDK expert either.  Hopefully one of our networking gurus 
can chime in and comment on whether this should work.


On 11/21/2017 02:01 PM, Samuel Monderer wrote:

http://paste.openstack.org/show/626557/

On Tue, Nov 21, 2017 at 8:22 PM Ben Nemec > wrote:


Your configuration lost all of its indentation, which makes it extremely
difficult to read.  Can you try sending it a different way, maybe
paste.openstack.org ?

On 11/16/2017 02:43 AM, Samuel Monderer wrote:
 > Hi,
 >
 > I managed to deploy a compute node with ovs-dpdk using two NICs. The
 > first for the provisioning network and control plane, the other
NIC is
 > used tenant network over ovs-dpdk.
 >
 > I then tried to use only a single nic for provisioning and ovs-dpdk.
 > I used the nic configuration below for the compute nodes running
 > ovs-dpdk but encountered two problems.
 > First the tenant network was working (wasn't able to get DHCP running
 > and even when I manually configured it wasn't able to reach the
router)
 > Second the default route on control plane is not set even though
it is
 > configured in /etc/sysconfig/network-scripts/route-br-ex
 >
 > Samuel
 >
 > OsNetConfigImpl:
 > type: OS::Heat::StructuredConfig
 > properties:
 > group: os-apply-config
 > config:
 > os_net_config:
 > network_config:
 > -
 > type: ovs_user_bridge
 > name: {get_input: bridge_name}
 > use_dhcp: false
 > dns_servers: {get_param: DnsServers}
 > addresses:
 > -
 > ip_netmask:
 > list_join:
 > - '/'
 > - - {get_param: ControlPlaneIp}
 > - {get_param: ControlPlaneSubnetCidr}
 > routes:
 > -
 > ip_netmask: 169.254.169.254/32 

 > next_hop: {get_param: EC2MetadataIp}
 > -
 > default: true
 > next_hop: {get_param: ControlPlaneDefaultRoute}
 > members:
 > -
 > type: ovs_dpdk_port
 > name: dpdk0
 > members:
 > -
 > type: interface
 > name: nic1
 > -
 > type: vlan
 > vlan_id: {get_param: InternalApiNetworkVlanID}
 > addresses:
 > -
 > ip_netmask: {get_param: InternalApiIpSubnet}
 > -
 > type: vlan
 > vlan_id: {get_param: TenantNetworkVlanID}
 > addresses:
 > -
 > ip_netmask: {get_param: TenantIpSubnet}
 >
 >
 >
 >
__
 > OpenStack Development Mailing 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] Composable role OVS-DPDK compute node with single NIC

[Samuel Monderer]

http://paste.openstack.org/show/626557/

On Tue, Nov 21, 2017 at 8:22 PM Ben Nemec  wrote:

> Your configuration lost all of its indentation, which makes it extremely
> difficult to read.  Can you try sending it a different way, maybe
> paste.openstack.org?
>
> On 11/16/2017 02:43 AM, Samuel Monderer wrote:
> > Hi,
> >
> > I managed to deploy a compute node with ovs-dpdk using two NICs. The
> > first for the provisioning network and control plane, the other NIC is
> > used tenant network over ovs-dpdk.
> >
> > I then tried to use only a single nic for provisioning and ovs-dpdk.
> > I used the nic configuration below for the compute nodes running
> > ovs-dpdk but encountered two problems.
> > First the tenant network was working (wasn't able to get DHCP running
> > and even when I manually configured it wasn't able to reach the router)
> > Second the default route on control plane is not set even though it is
> > configured in /etc/sysconfig/network-scripts/route-br-ex
> >
> > Samuel
> >
> > OsNetConfigImpl:
> > type: OS::Heat::StructuredConfig
> > properties:
> > group: os-apply-config
> > config:
> > os_net_config:
> > network_config:
> > -
> > type: ovs_user_bridge
> > name: {get_input: bridge_name}
> > use_dhcp: false
> > dns_servers: {get_param: DnsServers}
> > addresses:
> > -
> > ip_netmask:
> > list_join:
> > - '/'
> > - - {get_param: ControlPlaneIp}
> > - {get_param: ControlPlaneSubnetCidr}
> > routes:
> > -
> > ip_netmask: 169.254.169.254/32 
> > next_hop: {get_param: EC2MetadataIp}
> > -
> > default: true
> > next_hop: {get_param: ControlPlaneDefaultRoute}
> > members:
> > -
> > type: ovs_dpdk_port
> > name: dpdk0
> > members:
> > -
> > type: interface
> > name: nic1
> > -
> > type: vlan
> > vlan_id: {get_param: InternalApiNetworkVlanID}
> > addresses:
> > -
> > ip_netmask: {get_param: InternalApiIpSubnet}
> > -
> > type: vlan
> > vlan_id: {get_param: TenantNetworkVlanID}
> > addresses:
> > -
> > ip_netmask: {get_param: TenantIpSubnet}
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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] Question about pxe_ssh drivers

[Julia Kreger]

On Tue, Nov 21, 2017 at 10:59 AM, Waines, Greg
 wrote:
> i am now thinking that perhaps i am thinking of a USE CASE that is NOT the
> typical IRONIC USE CASE.

\o/

> i.e.
>
> I think the ‘typical’ IRONIC USE CASE is that there are a pool of physical
> servers
> that are available to run requested Instances/Images on.
>
>
> However,
>
> the USE CASE that i am thinking of is where there are ‘DEDICATED’ physical
> servers
>
> deployed for specific purposes where I was thinking of using IRONIC to
> manage the Images running on these servers.
>
> ( This is for say a Industrial / Control type scenario )
>
> ( It’s sort of using IRONIC as simply a generic boot server ... of bare
> metal servers )

As it stands, your assessment of the typical use case is correct. But
at the same time, we do and have seen some operators directly use
ironic to deploy dedicated servers, in either a directly orchestrated
against ironic's API process. Largely the use cases have been managed
services/lab environments in data centers where machines may need to
be rebuilt or redeployed fairly often.

I believe it would be possible, at least conceptually with power
control, as ironic expects to check and be able to assert power
control state. Part of this behavior can be disabled, or human driven
with a button push, but from experience, it is much easier to be able
to remotely tell something to cycle power.

Operating with-in Ironic's management framework without modifying the
process or concepts, I guess in an industrial/controls scenario, we
would likely end up with some sort of PLC integrated power driver,
with enough configuration for each baremetal node to potentially
control power. The closest thing we have to that right now is an SNMP
power driver (https://docs.openstack.org/ironic/pike/admin/drivers/snmp.html).
The SNMP power driver is intended for use with power distribution
units where the outlet's power can be turned on/off remotely.

> Any comments on whether it makes sense to do this with Ironic ?

I think it comes down to the needs as it relates to automating such a
deployment process, or possibly more clearly defining the deployment
process as you would see.


> Is there an alternative OpenStack project to do this sort of thing ?

People do use bifrost to build a standalone ironic installation to
kind of do things along these lines. Bifrost is not intended to be for
long-lived management of machines, but it does now support hooking up
keystone as well, so it could be a nice happy median, and we're always
happy to accept patches to bifrost that solves someone's problem.

> ( in my use case, the end user is already using OpenStack in a traditional
> sense for
>   VMs on compute nodes ... but would like to extend the solution to manage
> images
>   on bare metal servers )

Totally viable, either with or without nova, depending on the process
that needs to be fulfilled. One thing worth noting with baremetal
hardware is the security implications that do exist. Ironic's API is
built around the concept that the user is not a normal user, but an
administrative user. I'd personally love to change that with time, but
it is far from a simple undertaking in a generic sense.

Going back to the previous question of reset functions and, ironic
actually turns the power off, and then back on to perform a reset.
With cases like wake-on-lan, there is nothing that can be done. I
believe that driver might just not attempt to do anything, hence my
comment about maybe some sort of PLC power driver, or perhaps the SNMP
driver.

As for is anything deployed immediately upon enroll, ironic presently
does not do that as it expects you to step through the state machine
so the node passes through cleaning. If your hardware or use case does
not need or require cleaning, then you can run through the process
quite quickly with a script or an ansible playbook (which is exactly
what bifrost does for CI testing)

Hope this helps!

-Julia

__
OpenStack Development Mailing 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] Removing internet access from unit test gates

[Jeremy Stanley]

On 2017-11-21 17:46:14 +0100 (+0100), Thomas Goirand wrote:
[...]
> Doing this kind of a patch at first on a few project's tox.ini,
> absolutely! I might even start with Horizon and PBR (yes, there's a
> problem there as well... which I haven't reported yet). Though
> generalizing it to 300+ patches, I'm really not sure. Your thoughts?

As Paul suggested we might be able to take advantage of the fact
that we pull distro and Python packages from a mirror server which
is identified in the build's Ansible variables, to disallow stateful
egress except to that server but continue allowing stateful ingress
from our control plane and whatever else gets access to the job
nodes now.
-- 
Jeremy Stanley


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

Re: [openstack-dev] Removing internet access from unit test gates

[Jeremy Stanley]

On 2017-11-21 13:34:57 -0500 (-0500), Paul Belanger wrote:
[...]
> I don't think we'd need to use security groups, we could just
> setup a local firewall ruleset to do this on the node if we
> wanted.
[...]

I considered suggesting that in my original reply, but then realized
that we still have steps in the job which are going to need to do
egress (though perhaps only to our mirror servers?) and in
particular between phases of tox itself where we can't easily pause
execution to perform root tasks like injecting iptables rules. I
suppose if someone wants to write up a generic role which restricts
egress access to only allow reaching the mirror server for the
provider where that job is running, we could try adding it to some
copies of unit test jobs in a few projects to see what happens.
-- 
Jeremy Stanley


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

[openstack-dev] [openstack-operators][all][heat] Hidden OS::Heat::HARestarter resource

[Rico Lin]

Dear all

As you might know, `OS::Heat::HARestarter` been deprecate for really long
time. It never really restarts servers (only recreate them), and the code
(and logic) looks really old.
Would like to reach out all users to see if this resource still uses by
anyone.
If it's fine for all, I like to propose with [1] to hidden that resource
type and mark it as placeholder resource.
For resources already exists (which not a placeholder resource), still can
be deleted through the client. Any newly created resources will be
considered as placeholder resources like none resource. We will schedule to
delete it from heat resources list.

For users that really need this kind of feature, can also consider using
auto-healing like the sample template in [2]. Which IMO is way better than
HARestarter.

[1] https://review.openstack.org/#/c/511278
[2]
https://git.openstack.org/cgit/openstack/heat-templates/tree/hot/autohealing

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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] Removing internet access from unit test gates

[Paul Belanger]

On Tue, Nov 21, 2017 at 04:41:13PM +, Mooney, Sean K wrote:
> 
> 
> > -Original Message-
> > From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> > Sent: Tuesday, November 21, 2017 3:05 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] Removing internet access from unit test
> > gates
> > 
> > On 2017-11-21 09:28:20 +0100 (+0100), Thomas Goirand wrote:
> > [...]
> > > The only way that I see going forward, is having internet access
> > > removed from unit tests in the gate, or probably just the above
> > > variables set.
> > [...]
> > 
> > Historically, our projects hadn't done a great job of relegating their
> > "unit test" jobs to only run unit tests, and had a number of what would
> > be commonly considered functional tests mixed in. This has improved in
> > recent years as many of those projects have created separate functional
> > test jobs and are able to simplify their unit test jobs accordingly, so
> > this may be more feasible now than it was in the past.
> > 
> > Removing network access from the machines running these jobs won't
> > work, of course, because our job scheduling and execution service needs
> > to reach them over the Internet to start jobs, monitor progress and
> > collect results. As you noted, faking Python out with envvars pointing
> > it at nonexistent HTTP proxies might help at least where tests attempt
> > to make HTTP(S) connections to remote systems.
> > The Web is not all there is to the Internet however, so this wouldn't
> > do much to prevent use of remote DNS, NTP, SMTP or other
> > non-HTTP(S) protocols.
> > 
> > The biggest wrinkle I see in your "proxy" idea is that most of our
> > Python-based projects run their unit tests with tox, and it will use
> > pip to install project and job dependencies via HTTPS prior to starting
> > the test runner. As such, any proxy envvar setting would need to happen
> > within the scope of tox itself so that it will be able to set up the
> > virtualenv prior to configuring the proxy vars for the ensuing tests.
> > It might be easiest for you to work out the tox.ini modification on one
> > project (it'll be self-testing at least) and then once the pilot can be
> > shown working the conversation with the community becomes a little
> > easier.
> [Mooney, Sean K] I may be over simplifying here but our unit tests are still 
> executed by
> Zuul in vms provided by nodepool. Could we simply take advantage of openstack 
> and
> use security groups to to block egress traffic from the vm except that 
> required to upload the logs?
> e.g. don't mess with tox or proxyies within the vms and insteand do this 
> externally via neutron.
> This would require the cloud provider to expose neutron however which may be 
> an issue for Rackspace but
> It its only for unit test which are relatively short lived vs tempest jobs 
> perhaps the other providers would
> Still have enough capacity?
> > --
> > Jeremy Stanley
> 
I don't think we'd need to use security groups, we could just setup a local
firewall ruleset to do this on the node if we wanted.

-Paul

__
OpenStack Development Mailing 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] Composable role OVS-DPDK compute node with single NIC

[Ben Nemec]

Your configuration lost all of its indentation, which makes it extremely 
difficult to read.  Can you try sending it a different way, maybe 
paste.openstack.org?


On 11/16/2017 02:43 AM, Samuel Monderer wrote:

Hi,

I managed to deploy a compute node with ovs-dpdk using two NICs. The 
first for the provisioning network and control plane, the other NIC is 
used tenant network over ovs-dpdk.


I then tried to use only a single nic for provisioning and ovs-dpdk.
I used the nic configuration below for the compute nodes running 
ovs-dpdk but encountered two problems.
First the tenant network was working (wasn't able to get DHCP running 
and even when I manually configured it wasn't able to reach the router)
Second the default route on control plane is not set even though it is 
configured in /etc/sysconfig/network-scripts/route-br-ex


Samuel

OsNetConfigImpl:
type: OS::Heat::StructuredConfig
properties:
group: os-apply-config
config:
os_net_config:
network_config:
-
type: ovs_user_bridge
name: {get_input: bridge_name}
use_dhcp: false
dns_servers: {get_param: DnsServers}
addresses:
-
ip_netmask:
list_join:
- '/'
- - {get_param: ControlPlaneIp}
- {get_param: ControlPlaneSubnetCidr}
routes:
-
ip_netmask: 169.254.169.254/32 
next_hop: {get_param: EC2MetadataIp}
-
default: true
next_hop: {get_param: ControlPlaneDefaultRoute}
members:
-
type: ovs_dpdk_port
name: dpdk0
members:
-
type: interface
name: nic1
-
type: vlan
vlan_id: {get_param: InternalApiNetworkVlanID}
addresses:
-
ip_netmask: {get_param: InternalApiIpSubnet}
-
type: vlan
vlan_id: {get_param: TenantNetworkVlanID}
addresses:
-
ip_netmask: {get_param: TenantIpSubnet}



__
OpenStack Development Mailing 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] Question about pxe_ssh drivers

[Waines, Greg]

Good question about how the smaller devices have their power managed.

Actually stepping back a bit,
i am now thinking that perhaps i am thinking of a USE CASE that is NOT the 
typical IRONIC USE CASE.

i.e.
I think the ‘typical’ IRONIC USE CASE is that there are a pool of physical 
servers
that are available to run requested Instances/Images on.

However,
the USE CASE that i am thinking of is where there are ‘DEDICATED’ physical 
servers
deployed for specific purposes where I was thinking of using IRONIC to
manage the Images running on these servers.
( This is for say a Industrial / Control type scenario )
( It’s sort of using IRONIC as simply a generic boot server ... of bare metal 
servers )

Any comments on whether it makes sense to do this with Ironic ?
Is there an alternative OpenStack project to do this sort of thing ?
( in my use case, the end user is already using OpenStack in a traditional 
sense for
  VMs on compute nodes ... but would like to extend the solution to manage 
images
  on bare metal servers )

Comments ?
Greg.


From: Ilya Etingof 
Organization: Red Hat Inc.
Date: Tuesday, November 21, 2017 at 11:37 AM
To: "openstack-dev@lists.openstack.org" , 
Greg Waines 
Cc: "Nasir, Shoaib" 
Subject: Re: [openstack-dev] [ironic] Question about pxe_ssh drivers


Hi Greg,

How do these smaller devices allow you to manage their power state?

Typically you have a side-computer (AKA bare-metal controller) which is
always up so you can talk to it (via IPMI/Redfish/SNMP/ssh) to manage
power state of its big brother.

The pxe_ssh driver is about libvirt VMs simulating bare-metal nodes. I
am not sure this is what you need. Also, pxe_ssh driver is obsoleted by
the virtualbmc proxy by now.


On 11/21/2017 05:22 PM, Waines, Greg wrote:
Hey,

We have been integrating OpenStack Ironic into our own OpenStack
Distribution.
Thanks to help from the mailing list, we’ve been able to successfully
‘nova boot’ a bare metal instance on an ironic node using the
pxe_ipmitool drivers.
Thanks again for all the help.

A QUESTION about some future work we are starting to look at.

We are interested in using Ironic to boot smaller devices that do NOT
support IPMI.

I believe that there are other drivers such as pxe_ssh for managing
resets and power on/off of such servers.
But i don’t understand how these work at a high-level.
e.g.
- where do the pxe_ssh drivers SSH to ?
  >  for reset, i suppose it could be the ironic node itself (if
it’s actually running a load, like the deployment image)
  > but for power on/off ... it can’t be the ironic node itself

Can somebody provide or point me to a brief explanation of how Ironic
can be used for
serving loads to devices NOT supporting IPMI ?

thanks in advance,
Greg




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


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

[Juan Antonio Osorio]

On 21 Nov 2017 01:19, "Alex Schultz"  wrote:

On Thu, Nov 16, 2017 at 12:01 AM, Juan Antonio Osorio
 wrote:
> Hello folks!
>
> A few months ago Dan Sneddon and me worked in an ansible role that would
> enable IPSEC for the overcloud [1]. Currently, one would run it as an
extra
> step after the overcloud deployment. But, I would like to start
integrating
> it to TripleO itself, making it another option, probably as a composable
> service.
>

Is there a spec for this or at least some more detail as to what
exactly this is solving?  I would really like some more explanation
around this feature than just an ansible role proposal.


Spec created https://blueprints.launchpad.net/tripleo/+spec/ipsec


> For this, I'm planning to move the tripleo-ipsec ansible role repository
> under the TripleO umbrella. Would that be fine with everyone? Or should I
> add this ansible role as part of another repository? After that's
available
> and packaged in RDO. I'll then look into the actual TripleO composable
> service.
>

As I've previously indicated it probably should live under the tripleo
umbrella but I would like to see more details around this prior to
further integration.  It's also very late in the cycle (almost m2) to
be proposing something like this. Is the target for this Rocky?

That being said I don't see anything specific to this role that would
cause problems as part of the deployment process as it exists today.
I do see some possible conflicts around the iptables configuration as
we currently manage that via heat/puppet but I think it's smart enough
to not stomp on each other if we carefully format the rules.  Another
implementation item that might be problematic is the more hard-coded
configuration via template files. What is the plan to make those more
dynamic to support other roles besides just compute/controller?


It's on the works. It shouldn't be a big change.

Right
now tripleo-heat-templates is the source of configuration items that
we expose for the deployment.  What would we be looking to expose to
deployers since what is currently exposed from the role is minimal?


I'm looking to get deployers to only need to enable it via an environment
variable. The rest should be automatic.



> Any input and contributions are welcome!
>
> [1] https://github.com/JAORMX/tripleo-ipsec
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
>

Thanks,
-Alex

__
OpenStack Development Mailing 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] Question about pxe_ssh drivers

[Waines, Greg]

Aah that’s an interesting idea, using the wake-on-lan technology to solve the 
problem of how to power on the server without IPMI.

So how does the solution solve the power-off and reset functions ?
i.e.

· is the deployment image (with IPA) deployed on the ironic node as 
soon as it is enrolled ?
i.e. in order to manage these operations ?
( as well as configure the wake-on-lan hardware ? )

Greg.


From: Lukas Bezdicka 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Tuesday, November 21, 2017 at 11:28 AM
To: "openstack-dev@lists.openstack.org" 
Cc: "Nasir, Shoaib" 
Subject: Re: [openstack-dev] [ironic] Question about pxe_ssh drivers

This is issue I hit recently. There are staging drivers [1] and there is 
virtualbmc [2] to emulate ipmi for virtual machines. I ended up using 
pxe_wol_isci driver.

[1] - http://ironic-staging-drivers.readthedocs.io/en/latest/README.html
[2] - https://pypi.python.org/pypi/virtualbmc/1.2.0

On Tue, Nov 21, 2017 at 5:22 PM, Waines, Greg 
> wrote:
Hey,

We have been integrating OpenStack Ironic into our own OpenStack Distribution.
Thanks to help from the mailing list, we’ve been able to successfully ‘nova 
boot’ a bare metal instance on an ironic node using the pxe_ipmitool drivers.
Thanks again for all the help.

A QUESTION about some future work we are starting to look at.

We are interested in using Ironic to boot smaller devices that do NOT support 
IPMI.

I believe that there are other drivers such as pxe_ssh for managing resets and 
power on/off of such servers.
But i don’t understand how these work at a high-level.
e.g.
- where do the pxe_ssh drivers SSH to ?
  >  for reset, i suppose it could be the ironic node itself (if it’s 
actually running a load, like the deployment image)
  > but for power on/off ... it can’t be the ironic node itself

Can somebody provide or point me to a brief explanation of how Ironic can be 
used for
serving loads to devices NOT supporting IPMI ?

thanks in advance,
Greg





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

__
OpenStack Development Mailing 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] Ops Meetups team minutes + main topics

[Jonathan Proulx]

On Tue, Nov 21, 2017 at 10:10:00AM -0700, David Medberry wrote:
:Jon,
:
:I think the Foundation staff were very very wary of extending the PTG or
:doing dual sites simultaneously due to not saving a thing logistically.
:Yes, it would conceivably save travel for folks that need to go to two
:separate events (as would the other colo options on the table) but not
:saving a thing logistically over two separate events as we have now. A six
:or seven day sprint/thing/ptg would also mean encroaching on one or both
:weekends (above and beyond travel dates) and that may really limit venue
:choices as private parties (weddings, etc) tend to book those locales on
:weekends.

Yes, that was my main concern as well.  Though I'd not extended it to
the fact the two events wouldn't fit in a single working week.  So
sounds like the logistics are just illogistical.

-Jon

:On Tue, Nov 21, 2017 at 10:06 AM, Jonathan Proulx  wrote:
:
:> :On Tue, Nov 21, 2017 at 9:15 AM, Chris Morgan 
:> wrote:
:>
:> :> The big topic of debate, however, was whether subsequent meetups should
:> be
:> :> co-located with OpenStack PTG. This is a question for the wider
:> OpenStack
:> :> operators community.
:>
:> For people who attend both I thnik this would be a big win, if they
:> were in the same location (city anyway) but held in series.  One
:> (longer) trip but no scheduling conflict.
:>
:> Downside I see is that makes scheduling constraints pretty tight
:> either for having two sponsorslocation available in a coordinated time
:> and place or making a much bigger ask of a single location.
:>
:> Those are my thoughts, not sure if the amount to an opinion.
:>
:> -Jon
:>
:>
:>

-- 

__
OpenStack Development Mailing 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] [doc][infra][stable] we are ready to restore stable/mitaka for openstack-manuals

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-11-20 11:32:53 -0500:
> As we agreed in the new documentation retention policy spec [1], I need
> to restore the stable/mitaka branch for the openstack/openstack-manuals
> repository and then trigger a build of the mitaka version of the guides.
> I have a local patch ready that works, so I believe the next steps are
> to create the branch, propose the patch, and fix whatever infra issues
> we have due to running the change on such an old branch.
> 
> I believe I have the permissions needed to create the branch from the
> existing mitaka-eol tag. Before I do that, however, I wanted to make
> sure there are no additional steps needed. Should we delete the tag, for
> example? Or is creating the branch sufficient?
> 
> Doug
> 
> [1] 
> http://specs.openstack.org/openstack/docs-specs/specs/queens/retention-policy.html
> 

OK, I have recreated the branch and proposed the patch to fix the build
in [2].

Doug

[2] https://review.openstack.org/#/c/521961/

__
OpenStack Development Mailing 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][ptl] Improving the process for release marketing

[Sean McGinnis]

On Tue, Nov 21, 2017 at 08:52:17AM -0800, Michael Johnson wrote:
> Is there a template for this?  I wouldn't want to have 12 different
> formatting styles for the page (Yes, I'm looking at Amrith and the
> blinking red text. grin)
> 
> Michael
> 
> 

There is not a set template for now. Since this is just distilled data that
will be shared as a way to communicate to marketing, and not intended as a
final marketing output, I think we are probably safe there.

If it does end up that we have issues with the way some choose to add this
information, we could certainly add some guidelines or recommendations for the
format to use. My guess would be that after a few projects do this, the rest
will mostly follow the same general direction. We shall see though. I guess we
all need to keep our eyes on Amrith. ;)

Sean


__
OpenStack Development Mailing 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][ptl] Improving the process for release marketing

[Doug Hellmann]

Excerpts from Michael Johnson's message of 2017-11-21 08:52:17 -0800:
> Is there a template for this?  I wouldn't want to have 12 different
> formatting styles for the page (Yes, I'm looking at Amrith and the
> blinking red text. grin)
> 
> Michael

I think just keep it simple and it will be fine (lists and paragraphs,
no images). The page is meant to be used as source material, rather
than to be linked to directly. If we start finding people linking
to it we can standardize the formatting.

Doug

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

Re: [openstack-dev] [Openstack-operators] Ops Meetups team minutes + main topics

[David Medberry]

Jon,

I think the Foundation staff were very very wary of extending the PTG or
doing dual sites simultaneously due to not saving a thing logistically.
Yes, it would conceivably save travel for folks that need to go to two
separate events (as would the other colo options on the table) but not
saving a thing logistically over two separate events as we have now. A six
or seven day sprint/thing/ptg would also mean encroaching on one or both
weekends (above and beyond travel dates) and that may really limit venue
choices as private parties (weddings, etc) tend to book those locales on
weekends.

On Tue, Nov 21, 2017 at 10:06 AM, Jonathan Proulx  wrote:

> :On Tue, Nov 21, 2017 at 9:15 AM, Chris Morgan 
> wrote:
>
> :> The big topic of debate, however, was whether subsequent meetups should
> be
> :> co-located with OpenStack PTG. This is a question for the wider
> OpenStack
> :> operators community.
>
> For people who attend both I thnik this would be a big win, if they
> were in the same location (city anyway) but held in series.  One
> (longer) trip but no scheduling conflict.
>
> Downside I see is that makes scheduling constraints pretty tight
> either for having two sponsorslocation available in a coordinated time
> and place or making a much bigger ask of a single location.
>
> Those are my thoughts, not sure if the amount to an opinion.
>
> -Jon
>
>
>
__
OpenStack Development Mailing 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] Ops Meetups team minutes + main topics

[Jonathan Proulx]

:On Tue, Nov 21, 2017 at 9:15 AM, Chris Morgan  wrote:

:> The big topic of debate, however, was whether subsequent meetups should be
:> co-located with OpenStack PTG. This is a question for the wider OpenStack
:> operators community.

For people who attend both I thnik this would be a big win, if they
were in the same location (city anyway) but held in series.  One
(longer) trip but no scheduling conflict.

Downside I see is that makes scheduling constraints pretty tight
either for having two sponsorslocation available in a coordinated time
and place or making a much bigger ask of a single location.

Those are my thoughts, not sure if the amount to an opinion.

-Jon



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

Re: [openstack-dev] 回复： [manila] Nominating Zhong Jun (zhongjun) for Manilacore

[Mark Sturdevant]

+1
 
Congrats, Jun!  Thanks for all the hard work.  Keep it up.
 
- Original message -From: Xing Yang To: "OpenStack Development Mailing List (not for usage questions)" Cc:Subject: Re: [openstack-dev] 回复： [manila] Nominating Zhong Jun (zhongjun) for ManilacoreDate: Sun, Nov 19, 2017 6:59 PM 
+1.  Jun has been making valuable contributions to Manila for a long time.  Very well deserved!
 
Xing
 
 
On Sun, Nov 19, 2017 at 9:06 PM, jiaopengju  wrote:

+1 for zhongjun! 

 原始邮件  
发件人: Goutham" 
收件人: OpenStack Development Mailing List (not for usage questions)
发送时间: 2017年11月20日(周一) 07:29
主题: [openstack-dev] [manila] Nominating Zhong Jun (zhongjun) for Manilacore 

Hello Manila developers, 
 
I would like to nominate Zhong Jun (zhongjun on irc, zhongjun2 on gerrit) to be part of the Manila core team. Zhongjun has been an important member of our community since the Kilo release, and has, in the past few releases made significant contributions to the constellation of projects related to openstack/manila [1]. She is also our ambassador in the APAC region/timezones. Her opinion is valued amongst the core team and I think, as a core reviewer and maintainer, she would continue to help grow and maintain our project. 
 
Please respond with a +1/-1. 
 
We will not be having an IRC meeting this Thursday (23rd November 2017), so if we have sufficient quorum, PTL extraordinaire, Ben Swartzlander will confirm her nomination here.
 
[1]  http://stackalytics.com/?user_id=jun-zhongjun=all&metric=person-day 
 
Thanks, 
Goutham__OpenStack Development Mailing List (not for usage questions)Unsubscribe: OpenStack-dev-request@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:unsubscribehttps://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=RG0OaOa-NIYjqXDdMp2yXthzBnSKzL1CQrNZ3qjxk2U=wBpqRafKUNuuxvSAny0gMmUVGaZOx4UzCPPhyJ-wDRs=qXvZehQFVm5rNB9NsMWYStuchytnHYiQAWf8QaNvo4E=
 


__
OpenStack Development Mailing 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] [QA] Is forcing dynamic creds too restrictive?

[Andrea Frittoli]

On Tue, Nov 21, 2017 at 4:47 PM MCCASLAND, TREVOR  wrote:

> Hello QA Team,
>
> In many of the tempest tests there is a statement[1] that overrides the
> tempest.conf value for use_dynamic_credentials.
> In the event of an immutable user source, these test cases[2] and the
> one's inherited by them will fail.
> Can we remove or reduce the scope of the overrides? You can see my
> proposed solution for identity admin cases here[3] and my bug report here[4]
>
> What is the QA team's opinion on this?
> Is forcing dynamic creds too restrictive since it would prevent any tests
> being executed against clouds where credential creation is not allowed?
>

The reason we force dynamic credentials for identity admin tests is that
pre-provisioned credentials are generally not a good fit for admin test
cases.
Admin tests are not a concern from an interoperability point of view, so
forcing dynamic credentials on admin tests is not an issue for
interoperability testing either.

That said there are probably cases where we could allow for pre-provisioned
credentials without risking to break test isolation.
I'm fine with that in principle, I guess it has to be discussed on a test
by test basis.

Andrea Frittoli (andreaf)



> [1]
> https://github.com/openstack/tempest/blob/eed21d7a1c0b3e5620960de9878ac9df0d2907fa/tempest/api/identity/base.py#L120-L127
> [2]
> http://codesearch.openstack.org/?q=force_tenant_isolation%20%3D%20True=nope==tempest
> [3] https://review.openstack.org/#/c/499756/
> [4] https://bugs.launchpad.net/tempest/+bug/1714277
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][ptl] Improving the process for release marketing

[Michael Johnson]

Is there a template for this?  I wouldn't want to have 12 different
formatting styles for the page (Yes, I'm looking at Amrith and the
blinking red text. grin)

Michael


On Tue, Nov 21, 2017 at 6:28 AM, Amrith Kumar  wrote:
> Very cool, thanks Sean!
>
>
> -amrith
>
>
> On Mon, Nov 20, 2017 at 12:18 PM, Sean McGinnis 
> wrote:
>>
>> Hello PTL's, release liaisons, and all those interested.
>>
>> The changes on our side to support a release cycle highlights page have
>> been
>> completed, and things have settled a bit from the Summit activies, so I
>> think
>> now is a good time to get things going again for this.
>>
>> See below for the background, but if you missed it or have forgotten by
>> now, we
>> plan to have an easier way to collect significant "highlights" for each
>> release
>> cycle in order to collect "key features" flagged by each team that
>> marketing
>> teams can use during release communication times. The goal is to reduce
>> the
>> number of times PTL's get asked by various groups to "tell us what changed
>> in
>> this release."
>>
>> The way we are approaching this is by adding a "cycle-highlights" key to
>> the
>> deliverable file for your project [1]. This field will take RST formatted
>> text
>> that will then be rendered into the highlights page we will share with
>> marketing.
>>
>> Our goal is to have roughly three "highlights" per team for each release,
>> but
>> this will vary based on the needs of the team and the amount of work done
>> during the cycle. If there is only one significant change to share, that
>> is
>> fine. If there are five, that's OK too. Just keep in mind that these
>> should be
>> limited to only the significant changes that you feel are worth
>> communicating
>> to the marketing, sales, and end users out there that need to know what to
>> expect.
>>
>> We will want to start collecting this information as we near RC releases,
>> but
>> feel free to start adding items of interest with the upcoming Queens-2
>> release
>> if you already have changes worth noting.
>>
>> And please ask here or in the #openstack-release channel if you have any
>> questions about how this works.
>>
>> Thanks,
>> Sean
>>
>> [1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n466
>>
>> P.S. This is for cycle_* deliverables only. If you see a need for this
>> with the
>> independent releases, let me know and we can talk about how that might
>> look.
>>
>>
>> On Tue, Sep 26, 2017 at 02:33:09PM -0700, Anne Bertucio wrote:
>> > Release marketing is a critical part of sharing what’s new in each
>> > release, and we want to rework how the marketing community and projects 
>> > work
>> > together to make the release communications happen.
>> >
>> > Having multiple, repetetive demands to summarize "top features" during
>> > release time can be pestering and having to recollect the information each
>> > time isn't an effective use of time. Being asked to make polished,
>> > "press-friendly" messages out of release notes can feel too far outside of
>> > the PTL's focus areas or skills. At the same time, for technical content
>> > marketers, attempting to find the key features from release notes, ML 
>> > posts,
>> > specs, Roadmap, etc., means interesting features are sometimes overlooked.
>> > Marketing teams don't have the latest on what features landed and with what
>> > caveats.
>> >
>> > To address this gap, the Release team and Foundation marketing team
>> > propose collecting information as part of the release tagging process.
>> > Similar to the existing (unused) "highlights" field for an individual tag,
>> > we will collect some text in the deliverable file to provide highlights for
>> > the series (about 3 items). That text will then be used to build a landing
>> > page on release.openstack.org that shows the "key features" flagged by PTLs
>> > that marketing teams should be looking at during release communication
>> > times. The page will link to the release notes, so marketers can start 
>> > there
>> > to gather additional information, eliminating repetitive asks of PTLs. The
>> > "pre selection" of features means marketers can spend more time diving into
>> > release note details and less sifting through them.
>> >
>> > To supplement the written information, the marketing community is also
>> > going to work together to consolidate follow up questions and deliver them
>> > in "press corps" style (i.e. a single phone call to be asked questions from
>> > multiple parties vs. multiple phone calls from individuals).
>> >
>> > We will provide more details about the implementation for the highlights
>> > page when that is ready, but want to gather feedback about both aspects of
>> > the plan early.
>> >
>> > Thanks for your input,
>> > Anne Bertucio and Sean McGinnis
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List 

Re: [openstack-dev] [Openstack-operators] Ops Meetups team minutes + main topics

[David Medberry]

I'm actually pushing this out to a broader list and modifying the title as
well. We need to try and get all operators viewing this (even if they are
also devels, deployers, sigs.)

Feel free to reply to me about spamming lists, but I think we need lots of
eyes on this.



On Tue, Nov 21, 2017 at 9:15 AM, Chris Morgan  wrote:

> We had a busy meeting today. Here are the minutes
>
> Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/
> 2017/ops_meetup_team.2017-11-21-14.00.html
> 10:01 AM Minutes (text): http://eavesdrop.openstack.
> org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-11-21-14.00.txt
> 10:01 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/
> 2017/ops_meetup_team.2017-11-21-14.00.log.html
>
> The next Operators focused meeting is to be in Tokyo next March. Planning
> is going well (more on this later).
>
> The big topic of debate, however, was whether subsequent meetups should be
> co-located with OpenStack PTG. This is a question for the wider OpenStack
> operators community.
>
> The three broad options as I see it are
>
> 1. continue completely separate events
> 2. 2 events under one roof (PTG and ops meet ups at same venue, same days,
> but distinct)
> 3. redefine ops meetups (and to some extent PTG) so that days 1 and 2 are
> community inter-working between devs and operators.
>
> I would like to request a full and open discussion on this because the
> meetups team alone can't decide something like this, obviously, and yet
> we'll need to know what the community as a whole would like to do if future
> events are to succeed. Some of the issues around this are captured here
> (thanks to Melvin Hillman for starting this doc) :
>
> https://docs.google.com/document/d/1BgICOa-Mct9pKwjUEuYp_BSD1V_GdRLL_IM-
> BU0iPUw
>
> Thanks!
>
> Chris
>
> --
> Chris Morgan 
>
> ___
> 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

[openstack-dev] [QA] Is forcing dynamic creds too restrictive?

[MCCASLAND, TREVOR]

Hello QA Team,

In many of the tempest tests there is a statement[1] that overrides the 
tempest.conf value for use_dynamic_credentials. 
In the event of an immutable user source, these test cases[2] and the one's 
inherited by them will fail.
Can we remove or reduce the scope of the overrides? You can see my proposed 
solution for identity admin cases here[3] and my bug report here[4]

What is the QA team's opinion on this? 
Is forcing dynamic creds too restrictive since it would prevent any tests being 
executed against clouds where credential creation is not allowed?

[1] 
https://github.com/openstack/tempest/blob/eed21d7a1c0b3e5620960de9878ac9df0d2907fa/tempest/api/identity/base.py#L120-L127
[2] 
http://codesearch.openstack.org/?q=force_tenant_isolation%20%3D%20True=nope==tempest
[3] https://review.openstack.org/#/c/499756/
[4] https://bugs.launchpad.net/tempest/+bug/1714277

__
OpenStack Development Mailing 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] Removing internet access from unit test gates

[Thomas Goirand]

On 11/21/2017 04:04 PM, Jeremy Stanley wrote:
> Removing network access from the machines running these jobs won't
> work, of course, because our job scheduling and execution service
> needs to reach them over the Internet to start jobs, monitor
> progress and collect results.

Right.

> As you noted, faking Python out with
> envvars pointing it at nonexistent HTTP proxies might help at least
> where tests attempt to make HTTP(S) connections to remote systems.
> The Web is not all there is to the Internet however, so this
> wouldn't do much to prevent use of remote DNS, NTP, SMTP or other
> non-HTTP(S) protocols.

To my experience, in the vast majority of cases, setting-up the env vars
is enough to prevent problems. There was a few (non test failure
producing) DNS access, IIRC with glanceclient, but that's all I noticed.

> As such, any proxy envvar setting would
> need to happen within the scope of tox itself so that it will be
> able to set up the virtualenv prior to configuring the proxy vars
> for the ensuing tests.

This is a workable solution, though it involves patching absolutely all
projects tox.ini. I'm certain I don't have enough available time to
produce 300+ tox.ini patches and follow their review. Wouldn't there be
a more global approach?

> It might be easiest for you to work out the
> tox.ini modification on one project (it'll be self-testing at least)
> and then once the pilot can be shown working the conversation with
> the community becomes a little easier.

Doing this kind of a patch at first on a few project's tox.ini,
absolutely! I might even start with Horizon and PBR (yes, there's a
problem there as well... which I haven't reported yet). Though
generalizing it to 300+ patches, I'm really not sure. Your thoughts?

Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] Removing internet access from unit test gates

[Mooney, Sean K]

> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Tuesday, November 21, 2017 3:05 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] Removing internet access from unit test
> gates
> 
> On 2017-11-21 09:28:20 +0100 (+0100), Thomas Goirand wrote:
> [...]
> > The only way that I see going forward, is having internet access
> > removed from unit tests in the gate, or probably just the above
> > variables set.
> [...]
> 
> Historically, our projects hadn't done a great job of relegating their
> "unit test" jobs to only run unit tests, and had a number of what would
> be commonly considered functional tests mixed in. This has improved in
> recent years as many of those projects have created separate functional
> test jobs and are able to simplify their unit test jobs accordingly, so
> this may be more feasible now than it was in the past.
> 
> Removing network access from the machines running these jobs won't
> work, of course, because our job scheduling and execution service needs
> to reach them over the Internet to start jobs, monitor progress and
> collect results. As you noted, faking Python out with envvars pointing
> it at nonexistent HTTP proxies might help at least where tests attempt
> to make HTTP(S) connections to remote systems.
> The Web is not all there is to the Internet however, so this wouldn't
> do much to prevent use of remote DNS, NTP, SMTP or other
> non-HTTP(S) protocols.
> 
> The biggest wrinkle I see in your "proxy" idea is that most of our
> Python-based projects run their unit tests with tox, and it will use
> pip to install project and job dependencies via HTTPS prior to starting
> the test runner. As such, any proxy envvar setting would need to happen
> within the scope of tox itself so that it will be able to set up the
> virtualenv prior to configuring the proxy vars for the ensuing tests.
> It might be easiest for you to work out the tox.ini modification on one
> project (it'll be self-testing at least) and then once the pilot can be
> shown working the conversation with the community becomes a little
> easier.
[Mooney, Sean K] I may be over simplifying here but our unit tests are still 
executed by
Zuul in vms provided by nodepool. Could we simply take advantage of openstack 
and
use security groups to to block egress traffic from the vm except that required 
to upload the logs?
e.g. don't mess with tox or proxyies within the vms and insteand do this 
externally via neutron.
This would require the cloud provider to expose neutron however which may be an 
issue for Rackspace but
It its only for unit test which are relatively short lived vs tempest jobs 
perhaps the other providers would
Still have enough capacity?
> --
> Jeremy Stanley

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

Re: [openstack-dev] [ironic] Question about pxe_ssh drivers

[Ilya Etingof]

Hi Greg,

How do these smaller devices allow you to manage their power state?

Typically you have a side-computer (AKA bare-metal controller) which is
always up so you can talk to it (via IPMI/Redfish/SNMP/ssh) to manage
power state of its big brother.

The pxe_ssh driver is about libvirt VMs simulating bare-metal nodes. I
am not sure this is what you need. Also, pxe_ssh driver is obsoleted by
the virtualbmc proxy by now.


On 11/21/2017 05:22 PM, Waines, Greg wrote:
> Hey,
> 
>  
> 
> We have been integrating OpenStack Ironic into our own OpenStack
> Distribution.
> 
> Thanks to help from the mailing list, we’ve been able to successfully
> ‘nova boot’ a bare metal instance on an ironic node using the
> pxe_ipmitool drivers.
> 
> Thanks again for all the help.
> 
>  
> 
> A QUESTION about some future work we are starting to look at.
> 
>  
> 
> We are interested in using Ironic to boot smaller devices that do NOT
> support IPMI.
> 
>  
> 
> I believe that there are other drivers such as pxe_ssh for managing
> resets and power on/off of such servers.
> But i don’t understand how these work at a high-level.
> 
> e.g.
> 
> - where do the pxe_ssh drivers SSH to ?
> 
>   >  for reset, i suppose it could be the ironic node itself (if
> it’s actually running a load, like the deployment image)
> 
>   > but for power on/off ... it can’t be the ironic node itself
> 
>  
> 
> Can somebody provide or point me to a brief explanation of how Ironic
> can be used for
> serving loads to devices NOT supporting IPMI ?
> 
>  
> 
> thanks in advance,
> 
> Greg
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing 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] Question about pxe_ssh drivers

[Lukas Bezdicka]

This is issue I hit recently. There are staging drivers [1] and there is
virtualbmc [2] to emulate ipmi for virtual machines. I ended up using
pxe_wol_isci driver.

[1] - http://ironic-staging-drivers.readthedocs.io/en/latest/README.html
[2] - https://pypi.python.org/pypi/virtualbmc/1.2.0

On Tue, Nov 21, 2017 at 5:22 PM, Waines, Greg 
wrote:

> Hey,
>
>
>
> We have been integrating OpenStack Ironic into our own OpenStack
> Distribution.
>
> Thanks to help from the mailing list, we’ve been able to successfully
> ‘nova boot’ a bare metal instance on an ironic node using the pxe_ipmitool
> drivers.
>
> Thanks again for all the help.
>
>
>
> A QUESTION about some future work we are starting to look at.
>
>
>
> We are interested in using Ironic to boot smaller devices that do NOT
> support IPMI.
>
>
>
> I believe that there are other drivers such as pxe_ssh for managing resets
> and power on/off of such servers.
> But i don’t understand how these work at a high-level.
>
> e.g.
>
> - where do the pxe_ssh drivers SSH to ?
>
>   >  for reset, i suppose it could be the ironic node itself (if it’s
> actually running a load, like the deployment image)
>
>   > but for power on/off ... it can’t be the ironic node itself
>
>
>
> Can somebody provide or point me to a brief explanation of how Ironic can
> be used for
> serving loads to devices NOT supporting IPMI ?
>
>
>
> thanks in advance,
>
> Greg
>
>
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Question about pxe_ssh drivers

[Waines, Greg]

Hey,

We have been integrating OpenStack Ironic into our own OpenStack Distribution.
Thanks to help from the mailing list, we’ve been able to successfully ‘nova 
boot’ a bare metal instance on an ironic node using the pxe_ipmitool drivers.
Thanks again for all the help.

A QUESTION about some future work we are starting to look at.

We are interested in using Ironic to boot smaller devices that do NOT support 
IPMI.

I believe that there are other drivers such as pxe_ssh for managing resets and 
power on/off of such servers.
But i don’t understand how these work at a high-level.
e.g.
- where do the pxe_ssh drivers SSH to ?
  >  for reset, i suppose it could be the ironic node itself (if it’s 
actually running a load, like the deployment image)
  > but for power on/off ... it can’t be the ironic node itself

Can somebody provide or point me to a brief explanation of how Ironic can be 
used for
serving loads to devices NOT supporting IPMI ?

thanks in advance,
Greg




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

Re: [openstack-dev] [kolla] Compute fails to startup

[Eduardo Gonzalez]

Hi Goutham,

Please share your nova-compute and libvirt logs from
/var/lib/docker/volumes/kolla_logs/_data/nova.

What kolla release is deployed?
If using nested virtualization, is correctly configured to use qemu instead
of kvm?

Regards

2017-11-21 15:37 GMT+01:00 Goutham Pratapa :

> Hi all,
>
> I have been trying to deploy Kolla on a virtualized environment with
> Centos Docker images using the
>
> stable/pike branch
>
> Deployment fails with -- https://hastebin.com/gubilijecu.vbs
> Inventory fail -- https://hastebin.com/etosipegez.pl
> extra log -- https://hastebin.com/yudafudegu.go
> Docker logs https://hastebin.com/imotenanob.cs
> Gloabls.yml https://hastebin.com/ihamepanim.coffeescript
>
> Any help would be of great use ???
>
> Thanks in advance...
>
> Thank you !!!
> Goutham Pratapa
>
> __
> OpenStack Development Mailing 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] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

[Pavlo Shchelokovskyy]

Hi all,

thank you all for your replies.

AFAIU the consensus is leaning towards option 1, so I've proposed a patch
to governance that adds networking-generic-switch under ironic:

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

(not actually sure how that works / being decided on from TC side, but will
see :) )

Cheers,

On Mon, Nov 20, 2017 at 6:14 PM, Ruby Loo  wrote:

>
>
> On Wed, Nov 15, 2017 at 4:41 AM, Shivanand Tendulker  > wrote:
>
>> Thank you. I too vote for 'Option 1'.
>>
>> Thanks and Regards
>> Shiv
>>
>>
>>
>> On Wed, Nov 15, 2017 at 1:03 AM, Villalovos, John L <
>> john.l.villalo...@intel.com> wrote:
>>
>>> Thanks for sending this out.
>>>
>>>
>>>
>>> I would vote for Option 1.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>
>>>
>>> *From:* Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
>>> *Sent:* Tuesday, November 14, 2017 8:16 AM
>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>> openstack-dev@lists.openstack.org>
>>> *Subject:* [openstack-dev] [ironic] inclusion of
>>> openstack/networking-generic-switch project under OpenStack baremetal
>>> program
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> as this topic it was recently brought up in ironic IRC meeting, I'd like
>>> to start a discussion on the subject.
>>>
>>>
>>>
>>> A quick recap - networking-generic-switch project (n-g-s) was born out
>>> of necessity to do two things:
>>>
>>>
>>>
>>> -  test the "network isolation for baremetal nodes" (a.k.a.
>>> multi-tenancy) feature of ironic on upstream gates in virtualized
>>> environment and
>>>
>>> - do the same on cheap/simple/dumb hardware switches that are not
>>> supported by other various openstack/networking-* projects.
>>>
>>>
>>>
>>> Back when it was created AFAIR neutron governance (neutron stadium) was
>>> under some changes, so in the end n-g-s ended up not belonging to any
>>> official program.
>>>
>>>
>>>
>>> Over time n-g-s grew to be an essential part of ironic gate testing
>>> (similar to virtualbmc). What's more, we have reports that it is already
>>> being used in production.
>>>
>>>
>>>
>>> Currently the core reviewers team of n-g-s consists of 4 people (2 of
>>> those are currently core reviewers in ironic too), all of them are working
>>> for the same company (Mirantis). This poses some risk as companies and
>>> people come and go, plus since some voting ironic gate jobs depend on n-g-s
>>> stability, a more diverse group of core reviewers from baremetal program
>>> might be beneficial to be able to land patches in case of severe gate
>>> troubles.
>>>
>>>
>>>
>>> Currently I know of 3 proposed ways to change the current situation:
>>>
>>>
>>>
>>> 1) include n-g-s under ironic (OpenStack Baremetal program) governance,
>>> effectively including ironic-core team to the core team of  n-g-s similar
>>> to how ironic-inspector currently governed (keeping an extended sub-core
>>> team). Reasoning for addition is the same as with virtualbmc/sushy
>>> projects, with the debatable difference that the actual scope of n-g-s is
>>> quite bigger and apparently includes production use-cases;
>>>
>>>
>>>
>>> 2) keep things as they are now, just add ironic-stable-maint team to the
>>> n-g-s core reviewers to decrease low diversity risks;
>>>
>>>
>>>
>>> 3) merge the code from n-g-s into networking-baremetal project which is
>>> already under ironic governance.
>>>
>>>
>>>
>>> As a core in n-g-s myself I'm happy with either 1) or 2), but not really
>>> fond of 3) as it kind of stretches the networking-baremetal scope too much
>>> IMHO.
>>>
>>>
>>>
>>> Eager to hear your comments and proposals.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> --
>>>
>>> Dr. Pavlo Shchelokovskyy
>>>
>>> Senior Software Engineer
>>>
>>> Mirantis Inc
>>>
>>> www.mirantis.com
>>>
>>>
>  I'm good with 1 or 2. Since we have two 1's and no nays (so far), let's
> go with 1 and move on :)
>
> Thanks for bringing this up!
>
> --ruby
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [nova] Notification update week 47

[Balazs Gibizer]

Hi,

Here is the status update / focus settings mail for w47

Bugs

[Undecided] https://bugs.launchpad.net/nova/+bug/1535254 illustration
of 'notify_on_state_change' are different from implementation
As the behavior is unchanged in the last 5 years a patch is proposed to
update the documentation to reflect this long standing behavior.
The fix merged to the master and backports has been proposed to the 
stable branches https://review.openstack.org/#/q/topic:bug/1535254


[Undecided] https://bugs.launchpad.net/nova/+bug/1732685 
instance.snapshot notification samples are assigned to two different 
Notification classes
This is a trivial doc bug with fix proposed: 
https://review.openstack.org/#/c/520579/


Versioned notification transformation
-
To move forward with the live migration notification transformations we 
have to merge couple of pre-requisits in the functional test 
enviornment. The live_migration_pre notifiacation transformation is 
basically r
eady and approved in https://review.openstack.org/#/c/482070/ but the 
prerequisti patches needs some core attention.


Also the following transformation patches are ready to look at:
* https://review.openstack.org/#/c/410297 Transform missing delete
notifications
* https://review.openstack.org/#/c/476459 Send soft_delete from context
manager


Service create and destroy notifications

https://blueprints.launchpad.net/nova/+spec/service-create-destroy-notification
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/service-create-destroy-notification.html
The implementation was propose last week and code review is ongoing in 
https://review.openstack.org/#/c/519588/ .


Factor out duplicated notification sample
-
https://review.openstack.org/#/q/topic:refactor-notification-samples

It is so easy work that as soon as somebody pushes such a patch it is 
merged quickly. We still have plenty of samples to be deduplicated so I 
will monitor the above topic for incoming patches for easy review. :)



Weekly meeting
--
Next subteam meeting will be held on 21th of November, Tuesday 17:00
UTC on openstack-meeting-4.
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20171121T17


Cheers,
gibi




__
OpenStack Development Mailing 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] [FEMDC] Wed. 22 Nov - IRC Meeting 15:00 UTC

[lebre . adrien]

Dear all, 

A gentle reminder for our tomorrow meeting at 15:00 UTC 

A draft agenda is available at line 1484, you are very welcome to add any item.
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017

Best regards, 
ad_rien_

__
OpenStack Development Mailing 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] Removing internet access from unit test gates

[Jeremy Stanley]

On 2017-11-21 09:28:20 +0100 (+0100), Thomas Goirand wrote:
[...]
> The only way that I see going forward, is having internet access
> removed from unit tests in the gate, or probably just the above
> variables set.
[...]

Historically, our projects hadn't done a great job of relegating
their "unit test" jobs to only run unit tests, and had a number of
what would be commonly considered functional tests mixed in. This
has improved in recent years as many of those projects have created
separate functional test jobs and are able to simplify their unit
test jobs accordingly, so this may be more feasible now than it was
in the past.

Removing network access from the machines running these jobs won't
work, of course, because our job scheduling and execution service
needs to reach them over the Internet to start jobs, monitor
progress and collect results. As you noted, faking Python out with
envvars pointing it at nonexistent HTTP proxies might help at least
where tests attempt to make HTTP(S) connections to remote systems.
The Web is not all there is to the Internet however, so this
wouldn't do much to prevent use of remote DNS, NTP, SMTP or other
non-HTTP(S) protocols.

The biggest wrinkle I see in your "proxy" idea is that most of our
Python-based projects run their unit tests with tox, and it will use
pip to install project and job dependencies via HTTPS prior to
starting the test runner. As such, any proxy envvar setting would
need to happen within the scope of tox itself so that it will be
able to set up the virtualenv prior to configuring the proxy vars
for the ensuing tests. It might be easiest for you to work out the
tox.ini modification on one project (it'll be self-testing at least)
and then once the pilot can be shown working the conversation with
the community becomes a little easier.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [glance] nominating Nikhil Komawar for glance core

[Brian Rosmaita]

Having heard only positive responses, I'm happy to reinstate Nikhil
Komawar as a glance core, with all the rights and privileges
pertaining thereto.

Welcome back, Nikhil!

cheers,
brian

On Thu, Nov 16, 2017 at 8:20 PM, Abhishek Kekane  wrote:
> Big +2
> Glad you are back :)
>
> Abhishek
>
> On 17-Nov-2017 4:59 AM, "Brian Rosmaita"  wrote:
>>
>> I'm sure I don't need to introduce Nikhil Komawar (nikhil in IRC), who
>> was Glance PTL for the Kilo, Liberty, and Newton releases and who was
>> a long time Glance core until he stepped down at the end of June this
>> year.  Nikhil has informed me that he now has time to do Glance code
>> reviews again, and I will be happy to have his experience and
>> knowledge of the Glance code base available to inform our code
>> reviews, and I propose to reinstate him as a member of the glance core
>> team.
>>
>> I discussed this with the other cores present at today's weekly Glance
>> meeting, and they support reinstating Nikhil, so I don't see any
>> reason to have a long waiting period.  I'd like to add Nikhil to the
>> core list on Monday, November 20, so if anyone has any comments or
>> concerns, please let me know before then.
>>
>> 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 Development Mailing 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] [kolla] Compute fails to startup

[Goutham Pratapa]

Hi all,

I have been trying to deploy Kolla on a virtualized environment with Centos
Docker images using the

stable/pike branch

Deployment fails with -- https://hastebin.com/gubilijecu.vbs
Inventory fail -- https://hastebin.com/etosipegez.pl
extra log -- https://hastebin.com/yudafudegu.go
Docker logs https://hastebin.com/imotenanob.cs
Gloabls.yml https://hastebin.com/ihamepanim.coffeescript

Any help would be of great use ???

Thanks in advance...

Thank you !!!
Goutham Pratapa
__
OpenStack Development Mailing 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][ptl] Improving the process for release marketing

[Amrith Kumar]

Very cool, thanks Sean!


-amrith


On Mon, Nov 20, 2017 at 12:18 PM, Sean McGinnis 
wrote:

> Hello PTL's, release liaisons, and all those interested.
>
> The changes on our side to support a release cycle highlights page have
> been
> completed, and things have settled a bit from the Summit activies, so I
> think
> now is a good time to get things going again for this.
>
> See below for the background, but if you missed it or have forgotten by
> now, we
> plan to have an easier way to collect significant "highlights" for each
> release
> cycle in order to collect "key features" flagged by each team that
> marketing
> teams can use during release communication times. The goal is to reduce the
> number of times PTL's get asked by various groups to "tell us what changed
> in
> this release."
>
> The way we are approaching this is by adding a "cycle-highlights" key to
> the
> deliverable file for your project [1]. This field will take RST formatted
> text
> that will then be rendered into the highlights page we will share with
> marketing.
>
> Our goal is to have roughly three "highlights" per team for each release,
> but
> this will vary based on the needs of the team and the amount of work done
> during the cycle. If there is only one significant change to share, that is
> fine. If there are five, that's OK too. Just keep in mind that these
> should be
> limited to only the significant changes that you feel are worth
> communicating
> to the marketing, sales, and end users out there that need to know what to
> expect.
>
> We will want to start collecting this information as we near RC releases,
> but
> feel free to start adding items of interest with the upcoming Queens-2
> release
> if you already have changes worth noting.
>
> And please ask here or in the #openstack-release channel if you have any
> questions about how this works.
>
> Thanks,
> Sean
>
> [1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n466
>
> P.S. This is for cycle_* deliverables only. If you see a need for this
> with the
> independent releases, let me know and we can talk about how that might
> look.
>
>
> On Tue, Sep 26, 2017 at 02:33:09PM -0700, Anne Bertucio wrote:
> > Release marketing is a critical part of sharing what’s new in each
> release, and we want to rework how the marketing community and projects
> work together to make the release communications happen.
> >
> > Having multiple, repetetive demands to summarize "top features" during
> release time can be pestering and having to recollect the information each
> time isn't an effective use of time. Being asked to make polished,
> "press-friendly" messages out of release notes can feel too far outside of
> the PTL's focus areas or skills. At the same time, for technical content
> marketers, attempting to find the key features from release notes, ML
> posts, specs, Roadmap, etc., means interesting features are sometimes
> overlooked. Marketing teams don't have the latest on what features landed
> and with what caveats.
> >
> > To address this gap, the Release team and Foundation marketing team
> propose collecting information as part of the release tagging process.
> Similar to the existing (unused) "highlights" field for an individual tag,
> we will collect some text in the deliverable file to provide highlights for
> the series (about 3 items). That text will then be used to build a landing
> page on release.openstack.org that shows the "key features" flagged by
> PTLs that marketing teams should be looking at during release communication
> times. The page will link to the release notes, so marketers can start
> there to gather additional information, eliminating repetitive asks of
> PTLs. The "pre selection" of features means marketers can spend more time
> diving into release note details and less sifting through them.
> >
> > To supplement the written information, the marketing community is also
> going to work together to consolidate follow up questions and deliver them
> in "press corps" style (i.e. a single phone call to be asked questions from
> multiple parties vs. multiple phone calls from individuals).
> >
> > We will provide more details about the implementation for the highlights
> page when that is ready, but want to gather feedback about both aspects of
> the plan early.
> >
> > Thanks for your input,
> > Anne Bertucio and Sean McGinnis
> >
> >
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing 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
> 

[openstack-dev] [tricircle] No Tricircle meeting tomorrow

[Vega Cai]

Hi,

Tomorrow I will attend the bug smash in Wuhan so I will not be able to
chair the weekly meeting. We will resume the meeting next week.

BR
Zhiyuan
-- 
BR
Zhiyuan
__
OpenStack Development Mailing 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] Request for input: scaling the number of Ceph clusters deployed in the overcloud

[Giulio Fidente]

Hi,

we're currently exploring ways to deploy multiple Ceph clusters in the
overcloud.

Given Ceph is now managed by a ceph-ansible playbook, we can "easily"
deploy multiple Ceph clusters running multiple times the playbook with
different parameters and inventory.


The initial idea to make this consumable in TripleO has been to have
jinja add a prefix to the Ceph service names and its parameters, and let
the user build custom roles (deploying on each a different instance of
the Ceph service) to distribute the Ceph services as needed on any
arbitrary role.

The benefits of the above approach are that daemons of different Ceph
clusters can be colocated on the same node and that operators continue
to customize any Ceph parameter using heat environment files as they
used to (they just add the jinja prefix to the parameter name).

The cons are that we'd need to scale (hence use jinja) also for other
services, like Cinder or Nova because the Ceph parameters can be
consumed by those too.


An alternate proposal has been to tag the roles, bound the Ceph cluster
to a tag to build the inventory and use role-specific settings so that
instances of the Ceph services deployed on a role would get different
parameters based on the role they run on.

The most important benefit that I can see of the above approach is that
it is a lot less intrusive as it does not require jinja processing of
the templates but I think I do not understand fully how the
implementation would look like so I was curious if there are examples in
tree of anything similar?

I would also like to know if other people is interested in this same
functionality so that we can come up with a more generalized solution?

Last but not least, I would like to hear more input, ideas and feedback
to see if there are more ways of doing this!

Thanks for the feedback
-- 
Giulio Fidente
GPG KEY: 08D733BA

__
OpenStack Development Mailing 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] Updates on the TripleO on Kubernetes work

[Jiří Stránský]

Kubernetes on the overcloud
===

The work on this front started with 2[0][1] patches that some of you might have
seen and then evolved into using the config download mechanism to execute these
tasks as part of the undercloud tasks[2][3] (Thanks a bunch, Jiri, for your work
here). Note that [0] needs to be refactored to use the same mechanism used in
[2].


For those interested in trying the work we've done on deploying vanilla 
Kubernetes, i put together a post showing how to deploy it with OOOQ, 
and also briefly explaining the new external_deploy_tasks in service 
templates:


https://www.jistr.com/blog/2017-11-21-kubernetes-in-tripleo/



There are quite a few things to improve here:

- How to configure/manage the loadbalancer/vips on the overcloud Kubespray is
- currently being cloned and we need to build a package for it More CI is likely
- needed for this work

[0] https://review.openstack.org/494470
[1] https://review.openstack.org/471759
[2] https://review.openstack.org/#/c/511272/
[3] https://review.openstack.org/#/c/514730/


__
OpenStack Development Mailing 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] [Networking-odl] [Qos] networking-odl is not sending complete data during qos-policy-name update

[A Vamsikrishna]

Hi All,

Networking-odl is not sending bandwidth_limit_rules & dscp_marking_rules along 
with the updated qos policy name when I have updated the qos-policy-name from 
Vamsi to Krish.

Expected behavior is to have the updated policy name along with 
bandwidth_limit_rules & dscp_marking_rules same as that in old qos-policy-name.



Version: Stable/Newton
192.168.56.102 --> Openstack
192.168.56.1 --> ODL

Any thoughts on how to move forward ?

PFA for wireshark cap.

JavaScript Object Notation: application/json
Object
Member Key: policy
Object
Member Key: bandwidth_limit_rules
Array
Key: bandwidth_limit_rules
Member Key: name
String value: Krish
Key: name
Member Key: created_at
String value: 2017-11-20T19:27:06Z
Key: created_at
Member Key: updated_at
String value: 2017-11-20T19:27:15Z
Key: updated_at
Member Key: dscp_marking_rules
Array
Key: dscp_marking_rules
Member Key: revision_number
Number value: 4
Key: revision_number
Member Key: shared
False value
Key: shared
Member Key: project_id
String value: eacd04d3ff4b4e1d9dc2f5282edbb9e0
Key: project_id
Member Key: id
String value: 066fd21e-2041-43f6-956a-6bec0948bf15
Key: id
Member Key: description
String value:
Key: description
Key: policy


Thanks,
Vamsi


final wireshark.pcap
Description: final wireshark.pcap
__
OpenStack Development Mailing 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] New core on networking-bgpvpn

[Thomas Morin]

Hi everyone,

Let me welcome Édouard Thuleau (doude) as a new core on
networking-bgpvpn!

Édouard has been following and contributing from the early days, in
particular on the framework and on the API client. He knows the project
well and has done multiple reviews. He also knows about the questions
related to drivers, having written the driver for OpenContrail.  

Cheers,

-Thomas





































































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

[openstack-dev] [nova] Add scenario tests based on multiple cells environment

[koshiya maho]

Hi, all

Multiple cells (Nova-Cells-v2) is supported in Pike release.
It is necessary to confirm that existing APIs work appropriately in the 
multiple cells environment.
We will post multiple patches, so I created BluePrint[1] to make it easier to 
keep track of those patches.
Please check the contents and approve it.

[1] 
https://blueprints.launchpad.net/nova/+spec/add-multiple-cells-scenario-tests

Best regards,
--
Maho Koshiya
E-Mail : koshiya.m...@po.ntt-tx.co.jp



__
OpenStack Development Mailing 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] Removing internet access from unit test gates

[Thomas Goirand]

Hi everyone!

I believe all distributions are running unit tests of packages, either
at build time, or later on (for example in autopkgtest). In Debian, it's
done mostly at build time. There it's forbidden to access internet, and
on purpose, Debian buildd servers wont provide internet access when
building.

Unfortunately, a number of OpenStack packages have internet accessing
unit tests. I believe this is by mistake, or lack of knowledge of some
upstream developers. It's unfortunately often discovered after the
facts, like for example https://bugs.debian.org/882266 (note: no finger
pointing here, this is just yet another instance of the issue and just
an example out of many others, and probably the first time in Horizon).

One easy way, at least in python, is to define the environment variables:

http_proxy=127.0.0.1:9
https_proxy=127.0.0.9:9
HTTP_PROXY=127.0.0.1:9
HTTPS_PROXY=127.0.0.1:9

This way, no way to do an accidental implementation mistake.

This is of course not desirable under the functional/integration testing
environment.

The only way that I see going forward, is having internet access removed
from unit tests in the gate, or probably just the above variables set.

Your thoughts?

Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] [gnocchi]can we put the api on udp?

[Julien Danjou]

On Tue, Nov 21 2017, 李田清 wrote:

> right now, ceilometer notification agent can send samples by udp 
> publisher..
> But gnocchi can only accept by rest api. Is there a way to use udp to 
> accept notification agent's samples that sending by udp?

I'd suggest tracking this here since an issue just has been opened about
it:
  https://github.com/gnocchixyz/gnocchi/issues/496

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