Re: [openstack-dev] [Openstack-sigs] [all] Naming the T release of OpenStack

2018-10-18 Thread Remo Mattei 
Michal, that will never work it’s 11 characters long


 

> On Oct 18, 2018, at 09:43, Eric Fried  wrote:
> 
> Sorry, I'm opposed to this idea.
> 
> I admit I don't understand the political framework, nor have I read the
> governing documents beyond [1], but that document makes it clear that
> this is supposed to be a community-wide vote.  Is it really legal for
> the TC (or whoever has merge rights on [2]) to merge a patch that gives
> that same body the power to take the decision out of the hands of the
> community? So it's really an oligarchy that gives its constituency the
> illusion of democracy until something comes up that it feels like not
> having a vote on? The fact that it's something relatively "unimportant"
> (this time) is not a comfort.
> 
> Not that I think the TC would necessarily move forward with [2] in the
> face of substantial opposition from non-TC "cores" or whatever.
> 
> I will vote enthusiastically for "Train". But a vote it should be.
> 
> -efried
> 
> [1] https://governance.openstack.org/tc/reference/release-naming.html 
> 
> [2] https://review.openstack.org/#/c/611511/ 
> 
> 
> On 10/18/2018 10:52 AM, arkady.kanev...@dell.com 
>  wrote:
>> +1 for the poll.
>> 
>> Let’s follow well established process.
>> 
>> If we want to add Train as one of the options for the name I am OK with it.
>> 
>>  
>> 
>> *From:* Jonathan Mills 
>> *Sent:* Thursday, October 18, 2018 10:49 AM
>> *To:* openstack-s...@lists.openstack.org
>> *Subject:* Re: [Openstack-sigs] [all] Naming the T release of OpenStack
>> 
>>  
>> 
>> [EXTERNAL EMAIL]
>> Please report any suspicious attachments, links, or requests for
>> sensitive information.
>> 
>> +1 for just having a poll
>> 
>>  
>> 
>> On Thu, Oct 18, 2018 at 11:39 AM David Medberry > >> wrote:
>> 
>>I'm fine with Train but I'm also fine with just adding it to the
>>list and voting on it. It will win.
>> 
>> 
>> 
>>Also, for those not familiar with the debian/ubuntu command "sl",
>>now is the time to become so.
>> 
>> 
>> 
>>apt install sl
>> 
>>sl -Flea #ftw
>> 
>> 
>> 
>>On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds
>>mailto:t...@bakeyournoodle.com> 
>> >> wrote:
>> 
>>Hello all,
>>As per [1] the nomination period for names for the T release
>>have
>>now closed (actually 3 days ago sorry).  The nominated names and any
>>qualifying remarks can be seen at2].
>> 
>>Proposed Names
>> * Tarryall
>> * Teakettle
>> * Teller
>> * Telluride
>> * Thomas
>> * Thornton
>> * Tiger
>> * Tincup
>> * Timnath
>> * Timber
>> * Tiny Town
>> * Torreys
>> * Trail
>> * Trinidad
>> * Treasure
>> * Troublesome
>> * Trussville
>> * Turret
>> * Tyrone
>> 
>>Proposed Names that do not meet the criteria
>> * Train
>> 
>>However I'd like to suggest we skip the CIVS poll and select
>>'Train' as
>>the release name by TC resolution[3].  My think for this is
>> 
>> * It's fun and celebrates a humorous moment in our community
>> * As a developer I've heard the T release called Train for quite
>>   sometime, and was used often at the PTG[4].
>> * As the *next* PTG is also in Colorado we can still choose a
>>   geographic based name for U[5]
>> * If train causes a problem for trademark reasons then we can
>>always
>>   run the poll
>> 
>>I'll leave[3] for marked -W for a week for discussion to happen
>>before the
>>TC can consider / vote on it.
>> 
>>Yours Tony.
>> 
>>[1]
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
>>[2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
>>[3]
>>
>> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
>>[4] https://twitter.com/vkmc/status/1040321043959754752
>>[5]
>>https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z 
>> 
>>
>> > >
>>___
>>openstack-sigs mailing list
>>openstack-s...@lists.openstack.org 
>> 
>>> >
>>

Re: [openstack-dev] [Tripleo] fluentd logging status

2018-08-24 Thread Remo Mattei 
My co-worker has it working on OOO, Pike release bm not containers. There was a 
plan to clean up the code and open it up since it’s all ansible-playbooks doing 
the work. 

Remo 

> On Aug 24, 2018, at 07:37, Ben Nemec  wrote:
> 
> 
> 
> On 08/24/2018 04:17 AM, Juan Badia Payno wrote:
>> Recently, I did a little test regarding fluentd logging on the gates 
>> master[1], queens[2], pike [3]. I don't like the status of it, I'm still 
>> working on them, but basically there are quite a lot of misconfigured logs 
>> and some services that they are not configured at all.
>> I think we need to put some effort on the logging. The purpose of this email 
>> is to point out that we need to do a little effort on the task.
>> First of all, I think we need to enable fluentd on all the scenarios, as it 
>> is on the tests [1][2][3] commented on the beginning of the email. Once 
>> everything is ok and some automatic test regarding logging is done they can 
>> be disabled.
>> I'd love not to create a new bug for every misconfigured/unconfigured 
>> service, but if requested to grab more attention on it, I will open it.
>> The plan I have in mind is something like:
>>  * Make an initial picture of what the fluentd/log status is (from pike 
>> upwards).
>>  * Fix all misconfigured services. (designate,...)
> 
> For the record, Designate in TripleO is not considered production-ready at 
> this time.  There are a few other issues that need to be resolved too.  I'll 
> add this to my todo list though.
> 
>>  * Add the non-configured services. (manila,...)
>>  * Add an automated check to find a possible unconfigured/misconfigured 
>> problem.
> 
> This would be good.  I copy-pasted the log config from another service but 
> had no idea whether it was correct (apparently it wasn't :-).
> 
>> Any comments, doubts or questions are welcome
>> Cheers,
>> Juan
>> [1] https://review.openstack.org/594836
>> [2] https://review.openstack.org/594838
>> [3] https://review.openstack.org/594840
>> __
>> OpenStack Development Mailing 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] Stepping down as coordinator for the Outreachy internships

2018-08-08 Thread Remo Mattei 
Great Job!! Victoria. 

Ciao

> On Aug 8, 2018, at 19:28, Ghanshyam Mann  wrote:
> 
> Thanks Victoria  for such a great work and well coordinated. You have done 
> remarkable work in internships program. 
> 
> -gmann 
> 
>  On Wed, 08 Aug 2018 08:47:28 +0900 Victoria Martínez de la Cruz 
>  wrote  
>> Hi all,
>> I'm reaching you out to let you know that I'll be stepping down as 
>> coordinator for OpenStack next round. I had been contributing to this effort 
>> for several rounds now and I believe is a good moment for somebody else to 
>> take the lead. You all know how important is Outreachy to me and I'm 
>> grateful for all the amazing things I've done as part of the Outreachy 
>> program and all the great people I've met in the way. I plan to keep 
>> involved with the internships but leave the coordination tasks to somebody 
>> else.
>> If you are interested in becoming an Outreachy coordinator, let me know and 
>> I can share my experience and provide some guidance.
>> Thanks,
>> Victoria 
>> __
>> OpenStack Development Mailing 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] deployement fails

2018-07-30 Thread Remo Mattei 
Take it off and check :) 



> On Jul 30, 2018, at 09:46, Samuel Monderer  
> wrote:
> 
> Yes 
> I tried eith 60 and 120
> 
> On Mon, Jul 30, 2018, 19:42 Remo Mattei mailto:r...@rm.ht>> 
> wrote:
> Do you have a timeout set? 
> 
> > On Jul 30, 2018, at 07:48, Samuel Monderer  > <mailto:smonde...@vasonanetworks.com>> wrote:
> > 
> > Hi,
> > 
> > I'm trying to deploy a small environment with one controller and one 
> > compute but i get a timeout with no specific information in the logs
> > 
> > 2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]: 
> > CREATE_IN_PROGRESS  state changed
> > 2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]: 
> > CREATE_COMPLETE  state changed
> > 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: CREATE_FAILED  CREATE 
> > aborted (Task create from ResourceGroup "ComputeGammaV3" Stack "overcloud" 
> > [690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
> > 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: UPDATE_FAILED  Stack 
> > UPDATE cancelled
> > 2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
> > 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED  Stack 
> > CREATE cancelled
> > 2018-07-30 14:04:51Z [overcloud.Controller]: CREATE_FAILED  CREATE aborted 
> > (Task create from ResourceGroup "Controller" Stack "overcloud" 
> > [690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
> > 2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
> > 2018-07-30 14:04:51Z [overcloud.Controller]: UPDATE_FAILED  Stack UPDATE 
> > cancelled
> > 2018-07-30 14:04:51Z [overcloud.Controller.0]: CREATE_FAILED  Stack CREATE 
> > cancelled
> > 2018-07-30 14:04:52Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED  
> > resources[0]: Stack CREATE cancelled
> > 
> >  Stack overcloud CREATE_FAILED 
> > 
> > overcloud.ComputeGammaV3.0:
> >   resource_type: OS::TripleO::ComputeGammaV3
> >   physical_resource_id: 5755d746-7cbf-4f3d-a9e1-d94a713705a7
> >   status: CREATE_FAILED
> >   status_reason: |
> > resources[0]: Stack CREATE cancelled
> > overcloud.Controller.0:
> >   resource_type: OS::TripleO::Controller
> >   physical_resource_id: 4bcf84c1-1d54-45ee-9f81-b6dda780cbd7
> >   status: CREATE_FAILED
> >   status_reason: |
> > resources[0]: Stack CREATE cancelled
> > Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
> > Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
> > Heat Stack create failed.
> > Heat Stack create failed.
> > (undercloud) [stack@staging-director ~]$
> > 
> > It seems that it wasn't able to configure the OVS bridges
> > 
> > (undercloud) [stack@staging-director ~]$ openstack software deployment show 
> > 4b4fc54f-7912-40e2-8ad4-79f6179fe701
> > +---++
> > | Field | Value  |
> > +---++
> > | id| 4b4fc54f-7912-40e2-8ad4-79f6179fe701   |
> > | server_id | 0accb7a3-4869-4497-8f3b-5a3d99f3926b   |
> > | config_id | 2641b4dd-afc7-4bf5-a2e2-481c207e4b7f   |
> > | creation_time | 2018-07-30T13:19:44Z   |
> > | updated_time  ||
> > | status| IN_PROGRESS|
> > | status_reason | Deploy data available  |
> > | input_values  | {u'interface_name': u'nic1', u'bridge_name': u'br-ex'} |
> > | action| CREATE |
> > +---++
> > (undercloud) [stack@staging-director ~]$ openstack software deployment show 
> > a297e8ae-f4c9-41b0-938f-c51f9fe23843
> > +---++
> > | Field | Value  |
> > +---++
> > | id| a297e8ae-f4c9-41b0-938f-c51f9fe23843   |
> > | server_id | 145167da-9b96-4eee-bfe9-399b854c1e84   |
> > | config_id | d1baf0a5-de9b-48f2-b486-9f5d97f7e94f   |
> > | creation_time | 2018-07-30T13:17:29Z   |
>

Re: [openstack-dev] [tripleo] deployement fails

2018-07-30 Thread Remo Mattei 
Do you have a timeout set? 

> On Jul 30, 2018, at 07:48, Samuel Monderer  
> wrote:
> 
> Hi,
> 
> I'm trying to deploy a small environment with one controller and one compute 
> but i get a timeout with no specific information in the logs
> 
> 2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]: 
> CREATE_IN_PROGRESS  state changed
> 2018-07-30 13:19:41Z [overcloud.Controller.0.ControllerConfig]: 
> CREATE_COMPLETE  state changed
> 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: CREATE_FAILED  CREATE 
> aborted (Task create from ResourceGroup "ComputeGammaV3" Stack "overcloud" 
> [690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
> 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3]: UPDATE_FAILED  Stack UPDATE 
> cancelled
> 2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
> 2018-07-30 14:04:51Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED  Stack 
> CREATE cancelled
> 2018-07-30 14:04:51Z [overcloud.Controller]: CREATE_FAILED  CREATE aborted 
> (Task create from ResourceGroup "Controller" Stack "overcloud" 
> [690ee33c-8194-4713-a44f-9c8dcf88359f] Timed out)
> 2018-07-30 14:04:51Z [overcloud]: CREATE_FAILED  Timed out
> 2018-07-30 14:04:51Z [overcloud.Controller]: UPDATE_FAILED  Stack UPDATE 
> cancelled
> 2018-07-30 14:04:51Z [overcloud.Controller.0]: CREATE_FAILED  Stack CREATE 
> cancelled
> 2018-07-30 14:04:52Z [overcloud.ComputeGammaV3.0]: CREATE_FAILED  
> resources[0]: Stack CREATE cancelled
> 
>  Stack overcloud CREATE_FAILED 
> 
> overcloud.ComputeGammaV3.0:
>   resource_type: OS::TripleO::ComputeGammaV3
>   physical_resource_id: 5755d746-7cbf-4f3d-a9e1-d94a713705a7
>   status: CREATE_FAILED
>   status_reason: |
> resources[0]: Stack CREATE cancelled
> overcloud.Controller.0:
>   resource_type: OS::TripleO::Controller
>   physical_resource_id: 4bcf84c1-1d54-45ee-9f81-b6dda780cbd7
>   status: CREATE_FAILED
>   status_reason: |
> resources[0]: Stack CREATE cancelled
> Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
> Not cleaning temporary directory /tmp/tripleoclient-vxGzKo
> Heat Stack create failed.
> Heat Stack create failed.
> (undercloud) [stack@staging-director ~]$
> 
> It seems that it wasn't able to configure the OVS bridges
> 
> (undercloud) [stack@staging-director ~]$ openstack software deployment show 
> 4b4fc54f-7912-40e2-8ad4-79f6179fe701
> +---++
> | Field | Value  |
> +---++
> | id| 4b4fc54f-7912-40e2-8ad4-79f6179fe701   |
> | server_id | 0accb7a3-4869-4497-8f3b-5a3d99f3926b   |
> | config_id | 2641b4dd-afc7-4bf5-a2e2-481c207e4b7f   |
> | creation_time | 2018-07-30T13:19:44Z   |
> | updated_time  ||
> | status| IN_PROGRESS|
> | status_reason | Deploy data available  |
> | input_values  | {u'interface_name': u'nic1', u'bridge_name': u'br-ex'} |
> | action| CREATE |
> +---++
> (undercloud) [stack@staging-director ~]$ openstack software deployment show 
> a297e8ae-f4c9-41b0-938f-c51f9fe23843
> +---++
> | Field | Value  |
> +---++
> | id| a297e8ae-f4c9-41b0-938f-c51f9fe23843   |
> | server_id | 145167da-9b96-4eee-bfe9-399b854c1e84   |
> | config_id | d1baf0a5-de9b-48f2-b486-9f5d97f7e94f   |
> | creation_time | 2018-07-30T13:17:29Z   |
> | updated_time  ||
> | status| IN_PROGRESS|
> | status_reason | Deploy data available  |
> | input_values  | {u'interface_name': u'nic1', u'bridge_name': u'br-ex'} |
> | action| CREATE |
> +---++
> (undercloud) [stack@staging-director ~]$
> 
> Regards,
> Samuel
> __
> OpenStack Development Mailing 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:

Re: [openstack-dev] [tripleo] PTL non-candidacy

2018-07-25 Thread Remo Mattei 
I want publically  want to say THANK YOU Alex. You ROCK. 

Hopefully one of those summit, I will meet. 

Ciao, 
Remo 

> On Jul 25, 2018, at 6:23 AM, Alex Schultz  wrote:
> 
> Hey folks,
> 
> So it's been great fun and we've accomplished much over the last two
> cycles but I believe it is time for me to step back and let someone
> else do the PTLing.  I'm not going anywhere so I'll still be around to
> focus on the simplification and improvements that TripleO needs going
> forward.  I look forwards to continuing our efforts with everyone.
> 
> Thanks,
> -Alex
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 

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

Re: [openstack-dev] [tripleo] PTL candidacy for the Stein Cycle

2018-07-25 Thread Remo Mattei 
+1 for Juan, 


> On Jul 25, 2018, at 5:03 AM, Juan Antonio Osorio  wrote:
> 
> Hello folks!
> 
> I'd like to nominate myself for the TripleO PTL role for the Stein cycle.
> 
> Alex has done a great job as a PTL: The project is progressing nicely with 
> many
> new, exciting features and uses for TripleO coming to fruition recently. It's 
> a
> great time for the project. But, there's more work to be done.
> 
> I have served the TripleO community as a core-reviewer for some years now and,
> more recently, by driving the Security Squad. This project has been a
> great learning experience for me, both technically (I got to learn even more 
> of
> OpenStack) and community-wise. Now I wish to better serve the community 
> further
> by bringing my experiences into PTL role. While I have not yet served as PTL
> for a project before,I'm eager to learn the ropes and help improve the
> community that has been so influential on me.
> 
> For Stein, I would like to focus on:
> 
> * Increasing TripleO's usage in the testing of other projects
>   Now that TripleO can deploy a standalone OpenStack installation, I hope it
>   can be leveraged to add value to other projects' testing efforts. I hope 
> this
>   would subsequentially help increase TripleO's testing coverage, and reduce
>   the footprint required for full-deployment testing.
> 
> * Technical Debt & simplification
>   We've been working on simplifying the deployment story and battle technical
>   depth -- let’s keep  this momentum going.  We've been running (mostly) fully
>   containerized environments for a couple of releases now; I hope we can 
> reduce
>   the number of stacks we create, which would in turn simplify the project
>   structure (at least on the t-h-t side). We should also aim for the most
>   convergence we can achieve (e.g. CLI and UI workflows).
> 
> * CI and testing
>   The project has made great progress regarding CI and testing; lets keep this
>   moving forward and get developers easier ways to bring up testing
>   environments for them to work on and to be able to reproduce CI jobs.
> 
> Thanks!
> 
> Juan Antonio Osorio Robles
> IRC: jaosorior
> 
> 
> -- 
> 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 Development Mailing 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] Mistral workflow cannot establish connection

2018-07-15 Thread Remo Mattei 
I still think there is something wrong with some of your yaml, the roles_data 
is elaborating based on what your yaml files are. Can you share your deployment 
script did you make any of the yaml files yourself? 

Remo 

> On Jul 15, 2018, at 8:57 AM, Remo Mattei  wrote:
> 
> Here is the one I use
> 
> 
> 
> 
>> On Jul 15, 2018, at 8:02 AM, Samuel Monderer > <mailto:smonde...@vasonanetworks.com>> wrote:
>> 
>> It seems that the problem is in my roles_data.yaml file but I don't see what 
>> is the problem
>> I've attached the file.
>> 
>> On Sun, Jul 15, 2018 at 12:46 AM Remo Mattei > <mailto:r...@rm.ht>> wrote:
>> It is a bad line in one of your yaml file. I would check them. 
>> 
>> Sent from my iPad
>> 
>> On Jul 14, 2018, at 2:25 PM, Samuel Monderer > <mailto:smonde...@vasonanetworks.com>> wrote:
>> 
>>> Hi,
>>> 
>>> I'm trying to deploy redhat OSP13 but I get the following error.
>>> (undercloud) [root@staging-director stack]# ./templates/deploy.sh 
>>> Started Mistral Workflow 
>>> tripleo.validations.v1.check_pre_deployment_validations. Execution ID: 
>>> 3ba53aa3-56c5-4024-8d62-bafad967f7c2
>>> Waiting for messages on queue 'tripleo' with no timeout.
>>> Removing the current plan files
>>> Uploading new plan files
>>> Started Mistral Workflow tripleo.plan_management.v1.update_deployment_plan. 
>>> Execution ID: ff359b14-78d7-4b64-8b09-6ec3c4697d71
>>> Plan updated.
>>> Processing templates in the directory 
>>> /tmp/tripleoclient-ae4yIf/tripleo-heat-templates
>>> Unable to establish connection to 
>>> https://192.168.50.30:13989/v2/action_executions 
>>> <https://192.168.50.30:13989/v2/action_executions>: ('Connection aborted.', 
>>> BadStatusLine("''",))
>>> (undercloud) [root@staging-director stack]#
>>> 
>>> Couldn't find any info in the logs of what causes the error.
>>> 
>>> Samuel
>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
>>> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>>> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> <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 
>> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> <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 
> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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] Mistral workflow cannot establish connection

2018-07-15 Thread Remo Mattei 
Here is the one I use

roles_data.yaml
Description: Binary data
On Jul 15, 2018, at 8:02 AM, Samuel Monderer <smonde...@vasonanetworks.com> wrote:It seems that the problem is in my roles_data.yaml file but I don't see what is the problemI've attached the file.On Sun, Jul 15, 2018 at 12:46 AM Remo Mattei <r...@rm.ht> wrote:It is a bad line in one of your yaml file. I would check them. Sent from my iPadOn Jul 14, 2018, at 2:25 PM, Samuel Monderer <smonde...@vasonanetworks.com> wrote:Hi,I'm trying to deploy redhat OSP13 but I get the following error.(undercloud) [root@staging-director stack]# ./templates/deploy.sh Started Mistral Workflow tripleo.validations.v1.check_pre_deployment_validations. Execution ID: 3ba53aa3-56c5-4024-8d62-bafad967f7c2Waiting for messages on queue 'tripleo' with no timeout.Removing the current plan filesUploading new plan filesStarted Mistral Workflow tripleo.plan_management.v1.update_deployment_plan. Execution ID: ff359b14-78d7-4b64-8b09-6ec3c4697d71Plan updated.Processing templates in the directory /tmp/tripleoclient-ae4yIf/tripleo-heat-templatesUnable to establish connection to https://192.168.50.30:13989/v2/action_executions: ('Connection aborted.', BadStatusLine("''",))(undercloud) [root@staging-director stack]#Couldn't find any info in the logs of what causes the error.Samuel__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Mistral workflow cannot establish connection

2018-07-14 Thread Remo Mattei 
It is a bad line in one of your yaml file. I would check them. 

Sent from my iPad

> On Jul 14, 2018, at 2:25 PM, Samuel Monderer  
> wrote:
> 
> Hi,
> 
> I'm trying to deploy redhat OSP13 but I get the following error.
> (undercloud) [root@staging-director stack]# ./templates/deploy.sh 
> Started Mistral Workflow 
> tripleo.validations.v1.check_pre_deployment_validations. Execution ID: 
> 3ba53aa3-56c5-4024-8d62-bafad967f7c2
> Waiting for messages on queue 'tripleo' with no timeout.
> Removing the current plan files
> Uploading new plan files
> Started Mistral Workflow tripleo.plan_management.v1.update_deployment_plan. 
> Execution ID: ff359b14-78d7-4b64-8b09-6ec3c4697d71
> Plan updated.
> Processing templates in the directory 
> /tmp/tripleoclient-ae4yIf/tripleo-heat-templates
> Unable to establish connection to 
> https://192.168.50.30:13989/v2/action_executions: ('Connection aborted.', 
> BadStatusLine("''",))
> (undercloud) [root@staging-director stack]#
> 
> Couldn't find any info in the logs of what causes the error.
> 
> Samuel
> __
> OpenStack Development Mailing 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] [magnum] K8S apiserver key sync

2018-06-20 Thread Remo Mattei 
Thanks Fei, 
I did post the question on that channel no much noise there though.. I would 
really like to get this configured since we are pushing for production. 

Thanks 

> On Jun 20, 2018, at 8:27 PM, Fei Long Wang  wrote:
> 
> Hi Remo,
> 
> I can't see obvious issue from the log you posted. You can pop up at 
> #openstack-containers IRC channel as for Magnum questions. Cheers.
> 
> 
> On 21/06/18 08:56, Remo Mattei wrote:
>> Hello guys, what will be the right channel to as a question about having K8 
>> (magnum working with Tripleo)? 
>> 
>> I have the following errors..
>> 
>> http://pastebin.mattei.co/index.php/view/2d1156f1 
>> <http://pastebin.mattei.co/index.php/view/2d1156f1>
>> 
>> Any tips are appreciated. 
>> 
>> Thanks 
>> Remo 
>> 
>>> On Jun 19, 2018, at 2:13 PM, Fei Long Wang >> <mailto:feil...@catalyst.net.nz>> wrote:
>>> 
>>> Hi there,
>>> 
>>> For people who maybe still interested in this issue. I have proposed a 
>>> patch, see https://review.openstack.org/576029 
>>> <https://review.openstack.org/576029> And I have verified with Sonobuoy for 
>>> both multi masters (3 master nodes) and single master clusters, all worked. 
>>> Any comments will be appreciated. Thanks.
>>> 
>>> 
>>> On 21/05/18 01:22, Sergey Filatov wrote:
>>>> Hi!
>>>> I’d like to initiate a discussion about this bug: [1].
>>>> To resolve this issue we need to generate a secret cert and pass it to 
>>>> master nodes. We also need to store it somewhere to support scaling.
>>>> This issue is specific for kubernetes drivers. Currently in magnum we have 
>>>> a general cert manager which is the same for all the drivers.
>>>> 
>>>> What do you think about moving cert_manager logic into a driver-specific 
>>>> area?
>>>> Having this common cert_manager logic forces us to generate client cert 
>>>> with “admin” and “system:masters” subject & organisation names [2], 
>>>> which is really something that we need only for kubernetes drivers.
>>>> 
>>>> [1] https://bugs.launchpad.net/magnum/+bug/1766546 
>>>> <https://bugs.launchpad.net/magnum/+bug/1766546>
>>>> [2] 
>>>> https://github.com/openstack/magnum/blob/2329cb7fb4d197e49d6c07d37b2f7ec14a11c880/magnum/conductor/handlers/common/cert_manager.py#L59-L64
>>>>  
>>>> <https://github.com/openstack/magnum/blob/2329cb7fb4d197e49d6c07d37b2f7ec14a11c880/magnum/conductor/handlers/common/cert_manager.py#L59-L64>
>>>> 
>>>> 
>>>> ..Sergey Filatov
>>>> 
>>>> 
>>>> 
>>>>> On 20 Apr 2018, at 20:57, Sergey Filatov >>>> <mailto:s.s.filato...@gmail.com>> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> I looked into k8s drivers for magnum I see that each api-server on master 
>>>>> node generates it’s own service-account-key-file. This causes issues with 
>>>>> service-accounts authenticating on api-server. (In case api-server 
>>>>> endpoint moves).
>>>>> As far as I understand we should have either all api-server keys synced 
>>>>> on api-servesr or pre-generate single api-server key.
>>>>> 
>>>>> What is the way for magnum to get over this issue?
>>>> 
>>>> 
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>>>> <mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>>>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>> 
>>> -- 
>>> Cheers & Best regards,
>>> Feilong Wang (王飞龙)
>>> --
>>> Senior Cloud Software Engineer
>>> Tel: +64-48032246
>>> Email: flw...@catalyst.net.nz <mailto:flw...@catalyst.net.nz>
>>> Catalyst IT Limited
>>> Level 6, Catalyst House, 150 Willis Street, Wellington
>>> -- 
>>> __
>>>

Re: [openstack-dev] [magnum] K8S apiserver key sync

2018-06-20 Thread Remo Mattei 
Hello guys, what will be the right channel to as a question about having K8 
(magnum working with Tripleo)? 

I have the following errors..

http://pastebin.mattei.co/index.php/view/2d1156f1

Any tips are appreciated. 

Thanks 
Remo 

> On Jun 19, 2018, at 2:13 PM, Fei Long Wang  wrote:
> 
> Hi there,
> 
> For people who maybe still interested in this issue. I have proposed a patch, 
> see https://review.openstack.org/576029  
> And I have verified with Sonobuoy for both multi masters (3 master nodes) and 
> single master clusters, all worked. Any comments will be appreciated. Thanks.
> 
> 
> On 21/05/18 01:22, Sergey Filatov wrote:
>> Hi!
>> I’d like to initiate a discussion about this bug: [1].
>> To resolve this issue we need to generate a secret cert and pass it to 
>> master nodes. We also need to store it somewhere to support scaling.
>> This issue is specific for kubernetes drivers. Currently in magnum we have a 
>> general cert manager which is the same for all the drivers.
>> 
>> What do you think about moving cert_manager logic into a driver-specific 
>> area?
>> Having this common cert_manager logic forces us to generate client cert with 
>> “admin” and “system:masters” subject & organisation names [2], 
>> which is really something that we need only for kubernetes drivers.
>> 
>> [1] https://bugs.launchpad.net/magnum/+bug/1766546 
>> 
>> [2] 
>> https://github.com/openstack/magnum/blob/2329cb7fb4d197e49d6c07d37b2f7ec14a11c880/magnum/conductor/handlers/common/cert_manager.py#L59-L64
>>  
>> 
>> 
>> 
>> ..Sergey Filatov
>> 
>> 
>> 
>>> On 20 Apr 2018, at 20:57, Sergey Filatov >> > wrote:
>>> 
>>> Hello,
>>> 
>>> I looked into k8s drivers for magnum I see that each api-server on master 
>>> node generates it’s own service-account-key-file. This causes issues with 
>>> service-accounts authenticating on api-server. (In case api-server endpoint 
>>> moves).
>>> As far as I understand we should have either all api-server keys synced on 
>>> api-servesr or pre-generate single api-server key.
>>> 
>>> What is the way for magnum to get over this issue?
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> 
> 
> -- 
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz 
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> -- 
> __
> OpenStack Development Mailing 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 NeutronNetworkVLANRanges

2018-06-13 Thread Remo Mattei 
Hello guys, just want to double check and make sure that this option can be 
ignored if using vxlan. 

NeutronNetworkVLANRanges (used in the network isolation template)

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

Re: [openstack-dev] [all][sdk] Integrating OpenStack and k8s with a service broker

2018-06-05 Thread Remo Mattei 
I will be happy to check it out.

Remo 

> On Jun 5, 2018, at 9:19 AM, Zane Bitter  wrote:
> 
> I've been doing some investigation into the Service Catalog in Kubernetes and 
> how we can get OpenStack resources to show up in the catalog for use by 
> applications running in Kubernetes. (The Big 3 public clouds already support 
> this.) The short answer is via an implementation of something called the Open 
> Service Broker API, but there are shortcuts available to make it easier to do.
> 
> I'm convinced that this is readily achievable and something we ought to do as 
> a community.
> 
> I've put together a (long-winded) FAQ below to answer all of your questions 
> about it.
> 
> Would you be interested in working on a new project to implement this 
> integration? Reply to this thread and let's collect a list of volunteers to 
> form the initial core review team.
> 
> cheers,
> Zane.
> 
> 
> What is the Open Service Broker API?
> 
> 
> The Open Service Broker API[1] is a standard way to expose external resources 
> to applications running in a PaaS. It was originally developed in the context 
> of CloudFoundry, but the same standard was adopted by Kubernetes (and hence 
> OpenShift) in the form of the Service Catalog extension[2]. (The Service 
> Catalog in Kubernetes is the component that calls out to a service broker.) 
> So a single implementation can cover the most popular open-source PaaS 
> offerings.
> 
> In many cases, the services take the form of simply a pre-packaged 
> application that also runs inside the PaaS. But they don't have to be - 
> services can be anything. Provisioning via the service broker ensures that 
> the services requested are tied in to the PaaS's orchestration of the 
> application's lifecycle.
> 
> (This is certainly not the be-all and end-all of integration between 
> OpenStack and containers - we also need ways to tie PaaS-based applications 
> into the OpenStack's orchestration of a larger group of resources. Some 
> applications may even use both. But it's an important part of the story.)
> 
> What sorts of services would OpenStack expose?
> --
> 
> Some example use cases might be:
> 
> * The application needs a reliable message queue. Rather than spinning up 
> multiple storage-backed containers with anti-affinity policies and dealing 
> with the overhead of managing e.g. RabbitMQ, the application requests a Zaqar 
> queue from an OpenStack cloud. The overhead of running the queueing service 
> is amortised across all of the applications in the cloud. The queue gets 
> cleaned up correctly when the application is removed, since it is tied into 
> the application definition.
> 
> * The application needs a database. Rather than spinning one up in a 
> storage-backed container and dealing with the overhead of managing it, the 
> application requests a Trove DB from an OpenStack cloud.
> 
> * The application includes a service that needs to run on bare metal for 
> performance reasons (e.g. could also be a database). The application requests 
> a bare-metal server from Nova w/ Ironic for the purpose. (The same applies to 
> requesting a VM, but there are alternatives like KubeVirt - which also 
> operates through the Service Catalog - available for getting a VM in 
> Kubernetes. There are no non-proprietary alternatives for getting a 
> bare-metal server.)
> 
> AWS[3], Azure[4], and GCP[5] all have service brokers available that support 
> these and many more services that they provide. I don't know of any reason in 
> principle not to expose every type of resource that OpenStack provides via a 
> service broker.
> 
> How is this different from cloud-provider-openstack?
> 
> 
> The Cloud Controller[6] interface in Kubernetes allows Kubernetes itself to 
> access features of the cloud to provide its service. For example, if k8s 
> needs persistent storage for a container then it can request that from Cinder 
> through cloud-provider-openstack[7]. It can also request a load balancer from 
> Octavia instead of having to start a container running HAProxy to load 
> balance between multiple instances of an application container (thus enabling 
> use of hardware load balancers via the cloud's abstraction for them).
> 
> In contrast, the Service Catalog interface allows the *application* running 
> on Kubernetes to access features of the cloud.
> 
> What does a service broker look like?
> -
> 
> A service broker provides an HTTP API with 5 actions:
> 
> * List the services provided by the broker
> * Create an instance of a resource
> * Bind the resource into an instance of the application
> * Unbind the resource from an instance of the application
> * Delete the resource
> 
> The binding step is used for things like providing a set of DB credentials to 
> a container. You can rotate credentials when replacing a

Re: [openstack-dev] [tc] StarlingX project status update

2018-06-05 Thread Remo Mattei 
I agree with Graham +1

Remo 

> On Jun 5, 2018, at 8:42 AM, Graham Hayes  wrote:
> 
> 
> 
> On 30/05/18 21:23, Mohammed Naser wrote:
>> Hi everyone:
>> 
>> Over the past week in the summit, there was a lot of discussion
>> regarding StarlingX
>> and members of the technical commitee had a few productive discussions 
>> regarding
>> the best approach to deal with a proposed new pilot project for
>> incubation in the OSF's Edge
>> Computing strategic focus area: StarlingX.
>> 
>> If you're not aware, StarlingX includes forks of some OpenStack
>> components and other open source software
>> which contain certain features that are specific to edge and
>> industrial IoT computing use cases.  The code
>> behind the project is from Wind River (and is used to build a product
>> called "Titanium
>> Cloud").
>> 
>> At the moment, the goal of StarlingX hosting their projects on the
>> community infrastructure
>> is to get the developers used to the Gerrit workflow.  The intention
>> is to evenutally
>> work with upstream teams in order to bring the features and bug fixes which 
>> are
>> specific to the fork back upstream, with an ideal goal of bringing all
>> the differences
>> upstream.
>> 
>> We've discussed around all the different ways that we can approach
>> this and how to
>> help the StarlingX team be part of our community.  If we can
>> succesfully do this, it would
>> be a big success for our community as well as our community gaining
>> contributors from
>> the Wind River team.  In an ideal world, it's a win-win.
>> 
>> The plan at the moment is the following:
>> - StarlingX will have the first import of code that is not forked,
>> simply other software that
>>  they've developed to help deliver their product.  This code can be
>> hosted with no problems.
>> - StarlingX will generate a list of patches to be brought upstream and
>> the StarlingX team
>>  will work together with upstream teams in order to start backporting
>> and upstreaming the
>>  codebase.  Emilien Macchi (EmilienM) and I have volunteered to take
>> on the responsibility of
>>  monitoring the progress upstreaming these patches.
>> - StarlingX contains a few forks of other non-OpenStack software. The
>> StarlingX team will work
>>  with the authors of the original projects to ensure that they do not
>> mind us hosting a fork
>>  of their software.  If they don't, we'll proceed to host those
>> projects. If they prefer
>>  something else (hosting it themselves, placing it on another hosting
>> service, etc.),
>>  the StarlingX team will work with them in that way.
>> 
>> We discussed approaches for cases where patches aren't acceptable
>> upstream, because they
>> diverge from the project mission or aren't comprehensive. Ideally all
>> of those could be turned
>> into acceptable changes that meet both team's criteria. In some cases,
>> adding plugin interfaces
>> or driver interfaces may be the best alternative. Only as a last
>> resort would we retain the
>> forks for a long period of time.
> 
> I honestly think that these forks should never be inside the foundation.
> If there is a big enough disagreement between project teams and the
> fork, we (as the TC of the OpenStack project) and the board (of
> *OpenStack* Foundation) should support our current teams, who have
> been working in the open.
> 
> There is plenty of companies who would have loved certain features in
> OpenStack over the years that an extra driver extension point would
> have enabled, but when the upstream team pushed back, they redesigned
> the feature to work with the community vision. We should not reward
> companies that didn't.
> 
>> From what was brought up, the team from Wind River is hoping to
>> on-board roughly 50 new full
>> time contributors.  In combination with the features that they've
>> built that we can hopefully
>> upstream, I am hopeful that we can come to a win-win situation for
>> everyone in this.
>> 
>> Regards,
>> Mohammed
>> 
>> __
>> OpenStack Development Mailing 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] Hello all, puppet modules

2018-05-30 Thread Remo Mattei 
Hello all, 
I have talked to several people about this and I would love to get this 
finalized once and for all. I have checked the OpenStack puppet modules which 
are mostly developed by the Red Hat team, as of right now, TripleO is using a 
combo of Ansible and puppet to deploy but in the next couple of releases, the 
plan is to move away from the puppet option. 


So consequently, what will be the plan of TripleO and the puppet modules?

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

Re: [openstack-dev] [Openstack] Neutron: Internet not available in VM instances

2016-10-06 Thread Remo Mattei 
what’s your l3agent.ini says about external? 
> On Oct 6, 2016, at 06:16, kamalakannan sanjeevan 
>  wrote:
> 
> Hello,
> 
> I am not able to connect to internet in teh spawned VM's.
> 
> 
> Ethernet card details:
> Eth1 bridged through OVS(mybridge)  - 172.27.10.76
> Eth3- 
> 192.168.182.251
> 
> after executing the command
> 
> iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE 
> 
> iptables -t nat -A POSTROUTING -o mybridge -j MASQUERADE
> 
> - I see teh connectivity to VM's from my host name  ie 172.27.10.76 also 
> affected.
> 
> root@VFSR1:~# ovs-vsctl show
> 37f38767-0a2b-45fd-9507-abef7fd2d5c9
> Bridge br-int
> fail_mode: secure
> Port "qr-2ff64ff8-b8"
> tag: 6
> Interface "qr-2ff64ff8-b8"
> type: internal
> Port patch-tun
> Interface patch-tun
> type: patch
> options: {peer=patch-int}
> Port "qvo310233a4-9f"
> tag: 6
> Interface "qvo310233a4-9f"
> Port br-int
> Interface br-int
> type: internal
> Port "tap6bc359b6-f0"
> tag: 6
> Interface "tap6bc359b6-f0"
> type: internal
> Port "qvo703c764e-23"
> tag: 5
> Interface "qvo703c764e-23"
> Port int-mybridge
> Interface int-mybridge
> type: patch
> options: {peer=phy-mybridge}
> Port "qg-333a2d2b-ca"
> tag: 5
> Interface "qg-333a2d2b-ca"
> type: internal
> Bridge mybridge
> Port mybridge
> Interface mybridge
> type: internal
> Port "eth1"
> Interface "eth1"
> Port phy-mybridge
> Interface phy-mybridge
> type: patch
> options: {peer=int-mybridge}
> Bridge br-tun
> fail_mode: secure
> Port br-tun
> Interface br-tun
> type: internal
> Port patch-int
> Interface patch-int
> type: patch
> options: {peer=patch-tun}
> ovs_version: "2.5.0"
> 
> 
> Below is my network and router details
> 
> root@VFSR1:~# neutron net-list
> +--+-+-+
> | id   | name| subnets
>  |
> +--+-+-+
> | 51739543-b7d1-414b-bec1-9b38c3e5d5d7 | public  | 
> 0db9fa02-27eb-4f38-8693-200719fc1fbf 172.27.10.0/24  |
> | bf919707-b1eb-4d8f-90fe-5bcf0e07dce3 | private | 
> 7fddc311-7938-44c4-abd4-e5095adba422 192.168.0.0/24  |
> +--+-+-+
> root@VFSR1:~# neutron router-list
> +--++---+-+---+
> | id   | name   | external_gateway_info   
>   
>   
>   | distributed | ha|
> +--++---+-+---+
> | 323a6782-46aa-458e-ad76-f9462d8ad955 | router | {"network_id": 
> "51739543-b7d1-414b-bec1-9b38c3e5d5d7", "enable_snat": true, 
> "external_fixed_ips": [{"subnet_id": "0db9fa02-27eb-4f38-8693-200719fc1fbf", 
> "ip_address": "172.27.10.101"}]} | False   | False |
> +--++---+-+---+
> 
> Below are my instances created 
> 
> root@VFSR1:~# nova list
> +--++++-++
> | ID   | Name   | Status | Task State | Power 
> State | Networks   |
> +--++++-++
> | b737645b-317e-46be-b06a-f1b94f378d95 | test   | ACTIVE | -  | 
> Running | public=172.27.10.100

Re: [openstack-dev] [Openstack] [OpenStack] "nova list" doesn't show networks for few instances

2016-03-30 Thread Remo Mattei 
Wrong user? 

Try --all-tenants and see what shows up as an admin

Inviato da iPhone

> Il giorno 30 mar 2016, alle ore 10:08, varun bhatnagar 
>  ha scritto:
> 
> Hi,
> 
> I am using OpenStack Juno on a multinode setup.
> When I did nova list I couldn't see any interfaces attached to few of my VMs 
> although in Dashboard they are visible.
> 
> -+
> | ID   | Name  | Status | Task State | 
> Power State | Networks
>  |
> +--+---+++-+--+
> | e111e5b6-4a90-4a3b-a465-19000fe1a81d | VM-3  | ACTIVE | -  | 
> Running | 
>  |
> | 78c465e9-09a6-477b-9374-9a5eb455ab2b | VM-4  | ACTIVE | -  | 
> Running | 
>  |
> | 6cfdef27-018a-4fd3-8f4f-856d804d415b | VM-5  | ACTIVE | -  | 
> Running | 
>  |
> | 94f4bddb-e2d5-48e8-88ae-169aba75ebd4 | VM-6  | ACTIVE | -  | 
> Running | 
>  |
> 
> | c72a4d9d-fcd1-4b12-90de-ec46fc950ad2 | VM-7 | ACTIVE | -  | Running 
> | internal=3001::b, 10.0.0.13, 192.168.154.68 
>  |
> +--+---+++-+--+
> 
> 
> Can anyone please tell me what is causing this and how to fix it?
> 
> BR,
> Varun
> 
> !DSPAM:1,56fb8b2b98152623519187!
> ___
> 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
> 
> 
> !DSPAM:1,56fb8b2b98152623519187!


__
OpenStack Development Mailing 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-Infra] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves.

2015-08-18 Thread Remo Mattei 
There is a webex scheduled for this topic you want to check it out go to 
Solinea.com 

Remo

Inviato da iPhone

 Il giorno 18 ago 2015, alle ore 07:41, Abhishek Shrivastava 
 abhis...@cloudbyte.com ha scritto:
 
 Hi Folks,
 
 I was going through Ramy's guide for setting up CI, there I found out the 
 following:
 https://github.com/rasselin/os-ext-testing#setting-up-nodepool-jenkins-slaves
 But I don't get the fact on how to create the image, also what major settings 
 need to be done to make the config perfect for use. Can anyone help me with 
 that?
 
 -- 
 
 Thanks  Regards,
 Abhishek
 Cloudbyte Inc.
 !DSPAM:1,55d2c5ef145828302144768!
 ___
 OpenStack-Infra mailing list
 openstack-in...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
 
 
 !DSPAM:1,55d2c5ef145828302144768!
__
OpenStack Development Mailing 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] [qa] How to troubleshoot why a VM at Compute node won't response to ARP request from Neutron router

2014-10-12 Thread Remo Mattei 
By default icmp is not allowed 

Inviato da iPhone ()

 Il giorno 12/ott/2014, alle ore 09:25, Danny Choi (dannchoi) 
 dannc...@cisco.com ha scritto:
 
 Hi,
 
 Using devstack to deploy OpenStack, I have Controller + Network running at 
 one physical node and Compute at a separate node.
 
 I launched a VM at the Compute node with a private address 10.0.0.2 (Neutron 
 router interface is 10.0.0.1).
 
 At the Controller node, in the qrouter namespace, I could not ping the VM 
 private address 10.0.0.2.
 
 At the Compute node, tcpdump of the tap interface indicated ARP requests were 
 received.
 
 However, it did not show any ARP response.
 
 My understanding is that the VM’s virtual interface is directly connected to 
 this tap interface.  Since the VM is unreachable, I cannot
 launch its console to see if the ARP requests are received at the virtual 
 interface.
 
 Any suggestions on how to troubleshoot this? 
 
 localadmin@qa4:~/devstack$ nova show vm1
 +--++
 | Property | Value
   |
 +--++
 | OS-DCF:diskConfig| MANUAL   
   |
 | OS-EXT-AZ:availability_zone  | nova 
   |
 | OS-EXT-STS:power_state   | 1
   |
 | OS-EXT-STS:task_state| -
   |
 | OS-EXT-STS:vm_state  | active   
   |
 | OS-SRV-USG:launched_at   | 2014-10-12T14:25:15.00   
   |
 | OS-SRV-USG:terminated_at | -
   |
 | accessIPv4   |  
   |
 | accessIPv6   |  
   |
 | config_drive |  
   |
 | created  | 2014-10-12T14:23:30Z 
   |
 | flavor   | m1.tiny (1)  
   |
 | hostId   | 
 00ac69883737ebd290ad4f38cae979a6e268902333261ba6bfbade44   |
 | id   | 04b5a345-cadf-4dee-9209-5bcf589b6a3c 
   |
 | image| cirros-0.3.2-x86_64-uec 
 (14a55982-a093-4850-80c8-7b2ae3a7eaba) |
 | key_name | -
   |
 | metadata | {}   
   |
 | name | vm1  
   |
 | os-extended-volumes:volumes_attached | []   
   |
 | private network  | 10.0.0.2, 172.29.173.5   
   |
 | progress | 0
   |
 | security_groups  | default  
   |
 | status   | ACTIVE   
   |
 | tenant_id| 90058797dddc49efae4d1f45aa5ab982 
   |
 | updated  | 2014-10-12T14:23:39Z 
   |
 | user_id  | 5ab6344540974a1fbda5b539778ebe35 
   |
 +--++
 localadmin@qa4:~/devstack$ 
 localadmin@qa4:~/devstack$ ip netns
 qdhcp-f55f0683-830f-4523-82cb-46d638f91d47
 qrouter-62aecbdd-d58d-4b33-a743-b16ca38544c5
 localadmin@qa4:~/devstack$ 
 localadmin@qa4:~/devstack$ 
 localadmin@qa4:~/devstack$ sudo ip netns exec 
 qrouter-62aecbdd-d58d-4b33-a743-b16ca38544c5 ping 10.0.0.2
 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
 From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
 From 10.0.0.1 icmp_seq=2 Destination Host Unreachable
 From 10.0.0.1 icmp_seq=3 Destination Host Unreachable
 From 10.0.0.1 icmp_seq=4 Destination Host Unreachable
 From 10.0.0.1 icmp_seq=5 Destination Host Unreachable
 From 10.0.0.1 icmp_seq=6 Destination Host Unreachable
 
 
 localadmin@qa5:~/devstack$ sudo tcpdump -i tapade47169-57