[openstack-dev] .pem file and python-heatclient call

[David Gabriel]

Dears,

I want to use use a .pem file to call python-heatclient API in order to
create stacks (Openstack address is based on https).
I am wondering, where to copy this pem file and how to refer it ?
Bellow the errors I got:

  File "/usr/lib/python2.7/dist-packages/heatclient/v1/stacks.py", line
109, in create
data=kwargs, headers=headers)
  File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py", line
223, in json_request
resp = self._http_request(url, method, **kwargs)
  File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py", line
166, in _http_request
**kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 53,
in request
return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line
468, in request
resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line
576, in send
r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line
447, in send
raise SSLError(e, request=request)
SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
127.0.0.1 - - [08/Nov/2017 20:34:56] "POST /stack_create HTTP/1.1" 500 2801

Please tell me where to put my .pem and how to refer it in the code to work
with python heatclient ?

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

Re: [openstack-dev] [octavia] amphora fails to send request to members

[Yipei Niu]

Hi, Michael,

Based on your mail, the information is as follows.

1. The version of Octavia I used is Queens, and the latest commit message is
commit 2ab2836d0ebdd0fd5bc32d3adcc44a92557c8c1d
Author: OpenStack Proposal Bot 
Date:   Fri Nov 3 17:58:59 2017 +

Updated from global requirements

Change-Id: I9047e289b8a3c931156da480b3f9f676c54a8358

2. The info of the amphora and other VMs is as follows.
+--+
--+++---
--+-+
| ID   | Name
   | Status | Task State | Power State | Networks
  |
+--+
--+++---
--+-+
| 33bd02cb-f853-404d-a705-99bc1b04a178 |
amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
| ACTIVE | -  | Running | lb-mgmt-net1=192.168.1.4;
net1=10.0.1.8 |
| dd046fc9-e2bf-437d-8c51-c397bccc3dc1 | client1
  | ACTIVE | -  | Running | net1=10.0.1.3
 |
| 50446c75-7cb7-43eb-b057-4b6b89a926bc | client3
  | ACTIVE | -  | Running | net4=10.0.4.3
 |
+--+
--+++---
--+-+

3. The info of the load balancer is as follows.
+-++
| Field   | Value  |
+-++
| admin_state_up  | True   |
| description ||
| id  | 51cba1d5-cc3c-48ff-b41e-839619093334   |
| listeners   | {"id": "b20ad920-c6cd-4e71-a9b9-c134e57ecd20"} |
| name| lb1|
| operating_status| ONLINE |
| pools   | {"id": "d0042605-da50-4048-b298-660420b0a1d2"} |
| provider| octavia|
| provisioning_status | ACTIVE |
| tenant_id   | c2a97a04cb6d4f25bdcb8b3f263c869e   |
| vip_address | 10.0.1.4   |
| vip_port_id | 2209a819-0ac8-4211-b878-f0b41ac4727b   |
| vip_subnet_id   | cbcf4f04-da6d-4800-8b40-4b141972c2bf   |
+-++

4. The info of the listener is as follows.
+---+---
-+
| Field | Value
  |
+---+---
-+
| admin_state_up| True
 |
| connection_limit  | -1
 |
| default_pool_id   | d0042605-da50-4048-b298-660420b0a1d2
 |
| default_tls_container_ref |
  |
| description   |
  |
| id| b20ad920-c6cd-4e71-a9b9-c134e57ecd20
 |
| loadbalancers | {"id": "51cba1d5-cc3c-48ff-b41e-839619093334"}
|
| name  | listener1
  |
| protocol  | HTTP
 |
| protocol_port | 80
 |
| sni_container_refs|
  |
| tenant_id | c2a97a04cb6d4f25bdcb8b3f263c869e
 |
+---+---
-+

5. The members of the load balancer lb1 are as follows.
+--+--+-
-+--+---++--
++
| id   | name | tenant_id
  | address  | protocol_port | weight | subnet_id
  | admin_state_up |
+--+--+-
-+--+---++--
++
| 420c905c-1077-46c9-8b04-526a59d93376 |  |
c2a97a04cb6d4f25bdcb8b3f263c869e | 10.0.1.3 |80 |  1 |
cbcf4f04-da6d-4800-8b40-4b141972c2bf | True   |
+--+--+-
-+--+---++--
++

6. Since the VIP and the members reside in the same subnet, only two
subnets are listed as follows.
+--+-+--
++--
-+
| id   

Re: [openstack-dev] Building Openstack Trove Images

[Amrith Kumar]

Sorry, I should have been more clear.

You shouldn't use redstack.

And you should not be using trovestack with trusty.

All of the gate moved to Xenial a while back and I don't know that anyone
is verifying trusty any longer. But, YMMV, set the force flag and try again
if you want. I am not able to verify with Trusty, don't have a trusty env.

Apologies for the back and forth. It has been a long week at summit.



-amrith


On Thu, Nov 9, 2017 at 1:24 AM, Ritesh Vishwakarma <
ritesh.vishwaka...@indusnet.co.in> wrote:

> Hi Amrith,
>
> This time I followed the https://github.com/openstack/trove/tree/master/
> integration/ however, it still throws me the same error. Please find the
> log file attached.
>
>
> Regards,
> Ritesh
>
> On Wed, Nov 8, 2017 at 4:44 PM, Amrith Kumar 
> wrote:
>
>> Please see inline below.
>>
>> -amrith
>>
>>
>> On Wed, Nov 8, 2017 at 9:52 PM, Ritesh Vishwakarma <
>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>
>>>
>>>
>>> Hi Amrith,
>>>
>>>
>>>
>>> Please find my response to your queries below:
>>>
>>>
>>>
>>>
>>>
>>> 1.   What (exact) version of OpenStack are you using? Is it from
>>> upstream or a vendor, if it is the latter, which vendor?
>>>
>>> We are using Openstack Pike installed on CentOS7.
>>>
>>> 2.   What database (exact version) are you trying to create an
>>> image for?
>>>
>>> We want to build images for mysql5.7 as of now.
>>>
>>> 3.   What operating system (exact version) are you attempting to
>>> perform this   on?
>>>
>>> We have tried it from CentOS7 & Ubuntu 14.04.
>>>
>>> 4.   What command(s) are you executing?
>>>
>>> I am step-by-step following the 
>>> *https://github.com/openstack/trove-integration
>>> * and the “./redstack
>>> install” command. Also, I want to confirm that as this code installs its
>>> own devstack cloud, will we be able to use the images created using it
>>> in our Openstack Pike trove environment.
>>>
>>
>>
>> ​The Trove Integration repository is dead and gone for a couple of
>> releases now and you should be using the stuff from the trove repository as
>> the documentation indicates.​
>>
>>
>>
>>> 5.   What exact error(s) are you receiving?
>>>
>>> I have attached the logs.
>>>
>>
>>
>> ​The end of your error log indicates
>>
>> +./stack.sh:main:225   echo 'WARNING: this script
>> has not been tested on trusty'
>> WARNING: this script has not been tested on trusty
>> +./stack.sh:main:226   [[ '' != \y\e\s ]]
>> +./stack.sh:main:227   die 227 'If you wish to run
>> this script anyway run with FORCE=yes'
>> +functions-common:die:187  local exitcode=0
>> +functions-common:die:188  set +o xtrace
>> [Call Trace]
>> ./stack.sh:227:die
>> [ERROR] ./stack.sh:227 If you wish to run this script anyway run with
>> FORCE=yes
>>
>>
>> That seems pretty clear to me. Don't do it, redstack is dead, gone,
>> bye-bye.
>>
>> Use the stuff in trove/integration/scripts
>>
>> The trove-integration repository should now have been deleted as well.​
>>
>>
>>
>>>
>>>
>>>
>>>
>>>   Please guide us where are going wrong on this.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ritesh
>>>
>>>
>>>
>>>Please guide us where are going wrong on this.
>>>
>>> On Wed, Nov 8, 2017 at 12:11 PM, Ritesh Vishwakarma <
>>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>>
 ++Looping my fellow engineer.

 On Wed, Nov 8, 2017 at 2:34 AM, Amrith Kumar 
 wrote:

> Ritesh,
>
> Your answers don't help me understand the problems you are having. So
> let's try this instead.
>
> 1. What (exact) version of OpenStack are you using? Is it from
> upstream or a vendor, if it is the latter, which vendor?
> 2. What database (exact version) are you trying to create an image for?
> 3. What operating system (exact version) are you attempting to perform
> this on?
> 4. What command(s) are you executing?
> 5. What exact error(s) are you receiving?
>
> For #4 and #5 it would be ideal if you just cut/pasted a terminal
> session into an etherpad or gist or pastebuffer or some such thing and
> shared that link via email. If you have passwords and other sensitive
> stuff, make sure you redact it.
>
> Thanks.
>
> -amrith
>
>
>
> On Tue, Nov 7, 2017 at 5:40 PM, Ritesh Vishwakarma <
> ritesh.vishwaka...@indusnet.co.in> wrote:
>
>> Hi Amrith,
>>
>>
>> Many Thanks for your response. Hope you are doing well!
>>
>>
>> The confusing part here is that the OpenStack tutorial page itself
>> not seems to be updated https://docs.openstack.org/tro
>> ve/latest/admin/building_guest_images.html#build-guest-images
>>
>> as the *dib-lint* file is there instead of the mentioned 
>> *disk-image-create
>> *and when executed just verifies the other 

Re: [openstack-dev] [tripleo] Proposing John Fulton core on TripleO

[Saravanan KR]

+1

Regards,
Saravanan KR

On Thu, Nov 9, 2017 at 11:40 AM, Emilien Macchi  wrote:
> Of course +1, thanks for your hard work! Stay awesome.
> ---
> Emilien Macchi
>
> On Nov 9, 2017 4:58 PM, "Marios Andreou"  wrote:
>>
>>
>>
>> On Thu, Nov 9, 2017 at 12:24 AM, Giulio Fidente 
>> wrote:
>>>
>>> Hi,
>>>
>>> I would like to propose John Fulton core on TripleO.
>>>
>>> I think John did an awesome work during the Pike cycle around the
>>> integration of ceph-ansible as a replacement for puppet-ceph, for the
>>> deployment of Ceph in containers.
>>>
>>> I think John has good understanding of many different parts of TripleO
>>> given that the ceph-ansible integration has been a complicated effort
>>> involving changes in heat/tht/mistral workflows/ci and last but not
>>> least, docs and he is more recently getting busier with reviews outside
>>> his main comfort zone.
>>>
>>> I am sure John would be a great addition to the team and I welcome him
>>> first to tune into radioparadise with the rest of us when joining
>>> #tripleo
>>>
>>> Feedback is welcomed!
>>
>>
>> +1
>>
>>>
>>> --
>>> Giulio Fidente
>>> GPG KEY: 08D733BA
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing 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] Proposing John Fulton core on TripleO

[Emilien Macchi]

Of course +1, thanks for your hard work! Stay awesome.
---
Emilien Macchi

On Nov 9, 2017 4:58 PM, "Marios Andreou"  wrote:

>
>
> On Thu, Nov 9, 2017 at 12:24 AM, Giulio Fidente 
> wrote:
>
>> Hi,
>>
>> I would like to propose John Fulton core on TripleO.
>>
>> I think John did an awesome work during the Pike cycle around the
>> integration of ceph-ansible as a replacement for puppet-ceph, for the
>> deployment of Ceph in containers.
>>
>> I think John has good understanding of many different parts of TripleO
>> given that the ceph-ansible integration has been a complicated effort
>> involving changes in heat/tht/mistral workflows/ci and last but not
>> least, docs and he is more recently getting busier with reviews outside
>> his main comfort zone.
>>
>> I am sure John would be a great addition to the team and I welcome him
>> first to tune into radioparadise with the rest of us when joining #tripleo
>>
>> Feedback is welcomed!
>>
>
> +1
>
>
>> --
>> Giulio Fidente
>> GPG KEY: 08D733BA
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Proposing John Fulton core on TripleO

[Marios Andreou]

On Thu, Nov 9, 2017 at 12:24 AM, Giulio Fidente  wrote:

> Hi,
>
> I would like to propose John Fulton core on TripleO.
>
> I think John did an awesome work during the Pike cycle around the
> integration of ceph-ansible as a replacement for puppet-ceph, for the
> deployment of Ceph in containers.
>
> I think John has good understanding of many different parts of TripleO
> given that the ceph-ansible integration has been a complicated effort
> involving changes in heat/tht/mistral workflows/ci and last but not
> least, docs and he is more recently getting busier with reviews outside
> his main comfort zone.
>
> I am sure John would be a great addition to the team and I welcome him
> first to tune into radioparadise with the rest of us when joining #tripleo
>
> Feedback is welcomed!
>

+1


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

Re: [openstack-dev] [tripleo] Nominate akrivoka for tripleo-validations core

[Marios Andreou]

On Mon, Nov 6, 2017 at 4:32 PM, Honza Pokorny  wrote:

> Hello people,
>
> I would like to nominate Ana Krivokapić (akrivoka) for the core team for
> tripleo-validations.  She has really stepped up her game on that project
> in terms of helpful reviews, and great patches.
>

+1


>
> With Ana's help as a core, we can get more done, and innovate faster.
>
> If there are no objections within a week, we'll proceed with adding Ana
> to the team.
>
> Thanks
>
> Honza Pokorny
>
> __
> OpenStack Development Mailing 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] Next steps for pre-deployment workflows (e.g derive parameters)

[Saravanan KR]

On Thu, Nov 9, 2017 at 2:57 AM, Jiri Tomasek  wrote:
>
>
> On Wed, Nov 8, 2017 at 6:09 AM, Steven Hardy  wrote:
>>
>> Hi all,
>>
>> Today I had a productive hallway discussion with jtomasek and
>> stevebaker re $subject, so I wanted to elaborate here for the benefit
>> of those folks not present.  Hopefully we can get feedback on the
>> ideas and see if it makes sense to continue and work on some patches:
>>
>> The problem under discussion is how do we run pre-deployment workflows
>> (such as those integrated recently to calculate derived parameters,
>> and in future perhaps also those which download container images etc),
>> and in particular how do we make these discoverable via the UI
>> (including any input parameters).
>>
>> The idea we came up with has two parts:
>>
>> 1. Add a new optional section to roles_data for services that require
>> pre-deploy workflows
>>
>> E.g something like this:
>>
>>  pre_deploy_workflows:
>> - derive_params:
>>   workflow_name:
>> tripleo.derive_params_formulas.v1.dpdk_derive_params
>>   inputs:
>>   ...
>>
>> This would allow us to associate a specific mistral workflow with a
>> given service template, and also work around the fact that currently
>> mistral inputs don't have any schema (only key/value input) as we
>> could encode the required type and any constraints in the inputs block
>> (clearly this could be removed in future should typed parameters
>> become available in mistral).
>>
>> 2. Add a new workflow that calculates the enabled services and returns
>> all pre_deploy_workflows
>>
>> This would take all enabled environments, then use heat to validate
>> the configuration and return the merged resource registry (which will
>> require https://review.openstack.org/#/c/509760/), then we would
>> iterate over all enabled services in the registry and extract a given
>> roles_data key (e.g pre_deploy_workflows)
>>
>> The result of the workflow would be a list of all pre_deploy_workflows
>> for all enabled services, which the UI could then use to run the
>> workflows as part of the pre-deploy process.
>
>
> As I think about this more, we may find out that matching a service to
> workflow is not enough as workflow may require several services (together
> defining a feature) So maybe doing it in separate file would help. E.g.
>
> pre-deploy-workflows.yaml
> - name: my.workflow
>   services: a, b, c, d
>
> Maybe there is a better way, maybe this is not even needed. I am not sure.
> What do you think?

Currently, HCI derive parameters workflow is invoked if a role has
both NovaCompute and CephOSD services enabled.

>
>
> What I really like about this proposal is that it provides a standard way to
> configure deployment features and provides clear means to add additional
> such configurations.
>
> The resulting deployment configuration steps in GUI would look following:
>
> 1/ Hardware (reg. nodes, introspect etc)
>
> 2/ High level deployment configuration (basically selecting additional
> environment files)
>
> 3/ Roles management (Roles selection, roles -> nodes assignment, roles
> configuration - setting roles_data properties)
>
> 4/ Network configuration -  network configuration wizard: (I'll describe
> this in separate email)
>
> 5/ Deployment Features configuration (This proposal) - a list of features to
> configure, the list is nicely generated from information provided in
> previous steps, user has all the information to configure those features at
> hand and can go through these step by step.

Agreed on the UI workflow.

For DPDK and SR-IOV, there are common host specific parameters to be
derived. It has been added as a separate host-specific parameters
workflow. And both DPDK and SR-IOV workflow execution should follow
host-specific workflow.
In case of DPDK and HCI in same role, it is expected that DPDK
workflow is executed before HCI. And the service configuration should
provide this order to UI.
I am not able to realize how this information will be provided and
processed in UI with user. Do you have a UI wire frame for this
workflow?

>
> 6/ Advanced deployment config - a view providing a way to review
> Environment/Roles/Services parameters, search and tweak them if needed.
>
> 7/ Deploy.
>
> I believe these steps should cover anything we should need to do for
> deployment configuration.
>
> -- Jirka
>
>
>>
>>
>> If this makes sense I can go ahead and push some patches so we can
>> iterate on the implementation?
Agreed.

Regards,
Saravanan KR

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

[openstack-dev] [glance] Image encryption

[Peng Liu]

Hi,

I've been looking at the bp[1], which used to be named 'Glance Image
Signing and Encryption' at beginning. But encryption was remove after a
meet-up according [2].

Could anyone tell me 1) why the the image encryption was removed? 2) if it
still makes sense for Glance to have such functionality?


[1]
https://blueprints.launchpad.net/glance/+spec/image-signing-and-verification-support
[2]
https://etherpad.openstack.org/p/liberty-glance-image-signing-and-encryption


Thanks,
-- 
Peng Liu
__
OpenStack Development Mailing 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] Upstream LTS Releases

[Samuel Cassiba]

On Wed, Nov 8, 2017 at 11:17 AM, Doug Hellmann  wrote:
> Excerpts from Samuel Cassiba's message of 2017-11-08 08:27:12 -0800:
>> On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick
>>  wrote:
>> > Hello Ops folks,
>> >
>> > This morning at the Sydney Summit we had a very well attended and very
>> > productive session about how to go about keeping a selection of past
>> > releases available and maintained for a longer period of time (LTS).
>> >
>> > There was agreement in the room that this could be accomplished by
>> > moving the responsibility for those releases from the Stable Branch
>> > team down to those who are already creating and testing patches for
>> > old releases: The distros, deployers, and operators.
>> >
>> > The concept, in general, is to create a new set of cores from these
>> > groups, and use 3rd party CI to validate patches. There are lots of
>> > details to be worked out yet, but our amazing UC (User Committee) will
>> > be begin working out the details.
>> >
>> > Please take a look at the Etherpad from the session if you'd like to
>> > see the details. More importantly, if you would like to contribute to
>> > this effort, please add your name to the list starting on line 133.
>> >
>> > https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases
>> >
>> > Thanks to everyone who participated!
>> >
>> > Cheers,
>> > Erik
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> In advance, pardon the defensive tone. I was not in a position to
>> attend, or even be in Sydney. However, as this comes across the ML, I
>> can't help but get the impression this effort would be forcing more
>> work on already stretched teams, ie. deployment-focused development
>> teams already under a crunch as contributor count continues to decline
>> in favor of other projects inside and out of OpenStack.
>>
>> As a friendly reminder, Chef is still actively developed, though we've
>> not had a great return from recruiting more people. We have about 3.5
>> active developers, including active cores, and non-cores who felt it
>> worthwhile to contribute back upstream. There is no major corporate
>> backer here, but merely a handful of potentially stubborn volunteers.
>> Nobody is behind the curtain, but Chef OpenStack still have a few
>> active users (once again, I point to the annual User Survey results)
>> and contributors. However, we do not use the MLs as a primary
>> communication means, so I can see how we might be forgotten or
>> ignored.
>>
>> In practice, no one likes talking about Chef OpenStack that I've
>> experienced, neither in the Chef or OpenStack communities. However, as
>> a maintainer, I keep making it a point to bring it up when it seems
>> the project gets papered over, or the core team gets signed up for
>> more work decided in a room half a world away. Admittedly, the whole
>> deployment method is a hard sell if you're not using Chef in some way.
>> It has always been my takeaway that the project was merely tolerated
>> under the OpenStack designation, neither embraced nor even liked, even
>> being the "official" OpenStack deployment method for a major
>> deployment toolset. The Foundation's support has been outstanding when
>> we've needed it, but that's about as far as the delightful goes. The
>> Chef community is a bit more tolerant of someone using the Chef
>> moniker for OpenStack, but migrating from Gerrit to GitHub is a major
>> undertaking that the development team may or may not be able to
>> reasonably support without more volunteers. Now that the proposition
>> exists about making a Stable Release liaison derived from existing
>> cores, I can't help but get the impression that, for active-but-quiet
>> projects, it'll be yet another PTL responsibility to keep up with, in
>> addition to the rigors that already come with the role. I'm hoping
>> I'll be proven wrong here, but I can and do get in trouble for hoping.
>>
>
> There are still a lot of details to work out, so the announcement
> of an "agreement" is a bit premature. Rest assured, however, that
> the proposed change is not about "requiring," or even asking, anyone
> to do any new work that they don't want to do.
>
> In the past, we asked folks who wanted to have old branches maintained
> for a long time to join our stable management team with the premise
> that if the stable team grew it could support more branches for
> longer. We've been repeating that answer for about 5 years now,
> without much success, in part because the expertise needed to
> actually deal with complex failures of stable branch jobs is not
> widely available and gaining the experience is a huge time commitment
> that most users can't afford.  It should be 

Re: [openstack-dev] [tripleo] Proposing John Fulton core on TripleO

[Steven Hardy]

On Wed, Nov 8, 2017 at 10:33 PM, Alex Schultz  wrote:
> On Wed, Nov 8, 2017 at 3:24 PM, Giulio Fidente  wrote:
>> Hi,
>>
>> I would like to propose John Fulton core on TripleO.
>>
>> I think John did an awesome work during the Pike cycle around the
>> integration of ceph-ansible as a replacement for puppet-ceph, for the
>> deployment of Ceph in containers.
>>
>> I think John has good understanding of many different parts of TripleO
>> given that the ceph-ansible integration has been a complicated effort
>> involving changes in heat/tht/mistral workflows/ci and last but not
>> least, docs and he is more recently getting busier with reviews outside
>> his main comfort zone.
>>
>> I am sure John would be a great addition to the team and I welcome him
>> first to tune into radioparadise with the rest of us when joining #tripleo
>>
>
> +1. Excellent work with the ceph-ansible items.

Agreed, +1!

__
OpenStack Development Mailing 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] Next steps for pre-deployment workflows (e.g derive parameters)

[Steven Hardy]

On Wed, Nov 8, 2017 at 10:55 PM, James Slagle  wrote:
> On Wed, Nov 8, 2017 at 7:16 AM, James Slagle  wrote:
>> On Wed, Nov 8, 2017 at 12:09 AM, Steven Hardy  wrote:
>>> Hi all,
>>>
>>> Today I had a productive hallway discussion with jtomasek and
>>> stevebaker re $subject, so I wanted to elaborate here for the benefit
>>> of those folks not present.  Hopefully we can get feedback on the
>>> ideas and see if it makes sense to continue and work on some patches:
>>>
>>> The problem under discussion is how do we run pre-deployment workflows
>>> (such as those integrated recently to calculate derived parameters,
>>> and in future perhaps also those which download container images etc),
>>> and in particular how do we make these discoverable via the UI
>>> (including any input parameters).
>
> After chatting with jtomasek on irc, I wanted to clarify that the part
> of this proposal I'm hesitant about.
>
> Specifically, it's adding an interface for any service to specify a
> mistral workflow, that in theory could do anything, as part of a
> pre_deploy interface "contract". If we do offer such an interface, I
> think it ought to be driven via ansible tasks/plays that are available
> as Heat stack outputs to match the config-download pattern.

Thanks for the feedback, yes I agree if we can do this with pure
ansible that would be great, but we'll have to take a closer look at
the existing implementation, e.g as mentioned by Saravanan there is an
existing integration with mistral workflows, which we'll either have
to maintain or migrate away from.

> Perhaps for just deriving parameters, having a way to specify
> workflows for the UI is Ok. It's more of the generic interface I'm not
> so keen on. As it relates to your example of downloading container
> images, it seems we could have a generic ansible task to do that, that
> could then be executed with Mistral for API purposes instead of
> specifying the Mistral workflow directly in the templates/roles_data.

Yeah good point, and also the point about CI moving towards undercloud
deploy is a good one - if we can work out a way to do this via ansible
(even if that means ansible running a mistral workflow as a
transitional step?) that would certainly be easier.

Hopefully we can chat more about this on IRC next week and prototype
the ansible approach to see how it could work.

Thanks!

Steve

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

Re: [openstack-dev] [TripleO] Next steps for pre-deployment workflows (e.g derive parameters)

[James Slagle]

On Wed, Nov 8, 2017 at 7:16 AM, James Slagle  wrote:
> On Wed, Nov 8, 2017 at 12:09 AM, Steven Hardy  wrote:
>> Hi all,
>>
>> Today I had a productive hallway discussion with jtomasek and
>> stevebaker re $subject, so I wanted to elaborate here for the benefit
>> of those folks not present.  Hopefully we can get feedback on the
>> ideas and see if it makes sense to continue and work on some patches:
>>
>> The problem under discussion is how do we run pre-deployment workflows
>> (such as those integrated recently to calculate derived parameters,
>> and in future perhaps also those which download container images etc),
>> and in particular how do we make these discoverable via the UI
>> (including any input parameters).

After chatting with jtomasek on irc, I wanted to clarify that the part
of this proposal I'm hesitant about.

Specifically, it's adding an interface for any service to specify a
mistral workflow, that in theory could do anything, as part of a
pre_deploy interface "contract". If we do offer such an interface, I
think it ought to be driven via ansible tasks/plays that are available
as Heat stack outputs to match the config-download pattern.

Perhaps for just deriving parameters, having a way to specify
workflows for the UI is Ok. It's more of the generic interface I'm not
so keen on. As it relates to your example of downloading container
images, it seems we could have a generic ansible task to do that, that
could then be executed with Mistral for API purposes instead of
specifying the Mistral workflow directly in the templates/roles_data.

-- 
-- James Slagle
--

__
OpenStack Development Mailing 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] Please do not approve or recheck anything not related to CI alert bugs

[Alex Schultz]

So we have some good news and some bad news.  The good news is that
we've managed to get the gate queue[0] under control since we've held
off on pushing new things to the gate.  The bad news is that we've
still got some random failures occurring during the deployment of
master.  Since we're not seeing infra related issues, we should be OK
to merge things to stable/* branches.  Unfortunately until we resolve
the issues in master[1] we could potentially backup the queue.  Please
do not merge things that are not critical bugs.  I would ask that
folks please take a look at the open bugs and help figure out what is
going wrong. I've created two issues today that I've seen in the gate
that we don't appear to have open patches for. One appears to be an
issue in the heat deployment process[3] and the other is related to
the tempest verification of being able to launch a VM & ssh to it[4].

Thanks,
-Alex

[3] https://bugs.launchpad.net/tripleo/+bug/1731032
[4] https://bugs.launchpad.net/tripleo/+bug/1731063

On Tue, Nov 7, 2017 at 8:33 AM, Alex Schultz  wrote:
> Hey Folks
>
> So we're at 24+ hours again in the gate[0] and the queue only
> continues to grow. We currently have 6 ci/alert bugs[1]. Please do not
> approve of recheck anything that isn't related to these bugs.  I will
> most likely need to go through the queue and abandon everything to
> clear it up as we are consistently hitting timeouts on various jobs
> which is preventing anything from merging.
>
> Thanks,
> -Alex
>
[0] http://zuulv3.openstack.org/
[1] 
https://bugs.launchpad.net/tripleo/+bugs?field.searchtext==-importance%3Alist=NEW%3Alist=CONFIRMED%3Alist=TRIAGED%3Alist=INPROGRESS%3Alist=CRITICAL_option=any=_reporter=_commenter==_subscriber==ci+alert_combinator=ALL_cve.used=_dupes.used=_dupes=on_me.used=_patch.used=_branches.used=_branches=on_no_branches.used=_no_branches=on_blueprints.used=_blueprints=on_no_blueprints.used=_no_blueprints=on=Search

__
OpenStack Development Mailing 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] Proposing John Fulton core on TripleO

[Alex Schultz]

On Wed, Nov 8, 2017 at 3:24 PM, Giulio Fidente  wrote:
> Hi,
>
> I would like to propose John Fulton core on TripleO.
>
> I think John did an awesome work during the Pike cycle around the
> integration of ceph-ansible as a replacement for puppet-ceph, for the
> deployment of Ceph in containers.
>
> I think John has good understanding of many different parts of TripleO
> given that the ceph-ansible integration has been a complicated effort
> involving changes in heat/tht/mistral workflows/ci and last but not
> least, docs and he is more recently getting busier with reviews outside
> his main comfort zone.
>
> I am sure John would be a great addition to the team and I welcome him
> first to tune into radioparadise with the rest of us when joining #tripleo
>

+1. Excellent work with the ceph-ansible items.

> Feedback is welcomed!
> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [tripleo] Proposing John Fulton core on TripleO

[Giulio Fidente]

Hi,

I would like to propose John Fulton core on TripleO.

I think John did an awesome work during the Pike cycle around the
integration of ceph-ansible as a replacement for puppet-ceph, for the
deployment of Ceph in containers.

I think John has good understanding of many different parts of TripleO
given that the ceph-ansible integration has been a complicated effort
involving changes in heat/tht/mistral workflows/ci and last but not
least, docs and he is more recently getting busier with reviews outside
his main comfort zone.

I am sure John would be a great addition to the team and I welcome him
first to tune into radioparadise with the rest of us when joining #tripleo

Feedback is welcomed!
-- 
Giulio Fidente
GPG KEY: 08D733BA

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

Re: [openstack-dev] [TripleO] containerized undercloud in Queens

[Wesley Hayutin]

On Wed, Nov 8, 2017 at 5:00 PM, Alex Schultz  wrote:

> On Tue, Nov 7, 2017 at 2:59 PM, Emilien Macchi  wrote:
> > On Wed, Nov 8, 2017 at 3:30 AM, James Slagle 
> wrote:
> >> On Sun, Nov 5, 2017 at 7:01 PM, Emilien Macchi 
> wrote:
> >>> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince  wrote:
> >>> [...]
> >>>
>   -CI resources: better use of CI resources. At the PTG we received
>  feedback from the OpenStack infrastructure team that our upstream CI
>  resource usage is quite high at times (even as high as 50% of the
>  total). Because of the shared framework and single node capabilities
> we
>  can re-architecture much of our upstream CI matrix around single node.
>  We no longer require multinode jobs to be able to test many of the
>  services in tripleo-heat-templates... we can just use a single cloud
> VM
>  instead. We'll still want multinode undercloud -> overcloud jobs for
>  testing things like HA and baremetal provisioning. But we can cover a
>  large set of the services (in particular many of the new scenario jobs
>  we added in Pike) with single node CI test runs in much less time.
> >>>
> >>> After the last (terrible) weeks in CI, it's pretty clear we need to
> >>> find a solution to reduce and optimize our testing.
> >>> I'm now really convinced by switching our current scenarios jobs to
> >>> NOT deploy the overcloud, and just an undercloud with composable
> >>> services & run tempest.
> >>
> >> +1 if you mean just the scenarios.
> >
> > Yes, just scenarios.
> >
> >> I think we need to keep at least 1 multinode job voting that deploys
> >> the overcloud, probably containers-multinode.
> >
> > Yes, exactly, and also work on optimizing OVB jobs (maybe just keep
> > one or 2 jobs, instead 3).
> >
> >>> Benefits:
> >>> - deploy 1 node instead of 2 nodes, so we save nodepool resources
> >>> - faster (no overcloud)
> >>> - reduce gate queue time, faster development process, faster CI
> >>>
> >>> Challenges:
> >>> - keep overcloud testing, with OVB
> >>
> >> This is why I'm not sure what you're proposing. Do you mean switch all
> >> multinode jobs to be just an undercloud, or just the scenarios?
> >
> > Keep 1 or 2 OVB jobs, to test ironic + mistral + HA (HA could be
> > tested with multinode though but well).
> >
> >>> - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic
> >>> containerized services on overcloud.
> >>>
> >>> I really want to get consensus on these points, please raise your
> >>> voice now before we engage some work on that front.
> >>
> >> I'm fine to optimize the scenarios to be undercloud driven, but feel
> >> we still need a multinode job that deploys the overcloud in the gate.
> >> Otherwise, we'll have nothing that deploys an overcloud in the gate,
> >> which is a step in the wrong direction imo. Primarily, b/c of the loss
> >> of coverage around mistral and all of our workflows. Perhaps down the
> >> road we could find ways to optimize that by using an ephemeral Mistral
> >> (similar to the ephemeral Heat container), and then use a single node,
> >> but we're not there yet.
> >>
> >> On the other hand, if the goal is just to test less upstream so that
> >> we can more quickly merge code, then *not* deploying an overcloud in
> >> the gate at all seems to fit that goal. Is that what you're after?
> >
> > Yes. Thanks for reformulate with better words.
> > Just to be clear, I want to transform the scenarios into single-node
> > jobs that deploy the SAME services (using composable services) from
> > the undercloud, using the new ansible installer. I also want to keep
> > running Tempest.
> > And of course, like we said, keep one multinode job to test overcloud
> > workflow, and OVB with some adjustments.
> >
>
> So I'm ok with switching to use the containerized undercloud deploy to
> smoke test functionality of more complex openstack service
> deployments. What I would like to see prior to investing in this is
> that the plain containerized undercloud deploy job reliability is on
> par with the existing undercloud install.  We had to switch the
> undercloud-containers back to non-voting due to higher failure rates
> and it is still not voting.


Agree, once we have a little success I'll update featureset027 ( the
undercloud-containers )
which is still non-voting to use this updated containerized deployment.
Then we'll compare
the undercloud-oooq to undercloud-containers (fs027) After a few weeks of
running.


> With the current state of CI being
> questionable due to random failures which are not fully have resolved,
> I would prefer that we ensure existing CI is stable and that what we
> plan to move is as stable.
>

Agreed,
There are times IMHO when one must strike when the iron is hot on certain
parts of the work here.  I felt compelled to help bootstrap Ian with the
containerized undercloud work or see old habits remain and 

Re: [openstack-dev] [TripleO] containerized undercloud in Queens

[Alex Schultz]

On Tue, Nov 7, 2017 at 2:59 PM, Emilien Macchi  wrote:
> On Wed, Nov 8, 2017 at 3:30 AM, James Slagle  wrote:
>> On Sun, Nov 5, 2017 at 7:01 PM, Emilien Macchi  wrote:
>>> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince  wrote:
>>> [...]
>>>
  -CI resources: better use of CI resources. At the PTG we received
 feedback from the OpenStack infrastructure team that our upstream CI
 resource usage is quite high at times (even as high as 50% of the
 total). Because of the shared framework and single node capabilities we
 can re-architecture much of our upstream CI matrix around single node.
 We no longer require multinode jobs to be able to test many of the
 services in tripleo-heat-templates... we can just use a single cloud VM
 instead. We'll still want multinode undercloud -> overcloud jobs for
 testing things like HA and baremetal provisioning. But we can cover a
 large set of the services (in particular many of the new scenario jobs
 we added in Pike) with single node CI test runs in much less time.
>>>
>>> After the last (terrible) weeks in CI, it's pretty clear we need to
>>> find a solution to reduce and optimize our testing.
>>> I'm now really convinced by switching our current scenarios jobs to
>>> NOT deploy the overcloud, and just an undercloud with composable
>>> services & run tempest.
>>
>> +1 if you mean just the scenarios.
>
> Yes, just scenarios.
>
>> I think we need to keep at least 1 multinode job voting that deploys
>> the overcloud, probably containers-multinode.
>
> Yes, exactly, and also work on optimizing OVB jobs (maybe just keep
> one or 2 jobs, instead 3).
>
>>> Benefits:
>>> - deploy 1 node instead of 2 nodes, so we save nodepool resources
>>> - faster (no overcloud)
>>> - reduce gate queue time, faster development process, faster CI
>>>
>>> Challenges:
>>> - keep overcloud testing, with OVB
>>
>> This is why I'm not sure what you're proposing. Do you mean switch all
>> multinode jobs to be just an undercloud, or just the scenarios?
>
> Keep 1 or 2 OVB jobs, to test ironic + mistral + HA (HA could be
> tested with multinode though but well).
>
>>> - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic
>>> containerized services on overcloud.
>>>
>>> I really want to get consensus on these points, please raise your
>>> voice now before we engage some work on that front.
>>
>> I'm fine to optimize the scenarios to be undercloud driven, but feel
>> we still need a multinode job that deploys the overcloud in the gate.
>> Otherwise, we'll have nothing that deploys an overcloud in the gate,
>> which is a step in the wrong direction imo. Primarily, b/c of the loss
>> of coverage around mistral and all of our workflows. Perhaps down the
>> road we could find ways to optimize that by using an ephemeral Mistral
>> (similar to the ephemeral Heat container), and then use a single node,
>> but we're not there yet.
>>
>> On the other hand, if the goal is just to test less upstream so that
>> we can more quickly merge code, then *not* deploying an overcloud in
>> the gate at all seems to fit that goal. Is that what you're after?
>
> Yes. Thanks for reformulate with better words.
> Just to be clear, I want to transform the scenarios into single-node
> jobs that deploy the SAME services (using composable services) from
> the undercloud, using the new ansible installer. I also want to keep
> running Tempest.
> And of course, like we said, keep one multinode job to test overcloud
> workflow, and OVB with some adjustments.
>

So I'm ok with switching to use the containerized undercloud deploy to
smoke test functionality of more complex openstack service
deployments. What I would like to see prior to investing in this is
that the plain containerized undercloud deploy job reliability is on
par with the existing undercloud install.  We had to switch the
undercloud-containers back to non-voting due to higher failure rates
and it is still not voting.  With the current state of CI being
questionable due to random failures which are not fully have resolved,
I would prefer that we ensure existing CI is stable and that what we
plan to move is as stable.

Additionally I think we need to ensure that the ovb jobs that still do
full deployment process become voting by switching to 3rd party CI.

Thanks,
-Alex

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

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

Re: [openstack-dev] [TripleO] containerized undercloud in Queens

[Wesley Hayutin]

On Tue, Nov 7, 2017 at 9:07 PM, James Slagle  wrote:

> On Tue, Nov 7, 2017 at 4:59 PM, Emilien Macchi  wrote:
> > Yes. Thanks for reformulate with better words.
> > Just to be clear, I want to transform the scenarios into single-node
> > jobs that deploy the SAME services (using composable services) from
> > the undercloud, using the new ansible installer. I also want to keep
> > running Tempest.
> > And of course, like we said, keep one multinode job to test overcloud
> > workflow, and OVB with some adjustments.
> >
> > Is it good?
>
> +1
>
>
> --
> -- James Slagle
> --
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


FYI,
Slow and I have been pair programming to get the latest containerized
undercloud work into the mainline CI.
The old containerized undercloud work in featureset027 was working and not
to be confused with this attempt.

Here's a link
http://logs.openstack.org/18/518118/2/check/legacy-tripleo-ci-centos-7-undercloud-containers/4eef40f/logs/undercloud/home/zuul/undercloud_install.log.txt.gz
__
OpenStack Development Mailing 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] Canceling this week's meeting

[Telles Nobrega]

Hi saharans, sorry for the late email, but I'm canceling this week's
meeting.

See you all next week.
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
__
OpenStack Development Mailing 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] Next steps for pre-deployment workflows (e.g derive parameters)

[Jiri Tomasek]

On Wed, Nov 8, 2017 at 6:09 AM, Steven Hardy  wrote:

> Hi all,
>
> Today I had a productive hallway discussion with jtomasek and
> stevebaker re $subject, so I wanted to elaborate here for the benefit
> of those folks not present.  Hopefully we can get feedback on the
> ideas and see if it makes sense to continue and work on some patches:
>
> The problem under discussion is how do we run pre-deployment workflows
> (such as those integrated recently to calculate derived parameters,
> and in future perhaps also those which download container images etc),
> and in particular how do we make these discoverable via the UI
> (including any input parameters).
>
> The idea we came up with has two parts:
>
> 1. Add a new optional section to roles_data for services that require
> pre-deploy workflows
>
> E.g something like this:
>
>  pre_deploy_workflows:
> - derive_params:
>   workflow_name:
> tripleo.derive_params_formulas.v1.dpdk_derive_params
>   inputs:
>   ...
>
> This would allow us to associate a specific mistral workflow with a
> given service template, and also work around the fact that currently
> mistral inputs don't have any schema (only key/value input) as we
> could encode the required type and any constraints in the inputs block
> (clearly this could be removed in future should typed parameters
> become available in mistral).
>
> 2. Add a new workflow that calculates the enabled services and returns
> all pre_deploy_workflows
>
> This would take all enabled environments, then use heat to validate
> the configuration and return the merged resource registry (which will
> require https://review.openstack.org/#/c/509760/), then we would
> iterate over all enabled services in the registry and extract a given
> roles_data key (e.g pre_deploy_workflows)
>
> The result of the workflow would be a list of all pre_deploy_workflows
> for all enabled services, which the UI could then use to run the
> workflows as part of the pre-deploy process.
>

As I think about this more, we may find out that matching a service to
workflow is not enough as workflow may require several services (together
defining a feature) So maybe doing it in separate file would help. E.g.

pre-deploy-workflows.yaml
- name: my.workflow
  services: a, b, c, d

Maybe there is a better way, maybe this is not even needed. I am not sure.
What do you think?


What I really like about this proposal is that it provides a standard way
to configure deployment features and provides clear means to add additional
such configurations.

The resulting deployment configuration steps in GUI would look following:

1/ Hardware (reg. nodes, introspect etc)

2/ High level deployment configuration (basically selecting additional
environment files)

3/ Roles management (Roles selection, roles -> nodes assignment, roles
configuration - setting roles_data properties)

4/ Network configuration -  network configuration wizard: (I'll describe
this in separate email)

5/ Deployment Features configuration (This proposal) - a list of features
to configure, the list is nicely generated from information provided in
previous steps, user has all the information to configure those features at
hand and can go through these step by step.

6/ Advanced deployment config - a view providing a way to review
Environment/Roles/Services parameters, search and tweak them if needed.

7/ Deploy.

I believe these steps should cover anything we should need to do for
deployment configuration.

-- Jirka



>
> If this makes sense I can go ahead and push some patches so we can
> iterate on the implementation?
>
> Thanks,
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Next steps for pre-deployment workflows (e.g derive parameters)

[Jiri Tomasek]

On Wed, Nov 8, 2017 at 11:09 AM, Saravanan KR  wrote:

> Thanks Steven for the update.
>
> Current CLI flow:
> --
> * User need to add -p parameter for the overcloud deploy command with
> workflows to be invoked [1]
> * Plan will update updated to the swift container
> * Derived parameters workflow is initiated
> - For each role
> * Get the introspection data of first node assigned to the role
> * Find the list features based on the services or parameters
> * If dpdk present, run dpdk formulas workflow
> * if sriov is present, run sriov formulas workfow (under
> development)
> * if sriov or dpdk is present, run host formulas workflow
> * if hci present, run hci formulas workflow
>
> Here the order of the formulas workflow invocation is important. For
> example,  in Compute-DPDK-HCI role, HCI formulas should exclude the
> CPUs allocated for DPDK PMD threads, while calculating cpu allocation
> ratio.
>
> I am trying to understand the proposed changes. Is it for assisting UI
> only or changing the existing CLI flow too? If the idea is to invoke
> the individual formulas workflow, it will not be possible with
> existing implementation, need to be re-worked. We need to introduce
> order for formulas workflow and direct fetching and merging of derived
> parameters in plan.
>

So there are several problems we're trying to solve with this proposal. In
general is to provide feature based workflows which will configure these
features, as well as provide means to get current configuration of these
features and provide sensible information about the input for these
workflows.

I think one of the main problem of current implementation is that user is
not able to get any information about input required to provide to run
derivation workflows. That information is purely documentation based and
also involves tweaking deployment-plan which I am convinced is not a good
way to provide the input.

So what we're proposing is to bring up a mechanism of mapping the
derivation workflows to services (roles/environments) so as Steven
described we're able to identify which workflows are possible to run and
provide extensive input definition so user can see what he is configuring
and why (input type, description, label).

This also means that there is several parameter derivation workflows rather
than just one and the input for the workflow is the actual input passed to
mistral (no plan-environment.yaml changes involved). Using this whole
approach means that for each such identified feature, we can provide -
Input details, general feature description (mistral workflow description)
and current configuration (by reaching to mistral workflow execution if
that was run before)

If as you're saying certain workflows depend on each other those should
probably be in one workflow. On the other hand, I think it is not goo
approach to try to put all the parameter derivation workflows into single
workflow.


-- Jirka


>
> As per earlier discussion jtomasek, to invoke derived parameters
> workflow (existing) for a plan, UI requires following information:
> * Whether derived parameters should be invoked for this deployment
> (based on roles and enabled services)
> * If yes, list of parameters, its types, and its default values (and
> choices if present), are required
>
> Did I miss anything?
>
> Regards,
> Saravanan KR
>
> [1] https://github.com/openstack/tripleo-heat-templates/blob/
> master/plan-samples/plan-environment-derived-params.yaml
>
> On Wed, Nov 8, 2017 at 2:39 PM, Bogdan Dobrelya 
> wrote:
> > On 11/8/17 6:09 AM, Steven Hardy wrote:
> >>
> >> Hi all,
> >>
> >> Today I had a productive hallway discussion with jtomasek and
> >> stevebaker re $subject, so I wanted to elaborate here for the benefit
> >> of those folks not present.  Hopefully we can get feedback on the
> >> ideas and see if it makes sense to continue and work on some patches:
> >>
> >> The problem under discussion is how do we run pre-deployment workflows
> >> (such as those integrated recently to calculate derived parameters,
> >> and in future perhaps also those which download container images etc),
> >> and in particular how do we make these discoverable via the UI
> >> (including any input parameters).
> >>
> >> The idea we came up with has two parts:
> >>
> >> 1. Add a new optional section to roles_data for services that require
> >> pre-deploy workflows
> >>
> >> E.g something like this:
> >>
> >>   pre_deploy_workflows:
> >>  - derive_params:
> >>workflow_name:
> >> tripleo.derive_params_formulas.v1.dpdk_derive_params
> >>inputs:
> >>...
> >>
> >> This would allow us to associate a specific mistral workflow with a
> >> given service template, and also work around the fact that currently
> >> mistral inputs don't have any schema (only key/value input) as we
> >> could encode the required 

Re: [openstack-dev] [Openstack] generation of .pem file

[David Gabriel]

I forget to send the errors I got:

  File "/usr/lib/python2.7/dist-packages/heatclient/v1/stacks.py", line
109, in create
data=kwargs, headers=headers)
  File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py", line
223, in json_request
resp = self._http_request(url, method, **kwargs)
  File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py", line
166, in _http_request
**kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 53,
in request
return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line
468, in request
resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line
576, in send
r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line
447, in send
raise SSLError(e, request=request)
SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
127.0.0.1 - - [08/Nov/2017 20:34:56] "POST /stack_create HTTP/1.1" 500 2801


2017-11-08 21:43 GMT+01:00 David Gabriel :

> Dear Juan,
>
> Thanks so much for your reply.
> I fact, the command you suggest leads to the structure of a .pem file like
> it is shown in the reference you provide.
>
> Let me please ask another question related to the new pem file.
> In fact, I want to use use it in to call python-heatclient API in order to
> create stacks (Openstack address is based on https).
> I am wondering, where to copy this pem file and how to refer it ?
>
> Thanks in advance.
> Best regards.
>
>
>
> 2017-11-08 15:39 GMT+01:00 Juan Antonio Osorio :
>
>> Hello,
>>
>> You need to verify the files and check how they look like. A good guide
>> to do this is this one http://how2ssl.com/articles/wo
>> rking_with_pem_files/ .
>> .cert and .key are not actual formats, but might actually contain the
>> cert and the key in PEM format. The main giveaway is that they should
>> contain the header. If you will use the file for HAProxy, then you need the
>> certificate and key in the same file. So you would do something like this:
>>
>> $ cat mycertificate.cert  mykey.key > cert-and-key.pem
>>
>> And the resulting file is something you could use for your HAProxy
>> instance. But again, it all depends on what you will use it for.
>>
>> On Wed, Nov 8, 2017 at 3:36 PM, David Gabriel 
>> wrote:
>>
>>> Dears,
>>>
>>> I need to generate the .pem file based on certifcate files (.cert).
>>> The key (.key file) is available too.
>>> All my files can be read as text files.
>>> Could you please detail the procedure for this ?
>>> I am using ubuntu as OS.
>>>
>>> Thanks in advance.
>>> Best regards.
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Juan Antonio Osorio R.
>> e-mail: jaosor...@gmail.com
>>
>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to : openst...@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] generation of .pem file

[David Gabriel]

Dear Juan,

Thanks so much for your reply.
I fact, the command you suggest leads to the structure of a .pem file like
it is shown in the reference you provide.

Let me please ask another question related to the new pem file.
In fact, I want to use use it in to call python-heatclient API in order to
create stacks (Openstack address is based on https).
I am wondering, where to copy this pem file and how to refer it ?

Thanks in advance.
Best regards.



2017-11-08 15:39 GMT+01:00 Juan Antonio Osorio :

> Hello,
>
> You need to verify the files and check how they look like. A good guide to
> do this is this one http://how2ssl.com/articles/working_with_pem_files/ .
> .cert and .key are not actual formats, but might actually contain the cert
> and the key in PEM format. The main giveaway is that they should contain
> the header. If you will use the file for HAProxy, then you need the
> certificate and key in the same file. So you would do something like this:
>
> $ cat mycertificate.cert  mykey.key > cert-and-key.pem
>
> And the resulting file is something you could use for your HAProxy
> instance. But again, it all depends on what you will use it for.
>
> On Wed, Nov 8, 2017 at 3:36 PM, David Gabriel 
> wrote:
>
>> Dears,
>>
>> I need to generate the .pem file based on certifcate files (.cert).
>> The key (.key file) is available too.
>> All my files can be read as text files.
>> Could you please detail the procedure for this ?
>> I am using ubuntu as OS.
>>
>> Thanks in advance.
>> Best regards.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
__
OpenStack Development Mailing 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] Call for sponsorship: hardware for Debian OpenStack packages functional testing

[Thomas Goirand]

tl;dr: I need hardware to run tempest on Debian + OpenStack. I wouldn't
refuse sponsorship of my work either.

Dear everyone,

As you may know, I have been packaging OpenStack in Debian nearly since
it existed (ie: since the Cactus release).

I used to be a Mirantis employee, though like many others from the
company, I've been "let go" last year (that's the wording of the
Mirantis marketing people... though I didn't want to go!). At the
moment, I'm still unemployed, even though I have very serious
opportunities offered to me.

Anyway, the thing is, every time my professional situation changes, I am
loosing the access to hardware used to do functional testing of the
Debian OpenStack packages. Currently, I don't have a server to run on,
so I cannot check if Pike works as expected.

I already had some offers from companies to use hardware that they also
would host. However, this also feels like not sustainable over a long
period of time. I would very much prefer to have such a hardware hosted
within the Debian infrastructure. Which is why I am hereby calling for
sponsorship of such a hardware.

Note that I already made such a request to the DSA team (Debian System
Administrators), and it was denied because they don't want to make
OpenStack a special case. Normally, DDs are supposed to test packages
themselves when uploading to Debian.

There's 3 types of setup that my current scripts are able to support:
1/ A Xen VM.
2/ A KVM vm.
3/ A Debian live system running on bare metal, which is reseted using
IMPI (using an ipmitool command).

It's that last one which is performing the best, because it's running on
bare metal, which avoids nested virtualization. Also, reinstalling the
system means simply doing a reset and waiting for the the server to be
up again. Last, the system runs on a tempfs, and IOPs are therefore a
way faster than on a normal disk (HDD / SSD). The local HDD is then used
as a scratch disk for testing Cinder and Swift, instead of a local
loopback in the case of KVM or Xen (so again, much faster). It also
needs to have IPMI, and preferably also KVM over IP.

The speed of the system used to do the functional testing is important,
because the time for setting-up the system is around 20 minutes (on
option 3 above, slower in other cases), then it takes roughly 1 hour to
run the functional test with tempest. Typically, such a debug process is
ran multiple times, iteratively, fixing one problem after another.

The hardware I last used was a multi-core 64 bits x86 system with 32 GB
of RAM, and an SSD scratch disk (100 GB of a single SSD is enough), plus
a server to run PXE network boot: tftp server, dhcp server, and apache
to provide the squashfs image to the server. That's about what I need.

Also, to be able to PXE boot the server, I need a 2nd server to run
dhcp, pxe and apache. On that server, I would run Xen to be able to also
install Jenkins server to do package build on each git push, which
avoids a lot of RC bugs in Debian, and speeds up therefore packaging.

So, all together, I'm searching for someone to sponsor:
- A 32 GB RAM server with at least 2 cores, and 100 GB SSD, and 2 nics
at least
and either:
- A 2nd server with a minimum of 1GB RAM & 20GB HDD and 2 nics
but preferably:
- 64 or even better 128 GB RAM, so I can host Jenkins servers and Debian
repositories (one per release, using virtualization), with a large
enough HDD to host the full set of packages per release: a pair of 1TB
HDD or more using RAID1 (or even better: 4 HDD with RAID10 for better
performances) seems a good choice to me.

If you are able to sponsor such a hardware, and send it either to
Univercity of British Columbia, or to Bytemarks in UK, please get in
touch with me.

Last thing. A number of companies offered me to sponsor my work
packaging OpenStack for Debian: at least 4 companies already. It really
feels like a number of companies were using my work over the years.
However, it never went through. As I've been unemployed for a long time,
I probably will accept a job not directly related to the packaging of
OpenStack. So if you wish that I continue what I've done, sponsoring is
welcome too. To such a sponsor, I can offer more than just the
packaging: I can offer my help for deploying OpenStack, and maintaining
it in production, plus whatever that company will need related to that,
and this either on Debian or Ubuntu (I can provide support for both,
even if my heart is on the Debian side). I also would accept any job
that would include OpenStack Debian packaging, and if it can be done
remote, from my home. The risk if this doesn't happen, is that the
Debian packaging of OpenStack stops. It was the case for Mitaka already,
and I decided to do Newton on my free time. I probably wont be able to
do that again for Queens, if I'm not paid for it: it's clearly not a
sustainable situation.

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing 

Re: [openstack-dev] Upstream LTS Releases

[Doug Hellmann]

Excerpts from Samuel Cassiba's message of 2017-11-08 08:27:12 -0800:
> On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick
>  wrote:
> > Hello Ops folks,
> >
> > This morning at the Sydney Summit we had a very well attended and very
> > productive session about how to go about keeping a selection of past
> > releases available and maintained for a longer period of time (LTS).
> >
> > There was agreement in the room that this could be accomplished by
> > moving the responsibility for those releases from the Stable Branch
> > team down to those who are already creating and testing patches for
> > old releases: The distros, deployers, and operators.
> >
> > The concept, in general, is to create a new set of cores from these
> > groups, and use 3rd party CI to validate patches. There are lots of
> > details to be worked out yet, but our amazing UC (User Committee) will
> > be begin working out the details.
> >
> > Please take a look at the Etherpad from the session if you'd like to
> > see the details. More importantly, if you would like to contribute to
> > this effort, please add your name to the list starting on line 133.
> >
> > https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases
> >
> > Thanks to everyone who participated!
> >
> > Cheers,
> > Erik
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> In advance, pardon the defensive tone. I was not in a position to
> attend, or even be in Sydney. However, as this comes across the ML, I
> can't help but get the impression this effort would be forcing more
> work on already stretched teams, ie. deployment-focused development
> teams already under a crunch as contributor count continues to decline
> in favor of other projects inside and out of OpenStack.
> 
> As a friendly reminder, Chef is still actively developed, though we've
> not had a great return from recruiting more people. We have about 3.5
> active developers, including active cores, and non-cores who felt it
> worthwhile to contribute back upstream. There is no major corporate
> backer here, but merely a handful of potentially stubborn volunteers.
> Nobody is behind the curtain, but Chef OpenStack still have a few
> active users (once again, I point to the annual User Survey results)
> and contributors. However, we do not use the MLs as a primary
> communication means, so I can see how we might be forgotten or
> ignored.
>
> In practice, no one likes talking about Chef OpenStack that I've
> experienced, neither in the Chef or OpenStack communities. However, as
> a maintainer, I keep making it a point to bring it up when it seems
> the project gets papered over, or the core team gets signed up for
> more work decided in a room half a world away. Admittedly, the whole
> deployment method is a hard sell if you're not using Chef in some way.
> It has always been my takeaway that the project was merely tolerated
> under the OpenStack designation, neither embraced nor even liked, even
> being the "official" OpenStack deployment method for a major
> deployment toolset. The Foundation's support has been outstanding when
> we've needed it, but that's about as far as the delightful goes. The
> Chef community is a bit more tolerant of someone using the Chef
> moniker for OpenStack, but migrating from Gerrit to GitHub is a major
> undertaking that the development team may or may not be able to
> reasonably support without more volunteers. Now that the proposition
> exists about making a Stable Release liaison derived from existing
> cores, I can't help but get the impression that, for active-but-quiet
> projects, it'll be yet another PTL responsibility to keep up with, in
> addition to the rigors that already come with the role. I'm hoping
> I'll be proven wrong here, but I can and do get in trouble for hoping.
> 

There are still a lot of details to work out, so the announcement
of an "agreement" is a bit premature. Rest assured, however, that
the proposed change is not about "requiring," or even asking, anyone
to do any new work that they don't want to do.

In the past, we asked folks who wanted to have old branches maintained
for a long time to join our stable management team with the premise
that if the stable team grew it could support more branches for
longer. We've been repeating that answer for about 5 years now,
without much success, in part because the expertise needed to
actually deal with complex failures of stable branch jobs is not
widely available and gaining the experience is a huge time commitment
that most users can't afford.  It should be clear to everyone that
the previous approach isn't working.

The new proposal is meant to empower people who want to do work
to have a place to do it. At the same time, we 

Re: [openstack-dev] Upstream LTS Releases

[Dmitry Tantsur]

Hi!

This is amazing to see this discussed! Looking forward to more details.

On 11/08/2017 12:28 AM, Erik McCormick wrote:

Hello Ops folks,

This morning at the Sydney Summit we had a very well attended and very
productive session about how to go about keeping a selection of past
releases available and maintained for a longer period of time (LTS).

There was agreement in the room that this could be accomplished by
moving the responsibility for those releases from the Stable Branch
team down to those who are already creating and testing patches for
old releases: The distros, deployers, and operators.

The concept, in general, is to create a new set of cores from these
groups, and use 3rd party CI to validate patches. There are lots of
details to be worked out yet, but our amazing UC (User Committee) will
be begin working out the details.


What is the most worrying is the exact "take over" process. Does it mean that 
the teams will give away the +2 power to a different team? Or will our (small) 
stable teams still be responsible for landing changes? If so, will they have to 
learn how to debug 3rd party CI jobs?


Generally, I'm scared of both overloading the teams and losing the control over 
quality at the same time :) Probably the final proposal will clarify it..




Please take a look at the Etherpad from the session if you'd like to
see the details. More importantly, if you would like to contribute to
this effort, please add your name to the list starting on line 133.

https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases

Thanks to everyone who participated!

Cheers,
Erik

__
OpenStack Development Mailing 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] Upstream LTS Releases

[Samuel Cassiba]

On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick
 wrote:
> Hello Ops folks,
>
> This morning at the Sydney Summit we had a very well attended and very
> productive session about how to go about keeping a selection of past
> releases available and maintained for a longer period of time (LTS).
>
> There was agreement in the room that this could be accomplished by
> moving the responsibility for those releases from the Stable Branch
> team down to those who are already creating and testing patches for
> old releases: The distros, deployers, and operators.
>
> The concept, in general, is to create a new set of cores from these
> groups, and use 3rd party CI to validate patches. There are lots of
> details to be worked out yet, but our amazing UC (User Committee) will
> be begin working out the details.
>
> Please take a look at the Etherpad from the session if you'd like to
> see the details. More importantly, if you would like to contribute to
> this effort, please add your name to the list starting on line 133.
>
> https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases
>
> Thanks to everyone who participated!
>
> Cheers,
> Erik
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

In advance, pardon the defensive tone. I was not in a position to
attend, or even be in Sydney. However, as this comes across the ML, I
can't help but get the impression this effort would be forcing more
work on already stretched teams, ie. deployment-focused development
teams already under a crunch as contributor count continues to decline
in favor of other projects inside and out of OpenStack.

As a friendly reminder, Chef is still actively developed, though we've
not had a great return from recruiting more people. We have about 3.5
active developers, including active cores, and non-cores who felt it
worthwhile to contribute back upstream. There is no major corporate
backer here, but merely a handful of potentially stubborn volunteers.
Nobody is behind the curtain, but Chef OpenStack still have a few
active users (once again, I point to the annual User Survey results)
and contributors. However, we do not use the MLs as a primary
communication means, so I can see how we might be forgotten or
ignored.

In practice, no one likes talking about Chef OpenStack that I've
experienced, neither in the Chef or OpenStack communities. However, as
a maintainer, I keep making it a point to bring it up when it seems
the project gets papered over, or the core team gets signed up for
more work decided in a room half a world away. Admittedly, the whole
deployment method is a hard sell if you're not using Chef in some way.
It has always been my takeaway that the project was merely tolerated
under the OpenStack designation, neither embraced nor even liked, even
being the "official" OpenStack deployment method for a major
deployment toolset. The Foundation's support has been outstanding when
we've needed it, but that's about as far as the delightful goes. The
Chef community is a bit more tolerant of someone using the Chef
moniker for OpenStack, but migrating from Gerrit to GitHub is a major
undertaking that the development team may or may not be able to
reasonably support without more volunteers. Now that the proposition
exists about making a Stable Release liaison derived from existing
cores, I can't help but get the impression that, for active-but-quiet
projects, it'll be yet another PTL responsibility to keep up with, in
addition to the rigors that already come with the role. I'm hoping
I'll be proven wrong here, but I can and do get in trouble for hoping.

-- 
Best,
Samuel Cassiba

__
OpenStack Development Mailing 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] [octavia] amphora fails to send request to members

[Michael Johnson]

Hi Yipei,

I need some more information to help you out.  Can you provide the following?

1. What version of Octavia you are using.
2. "openstack server list" output for the amphora.
3. "openstack loadbalancer show" for the load balancer.
4. "openstack loadbalancer listener show" for the listener.
5. "openstack loadbalancer member list" for the load balancer.
6. "openstack subnet list" showing all of the subnets used by the
lb-mgmt-net, VIP, and the members.
7. "openstack subnet show" for each of the lb-mgmt-net, VIP, and member subnets
8. "ifconfig" from inside the amphora and from inside the netns on the amphora
9. curl command you are using to connect to the VIP
10. "netstat -rn" from the host you are running curl from
11. Inside the amphora, cd /opt/amphora-agent, "git log" cut/paste the
top two commit messages.

That should help us see what your configuration is and narrow down
what is going on.
As always, you can also try to have an interactive session with us in
#openstack-lbaas on IRC. However, with the summit the hours folks are
available to answer questions may be a bit limited this week.

Michael


On Tue, Nov 7, 2017 at 11:32 PM, Yipei Niu  wrote:
> Hi, all,
>
> I created a lb whose vip is 10.0.1.4. When requesting the vip, i cannot
> receive the responses. Hence, I console in the amphora and trace packets
> handled by eth0 in the amphora-haproxy network namespace. The detailed info
> is as follows.
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy tcpdump -i eth1 -nn
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
> ^C07:25:24.225614 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq
> 1637781601, win 28200, options [mss 1410,sackOK,TS val 30692602 ecr
> 0,nop,wscale 7], length 0
> 07:25:24.237854 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:25.224801 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:25.228610 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq 1637781601,
> win 28200, options [mss 1410,sackOK,TS val 30692853 ecr 0,nop,wscale 7],
> length 0
> 07:25:26.224533 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:27.230911 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:27.250858 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq 1637781601,
> win 28200, options [mss 1410,sackOK,TS val 30693359 ecr 0,nop,wscale 7],
> length 0
> 07:25:28.228796 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:29.228697 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:29.290551 ARP, Request who-has 10.0.1.4 tell 10.0.1.2, length 28
> 07:25:29.290985 ARP, Reply 10.0.1.4 is-at fa:16:3e:be:5a:d5, length 28
> 07:25:31.251122 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:32.248737 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:33.250309 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
>
> 14 packets captured
> 14 packets received by filter
> 0 packets dropped by kernel
>
> As shown above, the amphora can receive the requests comes from outside but
> it fails to find 10.0.1.1. As a result, amphora cannot send the request to
> its load balancing member.
>
> To further demonstrate my environment, the route table and arp cache are
> listed as follows.
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy route
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse
> Iface
> default 10.0.1.10.0.0.0 UG0  00 eth1
> 10.0.1.0*   255.255.255.0   U 0  00 eth1
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy arp
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> Address  HWtype  HWaddress   Flags Mask
> Iface
> 10.0.1.2 ether   fa:16:3e:62:68:a8   C
> eth1
> 10.0.1.1 (incomplete)
> eth1
>
> What do you think? Look forward to your comments. Thank you.
>
> Best regards,
> Yipei
>
> __
> OpenStack Development Mailing 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] Nominate akrivoka for tripleo-validations core

[Florian Fuchs]

On Wed, Nov 8, 2017 at 2:26 PM, Martin André  wrote:
> +1 Hooray for Ana
>
> On Wed, Nov 8, 2017 at 1:00 PM, Michele Baldessari  wrote:
>> +1
>>
>> On Wed, Nov 08, 2017 at 12:11:40PM +0100, Jiří Stránský wrote:
>>> +1!
>>>
>>> On 6.11.2017 15:32, Honza Pokorny wrote:
>>> > Hello people,
>>> >
>>> > I would like to nominate Ana Krivokapić (akrivoka) for the core team for
>>> > tripleo-validations.  She has really stepped up her game on that project
>>> > in terms of helpful reviews, and great patches.

+1 I wholeheartedly agree and would have made the nomination myself
had Honza not been quicker. :-)

>>> >
>>> > With Ana's help as a core, we can get more done, and innovate faster.
>>> >
>>> > If there are no objections within a week, we'll proceed with adding Ana
>>> > to the team.
>>> >
>>> > Thanks
>>> >
>>> > Honza Pokorny
>>> >
>>> > __
>>> > OpenStack Development Mailing 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
>>
>> --
>> Michele Baldessari
>> C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] generation of .pem file

[Juan Antonio Osorio]

Hello,

You need to verify the files and check how they look like. A good guide to
do this is this one http://how2ssl.com/articles/working_with_pem_files/ .
.cert and .key are not actual formats, but might actually contain the cert
and the key in PEM format. The main giveaway is that they should contain
the header. If you will use the file for HAProxy, then you need the
certificate and key in the same file. So you would do something like this:

$ cat mycertificate.cert  mykey.key > cert-and-key.pem

And the resulting file is something you could use for your HAProxy
instance. But again, it all depends on what you will use it for.

On Wed, Nov 8, 2017 at 3:36 PM, David Gabriel  wrote:

> Dears,
>
> I need to generate the .pem file based on certifcate files (.cert).
> The key (.key file) is available too.
> All my files can be read as text files.
> Could you please detail the procedure for this ?
> I am using ubuntu as OS.
>
> Thanks in advance.
> Best 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
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] generation of .pem file

[Juan Antonio Osorio]

Hello,

You need to verify the files and check how they look like. A good guide to
do this is this one http://how2ssl.com/articles/working_with_pem_files/ .
.cert and .key are not actual formats, but might actually contain the cert
and the key in PEM format. The main giveaway is that they should contain
the header. If you will use the file for HAProxy, then you need the
certificate and key in the same file. So you would do something like this:

$ cat mycertificate.cert  mykey.key > cert-and-key.pem

And the resulting file is something you could use for your HAProxy
instance. But again, it all depends on what you will use it for.

On Wed, Nov 8, 2017 at 3:36 PM, David Gabriel  wrote:

> Dears,
>
> I need to generate the .pem file based on certifcate files (.cert).
> The key (.key file) is available too.
> All my files can be read as text files.
> Could you please detail the procedure for this ?
> I am using ubuntu as OS.
>
> Thanks in advance.
> Best 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
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Building Openstack Trove Images

[Ritesh Vishwakarma]

Kindly ignore the previous mail, let me try this out with Xenial and get
back to you.

Regards,
Ritesh

On Wed, Nov 8, 2017 at 7:54 PM, Ritesh Vishwakarma <
ritesh.vishwaka...@indusnet.co.in> wrote:

> Hi Amrith,
>
> This time I followed the https://github.com/openstack/trove/tree/master/
> integration/ however, it still throws me the same error. Please find the
> log file attached.
>
>
> Regards,
> Ritesh
>
> On Wed, Nov 8, 2017 at 4:44 PM, Amrith Kumar 
> wrote:
>
>> Please see inline below.
>>
>> -amrith
>>
>>
>> On Wed, Nov 8, 2017 at 9:52 PM, Ritesh Vishwakarma <
>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>
>>>
>>>
>>> Hi Amrith,
>>>
>>>
>>>
>>> Please find my response to your queries below:
>>>
>>>
>>>
>>>
>>>
>>> 1.   What (exact) version of OpenStack are you using? Is it from
>>> upstream or a vendor, if it is the latter, which vendor?
>>>
>>> We are using Openstack Pike installed on CentOS7.
>>>
>>> 2.   What database (exact version) are you trying to create an
>>> image for?
>>>
>>> We want to build images for mysql5.7 as of now.
>>>
>>> 3.   What operating system (exact version) are you attempting to
>>> perform this   on?
>>>
>>> We have tried it from CentOS7 & Ubuntu 14.04.
>>>
>>> 4.   What command(s) are you executing?
>>>
>>> I am step-by-step following the 
>>> *https://github.com/openstack/trove-integration
>>> * and the “./redstack
>>> install” command. Also, I want to confirm that as this code installs its
>>> own devstack cloud, will we be able to use the images created using it
>>> in our Openstack Pike trove environment.
>>>
>>
>>
>> ​The Trove Integration repository is dead and gone for a couple of
>> releases now and you should be using the stuff from the trove repository as
>> the documentation indicates.​
>>
>>
>>
>>> 5.   What exact error(s) are you receiving?
>>>
>>> I have attached the logs.
>>>
>>
>>
>> ​The end of your error log indicates
>>
>> +./stack.sh:main:225   echo 'WARNING: this script
>> has not been tested on trusty'
>> WARNING: this script has not been tested on trusty
>> +./stack.sh:main:226   [[ '' != \y\e\s ]]
>> +./stack.sh:main:227   die 227 'If you wish to run
>> this script anyway run with FORCE=yes'
>> +functions-common:die:187  local exitcode=0
>> +functions-common:die:188  set +o xtrace
>> [Call Trace]
>> ./stack.sh:227:die
>> [ERROR] ./stack.sh:227 If you wish to run this script anyway run with
>> FORCE=yes
>>
>>
>> That seems pretty clear to me. Don't do it, redstack is dead, gone,
>> bye-bye.
>>
>> Use the stuff in trove/integration/scripts
>>
>> The trove-integration repository should now have been deleted as well.​
>>
>>
>>
>>>
>>>
>>>
>>>
>>>   Please guide us where are going wrong on this.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ritesh
>>>
>>>
>>>
>>>Please guide us where are going wrong on this.
>>>
>>> On Wed, Nov 8, 2017 at 12:11 PM, Ritesh Vishwakarma <
>>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>>
 ++Looping my fellow engineer.

 On Wed, Nov 8, 2017 at 2:34 AM, Amrith Kumar 
 wrote:

> Ritesh,
>
> Your answers don't help me understand the problems you are having. So
> let's try this instead.
>
> 1. What (exact) version of OpenStack are you using? Is it from
> upstream or a vendor, if it is the latter, which vendor?
> 2. What database (exact version) are you trying to create an image for?
> 3. What operating system (exact version) are you attempting to perform
> this on?
> 4. What command(s) are you executing?
> 5. What exact error(s) are you receiving?
>
> For #4 and #5 it would be ideal if you just cut/pasted a terminal
> session into an etherpad or gist or pastebuffer or some such thing and
> shared that link via email. If you have passwords and other sensitive
> stuff, make sure you redact it.
>
> Thanks.
>
> -amrith
>
>
>
> On Tue, Nov 7, 2017 at 5:40 PM, Ritesh Vishwakarma <
> ritesh.vishwaka...@indusnet.co.in> wrote:
>
>> Hi Amrith,
>>
>>
>> Many Thanks for your response. Hope you are doing well!
>>
>>
>> The confusing part here is that the OpenStack tutorial page itself
>> not seems to be updated https://docs.openstack.org/tro
>> ve/latest/admin/building_guest_images.html#build-guest-images
>>
>> as the *dib-lint* file is there instead of the mentioned 
>> *disk-image-create
>> *and when executed just verifies the other elements.
>>
>> I have also tried using https://github.com/denismakogo
>> n/trove-guest-image-elements but the error on which I got stuck is
>> “deltarpm not installed” (deltarpm is installed on the host machine).
>> Though yesterday, I came across the https://github.com/openstack/t
>> rove-integration 

Re: [openstack-dev] [tripleo] Nominate akrivoka for tripleo-validations core

[Martin André]

+1 Hooray for Ana

On Wed, Nov 8, 2017 at 1:00 PM, Michele Baldessari  wrote:
> +1
>
> On Wed, Nov 08, 2017 at 12:11:40PM +0100, Jiří Stránský wrote:
>> +1!
>>
>> On 6.11.2017 15:32, Honza Pokorny wrote:
>> > Hello people,
>> >
>> > I would like to nominate Ana Krivokapić (akrivoka) for the core team for
>> > tripleo-validations.  She has really stepped up her game on that project
>> > in terms of helpful reviews, and great patches.
>> >
>> > With Ana's help as a core, we can get more done, and innovate faster.
>> >
>> > If there are no objections within a week, we'll proceed with adding Ana
>> > to the team.
>> >
>> > Thanks
>> >
>> > Honza Pokorny
>> >
>> > __
>> > OpenStack Development Mailing 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
>
> --
> Michele Baldessari
> C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D
>
> __
> OpenStack Development Mailing 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] Building Openstack Trove Images

[Ritesh Vishwakarma]

Hi Amrith,

This time I followed the
https://github.com/openstack/trove/tree/master/integration/ however, it
still throws me the same error. Please find the log file attached.


Regards,
Ritesh

On Wed, Nov 8, 2017 at 4:44 PM, Amrith Kumar  wrote:

> Please see inline below.
>
> -amrith
>
>
> On Wed, Nov 8, 2017 at 9:52 PM, Ritesh Vishwakarma <
> ritesh.vishwaka...@indusnet.co.in> wrote:
>
>>
>>
>> Hi Amrith,
>>
>>
>>
>> Please find my response to your queries below:
>>
>>
>>
>>
>>
>> 1.   What (exact) version of OpenStack are you using? Is it from
>> upstream or a vendor, if it is the latter, which vendor?
>>
>> We are using Openstack Pike installed on CentOS7.
>>
>> 2.   What database (exact version) are you trying to create an image
>> for?
>>
>> We want to build images for mysql5.7 as of now.
>>
>> 3.   What operating system (exact version) are you attempting to
>> perform this   on?
>>
>> We have tried it from CentOS7 & Ubuntu 14.04.
>>
>> 4.   What command(s) are you executing?
>>
>> I am step-by-step following the 
>> *https://github.com/openstack/trove-integration
>> * and the “./redstack
>> install” command. Also, I want to confirm that as this code installs its
>> own devstack cloud, will we be able to use the images created using it
>> in our Openstack Pike trove environment.
>>
>
>
> ​The Trove Integration repository is dead and gone for a couple of
> releases now and you should be using the stuff from the trove repository as
> the documentation indicates.​
>
>
>
>> 5.   What exact error(s) are you receiving?
>>
>> I have attached the logs.
>>
>
>
> ​The end of your error log indicates
>
> +./stack.sh:main:225   echo 'WARNING: this script has
> not been tested on trusty'
> WARNING: this script has not been tested on trusty
> +./stack.sh:main:226   [[ '' != \y\e\s ]]
> +./stack.sh:main:227   die 227 'If you wish to run
> this script anyway run with FORCE=yes'
> +functions-common:die:187  local exitcode=0
> +functions-common:die:188  set +o xtrace
> [Call Trace]
> ./stack.sh:227:die
> [ERROR] ./stack.sh:227 If you wish to run this script anyway run with
> FORCE=yes
>
>
> That seems pretty clear to me. Don't do it, redstack is dead, gone,
> bye-bye.
>
> Use the stuff in trove/integration/scripts
>
> The trove-integration repository should now have been deleted as well.​
>
>
>
>>
>>
>>
>>
>>   Please guide us where are going wrong on this.
>>
>>
>>
>> Regards,
>>
>> Ritesh
>>
>>
>>
>>Please guide us where are going wrong on this.
>>
>> On Wed, Nov 8, 2017 at 12:11 PM, Ritesh Vishwakarma <
>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>
>>> ++Looping my fellow engineer.
>>>
>>> On Wed, Nov 8, 2017 at 2:34 AM, Amrith Kumar 
>>> wrote:
>>>
 Ritesh,

 Your answers don't help me understand the problems you are having. So
 let's try this instead.

 1. What (exact) version of OpenStack are you using? Is it from upstream
 or a vendor, if it is the latter, which vendor?
 2. What database (exact version) are you trying to create an image for?
 3. What operating system (exact version) are you attempting to perform
 this on?
 4. What command(s) are you executing?
 5. What exact error(s) are you receiving?

 For #4 and #5 it would be ideal if you just cut/pasted a terminal
 session into an etherpad or gist or pastebuffer or some such thing and
 shared that link via email. If you have passwords and other sensitive
 stuff, make sure you redact it.

 Thanks.

 -amrith



 On Tue, Nov 7, 2017 at 5:40 PM, Ritesh Vishwakarma <
 ritesh.vishwaka...@indusnet.co.in> wrote:

> Hi Amrith,
>
>
> Many Thanks for your response. Hope you are doing well!
>
>
> The confusing part here is that the OpenStack tutorial page itself not
> seems to be updated https://docs.openstack.org/tro
> ve/latest/admin/building_guest_images.html#build-guest-images
>
> as the *dib-lint* file is there instead of the mentioned 
> *disk-image-create
> *and when executed just verifies the other elements.
>
> I have also tried using https://github.com/denismakogo
> n/trove-guest-image-elements but the error on which I got stuck is
> “deltarpm not installed” (deltarpm is installed on the host machine).
> Though yesterday, I came across the https://github.com/openstack/t
> rove-integration which I am going to try out today, kindly let me
> know if it is the right one or please share any relevant reference on 
> which
> we can work.
>
>
>
> Regards,
>
> Ritesh
>
> On Tue, Nov 7, 2017 at 8:16 AM, Amrith Kumar 
> wrote:
>
>> Ha, it isn't often that I get called out by name in a mailing 

Re: [openstack-dev] generation of .pem file

[Juan Antonio Osorio]

Hello,

You need to verify the files and check how they look like. A good guide to
do this is this one http://how2ssl.com/articles/working_with_pem_files/ .
.cert and .key are not actual formats, but might actually contain the cert
and the key in PEM format. The main giveaway is that they should contain
the header. If you will use the file for HAProxy, then you need the
certificate and key in the same file. So you would do something like this:

$ cat mycertificate.cert  mykey.key > cert-and-key.pem

And the resulting file is something you could use for your HAProxy
instance. But again, it all depends on what you will use it for.

On Wed, Nov 8, 2017 at 3:36 PM, David Gabriel  wrote:

> Dears,
>
> I need to generate the .pem file based on certifcate files (.cert).
> The key (.key file) is available too.
> All my files can be read as text files.
> Could you please detail the procedure for this ?
> I am using ubuntu as OS.
>
> Thanks in advance.
> Best 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
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] generation of .pem file

[David Gabriel]

Dears,

I need to generate the .pem file based on certifcate files (.cert).
The key (.key file) is available too.
All my files can be read as text files.
Could you please detail the procedure for this ?
I am using ubuntu as OS.

Thanks in advance.
Best 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-dev] [heat] Meaning of "updated" in stack update preview / --dry-run?

[James Wettenhall]

Hi,

I have some stacks created by heat which I want to update.

I download the current template with "heat template-show".

Then before modifying the template, I try running "heat stack-update" with
"--dry-run" to see what will be changed (if anything).

Sometimes, I see some resources (VMs) listed as "updated" in the stack
update preview, even though I haven't yet modified the template.

It's not obvious to me how to find out more about what will be "updated",
and without knowing, I'm a little nervous about performing the update on a
production stack.

When I run the stack update on a test stack, it seems to run fine, and I
don't notice any changes applied to the resources (VMs) which would
supposedly be "updated".  Then subsequent stack update previews on the test
stack don't show that any resources will be updated - the unexpected
"updated" status only appears once, until I go ahead and run "heat
stack-update" without --dry-run.

Is the unexpected "updated" status of these VM resources likely to have
been caused by a change made by my OpenStack administrators e.g. upgrading
their OpenStack version?

Should I stop worrying about the "updated" status of these resources in the
stack update preview, and just assume that if the stack update works on my
test stack with no unintended side effects as far as I can tell, then it
should work on production?

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

Re: [openstack-dev] [TripleO] Next steps for pre-deployment workflows (e.g derive parameters)

[James Slagle]

On Wed, Nov 8, 2017 at 12:09 AM, Steven Hardy  wrote:
> Hi all,
>
> Today I had a productive hallway discussion with jtomasek and
> stevebaker re $subject, so I wanted to elaborate here for the benefit
> of those folks not present.  Hopefully we can get feedback on the
> ideas and see if it makes sense to continue and work on some patches:
>
> The problem under discussion is how do we run pre-deployment workflows
> (such as those integrated recently to calculate derived parameters,
> and in future perhaps also those which download container images etc),
> and in particular how do we make these discoverable via the UI
> (including any input parameters).
>
> The idea we came up with has two parts:
>
> 1. Add a new optional section to roles_data for services that require
> pre-deploy workflows
>
> E.g something like this:
>
>  pre_deploy_workflows:
> - derive_params:
>   workflow_name:
> tripleo.derive_params_formulas.v1.dpdk_derive_params
>   inputs:
>   ...
>
> This would allow us to associate a specific mistral workflow with a
> given service template, and also work around the fact that currently
> mistral inputs don't have any schema (only key/value input) as we
> could encode the required type and any constraints in the inputs block
> (clearly this could be removed in future should typed parameters
> become available in mistral).
>
> 2. Add a new workflow that calculates the enabled services and returns
> all pre_deploy_workflows
>
> This would take all enabled environments, then use heat to validate
> the configuration and return the merged resource registry (which will
> require https://review.openstack.org/#/c/509760/), then we would
> iterate over all enabled services in the registry and extract a given
> roles_data key (e.g pre_deploy_workflows)
>
> The result of the workflow would be a list of all pre_deploy_workflows
> for all enabled services, which the UI could then use to run the
> workflows as part of the pre-deploy process.
>
> If this makes sense I can go ahead and push some patches so we can
> iterate on the implementation?

Instead of using mistral to express the pre_deploy workflows could we
just use pure ansible tasks/playbooks? We already use pure ansible for
upgrade and deploy, it seems disjointed to then require Mistral for
pre-deploy.

I think we should continue to move in the direction that the output
from Heat is ansible, which can then be driven via either Mistral or
ad-hoc via ansible-playbook. That pattern is more aligned with the
existing work around config-download as well. So, we would have a
Mistral workflow that automates what you describe above, *except* for
the detail that pre_deploy_workflows becomes either pre_deploy_tasks
or pre_deploy_playbooks, and the output of the Heat validation step is
pure ansible.

From the UI's perspective, whether the output from Heat is pure
ansible or mistral workflows should be an implementation detail hidden
behind a higher level mistral workflow that automates the full
"generation" of all pre_deploy stuff.

Also keep in mind Emilien's proposal to switch all scenario testing to
be driven via undercloud deploy. In that environment, there is no
Mistral, and everything is driven via config-download. What you're
proposing (unless I misunderstand) creates a tight coupling between
the Heat/Mistral ordering and requires one to use Mistral as part of
the deployment. Right now, we have no such requirement, and are able
to drive a deployment with only an ephemeral Heat and
ansible-playbook, which is the basis of how undercloud deploy works.

-- 
-- James Slagle
--

__
OpenStack Development Mailing 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] Nominate akrivoka for tripleo-validations core

[Michele Baldessari]

+1

On Wed, Nov 08, 2017 at 12:11:40PM +0100, Jiří Stránský wrote:
> +1!
> 
> On 6.11.2017 15:32, Honza Pokorny wrote:
> > Hello people,
> > 
> > I would like to nominate Ana Krivokapić (akrivoka) for the core team for
> > tripleo-validations.  She has really stepped up her game on that project
> > in terms of helpful reviews, and great patches.
> > 
> > With Ana's help as a core, we can get more done, and innovate faster.
> > 
> > If there are no objections within a week, we'll proceed with adding Ana
> > to the team.
> > 
> > Thanks
> > 
> > Honza Pokorny
> > 
> > __
> > OpenStack Development Mailing 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

-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

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

[openstack-dev] [FEMDC] No Meeting today

[lebre . adrien]

Dear all, 

Due to the summit event, our next meeting will be held on Nov, the 22nd. 

Cheers
ad_rien_

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

Re: [openstack-dev] [tripleo]

[Jiří Stránský]

On 7.11.2017 23:29, Wesley Hayutin wrote:

Greetings,

I'd like to propose we remove the upgrade jobs that are consistently
failing from the upstream infrastructure and instead focus our efforts in
RDO Software Factory.

The jobs listed in https://review.openstack.org/#/c/518405/ are
consistently failing after being reviewed by myself and Mathieu.  I am
leaving legacy-tripleo-ci-centos-7-multinode-upgrades in place as it's
passing with an overall rate of 87%.

It doesn't make any sense to continue to tax upstream resources on failing
jobs, lets get the jobs running correctly and consistently in rdo software
factory before moving these back to our mainline CI.


I think the most useful job being removed is 
containers-multinode-upgrades, and that one i already see coming back 
green from RDO CI as green (not experimental anymore). So +1 on the removal.




Please let me know what you think of the proposal.
Thanks

The upgrade job configuration for upgrades can be found in [1]
[1]
https://github.com/rdo-infra/review.rdoproject.org-config/blob/master/jobs/tripleo-upstream.yml



__
OpenStack Development Mailing 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] Building Openstack Trove Images

[Amrith Kumar]

Please see inline below.

-amrith


On Wed, Nov 8, 2017 at 9:52 PM, Ritesh Vishwakarma <
ritesh.vishwaka...@indusnet.co.in> wrote:

>
>
> Hi Amrith,
>
>
>
> Please find my response to your queries below:
>
>
>
>
>
> 1.   What (exact) version of OpenStack are you using? Is it from
> upstream or a vendor, if it is the latter, which vendor?
>
> We are using Openstack Pike installed on CentOS7.
>
> 2.   What database (exact version) are you trying to create an image
> for?
>
> We want to build images for mysql5.7 as of now.
>
> 3.   What operating system (exact version) are you attempting to
> perform this   on?
>
> We have tried it from CentOS7 & Ubuntu 14.04.
>
> 4.   What command(s) are you executing?
>
> I am step-by-step following the 
> *https://github.com/openstack/trove-integration
> * and the “./redstack
> install” command. Also, I want to confirm that as this code installs its
> own devstack cloud, will we be able to use the images created using it in
> our Openstack Pike trove environment.
>


​The Trove Integration repository is dead and gone for a couple of releases
now and you should be using the stuff from the trove repository as the
documentation indicates.​



> 5.   What exact error(s) are you receiving?
>
> I have attached the logs.
>


​The end of your error log indicates

+./stack.sh:main:225   echo 'WARNING: this script has
not been tested on trusty'
WARNING: this script has not been tested on trusty
+./stack.sh:main:226   [[ '' != \y\e\s ]]
+./stack.sh:main:227   die 227 'If you wish to run this
script anyway run with FORCE=yes'
+functions-common:die:187  local exitcode=0
+functions-common:die:188  set +o xtrace
[Call Trace]
./stack.sh:227:die
[ERROR] ./stack.sh:227 If you wish to run this script anyway run with
FORCE=yes


That seems pretty clear to me. Don't do it, redstack is dead, gone, bye-bye.

Use the stuff in trove/integration/scripts

The trove-integration repository should now have been deleted as well.​



>
>
>
>
>   Please guide us where are going wrong on this.
>
>
>
> Regards,
>
> Ritesh
>
>
>
>Please guide us where are going wrong on this.
>
> On Wed, Nov 8, 2017 at 12:11 PM, Ritesh Vishwakarma <
> ritesh.vishwaka...@indusnet.co.in> wrote:
>
>> ++Looping my fellow engineer.
>>
>> On Wed, Nov 8, 2017 at 2:34 AM, Amrith Kumar 
>> wrote:
>>
>>> Ritesh,
>>>
>>> Your answers don't help me understand the problems you are having. So
>>> let's try this instead.
>>>
>>> 1. What (exact) version of OpenStack are you using? Is it from upstream
>>> or a vendor, if it is the latter, which vendor?
>>> 2. What database (exact version) are you trying to create an image for?
>>> 3. What operating system (exact version) are you attempting to perform
>>> this on?
>>> 4. What command(s) are you executing?
>>> 5. What exact error(s) are you receiving?
>>>
>>> For #4 and #5 it would be ideal if you just cut/pasted a terminal
>>> session into an etherpad or gist or pastebuffer or some such thing and
>>> shared that link via email. If you have passwords and other sensitive
>>> stuff, make sure you redact it.
>>>
>>> Thanks.
>>>
>>> -amrith
>>>
>>>
>>>
>>> On Tue, Nov 7, 2017 at 5:40 PM, Ritesh Vishwakarma <
>>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>>
 Hi Amrith,


 Many Thanks for your response. Hope you are doing well!


 The confusing part here is that the OpenStack tutorial page itself not
 seems to be updated https://docs.openstack.org/tro
 ve/latest/admin/building_guest_images.html#build-guest-images

 as the *dib-lint* file is there instead of the mentioned *disk-image-create
 *and when executed just verifies the other elements.

 I have also tried using https://github.com/denismakogo
 n/trove-guest-image-elements but the error on which I got stuck is
 “deltarpm not installed” (deltarpm is installed on the host machine).
 Though yesterday, I came across the https://github.com/openstack/t
 rove-integration which I am going to try out today, kindly let me know
 if it is the right one or please share any relevant reference on which we
 can work.



 Regards,

 Ritesh

 On Tue, Nov 7, 2017 at 8:16 AM, Amrith Kumar 
 wrote:

> Ha, it isn't often that I get called out by name in a mailing list
> thread.
>
> What are the issues that you are facing? Currently there are complete
> notes about how to build guest images but the issues you may be facing may
> not relate to the images you are building.
>
> So please provide some more details so I can give you a more accurate
> reply.
> ​
> ​Thanks,​
>
>
> -amrith
>
>
> On Mon, Nov 6, 2017 at 6:09 PM, Ritesh Vishwakarma <
> 

Re: [openstack-dev] [tripleo] Nominate akrivoka for tripleo-validations core

[Jiří Stránský]

+1!

On 6.11.2017 15:32, Honza Pokorny wrote:

Hello people,

I would like to nominate Ana Krivokapić (akrivoka) for the core team for
tripleo-validations.  She has really stepped up her game on that project
in terms of helpful reviews, and great patches.

With Ana's help as a core, we can get more done, and innovate faster.

If there are no objections within a week, we'll proceed with adding Ana
to the team.

Thanks

Honza Pokorny

__
OpenStack Development Mailing 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] Building Openstack Trove Images

[Ritesh Vishwakarma]

Hi Amrith,



Please find my response to your queries below:





1.   What (exact) version of OpenStack are you using? Is it from
upstream or a vendor, if it is the latter, which vendor?

We are using Openstack Pike installed on CentOS7.

2.   What database (exact version) are you trying to create an image
for?

We want to build images for mysql5.7 as of now.

3.   What operating system (exact version) are you attempting to
perform this   on?

We have tried it from CentOS7 & Ubuntu 14.04.

4.   What command(s) are you executing?

I am step-by-step following the *https://github.com/openstack/trove-integration
* and the “./redstack
install” command. Also, I want to confirm that as this code installs its
own devstack cloud, will we be able to use the images created using it in
our Openstack Pike trove environment.

5.   What exact error(s) are you receiving?

I have attached the logs.





  Please guide us where are going wrong on this.



Regards,

Ritesh



   Please guide us where are going wrong on this.

On Wed, Nov 8, 2017 at 12:11 PM, Ritesh Vishwakarma <
ritesh.vishwaka...@indusnet.co.in> wrote:

> ++Looping my fellow engineer.
>
> On Wed, Nov 8, 2017 at 2:34 AM, Amrith Kumar 
> wrote:
>
>> Ritesh,
>>
>> Your answers don't help me understand the problems you are having. So
>> let's try this instead.
>>
>> 1. What (exact) version of OpenStack are you using? Is it from upstream
>> or a vendor, if it is the latter, which vendor?
>> 2. What database (exact version) are you trying to create an image for?
>> 3. What operating system (exact version) are you attempting to perform
>> this on?
>> 4. What command(s) are you executing?
>> 5. What exact error(s) are you receiving?
>>
>> For #4 and #5 it would be ideal if you just cut/pasted a terminal session
>> into an etherpad or gist or pastebuffer or some such thing and shared that
>> link via email. If you have passwords and other sensitive stuff, make sure
>> you redact it.
>>
>> Thanks.
>>
>> -amrith
>>
>>
>>
>> On Tue, Nov 7, 2017 at 5:40 PM, Ritesh Vishwakarma <
>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>
>>> Hi Amrith,
>>>
>>>
>>> Many Thanks for your response. Hope you are doing well!
>>>
>>>
>>> The confusing part here is that the OpenStack tutorial page itself not
>>> seems to be updated https://docs.openstack.org/tro
>>> ve/latest/admin/building_guest_images.html#build-guest-images
>>>
>>> as the *dib-lint* file is there instead of the mentioned *disk-image-create
>>> *and when executed just verifies the other elements.
>>>
>>> I have also tried using https://github.com/denismakogo
>>> n/trove-guest-image-elements but the error on which I got stuck is
>>> “deltarpm not installed” (deltarpm is installed on the host machine).
>>> Though yesterday, I came across the https://github.com/openstack/t
>>> rove-integration which I am going to try out today, kindly let me know
>>> if it is the right one or please share any relevant reference on which we
>>> can work.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ritesh
>>>
>>> On Tue, Nov 7, 2017 at 8:16 AM, Amrith Kumar 
>>> wrote:
>>>
 Ha, it isn't often that I get called out by name in a mailing list
 thread.

 What are the issues that you are facing? Currently there are complete
 notes about how to build guest images but the issues you may be facing may
 not relate to the images you are building.

 So please provide some more details so I can give you a more accurate
 reply.
 ​
 ​Thanks,​


 -amrith


 On Mon, Nov 6, 2017 at 6:09 PM, Ritesh Vishwakarma <
 ritesh.vishwaka...@indusnet.co.in> wrote:

> Hi Team,
>
> We have installed Openstack Pike in our campus but despite of numerous
> attempts we are just unable to build trove images that we can use to 
> launch
> database instances.We also came across a mail thread where Mr. Amrith
> updates that some review & update of the OpenStack Trove documents was
> going on, kindly provide us some reference document or link which we can
> follow.
>
> https://lists.gt.net/openstack/dev/58182
>
> We will be eagerly waiting for your response.
>
>
>
> Thanks  & Regards,
> Ritesh Vishwakarma
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.op
> enstack.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.op
 enstack.org?subject:unsubscribe
 

Re: [openstack-dev] [TripleO] Next steps for pre-deployment workflows (e.g derive parameters)

[Saravanan KR]

Thanks Steven for the update.

Current CLI flow:
--
* User need to add -p parameter for the overcloud deploy command with
workflows to be invoked [1]
* Plan will update updated to the swift container
* Derived parameters workflow is initiated
- For each role
* Get the introspection data of first node assigned to the role
* Find the list features based on the services or parameters
* If dpdk present, run dpdk formulas workflow
* if sriov is present, run sriov formulas workfow (under development)
* if sriov or dpdk is present, run host formulas workflow
* if hci present, run hci formulas workflow

Here the order of the formulas workflow invocation is important. For
example,  in Compute-DPDK-HCI role, HCI formulas should exclude the
CPUs allocated for DPDK PMD threads, while calculating cpu allocation
ratio.

I am trying to understand the proposed changes. Is it for assisting UI
only or changing the existing CLI flow too? If the idea is to invoke
the individual formulas workflow, it will not be possible with
existing implementation, need to be re-worked. We need to introduce
order for formulas workflow and direct fetching and merging of derived
parameters in plan.

As per earlier discussion jtomasek, to invoke derived parameters
workflow (existing) for a plan, UI requires following information:
* Whether derived parameters should be invoked for this deployment
(based on roles and enabled services)
* If yes, list of parameters, its types, and its default values (and
choices if present), are required

Did I miss anything?

Regards,
Saravanan KR

[1] 
https://github.com/openstack/tripleo-heat-templates/blob/master/plan-samples/plan-environment-derived-params.yaml

On Wed, Nov 8, 2017 at 2:39 PM, Bogdan Dobrelya  wrote:
> On 11/8/17 6:09 AM, Steven Hardy wrote:
>>
>> Hi all,
>>
>> Today I had a productive hallway discussion with jtomasek and
>> stevebaker re $subject, so I wanted to elaborate here for the benefit
>> of those folks not present.  Hopefully we can get feedback on the
>> ideas and see if it makes sense to continue and work on some patches:
>>
>> The problem under discussion is how do we run pre-deployment workflows
>> (such as those integrated recently to calculate derived parameters,
>> and in future perhaps also those which download container images etc),
>> and in particular how do we make these discoverable via the UI
>> (including any input parameters).
>>
>> The idea we came up with has two parts:
>>
>> 1. Add a new optional section to roles_data for services that require
>> pre-deploy workflows
>>
>> E.g something like this:
>>
>>   pre_deploy_workflows:
>>  - derive_params:
>>workflow_name:
>> tripleo.derive_params_formulas.v1.dpdk_derive_params
>>inputs:
>>...
>>
>> This would allow us to associate a specific mistral workflow with a
>> given service template, and also work around the fact that currently
>> mistral inputs don't have any schema (only key/value input) as we
>> could encode the required type and any constraints in the inputs block
>> (clearly this could be removed in future should typed parameters
>> become available in mistral).
>>
>> 2. Add a new workflow that calculates the enabled services and returns
>> all pre_deploy_workflows
>>
>> This would take all enabled environments, then use heat to validate
>> the configuration and return the merged resource registry (which will
>> require https://review.openstack.org/#/c/509760/), then we would
>> iterate over all enabled services in the registry and extract a given
>> roles_data key (e.g pre_deploy_workflows)
>>
>> The result of the workflow would be a list of all pre_deploy_workflows
>> for all enabled services, which the UI could then use to run the
>> workflows as part of the pre-deploy process.
>>
>> If this makes sense I can go ahead and push some patches so we can
>> iterate on the implementation?
>
>
> I apologise for a generic/non-techy comment: it would be nice to keep
> required workflows near the services' definition templates, to keep it as
> much self-contained as possible. IIUC, that's covered by #1.
> For future steps, I'd like to see all of the "bulk processing" to sit in
> those templates as well.
>
>>
>> Thanks,
>>
>> Steve
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
>
> __
> OpenStack Development Mailing 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] [octavia] how to recreate amphora instances

[mihaela.balas]

I am also interested how to fix this. If you can describe shortly the procedure.

Thanks,
Mihaela

-Original Message-
From: Michael Johnson [mailto:johnso...@gmail.com] 
Sent: Monday, November 06, 2017 6:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [octavia] how to recreate amphora instances

I think we helped you get going again in the IRC channel.  Please ping us again 
in the IRC channel if you need more assistance.

Michael

On Thu, Nov 2, 2017 at 4:42 AM, Kim-Norman Sahm  
wrote:
> Hi,
>
> after a rabbitmq problem octavia has removed all amphora instances.
> the loadbalancers are in provisioning_status "ACTIVE"
>
> ~$ neutron lbaas-loadbalancer-list
> neutron CLI is deprecated and will be removed in the future. Use 
> openstack CLI instead.
> | 07b41df6-bb75-4502-975a-20140b0832dd | Load Balancer
> 4   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.18   | ACTIVE  | octavia  |
> | 25664be7-15cb-426b-ad09-6102afb62b14 | Load Balancer
> 2   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.7| ACTIVE  | octavia  |
> | 927eb754-7c52-4060-b130-1f5e82d92555 | Load Balancer
> 6   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.17   | ACTIVE  | octavia  |
> | b4d93c68-89d6-4e4f-b06c-117d4ea933fa | Load Balancer
> 5   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.24   | ACTIVE  | octavia  |
> | d7699f8d-2106-42d6-8797-5feb72de6e2e | Load Balancer
> 1   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.5| ACTIVE  | octavia  |
> | dd6114ae-21e9-41bd-b155-325287aed420 | Load Balancer
> 3   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.23   | ACTIVE  | octavia  |
>
> How can we trigger octavia to rebuild the amphore instances?
> I've tried to restart the octavia services but it didn't solved the 
> problem.
>
> Best regards
> Kim
>
>
> Kim-Norman Sahm
> Cloud & Infrastructure(OCI)
> noris network AG
> Thomas-Mann-Straße 16-20
> 90471 Nürnberg
> Deutschland
> Tel +49 911 9352 1433
> Fax +49 911 9352 100
>
> kim-norman.s...@noris.de
> https://www.noris.de - Mehr Leistung als Standard
> Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel Vorsitzender des 
> Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
>
>
>
>
>
> __
>  OpenStack Development Mailing 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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
OpenStack Development Mailing 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] Nominate akrivoka for tripleo-validations core

[Julie Pichon]

On 6 November 2017 at 14:32, Honza Pokorny  wrote:
> I would like to nominate Ana Krivokapić (akrivoka) for the core team for
> tripleo-validations.  She has really stepped up her game on that project
> in terms of helpful reviews, and great patches.

+1

__
OpenStack Development Mailing 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] [Octavia] networking issues

[Volodymyr Litovka]

Please, disregard this message - I've found that part of networking 
resides in namespace.


On 11/7/17 5:54 PM, Volodymyr Litovka wrote:

Dear colleagues,

while trying to setup Octavia, I faced the problem of connecting 
amphora agent to VIP network.


*Environment:
*Octavia 1.0.1 (installed by using "pip install")
Openstack Pike:
- Nova 16.0.1
- Neutron 11.0.1
- Keystone 12.0.0

*Topology of testbed:*

    +
    |
    |    ++
    +   ++ n1 |
    |    +-+    |    ++
    ++ Amphora ++
    |    +-+    |    ++
  m | l ++ n2 |
  g | b |    ++    + e
  m | t |  | x
  t |   |    ++    | t
    | s ++ vR ++ e
    | u |    ++    | r
   ++ b |  | n
   | Controller | n |  | a
   ++ e |  + l
  t |
    +

*Summary:*

$ openstack loadbalancer create --name nlb2 --vip-subnet-id lbt-subnet
$ openstack loadbalancer list
+--+--+--+-+-+--+
| id   | name | 
project_id   | vip_address | provisioning_status | 
provider |

+--+--+--+-+-+--+
| 93facca0-d39a-44e0-96b6-28efc1388c2d | nlb2 | 
d8051a3ff3ad4c4bb380f828992b8178 | 1.1.1.16    | ACTIVE  | 
octavia  |

+--+--+--+-+-+--+
$ openstack server list --all
+--+--++-+-++
| ID   | 
Name | Status | 
Networks    | Image   | Flavor |

+--+--++-+-++
| 98ae591b-0270-4625-95eb-a557c1452eef | 
amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab | ACTIVE | 
lb-mgmt-net=172.16.252.28; lbt-net=1.1.1.11 | amphora |    |
| cc79ca78-b036-4d55-a4bd-5b3803ed2f9b | 
lb-n1    | ACTIVE | 
lbt-net=1.1.1.18    | | B-cup  |
| 6c43ccca-c808-44cf-974d-acdbdb4b26db | 
lb-n2    | ACTIVE | 
lbt-net=1.1.1.19    | | B-cup  |

+--+--++-+-++

This output shows that amphora agent is active with two interfaces, 
connected to management and project's networks (lb-mgmt-net and 
lbt-net respectively). BUT in fact there is no interface to lbt-net on 
the agent's VM:


*ubuntu@amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab:~$* ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1

[ ... ]
2: eth0:  mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000

    link/ether d0:1c:a0:58:e0:02 brd ff:ff:ff:ff:ff:ff
    inet 172.16.252.28/22 brd 172.16.255.255 scope global eth0
*ubuntu@amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab:~$* ls 
/sys/class/net/

_eth0_ _lo_
*ubuntu@amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab:~$*

The issue is that eth1 exists during start of agent's VM and then it 
magically disappears (snipped from syslog, note timing):


Nov  7 12:00:31 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1051]: DHCPREQUEST of 1.1.1.11 on eth1 to 255.255.255.255 
port 67 (xid=0x1c65db9b)
Nov  7 12:00:31 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1051]: DHCPOFFER of 1.1.1.11 from 1.1.1.10
Nov  7 12:00:31 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1051]: DHCPACK of 1.1.1.11 from 1.1.1.10
Nov  7 12:00:31 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1051]: bound to 1.1.1.11 -- renewal in 38793 seconds.

[ ... ]
Nov  7 12:00:44 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1116]: receive_packet failed on eth1: Network is down
Nov  7 12:00:44 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
systemd[1]: Stopping ifup for eth1...
Nov  7 12:00:44 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1715]: Killed old client process
Nov  7 12:00:45 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1715]: Error getting hardware address for "eth1": No such device
Nov  7 12:00:45 

Re: [openstack-dev] [TripleO] Next steps for pre-deployment workflows (e.g derive parameters)

[Bogdan Dobrelya]

On 11/8/17 6:09 AM, Steven Hardy wrote:

Hi all,

Today I had a productive hallway discussion with jtomasek and
stevebaker re $subject, so I wanted to elaborate here for the benefit
of those folks not present.  Hopefully we can get feedback on the
ideas and see if it makes sense to continue and work on some patches:

The problem under discussion is how do we run pre-deployment workflows
(such as those integrated recently to calculate derived parameters,
and in future perhaps also those which download container images etc),
and in particular how do we make these discoverable via the UI
(including any input parameters).

The idea we came up with has two parts:

1. Add a new optional section to roles_data for services that require
pre-deploy workflows

E.g something like this:

  pre_deploy_workflows:
 - derive_params:
   workflow_name:
tripleo.derive_params_formulas.v1.dpdk_derive_params
   inputs:
   ...

This would allow us to associate a specific mistral workflow with a
given service template, and also work around the fact that currently
mistral inputs don't have any schema (only key/value input) as we
could encode the required type and any constraints in the inputs block
(clearly this could be removed in future should typed parameters
become available in mistral).

2. Add a new workflow that calculates the enabled services and returns
all pre_deploy_workflows

This would take all enabled environments, then use heat to validate
the configuration and return the merged resource registry (which will
require https://review.openstack.org/#/c/509760/), then we would
iterate over all enabled services in the registry and extract a given
roles_data key (e.g pre_deploy_workflows)

The result of the workflow would be a list of all pre_deploy_workflows
for all enabled services, which the UI could then use to run the
workflows as part of the pre-deploy process.

If this makes sense I can go ahead and push some patches so we can
iterate on the implementation?


I apologise for a generic/non-techy comment: it would be nice to keep 
required workflows near the services' definition templates, to keep it 
as much self-contained as possible. IIUC, that's covered by #1.
For future steps, I'd like to see all of the "bulk processing" to sit in 
those templates as well.




Thanks,

Steve

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




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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] [acceleration] Cyborg Weekly Team Meeting 2017.11.08

[Zhipeng Huang]

Hi Team,

We will have our regular team meeting on #openstack-cyborg starting UTC1500
as usual. Agenda is at
https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting

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