Re: [openstack-dev] [tripleo] cannot configure host kernel-args for pci passthrough with first-boot

[Saravanan KR]

Could you check the log in the /var/log/cloud-init-output.log file to
see what are the first-boot scripts which are executed on the node?
Add "set -x" in the kernel-args.sh file to better logs.

Regards,
Saravanan KR

On Tue, May 22, 2018 at 12:49 AM, Samuel Monderer
 wrote:
> Hi,
>
> I'm trying to build a new OS environment with RHOSP 11 with a compute has
> that has GPU card.
> I've added a new role and a firstboot template to configure the kernel args
> to allow pci-passthrough.
> For some reason the firstboot is not working (can't see the changes on the
> compute node)
> Attached are the templates I used to deploy the environment.
>
> I used the same configuration I used for a compute role with sr-iov and it
> worked there.
> Could someone tell me what I missed?
>
> 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
>

__
OpenStack Development Mailing 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] Limiting sudo coverage of heat-admin / stack and other users.

[Cédric Jeanneret]

On 05/21/2018 03:49 PM, Luke Hinds wrote:
> A few operators have requested if its possible to limit sudo's coverage
> on both the under / overcloud. There is concern over `ALL=(ALL)
> NOPASSWD:ALL` , which allows someone to  `sudo su`.
> 
> This task has come under the care of the tripleo security squad.
> 
> The work is being tracked and discussed here [0].
> 
> So far it looks like the approach will be to use regexp within
> /etc/sudoers.d/*., to narrow down as close as possible to the specific
> commands called. Some services already do this with rootwrap:
> 
> ironic ALL = (root) NOPASSWD: /usr/bin/ironic-rootwrap
> /etc/ironic/rootwrap.conf *   
> 
> It's fairly easy to pick up a list of all sudo calls using a simple
> script [1]
> 
> The other prolific user of sudo is ansible / stack, for example:
> 
> /bin/sh -c echo BECOME-SUCCESS-kldpbeueyodisjajjqthpafzadrncdff;
> /usr/bin/python
> /home/stack/.ansible/tmp/ansible-tmp-1526579105.0-109863952786117/systemd.py;
> rm -rf
> "/home/stack/.ansible/tmp/ansible-tmp-1526579105.0-109863952786117/" >
> /dev/null 2>&1
> 
> My feelings here are to again use regexp around the immutable non random
> parts of the command.  cjeanner also made some suggestions in the
> etherpad [0].

Might be a temporary way to limit the surface indeed, but an upstream
change in Ansible would still be really nice. Predictable names is the
only "right" way, although this will create a long sudo ruleset. A
really long one to be honnest. Maintainability is also to be discussed
in either way (maintain a couple of regexp vs 200+ rules.. hmmm).

> 
> However aside to the approach, we need to consider the impact locking
> down might have should someone create a develop a new bit of code that
> leverages commands wrapped in sudo and assumes ALL with be in place.
> This of course will be blocked.

This will indeed require some doc, as this is a "major" change. However,
the use of regexp should somewhat limit the impact, especially since
Ansible pushes its exec script in the same location.
Even new parts should be allowed (that might be a bit of concern if we
want to really dig in the consequences of a bad template being injected
in some way [looking config-download ;)]).
But at some point, we might also decide to let the OPs ensure their
infra isn't compromised.
Always the same thread-of with Security vs The World - convenience vs
cumbersome management, and so on.

> 
> Now my guess is that our CI would capture this as the deploy would
> fail(?) and the developer should work out an entry is needed when
> testing their patch, but wanted to open this up to others who know
> testing at gate better much better than myself.  Also encourage any
> thoughts on the topic to be introduced to the etherpad [0]
> 
> [0] https://etherpad.openstack.org/p/tripleo-heat-admin-security
> [1] https://gist.github.com/lukehinds/4cdb1bf4de526a049c51f05698b8b04f
> 
> -- 
> Luke Hinds

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



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

Re: [openstack-dev] Problem when deploying Openstack with Kolla

[Rafael Weingärtner]

Sorry, I pressed send without the inventory file.

My inventory file has the following content (this is the standard file I
get when following the procedure described in [1]; I am deploying all-in
one node, therefore, I did not change anything here):


> # These initial groups are the only groups required to be modified. The
> # additional groups are for more control of the environment.
> [control]
> localhost   ansible_connection=local
>
> [network]
> localhost   ansible_connection=local
>
> # inner-compute is the groups of compute nodes which do not have
> # external reachability.
> # DEPRECATED, the group will be removed in S release of OpenStack,
> # use variable neutron_compute_dvr_mode instead.
> [inner-compute]
>
> # external-compute is the groups of compute nodes which can reach
> # outside.
> # DEPRECATED, the group will be removed in S release of OpenStack,
> # use variable neutron_compute_dvr_mode instead.
> [external-compute]
> localhost   ansible_connection=local
>
> [compute:children]
> inner-compute
> external-compute
>
> [storage]
> localhost   ansible_connection=local
>
> [monitoring]
> localhost   ansible_connection=local
>
> [deployment]
> localhost   ansible_connection=local
>
> # You can explicitly specify which hosts run each project by updating the
> # groups in the sections below. Common services are grouped together.
> [chrony-server:children]
> haproxy
>
> [chrony:children]
> network
> compute
> storage
> monitoring
>
> [collectd:children]
> compute
>
> [baremetal:children]
> control
>
> [grafana:children]
> monitoring
>
> [etcd:children]
> control
> compute
>
> [kafka:children]
> control
>
> [karbor:children]
> control
>
> [kibana:children]
> control
>
> [telegraf:children]
> compute
> control
> monitoring
> network
> storage
>
> [elasticsearch:children]
> control
>
> [haproxy:children]
> network
>
> [hyperv]
> #hyperv_host
>
> [hyperv:vars]
> #ansible_user=user
> #ansible_password=password
> #ansible_port=5986
> #ansible_connection=winrm
> #ansible_winrm_server_cert_validation=ignore
>
> [mariadb:children]
> control
>
> [rabbitmq:children]
> control
>
> [outward-rabbitmq:children]
> control
>
> [qdrouterd:children]
> control
>
> [mongodb:children]
> control
>
> [keystone:children]
> control
>
> [glance:children]
> control
>
> [nova:children]
> control
>
> [neutron:children]
> network
>
> [openvswitch:children]
> network
> compute
> manila-share
>
> [opendaylight:children]
> network
>
> [cinder:children]
> control
>
> [cloudkitty:children]
> control
>
> [freezer:children]
> control
>
> [memcached:children]
> control
>
> [horizon:children]
> control
>
> [swift:children]
> control
>
> [barbican:children]
> control
>
> [heat:children]
> control
>
> [murano:children]
> control
>
> [ceph:children]
> control
>
> [ironic:children]
> control
>
> [influxdb:children]
> monitoring
>
> [prometheus:children]
> monitoring
>
> [magnum:children]
> control
>
> [sahara:children]
> control
>
> [solum:children]
> control
>
> [mistral:children]
> control
>
> [manila:children]
> control
>
> [panko:children]
> control
>
> [gnocchi:children]
> control
>
> [ceilometer:children]
> control
>
> [aodh:children]
> control
>
> [congress:children]
> control
>
> [tacker:children]
> control
>
> [vitrage:children]
> control
>
> # Tempest
> [tempest:children]
> control
>
> [senlin:children]
> control
>
> [vmtp:children]
> control
>
> [trove:children]
> control
>
> [watcher:children]
> control
>
> [rally:children]
> control
>
> [searchlight:children]
> control
>
> [octavia:children]
> control
>
> [designate:children]
> control
>
> [placement:children]
> control
>
> [bifrost:children]
> deployment
>
> [zookeeper:children]
> control
>
> [zun:children]
> control
>
> [skydive:children]
> monitoring
>
> [redis:children]
> control
>
> [blazar:children]
> control
>
> # Additional control implemented here. These groups allow you to control
> which
> # services run on which hosts at a per-service level.
> #
> # Word of caution: Some services are required to run on the same host to
> # function appropriately. For example, neutron-metadata-agent must run on
> the
> # same host as the l3-agent and (depending on configuration) the
> dhcp-agent.
>
> # Glance
> [glance-api:children]
> glance
>
> [glance-registry:children]
> glance
>
> # Nova
> [nova-api:children]
> nova
>
> [nova-conductor:children]
> nova
>
> [nova-consoleauth:children]
> nova
>
> [nova-novncproxy:children]
> nova
>
> [nova-scheduler:children]
> nova
>
> [nova-spicehtml5proxy:children]
> nova
>
> [nova-compute-ironic:children]
> nova
>
> [nova-serialproxy:children]
> nova
>
> # Neutron
> [neutron-server:children]
> control
>
> [neutron-dhcp-agent:children]
> neutron
>
> [neutron-l3-agent:children]
> neutron
>
> [neutron-lbaas-agent:children]
> neutron
>
> [neutron-metadata-agent:children]
> neutron
>
> [neutron-bgp-dragent:children]
> neutron
>
> [neutron-infoblox-ipam-agent:children]
> neutron
>
> # Ceph
> [ceph-mds:children]
> ceph
>
> 

Re: [openstack-dev] Problem when deploying Openstack with Kolla

[Rafael Weingärtner]

Well, everything is pretty standard (I am only deploying a POC), I am
following this "documentation"[1]. I did not change much from the default
files.
[1]
https://docs.openstack.org/project-deploy-guide/kolla-ansible/queens/quickstart.html#

Globals:

> ---
> # You can use this file to override _any_ variable throughout Kolla.
> # Additional options can be found in the
> # 'kolla-ansible/ansible/group_vars/all.yml' file. Default value of all the
> # commented parameters are shown here, To override the default value
> uncomment
> # the parameter and change its value.
>
> ###
> # Kolla options
> ###
> # Valid options are [ COPY_ONCE, COPY_ALWAYS ]
> #config_strategy: "COPY_ALWAYS"
>
> # Valid options are ['centos', 'debian', 'oraclelinux', 'rhel', 'ubuntu']
> #kolla_base_distro: "centos"
> kolla_base_distro: "ubuntu"
>
> # Valid options are [ binary, source ]
> #kolla_install_type: "binary"
> kolla_install_type: "source"
>
> # Valid option is Docker repository tag
> #openstack_release: ""
> #openstack_release: "master"
> openstack_release: "queens"
>
> # Location of configuration overrides
> #node_custom_config: "/etc/kolla/config"
>
> # This should be a VIP, an unused IP on your network that will float
> between
> # the hosts running keepalived for high-availability. If you want to run an
> # All-In-One without haproxy and keepalived, you can set enable_haproxy to
> no
> # in "OpenStack options" section, and set this value to the IP of your
> # 'network_interface' as set in the Networking section below.
> network_interface: "enp0s8"
> kolla_internal_vip_address: "192.168.56.250"
>
> # This is the DNS name that maps to the kolla_internal_vip_address VIP. By
> # default it is the same as kolla_internal_vip_address.
> #kolla_internal_fqdn: "{{ kolla_internal_vip_address }}"
>
> # This should be a VIP, an unused IP on your network that will float
> between
> # the hosts running keepalived for high-availability. It defaults to the
> # kolla_internal_vip_address, allowing internal and external communication
> to
> # share the same address.  Specify a kolla_external_vip_address to separate
> # internal and external requests between two VIPs.
> #kolla_external_vip_address: "{{ kolla_internal_vip_address }}"
>
> # The Public address used to communicate with OpenStack as set in the
> public_url
> # for the endpoints that will be created. This DNS name should map to
> # kolla_external_vip_address.
> #kolla_external_fqdn: "{{ kolla_external_vip_address }}"
>
> 
> # Docker options
> 
> # Below is an example of a private repository with authentication. Note the
> # Docker registry password can also be set in the passwords.yml file.
>
> #docker_registry: "172.16.0.10:4000"
> #docker_namespace: "companyname"
> #docker_registry_username: "sam"
> #docker_registry_password: "correcthorsebatterystaple"
>
> ###
> # Messaging options
> ###
> # Below is an example of an separate backend that provides brokerless
> # messaging for oslo.messaging RPC communications
>
> #om_rpc_transport: "amqp"
> #om_rpc_user: "{{ qdrouterd_user }}"
> #om_rpc_password: "{{ qdrouterd_password }}"
> #om_rpc_port: "{{ qdrouterd_port }}"
> #om_rpc_group: "qdrouterd"
>
>
> ##
> # Neutron - Networking Options
> ##
> # This interface is what all your api services will be bound to by default.
> # Additionally, all vxlan/tunnel and storage network traffic will go over
> this
> # interface by default. This interface must contain an IPv4 address.
> # It is possible for hosts to have non-matching names of interfaces -
> these can
> # be set in an inventory file per host or per group or stored separately,
> see
> # http://docs.ansible.com/ansible/intro_inventory.html
> # Yet another way to workaround the naming problem is to create a bond for
> the
> # interface on all hosts and give the bond name here. Similar strategy can
> be
> # followed for other types of interfaces.
> #network_interface: "eth0"
>
> # These can be adjusted for even more customization. The default is the
> same as
> # the 'network_interface'. These interfaces must contain an IPv4 address.
> #kolla_external_vip_interface: "{{ network_interface }}"
> #api_interface: "{{ network_interface }}"
> #storage_interface: "{{ network_interface }}"
> #cluster_interface: "{{ network_interface }}"
> #tunnel_interface: "{{ network_interface }}"
> #dns_interface: "{{ network_interface }}"
>
> # This is the raw interface given to neutron as its external network port.
> Even
> # though an IP address can exist on this interface, it will be unusable in
> most
> # configurations. It is recommended this interface not be configured with
> any IP
> # addresses for that reason.
> #neutron_external_interface: "eth1"
> neutron_external_interface: "enp0s9"
>
> # Valid options are [ openvswitch, linuxbridge, vmware_nsxv, vmware_dvs,
> opendaylight ]
> neutron_plugin_agent: 

Re: [openstack-dev] Problem when deploying Openstack with Kolla

[Jeffrey Zhang]

seems there are some issue in you inventory file.
Could you compare your inventory file with the one in kolla-ansible code?

if you are still not fix it, try to provide you globals.yml file and
inventory file in ML.

On Tue, May 22, 2018 at 6:51 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Hello OpenStackers,
> First of all, I am not sure if this is the right list to post this
> question. Therefore, please excuse me if I am sending an e-mail to the
> wrong place.
>
> So, I have been trying to use Kolla to deploy a POC environment of
> OpenStack. However, I have not been able to do so. Right now I am getting
> the following error:
>
> fatal: [localhost]: FAILED! => {"msg": "The conditional check
>> '(neutron_l3_agent.enabled | bool and neutron_l3_agent.host_in_groups |
>> bool) or (neutron_vpnaas_agent.enabled | bool and
>>  neutron_vpnaas_agent.host_in_groups | bool)' failed. The error was:
>> error while evaluating conditional ((neutron_l3_agent.enabled | bool and
>> neutron_l3_agent.host_in_groups | bool) or (neutron_vpnaas_agent.enabled
>> | bool and  neutron_vpnaas_agent.host_in_groups | bool)): Unable to look
>> up a name or access an attribute in template string ({{ inventory_hostname
>> in groups['neutron-vpnaas-agent'] }}).\nMake sure your variable name does
>> not contain invalid characters like '-': argument of type 'StrictUndefined'
>> is not iterable\n\nThe error appears to have been in
>> '/usr/local/share/kolla-ansible/ansible/roles/neutron/tasks/config.yml':
>> line 2, column 3, but may\nbe elsewhere in the file depending on the exact
>> syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
>> Setting sysctl values\n  ^ here\n"}
>>
>
> It looks like an Ansible problem. I checked the file
> “/usr/local/share/kolla-ansible/ansible/roles/neutron/tasks/config.yml”
> at line 5, it has the following declaration:
>
>> neutron_l3_agent: "{{ neutron_services['neutron-l3-agent'] }}"
>>
>
> As far as I understand everything is ok with this variable declaration.
> There is the “neutron-l3-agent” parameter used to retrieve an element from
> “neutron_services” map, but that does look ok. Has anybody else experienced
> this problem before?
>
> I am using Kolla for OpenStack queens. I am using kolla with the following
> command.
>
>> kolla-ansible -i all-in-one bootstrap-servers && kolla-ansible -i
>> all-in-one prechecks && kolla-ansible -i all-in-one deploy
>>
>
> As you can see, it is a simple use case to deploy OpenStack in a single
> node. The command that is failing is the following.
>
>> kolla-ansible -i all-in-one deploy
>>
>
> --
> Rafael Weingärtner
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing 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] Problem when deploying Openstack with Kolla

[Rafael Weingärtner]

Hello OpenStackers,
First of all, I am not sure if this is the right list to post this
question. Therefore, please excuse me if I am sending an e-mail to the
wrong place.

So, I have been trying to use Kolla to deploy a POC environment of
OpenStack. However, I have not been able to do so. Right now I am getting
the following error:

fatal: [localhost]: FAILED! => {"msg": "The conditional check
> '(neutron_l3_agent.enabled | bool and neutron_l3_agent.host_in_groups |
> bool) or (neutron_vpnaas_agent.enabled | bool and
>  neutron_vpnaas_agent.host_in_groups | bool)' failed. The error was: error
> while evaluating conditional ((neutron_l3_agent.enabled | bool and
> neutron_l3_agent.host_in_groups | bool) or (neutron_vpnaas_agent.enabled |
> bool and  neutron_vpnaas_agent.host_in_groups | bool)): Unable to look up a
> name or access an attribute in template string ({{ inventory_hostname in
> groups['neutron-vpnaas-agent'] }}).\nMake sure your variable name does not
> contain invalid characters like '-': argument of type 'StrictUndefined' is
> not iterable\n\nThe error appears to have been in
> '/usr/local/share/kolla-ansible/ansible/roles/neutron/tasks/config.yml':
> line 2, column 3, but may\nbe elsewhere in the file depending on the exact
> syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
> Setting sysctl values\n  ^ here\n"}
>

It looks like an Ansible problem. I checked the file
“/usr/local/share/kolla-ansible/ansible/roles/neutron/tasks/config.yml” at
line 5, it has the following declaration:

> neutron_l3_agent: "{{ neutron_services['neutron-l3-agent'] }}"
>

As far as I understand everything is ok with this variable declaration.
There is the “neutron-l3-agent” parameter used to retrieve an element from
“neutron_services” map, but that does look ok. Has anybody else experienced
this problem before?

I am using Kolla for OpenStack queens. I am using kolla with the following
command.

> kolla-ansible -i all-in-one bootstrap-servers && kolla-ansible -i
> all-in-one prechecks && kolla-ansible -i all-in-one deploy
>

As you can see, it is a simple use case to deploy OpenStack in a single
node. The command that is failing is the following.

> kolla-ansible -i all-in-one deploy
>

--
Rafael Weingärtner
__
OpenStack Development Mailing 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] Migration to Storyboard

[Emilien Macchi]

During the Storyboard session today:
https://etherpad.openstack.org/p/continuing-the-migration-lp-sb

We mentioned that TripleO would continue to migrate during Rocky cycle.
Like Alex mentioned in this thread, we need to migrate the scripts used by
the CI squad so they work with SB.
Once this is done, we'll proceed to the full migration of all blueprints
and bugs into tripleo-common project in SB.
Projects like tripleo-validations, tripleo-ui (more?) who have 1:1 mapping
between their "name" and project repository could use a dedicated project
in SB, although we need to keep things simple for our users so they know
where to file a bug without confusion.
We hope to proceed during Rocky but it'll probably take some time to update
our scripts and documentation, also educate our community to use the tool,
so we expect the Stein cycle the first cycle where we actually consume SB.

I really wanted to thank the SB team for their patience and help, TripleO
is big and this migration hasn't been easy but we'll make it :-)

Thanks,

On Tue, May 15, 2018 at 7:53 AM, Alex Schultz  wrote:

> Bumping this up so folks can review this.  It was mentioned in this
> week's meeting that it would be a good idea for folks to take a look
> at Storyboard to get familiar with it.  The upstream docs have been
> updated[0] to point to the differences when dealing with proposed
> patches.  Please take some time to review this and raise any
> concerns/issues now.
>
> Thanks,
> -Alex
>
> [0] https://docs.openstack.org/infra/manual/developers.html#
> development-workflow
>
> On Wed, May 9, 2018 at 1:24 PM, Alex Schultz  wrote:
> > Hello tripleo folks,
> >
> > So we've been experimenting with migrating some squads over to
> > storyboard[0] but this seems to be causing more issues than perhaps
> > it's worth.  Since the upstream community would like to standardize on
> > Storyboard at some point, I would propose that we do a cut over of all
> > the tripleo bugs/blueprints from Launchpad to Storyboard.
> >
> > In the irc meeting this week[1], I asked that the tripleo-ci team make
> > sure the existing scripts that we use to monitor bugs for CI support
> > Storyboard.  I would consider this a prerequisite for the migration.
> > I am thinking it would be beneficial to get this done before or as
> > close to M2.
> >
> > Thoughts, concerns, etc?
> >
> > Thanks,
> > -Alex
> >
> > [0] https://storyboard.openstack.org/#!/project_group/76
> > [1] http://eavesdrop.openstack.org/meetings/tripleo/2018/
> tripleo.2018-05-08-14.00.log.html#l-42
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [all][tc][ptls] final stages of python 3 transition

[John Dickinson]

On 20 May 2018, at 17:19, Thomas Goirand wrote:


On 05/20/2018 06:24 PM, Matthew Treinish wrote:

On Sun, May 20, 2018 at 03:05:34PM +0200, Thomas Goirand wrote:

Thanks for these details. What exactly is the trouble with the Swift
backend? Do you know? Is anyone working on fixing it? At my company,
we'd be happy to work on that (if of course, it's not too time 
demanding).




Sorry I didn't mean the swift backend, but swift itself under 
python3:


https://wiki.openstack.org/wiki/Python3#OpenStack_applications_.28tc:approved-release.29

If you're trying to deploy everything under python3 I don't think 
you'll be
able to deploy swift. But if you already have a swift running then 
the glance

backend should work fine under pythom 3.


Of course I know Swift isn't Python 3 ready. And that's sad... :/


yep. we're still working on it. slowly.



However, we did also experience issues with the swift backend last 
week.

Hopefully, with the switch to uwsgi it's going to work. I'll let you
know if that's not the case.


Is the "switch to uwsgi" something about how you're running swift or 
something about how you're running glance?


FWIW, my experience with putting TLS in front of Swift is to run Swift 
as "normal" (ie run `swift-proxy-server /etc/swift/proxy-server.conf` 
itself instead of under apache or nginx or something else). Then use 
HAProxy or hitch to terminate TLS and forward that internally to the 
proxy server.




Cheers,

Thomas Goirand (zigo)

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

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

Re: [openstack-dev] Vancouver Forum Etherpad List

[Akihiro Motoki]

I would like to re-post this Sean's post on the YVR forum etherpad list as
I believe this is worth shared now again.

2018年5月9日(水) 7:48 Sean McGinnis :

> We are now less than two weeks away from the next Summit/Forum in
> Vancouver.
> Hopefully teams are able to spend some time preparing for their Forum
> sessions
> to make them productive.
>
> I have updated the Forum wiki page to start collecting links to session
> etherpads:
>
> https://wiki.openstack.org/wiki/Forum/Vancouver2018
>
> Please update this page with your etherpads as they are ready to make this
> one
> easy place to go to for all sessions. I have started populating some
> sessions
> so there is a start, but there are many that still need to be filled in.
>
> Looking forward to another week in Vancouver.
>
> Thanks!
> 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
>
__
OpenStack Development Mailing 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] [sahara] Meeting Canceled

[Telles Nobrega]

Hi folks,

Since I'm attending the OpenStack Summit I won't be able to attend the
meeting this week and therefore I'm canceling it.

If anything critical comes up and needs some discussion this week, send an
email on ML and I will reply ASAP.

Thanks,
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat Brasil  

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
 Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo Great Place to Work.
__
OpenStack Development Mailing 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] [docs] Updates to openstack-doc-core

[Petr Kovar]

Hi all,

I'd like to thank Brian Moss and Maria Zlatkova who
recently stepped down from the docs core team, for all their
contributions to OpenStack documentation in the past years. 

Thank you for your community work, insight, and ideas you shared with
the community while in your core role. Hope to see you around OpenStack or
other open source project in the future!

Cheers,
pk

__
OpenStack Development Mailing 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] Proposing Mark Goddard to ironic-core

[Jim Rollenhagen]

On Sun, May 20, 2018 at 10:45 AM, Julia Kreger 
wrote:

> Greetings everyone!
>
> I would like to propose Mark Goddard to ironic-core. I am aware he
> recently joined kolla-core, but his contributions in ironic have been
> insightful and valuable. The kind of value that comes from operative use.
>
> I also make this nomination knowing that our community landscape is
> changing and that we must not silo our team responsibilities or ability to
> move things forward to small highly focused team. I trust Mark to use his
> judgement as he has time or need to do so. He might not always have time,
> but I think at the end of the day, we’re all in that same boat.
>

+2!

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

[openstack-dev] [tripleo] Limiting sudo coverage of heat-admin / stack and other users.

[Luke Hinds]

A few operators have requested if its possible to limit sudo's coverage on
both the under / overcloud. There is concern over `ALL=(ALL) NOPASSWD:ALL`
, which allows someone to  `sudo su`.

This task has come under the care of the tripleo security squad.

The work is being tracked and discussed here [0].

So far it looks like the approach will be to use regexp within
/etc/sudoers.d/*., to narrow down as close as possible to the specific
commands called. Some services already do this with rootwrap:

ironic ALL = (root) NOPASSWD: /usr/bin/ironic-rootwrap
/etc/ironic/rootwrap.conf *

It's fairly easy to pick up a list of all sudo calls using a simple script
[1]

The other prolific user of sudo is ansible / stack, for example:

/bin/sh -c echo BECOME-SUCCESS-kldpbeueyodisjajjqthpafzadrncdff;
/usr/bin/python
/home/stack/.ansible/tmp/ansible-tmp-1526579105.0-109863952786117/systemd.py;
rm -rf "/home/stack/.ansible/tmp/ansible-tmp-1526579105.0-109863952786117/"
> /dev/null 2>&1

My feelings here are to again use regexp around the immutable non random
parts of the command.  cjeanner also made some suggestions in the etherpad
[0].

However aside to the approach, we need to consider the impact locking down
might have should someone create a develop a new bit of code that leverages
commands wrapped in sudo and assumes ALL with be in place. This of course
will be blocked.

Now my guess is that our CI would capture this as the deploy would fail(?)
and the developer should work out an entry is needed when testing their
patch, but wanted to open this up to others who know testing at gate better
much better than myself.  Also encourage any thoughts on the topic to be
introduced to the etherpad [0]

[0] https://etherpad.openstack.org/p/tripleo-heat-admin-security
[1] https://gist.github.com/lukehinds/4cdb1bf4de526a049c51f05698b8b04f

-- 
Luke Hinds
__
OpenStack Development Mailing 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 bug deputy report

[James Anziano]

Hi all,
 
As mentioned already in an early update last week, there is one critical bug: https://bugs.launchpad.net/neutron/+bug/1771293
 
Seems to have been a slow week, and the few other bugs were fairly minor, but I wanted to bring some up for attention:
 
Speaking of quotas from the critical bug, there is also https://bugs.launchpad.net/neutron/+bug/1771781. I don't know much about the neutron's quotas logic, so if anyone more familiar wants to take a look at this, please do :)
 
Discussion of EU's new GDPR guidelines and their potential impact on OpenStack or OpenStack users: https://bugs.launchpad.net/neutron/+bug/1771493 If anyone has some more relevant knowledge regarding GDPR, that would be appreciated!
 
 
For the following bug deputy this week, would you mind looking at https://bugs.launchpad.net/neutron/+bug/1771412 please? For whatever reason my py35 tox environment consistently refused to build, so I could not manage to recreate this bug.
 
Have fun in Vancouver for everyone attending!
 
Thanks,
 - James Anziano


__
OpenStack Development Mailing 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][heat] Heat sessions in Vancouver summit!! And they're all in Tuesday!

[Rico Lin]

Dear all

As Summit is about to start, looking forward to meet all of you here.
Don't miss out sessions from Heat team. They're all on Tuesday!
Feel free to let me know if you hope to see anything or learn anything
from sessions.
Will try my best to prepare it for you.




*Tuesday 229:00am - 9:40am Users & Ops feedback for Heat *
Vancouver Convention Centre West - Level Two - Room 220
https://www.openstack.org/summit/vancouver-2018/summit-
schedule/events/21713/users-and-ops-feedback-for-heat


*11:00am - 11:20am Heat - Project Update*
Vancouver Convention Centre West - Level Two - Room 212
https://www.openstack.org/summit/vancouver-2018/summit-
schedule/events/21595/heat-project-update


*1:50pm - 2:30pm Heat - Project Onboarding*
Vancouver Convention Centre West - Level Two - Room 223
https://www.openstack.org/summit/vancouver-2018/summit-
schedule/events/21629/heat-project-onboarding


See you all on Tuesday!!

-- 
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] [cyborg] [nova] Cyborg quotas

[Blair Bethwaite]

(Please excuse the top-posting)

The other possibility is that the Cyborg managed devices are plumbed in via
IP in guest network space. Then "attach" isn't so much a Nova problem as a
Neutron one - probably similar to Manila.

Has the Cyborg team considered a RESTful-API proxy driver, i.e., something
that wraps a vendor-specific accelerator service and makes it friendly to a
multi-tenant OpenStack cloud? Quantum co-processors might be a compelling
example which fit this model.

Cheers,

On Sun., 20 May 2018, 23:28 Chris Friesen, 
wrote:

> On 05/19/2018 05:58 PM, Blair Bethwaite wrote:
> > G'day Jay,
> >
> > On 20 May 2018 at 08:37, Jay Pipes  wrote:
> >> If it's not the VM or baremetal machine that is using the accelerator,
> what
> >> is?
> >
> > It will be a VM or BM, but I don't think accelerators should be tied
> > to the life of a single instance if that isn't technically necessary
> > (i.e., they are hot-pluggable devices). I can see plenty of scope for
> > use-cases where Cyborg is managing devices that are accessible to
> > compute infrastructure via network/fabric (e.g. rCUDA or dedicated
> > PCIe fabric). And even in the simple pci passthrough case (vfio or
> > mdev) it isn't hard to imagine use-cases for workloads that only need
> > an accelerator sometimes.
>
> Currently nova only supports attach/detach of volumes and network
> interfaces.
> Is Cyborg looking to implement new Compute API operations to support hot
> attach/detach of various types of accelerators?
>
> Chris
>
>
>
> __
> OpenStack Development Mailing 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] weekly meeting is cancelled May 23

[Jeffrey Zhang]

Hi guys,

we are canceling next Kolla weekly meeting on May 23th, due to the summit.
It will be resumed at May 30th.

-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing 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] [cyborg] [nova] Cyborg quotas

[Zhipeng Huang]

@Chris yes we are actively exploring this option :)

On Mon, May 21, 2018 at 2:27 PM, Chris Friesen 
wrote:

> On 05/19/2018 05:58 PM, Blair Bethwaite wrote:
>
>> G'day Jay,
>>
>> On 20 May 2018 at 08:37, Jay Pipes  wrote:
>>
>>> If it's not the VM or baremetal machine that is using the accelerator,
>>> what
>>> is?
>>>
>>
>> It will be a VM or BM, but I don't think accelerators should be tied
>> to the life of a single instance if that isn't technically necessary
>> (i.e., they are hot-pluggable devices). I can see plenty of scope for
>> use-cases where Cyborg is managing devices that are accessible to
>> compute infrastructure via network/fabric (e.g. rCUDA or dedicated
>> PCIe fabric). And even in the simple pci passthrough case (vfio or
>> mdev) it isn't hard to imagine use-cases for workloads that only need
>> an accelerator sometimes.
>>
>
> Currently nova only supports attach/detach of volumes and network
> interfaces. Is Cyborg looking to implement new Compute API operations to
> support hot attach/detach of various types of accelerators?
>
> Chris
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing 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] [cyborg] [nova] Cyborg quotas

[Chris Friesen]

On 05/19/2018 05:58 PM, Blair Bethwaite wrote:

G'day Jay,

On 20 May 2018 at 08:37, Jay Pipes  wrote:

If it's not the VM or baremetal machine that is using the accelerator, what
is?


It will be a VM or BM, but I don't think accelerators should be tied
to the life of a single instance if that isn't technically necessary
(i.e., they are hot-pluggable devices). I can see plenty of scope for
use-cases where Cyborg is managing devices that are accessible to
compute infrastructure via network/fabric (e.g. rCUDA or dedicated
PCIe fabric). And even in the simple pci passthrough case (vfio or
mdev) it isn't hard to imagine use-cases for workloads that only need
an accelerator sometimes.


Currently nova only supports attach/detach of volumes and network interfaces. 
Is Cyborg looking to implement new Compute API operations to support hot 
attach/detach of various types of accelerators?


Chris



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