Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Yeah that’s a good point. Thanks! From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 10:38 PM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 9:55 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought healthmon and pool. There will be an additional entity called ‘PoolMonitorAssociation’ which results in a many to many relationship between pool and monitors. Right? Now, the model is indicating a pool can have only one monitor. So a minor correction is required to indicate the many to many relationship via PoolMonitorAssociation. Thanks, Vijay V. From: Eugene Nikanorov [mailto:enikano...@mirantis.commailto:enikano...@mirantis.com] Sent: Thursday, May 15, 2014 7:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Hi Vijay, When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? Right, that's the same as health monitors and pools work right now: there are separate REST action to associate healthmon to a pool Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Default routes to SNAT gateway in DVR
Hi DVRers, I didn't see any detail documents or source code on how to deal with routing packet from DVR node to SNAT gw node. If the routing table see a outside ip, it should be matched with a default route, so for the next hop, which interface will it select? Maybe another standalone interconnect subnet per DVR is needed, which connect each DVR node and optionally, the SNAT gw node. For packets from dvr node-snat node, the interconnect subnet act as the default route for this host, and the next hop will be the snat node. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Meaning of qvo, qve, qbr, qr, qg and so on
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15/05/14 20:50, Eduard barrera wrote: Hi all, I was wondering what is the meaning of this acronyms... Are they acronyms, right ? Quantum Virtual O?? Quantum B Ridge ? It's bridge. qg ? It's gateway. qve ? What do they mean ? Thanks ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTdcxAAAoJEC5aWaUY1u57yzsH/Rj7s3YvPp7mcC1DxLrvKmij qzfpk/gWRm8BnjPUlzxX1J8gsAx2E4/vq0q+q8x/IFFBpHhGgG7bVSuhGhBgN0Xg m8mtZdax8Nc6EzgeBTR8kSbAIRjMWdg5EvCpNke69SwzV2gMP428wIBgGaV9jzax 4ojNqkGYJYwHMtj7Ze25IB79pOUdB0BXmwAmwnewCGvFN6vgpgKjSeodDQyggskr dKfeH19i3+fe58ON6KR1Ejpu55mGS2lRlBnJn5iFJmEusRAtv/3fRQ9eNNal2YbO 9tiU0dWjIYUT4A5cjOKTA57FWyADnyWMuL/9mOhm6lX4mrGDkEacl4bYQAEr3EU= =kwbg -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Logging exceptions and Python 3
*@Christian,* According to http://legacy.python.org/dev/peps/pep-0352/ the message attribute of BaseException is deprecated since Python 2.6 and was dropped in Python 3.0. Some projects have custom exception hierarchy, with strictly defined attributes (e.g. message, or something else). In a previous mail, I mean exactly that case, not the case with a built-in exceptions. *@Joshua, * Any reason we would want to do this vs using exc_info=True? 1. It will print traceback and it's not behavior we always want. 2. It doesn't handle unicode. I mean, we may have something like this in our output: \u043f\u0440\u0438\u0432\u0435\u0442 On Fri, May 16, 2014 at 5:19 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: Any reason we would want to do this vs using exc_info=True? This leaves it up to the underlying logger to dump the exception, the traceback and whatever else. For example u can do. LOG.warn(Something broke at this point, exc_info=True) From: Igor Kalnitsky ikalnit...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 2:20 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [oslo] Logging exceptions and Python 3 Hi, Is there a reason to log the exception as Unicode on Python 2? Sure, why not? Some exceptions may have unicode message with non-ASCII characters. and we obviously can't cast such exceptions with str() in Python 2.x. The problem is that I don't know what is the best syntax to log exceptions. I hate this unicode dances too, since I don't understand all nuances and potential pitfalls. But I belive the better approach is to use unicode() for Python 2.x and str() for Python 3.x. Example: LOG.error(six.text_type(e)) P.S: I've a quick look over logging implementaion, and figured out that it has some code to dial with unicode. In few words, if we know about exception's attributes, it's better to use it directly to log: Example: LOG.error(e.message) - Igor On Thu, May 15, 2014 at 6:29 PM, Victor Stinner victor.stin...@enovance.com wrote: Hi, I'm trying to define some rules to port OpenStack code to Python 3. I just added a section in the Port Python 2 code to Python 3 about formatting exceptions and the logging module: https://wiki.openstack.org/wiki/Python3#logging_module_and_format_exceptions The problem is that I don't know what is the best syntax to log exceptions. Some projects convert the exception to Unicode, others use str(). I also saw six.u(str(exc)) which is wrong IMO (it can raise unicode error if the message contains a non-ASCII character). IMO the safest option is to use str(exc). For example, use LOG.debug(str(exc)). Is there a reason to log the exception as Unicode on Python 2? Victor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Keystone
Hi,
We have an openstack Havana deployment on CentOS 6.4 and nova-network
network service installed using Mirantis Fuel v4.0.
We are trying to integrate the openstack setup with the Microsoft Active
Directory(LDAP server). I only have a read access to the LDAP server.
What will be the minimum changes needed to be made under the [ldap] tag in
keystone.conf file?Can you please specify what variables need to be set and
what should be the values for each variable?
[ldap]
# url = ldap://localhost
# user = dc=Manager,dc=example,dc=com
# password = None
# suffix = cn=example,cn=com
# use_dumb_member = False
# allow_subtree_delete = False
# dumb_member = cn=dumb,dc=example,dc=com
# Maximum results per page; a value of zero ('0') disables paging (default)
# page_size = 0
# The LDAP dereferencing option for queries. This can be either 'never',
# 'searching', 'always', 'finding' or 'default'. The 'default' option falls
# back to using default dereferencing configured by your ldap.conf.
# alias_dereferencing = default
# The LDAP scope for queries, this can be either 'one'
# (onelevel/singleLevel) or 'sub' (subtree/wholeSubtree)
# query_scope = one
# user_tree_dn = ou=Users,dc=example,dc=com
# user_filter =
# user_objectclass = inetOrgPerson
# user_id_attribute = cn
# user_name_attribute = sn
# user_mail_attribute = email
# user_pass_attribute = userPassword
# user_enabled_attribute = enabled
# user_enabled_mask = 0
# user_enabled_default = True
# user_attribute_ignore = default_project_id,tenants
# user_default_project_id_attribute =
# user_allow_create = True
# user_allow_update = True
# user_allow_delete = True
# user_enabled_emulation = False
# user_enabled_emulation_dn =
# tenant_tree_dn = ou=Projects,dc=example,dc=com
# tenant_filter =
# tenant_objectclass = groupOfNames
# tenant_domain_id_attribute = businessCategory
# tenant_id_attribute = cn
# tenant_member_attribute = member
# tenant_name_attribute = ou
# tenant_desc_attribute = desc
# tenant_enabled_attribute = enabled
# tenant_attribute_ignore =
# tenant_allow_create = True
# tenant_allow_update = True
# tenant_allow_delete = True
# tenant_enabled_emulation = False
# tenant_enabled_emulation_dn =
# role_tree_dn = ou=Roles,dc=example,dc=com
# role_filter =
# role_objectclass = organizationalRole
# role_id_attribute = cn
# role_name_attribute = ou
# role_member_attribute = roleOccupant
# role_attribute_ignore =
# role_allow_create = True
# role_allow_update = True
# role_allow_delete = True
# group_tree_dn =
# group_filter =
# group_objectclass = groupOfNames
# group_id_attribute = cn
# group_name_attribute = ou
# group_member_attribute = member
# group_desc_attribute = desc
# group_attribute_ignore =
# group_allow_create = True
# group_allow_update = True
# group_allow_delete = True
Kindly help us to resolve the issue.
Thanks,
Tizy
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone] policies using target in v2 API
Greetings, I have noticed a discrepancy in the way policies are enforced between v2 and v3 API calls. Namely, v3 calls pass the user and target contexts to the policy.enforce method, while v2's assert_admin only takes the user context into consideration. The differences appear here as far as I can tell: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L613 (v3) and here: https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py#L256 (v2) I've experimented with roughly patching the v2 API to take the target context into account, but I have run into problems when manually testing it against the CLI. For example, calling 'keystone user-role-add' will list users, projects and roles to retrieve IDs prior to adding the role to a user, but these calls are admin only, and no target context is passed when doing these calls so they will fail if you want, for example, tenant admins in v2 (as in admin rights limited to actions related to a specific tenant). Therefore, such a patch would probably involve some work on the CLI as well. I am aware the notion of tenant admin should probably be treated as business logic outside of keystone, but concerning the difference of treatment between policies enforcements: * Was it a design decision ? * If not, should the v2 API be patched so that the target context can be used with policies ? More generally speaking, what's the common opinion on this since the v2 API is deprecated from now on ? Matthieu Huin m...@enovance.com http://www.enovance.com 11 bis rue roquépine – 75008 PARIS France ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Haproxy configuration options
On 05/12/2014 10:35 AM, Dmitriy Shulyak wrote: Adding haproxy (or keepalived with lvs for load balancing) will require binding haproxy and openstack services on different sockets. Afaik there is 3 approaches that tripleo could go with. Consider configuration with 2 controllers: haproxy: nodes: - name: controller0 ip: 192.0.2.20 - name: controller1 ip: 192.0.2.21 1. Binding haproxy on virtual ip and standard ports haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual ip) port: 80 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22 (virtual ip) proxy_port: 9696 port: 9696 Pros: - No additional modifications in elements is required Actually openstack services elements have to be updated to bind to local address only. HA-Proxy version 1.4.24 2013/06/17 What was the reason this approach was dropped? IIRC the major reason was that having 2 services on same port (but different interface) would be too confusing for anyone who is not aware of this fact. 2. Haproxy listening on standard ports, services on non-standard haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual ip) port: 8080 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22 (virtual ip) proxy_port: 9696 port: 9797 Pros: - No changes will be required to init-keystone part of workflow - Proxied services will be accessible on accustomed ports Bear in mind that we already use not-standard SSL ports for public endpoints. Also extra work will be required for setting up stunnels (element openstack-ssl). - No changes to configs where services ports need to be hardcoded, for example in nova.conf https://review.openstack.org/#/c/92550/ Cons: - Config files should be changed to add possibility of ports configuration Another cons is also updating selinux and firewall rules for each node. 3. haproxy on non-standard ports, with services on standard haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual ip) port: 8080 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22 (virtual ip) proxy_port: 9797 port: 9696 Notice that i changed only port for neutron, main endpoint for horizon should listen on default http or https ports. Agree that having 2 service ports switched in other way than other is sub-optimal. Basicly it is opposite to 2 approach. I would prefer to go with 2, cause it requires only minor refactoring. Thoughts? Options 2 and 3 seem quite equal based on pros vs cons. Maybe we should reconsider option 1? Jan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Haproxy configuration options
HA-Proxy version 1.4.24 2013/06/17 What was the reason this approach was dropped? IIRC the major reason was that having 2 services on same port (but different interface) would be too confusing for anyone who is not aware of this fact. Major part of documentation for haproxy with vip setup is done with duplicated ports. From my experience lb solutions have been made with load balancer sitting on VIRTUAL_IP:STANDART_PORT and/or PUBLIC_VIRTUAL_IP:STANDART_PORT. Maybe this is not so big issue? It will be much easier to start with such deployment configuration Dmitry ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] nova compute repeating logs
Hi I'm trying to boot VM from my controller node(openstack dashboard) onto compute node but it is stucking at spawning state. I'm able to see the VM interface onto the compute but the status is spawning even after 10-15 minutes. Below are the nova schedular logs.. ova/openstack/common/loopingcall.py:130^M 2014-05-16 16:02:16.581 13421 DEBUG nova.openstack.common.periodic_task [-] Running periodic task SchedulerManager._expire_reservations run_periodic_tasks /opt/stack/nova/nova/openstack/common/periodic_task.py:178^M 2014-05-16 16:02:16.588 13421 DEBUG nova.openstack.common.periodic_task [-] Running periodic task SchedulerManager._run_periodic_tasks run_periodic_tasks /opt/stack/nova/nova/openstack/common/periodic_task.py:178^M 2014-05-16 16:02:16.589 13421 DEBUG nova.openstack.common.loopingcall [-] Dynamic looping call sleeping for 60.00 seconds _inner /opt/stack/nova/nova/openstack/common/loopingcall.py:130^M 2014-05-16 16:03:16.593 13421 DEBUG nova.openstack.common.periodic_task [-] Running periodic task SchedulerManager._expire_reservations run_periodic_tasks /opt/stack/nova/nova/openstack/common/periodic_task.py:178^M 2014-05-16 16:03:16.600 13421 DEBUG nova.openstack.common.periodic_task [-] Running periodic task SchedulerManager._run_periodic_tasks run_periodic_tasks /opt/stack/nova/nova/openstack/common/periodic_task.py:178^M 2014-05-16 16:03:16.601 13421 DEBUG nova.openstack.common.loopingcall [-] Dynamic looping call sleeping for 60.00 seconds _inner /opt/stack/nova/nova/openstack/common/loopingcall.py:130^M Also my nova-compute logs at the compute node are repeating continuesly.Below are the logs. -05-16 05:34:19.503 26935 DEBUG nova.openstack.common.periodic_task [-] Running periodic task ComputeManager._poll_volume_usage run_periodic_tasks /opt/stack/nova/nova/openstack/common/periodic_task.py:176^M 2014-05-16 05:34:19.504 26935 DEBUG nova.openstack.common.periodic_task [-] Running periodic task ComputeManager._instance_usage_audit run_periodic_tasks /opt/stack/nova/nova/openstack/common/periodic_task.py:176^M 2014-05-16 05:34:19.504 26935 DEBUG nova.openstack.common.periodic_task [-] Running periodic task ComputeManager.update_available_resource run_periodic_tasks /opt/stack/nova/nova/openstack/common/periodic_task.py:176^M 2014-05-16 05:34:19.505 26935 DEBUG nova.openstack.common.lockutils [-] Got semaphore compute_resources lock /opt/stack/nova/nova/openstack/common/lockutils.py:166^M 2014-05-16 05:34:19.505 26935 DEBUG nova.openstack.common.lockutils [-] Got semaphore / lock update_available_resource inner /opt/stack/nova/nova/openstack/common/lockutils.py:245^M 2014-05-16 05:34:19.505 26935 AUDIT nova.compute.resource_tracker [-] Auditing locally available compute resources^M 2014-05-16 05:34:19.506 26935 DEBUG nova.virt.libvirt.driver [-] Updating host stats update_status /opt/stack/nova/nova/virt/libvirt/driver.py:4865^M 2014-05-16 05:34:19.566 26935 DEBUG nova.openstack.common.processutils [-] Running cmd (subprocess): env LC_ALL=C LANG=C qemu-img info /opt/stack/data/nova/instances/961b0fcd-60e3-488f-93df-5b852d93ede2/disk execute /opt/stack/nova/nova/openstack/common/processutils.py:147^M 2014-05-16 05:34:19.612 26935 DEBUG nova.openstack.common.processutils [-] Running cmd (subprocess): env LC_ALL=C LANG=C qemu-img info /opt/stack/data/nova/instances/961b0fcd-60e3-488f-93df-5b852d93ede2/disk execute /opt/stack/nova/nova/openstack/common/processutils.py:147^M 2014-05-16 05:34:19.703 26935 DEBUG nova.compute.resource_tracker [-] Hypervisor: free ram (MB): 5565 _report_hypervisor_resource_view /opt/stack/nova/nova/compute/resource_tracker.py:388^M 2014-05-16 05:34:19.705 26935 DEBUG nova.compute.resource_tracker [-] Hypervisor: free disk (GB): 95 _report_hypervisor_resource_view /opt/stack/nova/nova/compute/resource_tracker.py:389^M 2014-05-16 05:34:19.705 26935 DEBUG nova.compute.resource_tracker [-] Hypervisor: free VCPUs: 24 _report_hypervisor_resource_view /opt/stack/nova/nova/compute/resource_tracker.py:394^M 2014-05-16 05:34:19.706 26935 DEBUG nova.compute.resource_tracker [-] Hypervisor: assignable PCI devices: [] _report_hypervisor_resource_view /opt/stack/nova/nova/compute/resource_tracker.py:401^M 2014-05-16 05:34:19.708 26935 DEBUG nova.openstack.common.rpc.amqp [-] Making synchronous call on conductor ... multicall /opt/stack/nova/nova/openstack/common/rpc/amqp.py:553^M 2014-05-16 05:34:19.709 26935 DEBUG nova.openstack.common.rpc.amqp [-] MSG_ID is 7435553a261b4f3eb61f985017441333 multicall /opt/stack/nova/nova/openstack/common/rpc/amqp.py:556^M 2014-05-16 05:34:19.709 26935 DEBUG nova.openstack.common.rpc.amqp [-] UNIQUE_ID is f2dd9f9fc517406bbe82366085de5523. _add_unique_id /opt/stack/nova/nova/openstack/common/rpc/amqp.py:341^M 2014-05-16 05:34:19.716 26935 DEBUG nova.openstack.common.rpc.amqp [-] Making synchronous call on conductor ... multicall /opt/stack/nova/nova/openstack/common/rpc/amqp.py:553^M 2014-05-16 05:34:19.717 26935 DEBUG
[openstack-dev] [Cinder] Volume replication design session
Hello, For those who attended the design session on volume replication, thank you, for those who didn't., the Etherpad with the discussion notes is available for your reference at https://etherpad.openstack.org/p/juno-cinder-volume-replication During the session there were people who indicated that they would like to see more features for volume replication, so it would support additional scenarios. If you are among them, and you are willing to document what is missing, what scenarios and use-cases and not being properly addresses, and even suggest how we could address them, please document that on the Etherpad. I created a section at the end to capture all these suggestions - while we may not be able to address all comments, that would be a head start for moving beyond this first step. Regards, __ Ronen I. Kat, PhD Storage Research IBM Research - Haifa Phone: +972.3.7689493 Email: ronen...@il.ibm.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Heat SoftwareConfig and SoftwareDevelopment
Hi all and Baker,
I had try to use Heat::SoftwareDeployment and Heat::SoftwareConfig but
there may be someting wrong with my configuration that the hook-puppet
didn't be invoked.
Firstly, I follow this
instructionhttps://github.com/openstack/heat-templates/tree/master/hot/software-config/elementsto
build a golden image.
*apt-get install qemu-utils*
*git clone https://github.com/openstack/diskimage-builder.git
https://github.com/openstack/diskimage-builder.git*
*git clone https://github.com/openstack/tripleo-image-elements.git
https://github.com/openstack/tripleo-image-elements.git*
*git clone https://github.com/openstack/heat-templates.git
https://github.com/openstack/heat-templates.git*
*root@cloud-t1:~/alex_scripts/heat# cat set_env_path.sh *
*#!/bin/bash*
*export
ELEMENTS_PATH=/root/alex_scripts/heat/tripleo-image-elements/elements:/root/alex_scripts/heat/heat-templates/hot/software-config/elements*
*export DIB_CLOUD_IMAGES=https://cloud-images.ubuntu.com/
https://cloud-images.ubuntu.com/*
*export DIB_RELEASE=trusty*
*export BASE_IMAGE_FILE=trusty-server-cloudimg-amd64-root.tar.gz*
*export
SHA256SUMS=https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS
https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS*
*export
CACHED_FILE=/root/.cache/image-create/trusty-server-cloudimg-amd64-root.tar.gz*
*./diskimage-builder/bin/disk-image-create -a amd64 -o
ubuntu-amd64-heat.qcow2 vm ubuntu heat-cfntools heat-config
heat-config-cfn-init heat-config-puppet heat-config-script
os-collect-config os-refresh-config os-apply-config*
Secondly, I use this
examplehttps://github.com/openstack/heat-templates/blob/master/hot/software-config/example-templates/example-puppet-template.yaml
to
try it out. Everything is OK but the resource of SoftwareDeployment. The
state of SoftwareDeployment is always IN_PROGRESS. I login to the vm, I
check something as follows:
1. Checking the /var/lib/heat-config, hook-puppet is installed.
*root@puppet-demo:/var/lib/heat-config# tree*
*.*
*└── hooks*
*├── cfn-init*
*├── puppet*
*└── script*
2. Checking the WORKING_DIR(/var/lib/heat-config/heat-config-puppet) of
hook-puppet. The WORKING_DIR is not created yet. No any .pp files in the
directory.
3. Checking the status of os-collect-config, it is running. But there are
some warrning in the /var/log/upstart/os-collect-config.log.
*2014-05-16 06:19:31.158 1140 WARNING os_collect_config.cfn [-] No
metadata_url configured.*
*2014-05-16 06:19:31.158 1140 WARNING os-collect-config [-] Source [cfn]
Unavailable.*
*2014-05-16 06:19:31.158 1140 WARNING os_collect_config.heat [-] No
auth_url configured.*
*2014-05-16 06:19:31.159 1140 WARNING os-collect-config [-] Source [heat]
Unavailable.*
4. Checking /var/lib/os-collect-config
*root@puppet-demo:/var/lib/os-collect-config# ls*
*ec2.json ec2.json.last ec2.json.orig heat_local.json
heat_local.json.last heat_local.json.orig os_config_files.json*
*root@puppet-demo:/var/lib/os-collect-config# cat heat_local.json*
*{*
* os-collect-config: {*
* heat: {*
* password: 88cdca28611a47b6af3f92cf350d7e93, *
* user_id: 8a8e83631f4544b88435833512f4fe04, *
* stack_id: puppet-demo/52b04dbb-0bc5-4c89-b4bd-543975a32e06, *
* resource_name: server1, *
* auth_url: http://10.22.129.21:5000/v2.0
http://10.22.129.21:5000/v2.0, *
* project_id: 156739be982340b9b6630bae76984634*
* }*
* }, *
* deployments: []*
*}*
5. Checking the connection between vm and heat-api-cfn server. It's OK.
After checking above things, I still can't to handle thie problem. There
are something I need to understand:
1. Where to store the puppet file and inputs, after the heat-engine
precessing the template?
2. Which meatadata server(heat_local, ec2 or heat-api-cfn) the
os-collect-config will fetching to get the SoftwareDeployment meatadata?
3. Is there any chapter to introduce the whole process of
SoftwareDeployment in detial?
Thanks very much.
Best Regards,
2014-05-16 11:33 GMT+08:00 Thomas Spatzier thomas.spatz...@de.ibm.com:
Excerpts from Lingxian Kong's message on 15/05/2014 22:51:33:
From: Lingxian Kong anlin.k...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 15/05/2014 22:53
Subject: Re: [openstack-dev] Heat SoftwareConfig and SoftwareDevelopment
snip
Do you know any information about examples or tutorials when using
SoftwareConfig and SoftwareDeployment? I found it's a little difficult
to understand for me.
Unfortunately, we do not have any good documentation (or any documentation
at all) on this right now. I was planning to start some, but did not get to
it so far. For now, you could look at some examples in the heat-templates
repository at
https://github.com/openstack/heat-templates/tree/master/hot/software-config/example-templates
Especially in
Re: [openstack-dev] [oslo] Logging exceptions and Python 3
On Fri, May 16, 2014, Igor Kalnitsky ikalnit...@mirantis.com wrote: According to http://legacy.python.org/dev/peps/pep-0352/ the message attribute of BaseException is deprecated since Python 2.6 and was dropped in Python 3.0. Some projects have custom exception hierarchy, with strictly defined attributes (e.g. message, or something else). In a previous mail, I mean exactly that case, not the case with a built-in exceptions. That's a fragile assumption to make. unicode(exc) (or six.text_type(exc)) works for all exceptions, built-in or custom. I don't see the reason why it's being avoided. JE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Logging exceptions and Python 3
On Thu, May 15, 2014, Victor Stinner victor.stin...@enovance.com wrote: I'm trying to define some rules to port OpenStack code to Python 3. I just added a section in the Port Python 2 code to Python 3 about formatting exceptions and the logging module: https://wiki.openstack.org/wiki/Python3#logging_module_and_format_exceptions The problem is that I don't know what is the best syntax to log exceptions. Some projects convert the exception to Unicode, others use str(). I also saw six.u(str(exc)) which is wrong IMO (it can raise unicode error if the message contains a non-ASCII character). IMO the safest option is to use str(exc). For example, use LOG.debug(str(exc)). Is there a reason to log the exception as Unicode on Python 2? Because the exception uses unicode characters? This isn't common, but it does happen and a lot of code in nova uses unicode(exc) as a result. Using str(exc) is bad because it will fail with any exception with unicode characters. six.u(exc) is bad too since it's only for text literals. It's mostly obsolete too since Python 3.3 has the u prefix again and I don't think any OpenStack projects target 3.0-3.2 six.text_type(exc) is the recommended solution. JE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Logging exceptions and Python 3
Le vendredi 16 mai 2014, 06:03:53 Johannes Erdfelt a écrit : On Fri, May 16, 2014, Igor Kalnitsky ikalnit...@mirantis.com wrote: According to http://legacy.python.org/dev/peps/pep-0352/ the message attribute of BaseException is deprecated since Python 2.6 and was dropped in Python 3.0. Some projects have custom exception hierarchy, with strictly defined attributes (e.g. message, or something else). In a previous mail, I mean exactly that case, not the case with a built-in exceptions. That's a fragile assumption to make. unicode(exc) (or six.text_type(exc)) works for all exceptions, built-in or custom. I don't see the reason why it's being avoided. See my documentation: https://wiki.openstack.org/wiki/Python3#logging_module_and_format_exceptions six.text_type(exc): always use Unicode. It may raise unicode error depending on the exception, be careful. Example of such error in python 2: unicode(Exception(nonascii:\xe9)). unicode(exc) works with such exception classes: --- class MyException1(Exception): pass exc = MyException1() exc.message = u\u20ac unicode(exc) #ok class MyException2(Exception): def __unicode__(self): return u\20ac exc = MyException2() unicode(exc) #ok --- If we want to format an exception as Unicode, we need a function trying unicode(), or use str() and then guess the encoding. It means adding a new safe function to Olso to format an exception. Victor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-docs] [Heat][Documentation] Heat template documentation
Le 2014-05-15 18:32, Steve Baker a écrit : On 15/05/14 11:54, Gauvain Pocentek wrote: (Resending to add openstack-dev) Gauvain Pocentek Objectif Libre - Infrastructure et Formations Linux http://www.objectif-libre.com Le 2014-05-15 17:34, Gauvain Pocentek a écrit : Hello, This mail probably mainly concerns the doc team, but I guess that the heat team wants to know what's going on. We've shortly discussed the state of heat documentation with Anne Gentle and Andreas Jaeger yesterday, and I'd like to share what we think would be nice to do. Currently we only have a small section in the user guide that describes how to start a stack, but nothing documenting how to write templates. The heat developer doc provides a good reference, but I think it's not easy to use to get started. So the idea is to add an OpenStack Orchestration chapter in the user guide that would document how to use a cloud with heat, and how to write templates. I've drafted a spec to keep track of this at [0]. Let me know if this sounds OK to you all. Gauvain Pocentek Objectif Libre - Infrastructure et Formations Linux http://www.objectif-libre.com [0]: https://blueprints.launchpad.net/openstack-manuals/+spec/heat-templates Thanks for raising this, I do hope I can help writing the content. Thanks! In addition to this, we will at some point need to port the resource reference generation to this guide as well. That would be nice. I'm not sure if the user guide is the proper book, but we'll figure out where to put this with the doc team. One thing that would be really useful for users would be to have versioned references. Correct me if I'm wrong, but I think that only the trunk doc is published on the developers doc site. It makes it hard to know which resources are available for a specific version of openstack. Thanks, Gauvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Logging exceptions and Python 3
Another idea, Django has the following: http://bit.ly/1n1cuWm It seems like a useful similar function we can have to do the correct thing for exceptions and other objects. Or maybe we should talk with the django folks to see why they have a useful method like that. -Josh -Original Message- From: Victor Stinner victor.stin...@enovance.com Organization: eNovance Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Friday, May 16, 2014 at 7:04 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [oslo] Logging exceptions and Python 3 Le vendredi 16 mai 2014, 06:03:53 Johannes Erdfelt a écrit : On Fri, May 16, 2014, Igor Kalnitsky ikalnit...@mirantis.com wrote: According to http://legacy.python.org/dev/peps/pep-0352/ the message attribute of BaseException is deprecated since Python 2.6 and was dropped in Python 3.0. Some projects have custom exception hierarchy, with strictly defined attributes (e.g. message, or something else). In a previous mail, I mean exactly that case, not the case with a built-in exceptions. That's a fragile assumption to make. unicode(exc) (or six.text_type(exc)) works for all exceptions, built-in or custom. I don't see the reason why it's being avoided. See my documentation: https://wiki.openstack.org/wiki/Python3#logging_module_and_format_exceptio ns six.text_type(exc): always use Unicode. It may raise unicode error depending on the exception, be careful. Example of such error in python 2: unicode(Exception(nonascii:\xe9)). unicode(exc) works with such exception classes: --- class MyException1(Exception): pass exc = MyException1() exc.message = u\u20ac unicode(exc) #ok class MyException2(Exception): def __unicode__(self): return u\20ac exc = MyException2() unicode(exc) #ok --- If we want to format an exception as Unicode, we need a function trying unicode(), or use str() and then guess the encoding. It means adding a new safe function to Olso to format an exception. Victor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Privacy extension
I’ll take this one a step further. I think one of the methods for getting (non-NAT) floating IPs in IPv6 would be to push a new, extra address to the same port. Either by crafting an extra, unicast RA to the specific VM or providing multiple IA_NA fields in the DHCPv6 transaction. This would require multiple addresses to be allowed on a single MAC. -Anthony From: Martinx - ジェームズ thiagocmarti...@gmail.commailto:thiagocmarti...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 14:18 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][IPv6] Privacy extension Hello! I agree that there is no need for Privacy Extensions in a Cloud environment, since MAC address are fake... No big deal... Nevertheless, I think that should be nice to allow 1 Instance to have more than 1 IPv6 addr, since IPv6 is (almost) virtually unlimited... This way, a VM with, for example, a range of IPv6s to it, can have a shared host environment when each website have its own IPv6 address (I prefer to use IP-Based virtualhosts on Apache, instead of Name-Based)... Cheers! Thiago On 15 May 2014 14:22, Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote: I was just about to respond to that in the session when we ran out of time. I would vote for simply insisting that VMs run without the privacy extension enabled, and only permitting the expected ipv6 address based on MAC. Its primary purpose is to conceal your MAC address so that your IP address can't be used to track you, as I understand it, and I don't think that's as relevant in a cloud environment and where the MAC addresses are basically fake. Someone interested in desktop virtualisation with Openstack may wish to contradict me... -- Ian. On 15 May 2014 09:30, Shixiong Shang sparkofwisdom.cl...@gmail.commailto:sparkofwisdom.cl...@gmail.com wrote: Hi, guys: Nice to meet with all of you in the technical session and design session. I mentioned the challenge of privacy extension in the meeting, but would like to hear your opinions of how to address the problem. If you have any comments or suggestions, please let me know. I will create a BP for this problem. Thanks! Shixiong Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-docs] [Heat][Documentation] Heat template documentation
On Thu, May 15, 2014 at 11:32 AM, Steve Baker sba...@redhat.com wrote: On 15/05/14 11:54, Gauvain Pocentek wrote: (Resending to add openstack-dev) Gauvain Pocentek Objectif Libre - Infrastructure et Formations Linux http://www.objectif-libre.com Le 2014-05-15 17:34, Gauvain Pocentek a écrit : Hello, This mail probably mainly concerns the doc team, but I guess that the heat team wants to know what's going on. We've shortly discussed the state of heat documentation with Anne Gentle and Andreas Jaeger yesterday, and I'd like to share what we think would be nice to do. Currently we only have a small section in the user guide that describes how to start a stack, but nothing documenting how to write templates. The heat developer doc provides a good reference, but I think it's not easy to use to get started. So the idea is to add an OpenStack Orchestration chapter in the user guide that would document how to use a cloud with heat, and how to write templates. I'd like to experiment a bit with converting the End User Guide to an easier markup to enable more contributors to it. Perhaps bringing in Orchestration is a good point to do this, plus it may help address the auto-generation Steve mentions. The loss would be the single sourcing of the End User Guide and Admin User Guide as well as loss of PDF output and loss of translation. If these losses are worthwhile for easier maintenance and to encourage contributions from more cloud consumers, then I'd like to try an experiment with it. The experiment would be to have a new repo set up, openstack/user-guide and use the docs-core team as reviewers on it. Convert the End User Guide from DocBook to RST and build with Sphinx. Use the oslosphinx tempate for output. But what I don't know is if it's possible to build the automated output outside of the openstack/heat repo, does anyone have interest in doing a proof of concept on this? I'd also like input on the loss of features I'm describing above. Is this worth experimenting with? Thanks, Anne I've drafted a spec to keep track of this at [0]. Let me know if this sounds OK to you all. Gauvain Pocentek Objectif Libre - Infrastructure et Formations Linux http://www.objectif-libre.com [0]: https://blueprints.launchpad.net/openstack-manuals/+spec/heat-templates Thanks for raising this, I do hope I can help writing the content. In addition to this, we will at some point need to port the resource reference generation to this guide as well. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Haproxy configuration options
On Fri, May 16, 2014, at 02:52 AM, Jan Provazník wrote: On 05/12/2014 10:35 AM, Dmitriy Shulyak wrote: Adding haproxy (or keepalived with lvs for load balancing) will require binding haproxy and openstack services on different sockets. Afaik there is 3 approaches that tripleo could go with. Consider configuration with 2 controllers: haproxy: nodes: - name: controller0 ip: 192.0.2.20 - name: controller1 ip: 192.0.2.21 1. Binding haproxy on virtual ip and standard ports haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual ip) port: 80 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22 (virtual ip) proxy_port: 9696 port: 9696 Pros: - No additional modifications in elements is required Actually openstack services elements have to be updated to bind to local address only. Another big issue with this set up is dealing with changes to interfaces on the box. We would have to detect when a new interface is added, and have the app-specific logic to make the application aware of the new interface (typically just editing the app's config file isn't enough for this). Note that this is not an issue when an app binds to 0.0.0.0. HA-Proxy version 1.4.24 2013/06/17 What was the reason this approach was dropped? IIRC the major reason was that having 2 services on same port (but different interface) would be too confusing for anyone who is not aware of this fact. 2. Haproxy listening on standard ports, services on non-standard haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual ip) port: 8080 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22 (virtual ip) proxy_port: 9696 port: 9797 Pros: - No changes will be required to init-keystone part of workflow - Proxied services will be accessible on accustomed ports Bear in mind that we already use not-standard SSL ports for public endpoints. Also extra work will be required for setting up stunnels (element openstack-ssl). - No changes to configs where services ports need to be hardcoded, for example in nova.conf https://review.openstack.org/#/c/92550/ Cons: - Config files should be changed to add possibility of ports configuration Another cons is also updating selinux and firewall rules for each node. Also Iptables rules. On the plus side, these ports should *really* be configurable anyway. 3. haproxy on non-standard ports, with services on standard haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual ip) port: 8080 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22 (virtual ip) proxy_port: 9797 port: 9696 Notice that i changed only port for neutron, main endpoint for horizon should listen on default http or https ports. Agree that having 2 service ports switched in other way than other is sub-optimal. +1 on this solution being the least preferred - we shouldn't be pushing the extra configuration work onto our clients. Basicly it is opposite to 2 approach. I would prefer to go with 2, cause it requires only minor refactoring. Thoughts? Options 2 and 3 seem quite equal based on pros vs cons. Maybe we should reconsider option 1? Jan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Cleaning up configuration settings
Regarding config opts for keystone, the keystoneclient middleware already registers the opts at https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L325under a keystone_authtoken group in the config file. Currently, Mistral registers the opts again at https://github.com/stackforge/mistral/blob/master/mistral/config.py#L108under a different configuration group. Should we remove the duplicate from Mistral and refactor the reference to keystone configurations to the keystone_authtoken group? This seems more consistent. On Thu, May 15, 2014 at 1:13 PM, W Chan m4d.co...@gmail.com wrote: Currently, the various configurations are registered in ./mistral/config.py. The configurations are registered when mistral.config is referenced. Given the way the code is written, PEP8 throws referenced but not used error if mistral.config is referenced but not called in the module. In various use cases, this is avoided by using importutils to import mistral.config (i.e. https://github.com/stackforge/mistral/blob/master/mistral/tests/unit/engine/test_transport.py#L34). I want to break down registration code in ./mistral/config.py into separate functions for api, engine, db, etc and move the registration closer to the module where the configuration is needed. Any objections? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] ANNOUNCE: New Nova Libvirt (Sub-)Team + Meeting
Hi Nova developers, Since Nova already has sub-teams for HyperV, VMWare, and XenAPI, I feel that it would be a worthwhile effort to introduce a sub-team + meeting for the Nova Libvirt driver: https://wiki.openstack.org/wiki/Nova#Nova_subteams https://wiki.openstack.org/wiki/Meetings/Libvirt https://etherpad.openstack.org/p/nova-libvirt-meeting-agenda I have arbitrarily picked Tuesdays at 1500 UTC on IRC #openstack-meeting-3 as the time + place for the meeting. If this turns out to be horrible for a significant number of people, we can discuss alternate times (as long as they are not friday evenings ;-), or alternate between 2 times. Currently this time point works out as 08:00 San Francisco 11:00 Boston 15:00 UTC 16:00 London 17:00 Berlin 20:30 Mumbai 23:00 Bejing 24:00 Tokyo http://www.timeanddate.com/worldclock/fixedtime.html?hour=15min=00sec=0p1=0 So I suggest the first meeting take place next week: Tuesday May 20th at 15:00 UTC I don't want to add bureaucracy to the libvirt driver development workflow. Rather I intend that this meeting is a way to facilitate libvirt related discussions between different parties/companies and to resolve roadblocks that people working on libvirt may be facing. It should also be a place for other OpenStack teams (Neutron/Glance/Infra/etc) to come to meeting the Nova libvirt team and raise topics they have. If you want to attend this meeting, please record topics for discussion in the etherpad (and put your name + IRC nick against items) https://etherpad.openstack.org/p/nova-libvirt-meeting-agenda Historically KVM / QEMU have got the majority of attention from libvirt developers, to the extent that we (unfortunately) caused breakage of both LXC and Xen during Icehouse. From mail and design summit discussions, it seems there is a critical mass of people interested in raising the quality of LXC and Xen during Juno and getting gate CI up running. So I think this meeting would be a good place for those interested in Libvirt LXC Xen support to coordinate their initial efforts / planning. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpenStack Containers Team
The Containers team is a new cross-functional team for OpenStack community stakeholders interested in adding better support in OpenStack for container technology. At the time of the Icehouse summit in Hong Kong there was a session and some IRC discussion on this topic, but after assorting some initial differences in opinion about where containers should be handled within OpenStack, discussions ended. This team aims to revisit this subject and drive to a conclusion that key stakeholders within the OpenStack community are comfortable with. This team will be considered successful once users of OpenStack can create and manage containers on OpenStack with an experience consistent with what they expect from using the Nova service to get virtual machines. https://wiki.openstack.org/wiki/Teams/Containers I have proposed an initial IRC team meeting schedule for 1600/2100 UTC on alternating Tuesdays. Please contact me off-list if you are a key stakeholder and are unable to attend regularly on this schedule: https://wiki.openstack.org/wiki/Meetings/Containers Thanks, Adrian Otto ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Cleaning up configuration settings
+1 for breaking down the configuration by modules. Not sure about names for configuration group. Do you mean just using the same group name? or more? IMO groups are project specific; it doesn’t always make sense to use the same group name in the context of different projects. Our requirement is 1) auto-generate mistral.conf.example from the config.py and 2) sections make sense in the product context. For example: how do we deal with rpc_backend and transport_url for oslo messaging? Should we do something like CONF.import(_transport_opts, “oslo.messaging.transport”, “transport”)? And use it by passing the group, not entire contfig, like: transport = messaging.get_transport(cfg.messaging.CONF) instead of transport = messaging.get_transport(cfg.CONF) DZ On May 16, 2014, at 12:46 PM, W Chan m4d.co...@gmail.com wrote: Regarding config opts for keystone, the keystoneclient middleware already registers the opts at https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L325 under a keystone_authtoken group in the config file. Currently, Mistral registers the opts again at https://github.com/stackforge/mistral/blob/master/mistral/config.py#L108 under a different configuration group. Should we remove the duplicate from Mistral and refactor the reference to keystone configurations to the keystone_authtoken group? This seems more consistent. On Thu, May 15, 2014 at 1:13 PM, W Chan m4d.co...@gmail.com wrote: Currently, the various configurations are registered in ./mistral/config.py. The configurations are registered when mistral.config is referenced. Given the way the code is written, PEP8 throws referenced but not used error if mistral.config is referenced but not called in the module. In various use cases, this is avoided by using importutils to import mistral.config (i.e. https://github.com/stackforge/mistral/blob/master/mistral/tests/unit/engine/test_transport.py#L34). I want to break down registration code in ./mistral/config.py into separate functions for api, engine, db, etc and move the registration closer to the module where the configuration is needed. Any objections? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Baremetal][Neutron] SDN Solution for Openstack Baremetal Driver
Hi fellow stacker, I am designing for a Baremetal stack with SDN support recently and would like to seek for the help from you all for how to do so. I am building an automated testing framework on top of Openstack Havana. For performance and platform sake I would need to provision my stack using baremetal driver (Not Ironic). But on the other hand I also need the network virtualization provided by neutron in order to maximize resource utilization. Therefore I started looking for SDN solutions for the baremetal use case. My network infrastructure is from Cisco and so I started with Cisco plugin within Neutron. According to [1], I found that the plugin pretty much supported all functionality for the virtualized VM case (i.e. dynamical VLAN creation and VLAN tag propagation from controller to compute host). But for baremetal case, it seems that the solution would not work as there is no OVS agent running on the BM node. Since information about baremetal + SDN is quit lacking so I wonder if anybody here has tried baremetal + SDN before and could share with me your experience in doing so? Or it is simply impossible to do SDN with baremetal driver? And how about the case for Ironic? Thanks. Regards, Tim Reference: [1] - http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/data_sheet_c78-727737.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] HA Fixes Catalogue
Fuelers, I have compiled a catalogue of all OpenStack HA fixes we have implemented so far, researched, or need to research and implement. Here is a summary of where things stand today (I've added the same list to https://etherpad.openstack.org/p/fuel-ha-rabbitmq): Applied in 5.0, needs a backport to 4.1.1: - https://review.openstack.org/78178 ocf-neutron-dhcp-orphan - https://review.openstack.org/93927 nova-reap-deleted-instance - https://review.openstack.org/77276 oslo-ccn-handling - https://review.openstack.org/76686 oslo-kombu-reconnect-delay Proposed for 5.0: - https://review.openstack.org/93884 ocf-haproxy-vip-colocate - https://review.openstack.org/93411 rabbitmq-keepalive - https://review.openstack.org/93815 kernel-match-tcp-keepalive-to-nova-report-interval - https://review.openstack.org/93883 rabbitmq-hosts-shuffle Must be implemented in 5.0: - python-kombu-and-amqp-upgrade (multiple CCN fixes) - https://launchpadlibrarian.net/160766270/transport.py.patch python-amqp-tcp-user-timeout - https://bugs.launchpad.net/fuel/+bug/1312177 pacemaker-neutron-agent-stickiness - https://bugs.launchpad.net/fuel/+bug/1297355 ocf-galera-full-stop - https://bugs.launchpad.net/fuel/+bug/1293680 ocf-galera-take-donor-out Should be implemented in 5.1: - https://bugs.launchpad.net/fuel/+bug/1318936 rabbitmq-does-not-restart Known not to help or cause breakage: - https://review.openstack.org/34949 rabbitmq-amqp-heartbeat (requires a heartbeat periodic task in every OpenStack component) Below is the full catalogue: pacemaker-haproxy-reload - applied in 4.0 - https://bugs.launchpad.net/fuel/+bug/1259639 - https://review.openstack.org/61453 ceph-mon-list - applied in 4.1 - https://bugs.launchpad.net/fuel/+bug/1268579 - https://review.openstack.org/73106 ocf-neutron-agent-pid-matching - applied in 4.1 - https://bugs.launchpad.net/fuel/+bug/1269334 - https://review.openstack.org/67101 ocf-galera-restart-wait - applied in 4.1 - https://bugs.launchpad.net/fuel/+bug/1281625 - https://review.openstack.org/74431 pacemaker-fd-leak - applied in 4.1 - https://bugs.launchpad.net/fuel/+bug/1272840 - https://github.com/ClusterLabs/libqb/commit/b327dbec7380e7de6896f9bb6cb1ca58677f4ed8 pacemaker-broadcast-calculation - applied in 4.1 # TODO(angdraug): report to upstream - https://bugs.launchpad.net/fuel/+bug/1277614 - https://review.openstack.org/72438 rabbitmq-hosts - applied in 4.1 - https://bugs.launchpad.net/fuel/+bug/1285449 - https://review.openstack.org/77409 mysql-read-timeout - applied in 4.1 - https://bugs.launchpad.net/fuel/+bug/1285449 - https://review.openstack.org/77643 drop-mysql-on-disconnect - applied in 4.1.1, 5.0 # TODO(angdraug): confirm all fixes are present in 5.0 - https://bugs.launchpad.net/fuel/+bug/1288438 - https://review.openstack.org/81225 haproxy-netns - applied in 4.1.1, 5.0 - https://review.openstack.org/82518 rabbitmq3 - applied in 4.1.1, 5.0 - depends on rabbitmq3-ha-mode - https://bugs.launchpad.net/fuel/+bug/1288831 rabbitmq3-ha-mode - applied in 4.1.1, 5.0 - https://bugs.launchpad.net/fuel/+bug/1296922 - https://review.openstack.org/84707 rabbitmq-init-retry - applied in 4.1.1, 5.0 - https://bugs.launchpad.net/fuel/+bug/1314617 - https://review.openstack.org/88593 ocf-gratuitous-arp - applied in 4.1.1, 5.0 - https://bugs.launchpad.net/fuel/+bug/1310676 - https://review.openstack.org/89378 neutron-l3-rootwrap - applied in 4.1.1, 5.0 # TODO(rmoe): confirm how this is related to the neutron umask/pid flock bug (0751) - https://bugs.launchpad.net/fuel/+bug/1310926 - https://bugs.launchpad.net/neutron/+bug/1311804 ocf-neutron-l3-cleanup-ns - applied in 4.1.1, 5.0 - https://review.openstack.org/89872 ocf-neutron-dhcp-cleanup-ns - applied in 4.1.1, 5.0 - https://bugs.launchpad.net/fuel/+bug/1285929 - https://review.openstack.org/89557 rabbitmq-fd-ulimit - applied in 4.1.1, 5.0 - https://bugs.launchpad.net/fuel/+bug/1279594 - https://gerrit.mirantis.com/10566 ocf-neutron-agent-lost-mysql - applied in 4.1.1, 5.0 - https://bugs.launchpad.net/fuel/+bug/1287716 - https://review.openstack.org/77895 ocf-neutron-dhcp-orphan - applied in 5.0 # TODO(xenolog): backport to 4.1.1 - https://bugs.launchpad.net/fuel/+bug/1285929 - https://review.openstack.org/78178 nova-reap-deleted-instance - applied in 5.0, proposed for 4.1.1 - https://review.openstack.org/93927 oslo-ccn-handling - applied in 5.0 # TODO(angdraug): backport to 4.1.1 - https://review.openstack.org/77276 oslo-kombu-reconnect-delay - applied in 5.0 # TODO(angdraug): backport to 4.1.1 - https://review.openstack.org/76686 ocf-haproxy-vip-colocate - https://review.openstack.org/93884 rabbitmq-keepalive - https://review.openstack.org/93411 kernel-match-tcp-keepalive-to-nova-report-interval - https://review.openstack.org/93815 rabbitmq-hosts-shuffle - https://review.openstack.org/93883 python-kombu-and-amqp-upgrade - # NOTE(angdraug): multiple CCN handling fixes - # TODO(rmoe): try kombu 3.0.15 and amqp 1.4.5; if breaks,
[openstack-dev] [Search] Search project - update Atlanta'14
Hi folks, Last summit we proposed Search project for OpenStack[1]. We didn't get much traction and other things took priorities, so the project didn't take off during Havana cycle. Now - before and during the summit - more people expressed keen interest. Some of us met on the summit and decided to unshelf the OpenStack Search. Let’s use this thread to get the interested parties together and define the next steps. The details for unshelfing: * Wiki - basic project description, and 2 min video showing Search in action. https://wiki.openstack.org/wiki/SearchProject * Etherpad - captures Summit discussions: https://etherpad.openstack.org/p/search * Github - the very rough prototype: * Search backend: https://github.com/StackStorm/search * Horizon plugin: https://github.com/StackStorm/search-horizon * Discussion on the openstack-dev: http://lists.openstack.org/pipermail/openstack-dev/2013-November/019742.html Regards, Dmitri. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-docs] [Heat][Documentation] Heat template documentation
Le 2014-05-16 17:13, Anne Gentle a écrit : On Thu, May 15, 2014 at 10:34 AM, Gauvain Pocentek gauvain.pocen...@objectif-libre.com wrote: Hello, This mail probably mainly concerns the doc team, but I guess that the heat team wants to know what's going on. We've shortly discussed the state of heat documentation with Anne Gentle and Andreas Jaeger yesterday, and I'd like to share what we think would be nice to do. Currently we only have a small section in the user guide that describes how to start a stack, but nothing documenting how to write templates. The heat developer doc provides a good reference, but I think it's not easy to use to get started. So the idea is to add an OpenStack Orchestration chapter in the user guide that would document how to use a cloud with heat, and how to write templates. I've drafted a spec to keep track of this at [0]. I'd like to experiment a bit with converting the End User Guide to an easier markup to enable more contributors to it. Perhaps bringing in Orchestration is a good point to do this, plus it may help address the auto-generation Steve mentions. The loss would be the single sourcing of the End User Guide and Admin User Guide as well as loss of PDF output and loss of translation. If these losses are worthwhile for easier maintenance and to encourage contributions from more cloud consumers, then I'd like to try an experiment with it. Using RST would probably make it easier to import/include the developers' documentation. But I'm not sure we can afford to loose the features you mention. Translations for the user guides are very important I think. How would we review changes made in external repositories? The user guides are continuously published, this means that a change done in the heat/docs/ dir would quite quickly land on the webserver without a doc team review. I completely trust the developers, but I'm not sure that this is the way to go. The experiment would be to have a new repo set up, openstack/user-guide and use the docs-core team as reviewers on it. Convert the End User Guide from DocBook to RST and build with Sphinx. Use the oslosphinx tempate for output. But what I don't know is if it's possible to build the automated output outside of the openstack/heat repo, does anyone have interest in doing a proof of concept on this? I'm not sure that this is possible, but I'm no RST expert. I'd also like input on the loss of features I'm describing above. Is this worth experimenting with? Starting this new book sounds like a lot of work. Right now I'm not convinced it's worth it. Gauvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Local Neutron Port
I have a cloud that is using vxlan's over infiniband. Its working great. Now, I have a second system, a Lustre cluster that I would like to make available to a tenant in the cloud. I can't bridge into this network since its IB. Routing onto it is also proving to be tricky... One idea I had was to allocate a local link pair on each Lustre node, install neutron-openvswitch, configure it the same as a compute node, then add one end of the local link to the tun-int the same way as Nova would. This would make the remaining link pair talk over the vxlan. One snag though, while it does work, it does so only if I launch a Nova instance on the Lustre node first so it gets the flow rules setup. Would it be difficult to write a little script, that creates a vif pair, just like Nova would and ensure all the flow rules were hooked up right? Thanks, Kevin ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Privacy extension
Precisely Anthony! We talked about this topic (Non-NAT Floating IPv6) here, on the following thread: -- [openstack-dev] [Neutron][IPv6] Idea: Floating IPv6 - Without any kind of NAT: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026871.html -- :-D About IPv6 Privacy Extensions, well, if it is too hard to implement, I think that it can be postponed... And only the IPv6 self-generated by SLAAC and previously calculated by Neutron itself (based on Instance's MAC address), should be allowed to pass/work for now... - Thiago On 16 May 2014 12:12, Veiga, Anthony anthony_ve...@cable.comcast.comwrote: I’ll take this one a step further. I think one of the methods for getting (non-NAT) floating IPs in IPv6 would be to push a new, extra address to the same port. Either by crafting an extra, unicast RA to the specific VM or providing multiple IA_NA fields in the DHCPv6 transaction. This would require multiple addresses to be allowed on a single MAC. -Anthony From: Martinx - ジェームズ thiagocmarti...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 14:18 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][IPv6] Privacy extension Hello! I agree that there is no need for Privacy Extensions in a Cloud environment, since MAC address are fake... No big deal... Nevertheless, I think that should be nice to allow 1 Instance to have more than 1 IPv6 addr, since IPv6 is (almost) virtually unlimited... This way, a VM with, for example, a range of IPv6s to it, can have a shared host environment when each website have its own IPv6 address (I prefer to use IP-Based virtualhosts on Apache, instead of Name-Based)... Cheers! Thiago On 15 May 2014 14:22, Ian Wells ijw.ubu...@cack.org.uk wrote: I was just about to respond to that in the session when we ran out of time. I would vote for simply insisting that VMs run without the privacy extension enabled, and only permitting the expected ipv6 address based on MAC. Its primary purpose is to conceal your MAC address so that your IP address can't be used to track you, as I understand it, and I don't think that's as relevant in a cloud environment and where the MAC addresses are basically fake. Someone interested in desktop virtualisation with Openstack may wish to contradict me... -- Ian. On 15 May 2014 09:30, Shixiong Shang sparkofwisdom.cl...@gmail.comwrote: Hi, guys: Nice to meet with all of you in the technical session and design session. I mentioned the challenge of privacy extension in the meeting, but would like to hear your opinions of how to address the problem. If you have any comments or suggestions, please let me know. I will create a BP for this problem. Thanks! Shixiong *Shixiong Shang* *!--- Stay Hungry, Stay Foolish ---!* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Baremetal][Neutron] SDN Solution for Openstack Baremetal Driver
This is a discussion that warrants a broader audience, as others are likely to have a very similar need. It would be good to get something like this documented, and perhaps bolted on to the operators’ guide or somewhere similarly appropriate. -Anthony Hi Tim, NTT-docomo and VTJ developed network isolation in baremetal before they merging baremetal driver to upstream, and I also supported them by providing SDN(OpenFlow) controller plugin. I don't have good article to explain that for now, but I can have discussion if you are in the summit. Regards, Ryota ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Privacy extension
Dane put some notes on the session’s ether pad to support multiple prefixes. Seem like this is really something that everyone want to support in openstack. ―Robert On 5/16/14, 2:23 PM, Martinx - ジェ�`ムズ thiagocmarti...@gmail.commailto:thiagocmarti...@gmail.com wrote: Precisely Anthony! We talked about this topic (Non-NAT Floating IPv6) here, on the following thread: -- [openstack-dev] [Neutron][IPv6] Idea: Floating IPv6 - Without any kind of NAT: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026871.html -- :-D About IPv6 Privacy Extensions, well, if it is too hard to implement, I think that it can be postponed... And only the IPv6 self-generated by SLAAC and previously calculated by Neutron itself (based on Instance's MAC address), should be allowed to pass/work for now... - Thiago On 16 May 2014 12:12, Veiga, Anthony anthony_ve...@cable.comcast.commailto:anthony_ve...@cable.comcast.com wrote: I’ll take this one a step further. I think one of the methods for getting (non-NAT) floating IPs in IPv6 would be to push a new, extra address to the same port. Either by crafting an extra, unicast RA to the specific VM or providing multiple IA_NA fields in the DHCPv6 transaction. This would require multiple addresses to be allowed on a single MAC. -Anthony From: Martinx - ジェ�`ムズ thiagocmarti...@gmail.commailto:thiagocmarti...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 14:18 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][IPv6] Privacy extension Hello! I agree that there is no need for Privacy Extensions in a Cloud environment, since MAC address are fake... No big deal... Nevertheless, I think that should be nice to allow 1 Instance to have more than 1 IPv6 addr, since IPv6 is (almost) virtually unlimited... This way, a VM with, for example, a range of IPv6s to it, can have a shared host environment when each website have its own IPv6 address (I prefer to use IP-Based virtualhosts on Apache, instead of Name-Based)... Cheers! Thiago On 15 May 2014 14:22, Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote: I was just about to respond to that in the session when we ran out of time. I would vote for simply insisting that VMs run without the privacy extension enabled, and only permitting the expected ipv6 address based on MAC. Its primary purpose is to conceal your MAC address so that your IP address can't be used to track you, as I understand it, and I don't think that's as relevant in a cloud environment and where the MAC addresses are basically fake. Someone interested in desktop virtualisation with Openstack may wish to contradict me... -- Ian. On 15 May 2014 09:30, Shixiong Shang sparkofwisdom.cl...@gmail.commailto:sparkofwisdom.cl...@gmail.com wrote: Hi, guys: Nice to meet with all of you in the technical session and design session. I mentioned the challenge of privacy extension in the meeting, but would like to hear your opinions of how to address the problem. If you have any comments or suggestions, please let me know. I will create a BP for this problem. Thanks! Shixiong Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Third Party] Weekly Third Party IRC Meeting - Monday 1800 UTC
The time has come to have a weekly third party meeting. I have agreed to act as chair and co-ordinator of the meetings. Jay Pipes will continue to assist those folks setting up their third party ci systems internally, as well as share his knowledge and perceptions of the rest of the OpenStack workflow. Kurt Taylor, who has worked on setting up and maintaining a third party testing system for his company, will also share the leadership baton, with Jay and myself, in this effort to help third party systems understand the benefit of creating these setups internally. Please find the wikipage here: https://wiki.openstack.org/wiki/Meetings/ThirdParty The initial meeting will discuss format for the meeting, who should attend and how we can address various issues. Please plan on attending so we gather the various experiences both with OpenStack programs and with third party testers. I look forward to seeing you there. Anita Kuno anteaya ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral][TaskFlow] Integration plan
Hey Josh, I’d like to thank you for a very productive discussion that we had at the summit, seems to be a great achievement for us in terms our collaboration and collective vision of both technologies. This was the first time I was able to clearly see how to align our capabilities better and hence provide tremendous usability benefits for the community. Totally support bi-weekly meetings, let me take this part and figure out the schedule that would work for everyone of us. Thanks Renat Akhmerov @ Mirantis Inc. On 15 May 2014, at 22:30, Joshua Harlow harlo...@yahoo-inc.com wrote: Looks good to me, We had a good 'meetup' in one of the breakout rooms on the second floor (those rooms are pretty useful!) This does seem like a good step toward making both groups successful and from the discussion I think we have a decent vision of how this can/could work out in the future and moving forward (and even some other neat ideas on related areas were also discovered/discussed, which is pretty cool). I'll writeup some more these as TF blueprints next week and we can continue there (iterating on them and getting some code produced/adjusted/refactored). The timeline maybe we should continue thinking about as I'm still sure on the 'final' date but I agree with the get started now and we can start to 'approximate' what the date would be as we get a better 'feeling' for it (K seems like a good estimate). Another idea: The bi-weekly meetings between teams/individuals/other on IRC seemed like a good idea (to at least sync and discuss ideas and such), maybe we should continue those. What do u guys think? -Original Message- From: Dmitri Zimine d...@stackstorm.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 1:06 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [Mistral][TaskFlow] Integration plan Renat, Joshua, Dmitri and Timur discussed the integration path for Mistral and TaskFlow. Quick summary - guys please correct any mistakes or omissions: Taskflow - Mistral integration plan 1) Mistral: define the set of workflow primitives, define correspondent DSL - Driven by user requirements. Keep to minimal. Implement in Mistral. 2) Taskflow: break out flow scheduler (decision maker) and persistence - it'll be a low level library interference, Joshua has details - once done, ready to re-prototype integration, iterate until happy 3) Move the primitives to TaskFlow (both teams) 4) Integrate TaskFlow into Mistral (replace Mistral workflow engine with TaskFlow engine) Once integration complete, Mistral DSL will continue to work, all TaskFlow and Mistral workflows will be interchangeable, the code reused. DZ. PS. When do we do it? We didn't commit to a date, but IMO (DZ) we start now, and with some luck get integrated in K cycle. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][HA][RabbitMQ] Rabbitmq-related HA issues
Guys. It seems that this patch: https://review.openstack.org/#/c/93815/ should fix everything. If it does not, let's do additional research. Also, Ryan says that kombu version 3 works much better, so if the fix is not good enough we can update kombu, but we will need to check its compliance with nailgun and astute. On Tue, May 13, 2014 at 3:17 PM, Vladimir Kuklin vkuk...@mirantis.comwrote: Alexey, could you link this particular change? I think, there is some miscommunication - it does not seem that keepalive patch helped a lot. On Tue, May 13, 2014 at 2:53 PM, Alexei Kornienko alexei.kornie...@gmail.com wrote: Hi, No good news from me now. I think I need to spend additional time to reproduce this issue. I've done some code research and it seems that problem may be related to how nova uses oslo.messaging library. P.S. I've seen a patch in fuel changing tcp_keepalive option and it says that it fixed the problem, am I right? Regards, On May 13, 2014 2:05 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Alexey Kornienko promised to give us an update. Alexey, do you have newer info? 12 мая 2014 г. 13:22 пользователь Vladimir Kuklin vkuk...@mirantis.com написал: Guys, I suggest that we meet at Mirantis booth as it is in the same hall with lunch 12 мая 2014 г. 13:02 пользователь Andrew Woodward xar...@gmail.com написал: Correct. Openstack HA On May 12, 2014 12:43 PM, Mike Scherbakov mscherba...@mirantis.com wrote: A little note - it's going to be about OpenStack HA issues, not about Fuel master node HA, right? On May 12, 2014 8:37 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Fuelers, We are going to discuss rabbit/kombu related HA issues today. I suggest we do this at 1pm today in Hall B2 during lunch. Feel free to provide alternative suggestions if you have any objections. Also bring in anyone who may be of help. List of problems and bugs is here: https://etherpad.openstack.org/p/fuel-ha-rabbitmq -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] useful deployment related talks
https://etherpad.openstack.org/p/juno-summit-ops-puppet On Tue, May 13, 2014 at 3:23 PM, Vladimir Kuklin vkuk...@mirantis.comwrote: Also puppet-openstack stuff is discussed here: https://etherpad.openstack.org/p/puppet-openstack-design On Mon, May 12, 2014 at 4:58 PM, Allamaraju, Subbu su...@subbu.orgwrote: We should perhaps clarify that these etherpads are about deployment/operations of OpenStack discussed under https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Ops, and not Fuel. Subbu On May 12, 2014, at 2:33 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Guys It would be awesome if we shared links on useful talks/meetups that can be related to FUEL and deployment/operations of Openstack. These are for setting optimal config options and upgrades: https://etherpad.openstack.org/p/juno-summit-ops-upgradesdeployment https://etherpad.openstack.org/p/juno-summit-ops-reasonabledefaults -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Port mirroring
Did anything interesting come out of the port mirroring discussion in the Neutron pod this morning? Through a failure to hear the alert from my phone I completely forgot to show up. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Gerrit rst
When looking at a change in Gerrit that includes an rst file, is there any easy way to view the rendered view rather than merely the markup view? The side by side diff is great, but I'd really like a clickable link to the rendered view, especially for ones that include nwdiag or blockdiag syntax. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Gerrit rst
On Fri, May 16, 2014 at 9:47 PM, CARVER, PAUL pc2...@att.com wrote: When looking at a change in Gerrit that includes an rst file, is there any easy way to view the rendered view rather than merely the markup view? The side by side diff is great, but I'd really like a clickable link to the rendered view, especially for ones that include nwdiag or blockdiag syntax. Yes, many projects have a gate-project-docs job and if you go to the patch and click under the Jenkins listing in the patch, look for the gate-project-docs (such as gate-glance-docs on https://review.openstack.org/#/c/49316/) you get a docs-draft.openstack.orglink and can view built docs. See http://docs-draft.openstack.org/16/49316/30/check/gate-glance-docs/e4e966a/doc/build/html/for example. Hope this helps -- and that I've explained where the link can be obtained well enough. Anne ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Searching for docs reviews in Gerrit
A great question came out of a docs session today and I wanted to post this hint/tip here, and also ask a question. Gerrit has documentation that describes how to use regular expressions to search for specific reviews. See https://review.openstack.org/Documentation/user-search.html One that I've found handy for docs reviews is: file:^*REGEX* Matches any change where REGEX matches a file that was affected by the change. The regular expression pattern must start with ^. For example, to match all XML files usefile:^.*\.xml$. The dk.brics.automaton libraryhttp://www.brics.dk/automaton/ is used for the evaluation of such patterns. The ^ required at the beginning of the regular expression not only denotes a regular expression, but it also has the usual meaning of anchoring the match to the start of the string. To match all Java files, use file:^.*\.java. The entire regular expression pattern, including the ^ character, should be double quoted when using more complex construction (like ones using a bracket expression). For example, to match all XML files named like *name1.xml*, *name2.xml*, and *name3.xml* use file:^name[1-3].xml. For example, if you want to review all RST files that are edited in a repo, log into review.openstack.org, then go to Settings Watched Projects. Then, on a particular project's repo, look for file:^.*\.rst. One example I'd like to know about -- is it possible to watch all changes to the Networking chapter in the Cloud Admin Guide in the openstack/openstack-manuals repo? This particular search didn't work for me: file:section_networking-adv-config.xml project:openstack/openstack-manuals nor does: file:docs/admin-guide-cloud/networking/section_networking-adv-config.xml project:openstack/openstack-manuals Any more ideas for focusing on doc reviews in specialty areas? Thanks, Anne ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
