Re: [Openstack-operators] [OCTAVIA][KOLLA] - Self signed CA/CERTS

[Flint WALRUS]

Ok, I’ll have a look at the syslog logs as there was nothing but the 404
inside the agent logs.

I’ll not be able to get my hand on my lab until at least the middle of the
next week so don’t worry if I’m not coming back to you with my results.

It’s not that I solved it, just that I won’t get my lab available as I have
to share it to one of my colleagues working on keystone SSO signing :-)

Have a nice weekend and thanks again for your kind support.
Le sam. 18 août 2018 à 00:05, Michael Johnson  a
écrit :

> Yes, the amphora-agent logs to both the amphora-agent.log and syslog
> in /var/log inside the amphora.
>
> Michael
> On Thu, Aug 16, 2018 at 1:43 PM Flint WALRUS 
> wrote:
> >
> > Hi Michael,
> >
> > Ok, it was indeed an issue with the create_certificate.sh script for
> centos that indeed improperly created the client.pem certificate.
> >
> > However now the amphora is responding with a 404 not found when the
> worker is trying to post /v0.5/plug/vip/10.1.56.12
> >
> > I know the amphora and the worker are correctly communicating as I can
> see the amphora-proxy net namespace being set with the subnet ip as eth1
> and the vip as eth1:0
> >
> > I did a tcpdump on each side (worker and amphora) and correctly see the
> network two ways communication.
> >
> > I checked the 9443 port and it is correctly binded to the gunicorn
> server using the lb-mgmt-net ip of the amphora.
> >
> > Is there any logs regarding the gunicorn server where I could check why
> does the amphora is not able to found the api endpoint?
> > Le mar. 14 août 2018 à 19:53, Flint WALRUS  a
> écrit :
> >>
> >> I’ll try to check the certificate format and make the appropriate
> change if required or let you know if I’ve got something specific regarding
> that topic.
> >>
> >> Kind regards,
> >> G.
> >> Le mar. 14 août 2018 à 19:52, Flint WALRUS  a
> écrit :
> >>>
> >>> Hi Michael, thanks a lot for your quick response once again!
> >>> Le mar. 14 août 2018 à 18:21, Michael Johnson  a
> écrit :
> 
>  Hi there Flint.
> 
>  Octavia fully supports using self-signed certificates and we use those
>  in our gate tests.
>  We do not allow non-TLS authenticated connections in the code, even
>  for lab setups.
> 
>  This is a configuration issue or certificate file format issue. When
>  the controller is attempting to access the controller local
>  certificate file (likely the one we use to prove we are a valid
>  controller to the amphora agent) it is finding a file without the
>  required PEM format header. Check that your certificate files have the
>  "-BEGIN CERTIFICATE-" line (maybe they are in binary DER
>  format and just need to be converted).
> 
>  Also for reference, here are the minimal steps we use in our gate
>  tests to setup the TLS certificates:
> 
> https://github.com/openstack/octavia/blob/master/devstack/plugin.sh#L295-L305
> 
>  Michael
>  On Tue, Aug 14, 2018 at 4:54 AM Flint WALRUS 
> wrote:
>  >
>  >
>  > Hi guys,
>  >
>  > I continue to work on my Octavia integration using Kolla-Ansible
> and I'm facing a strange behavior.
>  >
>  > As for now I'm working on a POC using restricted HW and SW
> Capacities, I'm facing a strange issue when trying to launch a new
> load-balancer.
>  >
>  > When I create a new LB, would it be using CLI or WebUI, the amphora
> immediately disappear and the LB status switch to ERROR.
>  >
>  > When looking at logs and especially Worker logs, I see that the
> error seems to be related to the fact that the worker can't connect to the
> amphora because of a TLS Handshake issue which so trigger the contact
> timeout and rollback the amphora creation.
>  >
>  > Here is the worker.log relevant trace:
>  >
>  > 2018-08-07 07:33:57.108 24 INFO octavia.controller.queue.endpoint
> [-] Creating load balancer 'bf7ab6e4-081a-4b4d-b7a0-c176a9cb995e'...
>  > 2018-08-07 07:33:57.220 24 INFO
> octavia.controller.worker.tasks.database_tasks [-] Created Amphora in DB
> with id c20af002-1576-446e-b99f-7af607b8d885
>  > 2018-08-07 07:33:57.285 24 INFO
> octavia.certificates.generator.local [-] Signing a certificate request
> using OpenSSL locally.
>  > 2018-08-07 07:33:57.285 24 INFO
> octavia.certificates.generator.local [-] Using CA Certificate from config.
>  > 2018-08-07 07:33:57.285 24 INFO
> octavia.certificates.generator.local [-] Using CA Private Key from config.
>  > 2018-08-07 07:33:57.286 24 INFO
> octavia.certificates.generator.local [-] Using CA Private Key Passphrase
> from config.
>  > 2018-08-07 07:34:04.074 24 INFO
> octavia.controller.worker.tasks.database_tasks [-] Mark ALLOCATED in DB for
> amphora: c20af002-1576-446e-b99f-7af607b8d885 with compute id
> 3bbabfa6-366f-46a4-8fb2-1ec7158e19f1 for load balancer:
> bf7ab6e4-081a-4b4d-b7a0-c176a9cb995e
>  > 2018-08-07 07:34:04.253 24 INFO
> 

Re: [Openstack-operators] [OCTAVIA][KOLLA] - Self signed CA/CERTS

[Michael Johnson]

Yes, the amphora-agent logs to both the amphora-agent.log and syslog
in /var/log inside the amphora.

Michael
On Thu, Aug 16, 2018 at 1:43 PM Flint WALRUS  wrote:
>
> Hi Michael,
>
> Ok, it was indeed an issue with the create_certificate.sh script for centos 
> that indeed improperly created the client.pem certificate.
>
> However now the amphora is responding with a 404 not found when the worker is 
> trying to post /v0.5/plug/vip/10.1.56.12
>
> I know the amphora and the worker are correctly communicating as I can see 
> the amphora-proxy net namespace being set with the subnet ip as eth1 and the 
> vip as eth1:0
>
> I did a tcpdump on each side (worker and amphora) and correctly see the 
> network two ways communication.
>
> I checked the 9443 port and it is correctly binded to the gunicorn server 
> using the lb-mgmt-net ip of the amphora.
>
> Is there any logs regarding the gunicorn server where I could check why does 
> the amphora is not able to found the api endpoint?
> Le mar. 14 août 2018 à 19:53, Flint WALRUS  a écrit :
>>
>> I’ll try to check the certificate format and make the appropriate change if 
>> required or let you know if I’ve got something specific regarding that topic.
>>
>> Kind regards,
>> G.
>> Le mar. 14 août 2018 à 19:52, Flint WALRUS  a écrit :
>>>
>>> Hi Michael, thanks a lot for your quick response once again!
>>> Le mar. 14 août 2018 à 18:21, Michael Johnson  a écrit 
>>> :

 Hi there Flint.

 Octavia fully supports using self-signed certificates and we use those
 in our gate tests.
 We do not allow non-TLS authenticated connections in the code, even
 for lab setups.

 This is a configuration issue or certificate file format issue. When
 the controller is attempting to access the controller local
 certificate file (likely the one we use to prove we are a valid
 controller to the amphora agent) it is finding a file without the
 required PEM format header. Check that your certificate files have the
 "-BEGIN CERTIFICATE-" line (maybe they are in binary DER
 format and just need to be converted).

 Also for reference, here are the minimal steps we use in our gate
 tests to setup the TLS certificates:
 https://github.com/openstack/octavia/blob/master/devstack/plugin.sh#L295-L305

 Michael
 On Tue, Aug 14, 2018 at 4:54 AM Flint WALRUS  
 wrote:
 >
 >
 > Hi guys,
 >
 > I continue to work on my Octavia integration using Kolla-Ansible and I'm 
 > facing a strange behavior.
 >
 > As for now I'm working on a POC using restricted HW and SW Capacities, 
 > I'm facing a strange issue when trying to launch a new load-balancer.
 >
 > When I create a new LB, would it be using CLI or WebUI, the amphora 
 > immediately disappear and the LB status switch to ERROR.
 >
 > When looking at logs and especially Worker logs, I see that the error 
 > seems to be related to the fact that the worker can't connect to the 
 > amphora because of a TLS Handshake issue which so trigger the contact 
 > timeout and rollback the amphora creation.
 >
 > Here is the worker.log relevant trace:
 >
 > 2018-08-07 07:33:57.108 24 INFO octavia.controller.queue.endpoint [-] 
 > Creating load balancer 'bf7ab6e4-081a-4b4d-b7a0-c176a9cb995e'...
 > 2018-08-07 07:33:57.220 24 INFO 
 > octavia.controller.worker.tasks.database_tasks [-] Created Amphora in DB 
 > with id c20af002-1576-446e-b99f-7af607b8d885
 > 2018-08-07 07:33:57.285 24 INFO octavia.certificates.generator.local [-] 
 > Signing a certificate request using OpenSSL locally.
 > 2018-08-07 07:33:57.285 24 INFO octavia.certificates.generator.local [-] 
 > Using CA Certificate from config.
 > 2018-08-07 07:33:57.285 24 INFO octavia.certificates.generator.local [-] 
 > Using CA Private Key from config.
 > 2018-08-07 07:33:57.286 24 INFO octavia.certificates.generator.local [-] 
 > Using CA Private Key Passphrase from config.
 > 2018-08-07 07:34:04.074 24 INFO 
 > octavia.controller.worker.tasks.database_tasks [-] Mark ALLOCATED in DB 
 > for amphora: c20af002-1576-446e-b99f-7af607b8d885 with compute id 
 > 3bbabfa6-366f-46a4-8fb2-1ec7158e19f1 for load balancer: 
 > bf7ab6e4-081a-4b4d-b7a0-c176a9cb995e
 > 2018-08-07 07:34:04.253 24 INFO 
 > octavia.network.drivers.neutron.allowed_address_pairs [-] Port 
 > a7bae53e-0bc6-4830-8c75-646a8baf2885 already exists. Nothing to be done.
 > 2018-08-07 07:34:19.656 24 WARNING 
 > octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect 
 > to instance. Retrying.: ConnectTimeout: 
 > HTTPSConnectionPool(host='10.1.56.103', port=9443): Max retries exceeded 
 > with url: /0.5/plug/vip/192.168.56.100 (Caused by 
 > ConnectTimeoutError(>>> >  object at 0x7f4c28415c50>, 'Connection to 10.1.56.103 timed out. 
 > (connect timeout=10.0)'))

Re: [Openstack-operators] [openstack-dev] [puppet] migrating to storyboard

[Kendall Nelson]

On Fri, Aug 17, 2018 at 12:15 AM Tobias Urdin 
wrote:

> Hello Kendall,
>
> I went through the list of projects [1] and could only really see two
> things.
>
> 1) puppet-rally and puppet-openstack-guide is missing
>
> I had created the projects, but missed adding them to the group. They
should be there now :)


> 2) We have some support projects which doesn't really need bug tracking,
> where some others do.
> You can remove puppet-openstack-specs and
> puppet-openstack-cookiecutter all others would be
> nice to still have left so we can track bugs. [2]
>
> i can remove them from the group if you want, but I don't think I can
delete the projects entirely.


> Best regards
> Tobias
>
> [1] https://storyboard-dev.openstack.org/#!/project_group/60
> [2] Keeping puppet-openstack-integration (integration testing) and
> puppet-openstack_spec_helper (helper for testing).
>   These two usually has a lot of changes so would be good to be able
> to track them.
>
>
> On 08/16/2018 09:40 PM, Kendall Nelson wrote:
>
> Hey :)
>
> I created all the puppet openstack repos in the storyboard-dev envrionment
> and made a project group[1]. I am struggling a bit with finding all of your
> launchpad projects to perform the migrations through, can you share a list
> of all of them?
>
> -Kendall (diablo_rojo)
>
> [1] https://storyboard-dev.openstack.org/#!/project_group/60
>
> On Wed, Aug 15, 2018 at 12:08 AM Tobias Urdin 
> wrote:
>
>> Hello Kendall,
>>
>> Thanks for your reply, that sounds awesome!
>> We can then dig around and see how everything looks when all project bugs
>> are imported to stories.
>>
>> I see no issues with being able to move to Storyboard anytime soon if the
>> feedback for
>> moving is positive.
>>
>> Best regards
>>
>> Tobias
>>
>>
>> On 08/14/2018 09:06 PM, Kendall Nelson wrote:
>>
>> Hello!
>>
>> The error you hit can be resolved by adding launchpadlib to your tox.ini
>> if I recall correctly..
>>
>> also, if you'd like, I can run a test migration of puppet's launchpad
>> projects into our storyboard-dev db (where I've done a ton of other test
>> migrations) if you want to see how it looks/works with a larger db. Just
>> let me know and I can kick it off.
>>
>> As for a time to migrate, if you all are good with it, we usually
>> schedule for Friday's so there is even less activity. Its a small project
>> config change and then we just need an infra core to kick off the script
>> once the change merges.
>>
>> -Kendall (diablo_rojo)
>>
>> On Tue, Aug 14, 2018 at 9:33 AM Tobias Urdin 
>> wrote:
>>
>>> Hello all incredible Puppeters,
>>>
>>> I've tested setting up an Storyboard instance and test migrated
>>> puppet-ceph and it went without any issues there using the documentation
>>> [1] [2]
>>> with just one minor issue during the SB setup [3].
>>>
>>> My goal is that we will be able to swap to Storyboard during the Stein
>>> cycle but considering that we have a low activity on
>>> bugs my opinion is that we could do this swap very easily anything soon
>>> as long as everybody is in favor of it.
>>>
>>> Please let me know what you think about moving to Storyboard?
>>> If everybody is in favor of it we can request a migration to infra
>>> according to documentation [2].
>>>
>>> I will continue to test the import of all our project while people are
>>> collecting their thoughts and feedback :)
>>>
>>> Best regards
>>> Tobias
>>>
>>> [1] https://docs.openstack.org/infra/storyboard/install/development.html
>>> [2] https://docs.openstack.org/infra/storyboard/migration.html
>>> [3] It failed with an error about launchpadlib not being installed,
>>> solved with `tox -e venv pip install launchpadlib`
>>>
>>>
>>> __
>>> 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




If that's all good now, I can kick off test migrations but having a
complete list of the launchpad projects you maintain and use would be super
helpful so I don't miss any. Is there somewhere this is documented? Or can
you send me a list?

-Kendall (diablo_rojo)
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

Re: [Openstack-operators] [openstack-dev] [kolla][ptg] Denver PTG on-site or virtual

[Mark Goddard]

Whether there is a physical PTG session or not, I'd certainly like to meet
up with other folks who are using and/or contributing to Kolla, let's be
sure to make time for that.
Mark

On 17 August 2018 at 12:54, Adam Harwell  wrote:

> As one of the other two in the etherpad, I will say that I was looking
> forward to getting together face to face with other contributors for the
> first time (as I am new to the project), but I guess the majority won't
> actually be there, and I understand that we need to do what is best for the
> majority as well.
> I know that at least one or maybe two other people from my team were also
> planning to attend some Kolla sessions, so I'll see if I can get them to
> sign up.
> The other projects I'll be focused on are Octavia and Barbican, and I know
> both have been successful with a hybrid approach in the past (providing
> video of the room and allowing folks to dial in and contribute, while also
> having a number of people present physically).
> Since the room is already reserved, I don't see a huge point in avoiding
> its use either.
>
>--Adam
>
>
> On Fri, Aug 17, 2018, 20:27 Mark Goddard  wrote:
>
>> As one of the lucky three kolleagues able to make the PTG, here's my
>> position (inline).
>>
>> On 17 August 2018 at 11:52, Eduardo Gonzalez  wrote:
>>
>>> Fellow kolleages.
>>>
>>> In september is Denver PTG, as per the etherpad [0] only 3 contributors
>>> confirmed their presence in the PTG, we expected more people to be there as
>>> previous PTGs were full of contributors and operators.
>>>
>>> In the last kolla meeting [1] with discussed if we should make a virtual
>>> PTG rather than a on-site one as we will probably reach a bigger number of
>>> attendance.
>>>
>>> This set us in a bad possition as per:
>>>
>>> If we do an on-site PTG
>>>
>>> - Small representation for a whole cycle design, being this one larger
>>> than usual.
>>> - Many people whiling to attend is not able to be there.
>>>
>>
>> I agree that three is too small a number to justify an on-site PTG. I was
>> planning to split my time between kolla and ironic, so being able to focus
>> on one project would be beneficial to me, assuming the virtual PTG takes
>> place at a different time. I could still split my time if the virtual PTG
>> occurs at the same time.
>>
>>
>>>
>>> If we do a virtual PTG
>>>
>>> - Some people already spend money to travel for kolla PTG
>>>
>>
>> I would be going anyway.
>>
>>
>>> - PTG rooms are already reserved for kolla session
>>>
>>
>> If the virtual PTG occurs at the same time, we could use the (oversized)
>> reserved room to dial into calls.
>>
>> - No cross project discussion
>>>
>>
>> Happy to attend on behalf of kolla and feed back to the team.
>>
>>>
>>> If there are more people who is going to Denver and haven't signed up at
>>> the etherpad, please confirm your presence as it will probably influence on
>>> this topic.
>>>
>>> Here is the though question...
>>>
>>> What kind of PTG do you prefer for this one, virtual or on-site in
>>> Denver?
>>>
>>
>> Virtual makes sense to me.
>>
>>>
>>> CC to Kendall Nelson from the foundation if she could help us on this
>>> though decission, given the small time we have until the PTG both ways have
>>> some kind of bad consecuencies for both the project and the contributors.
>>>
>>> [0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning
>>> [1] http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.
>>> 2018-08-15-15.00.log.html#l-13
>>>
>>> Regards
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>>> unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [kolla][ptg] Denver PTG on-site or virtual

[Mark Goddard]

As one of the lucky three kolleagues able to make the PTG, here's my
position (inline).

On 17 August 2018 at 11:52, Eduardo Gonzalez  wrote:

> Fellow kolleages.
>
> In september is Denver PTG, as per the etherpad [0] only 3 contributors
> confirmed their presence in the PTG, we expected more people to be there as
> previous PTGs were full of contributors and operators.
>
> In the last kolla meeting [1] with discussed if we should make a virtual
> PTG rather than a on-site one as we will probably reach a bigger number of
> attendance.
>
> This set us in a bad possition as per:
>
> If we do an on-site PTG
>
> - Small representation for a whole cycle design, being this one larger
> than usual.
> - Many people whiling to attend is not able to be there.
>

I agree that three is too small a number to justify an on-site PTG. I was
planning to split my time between kolla and ironic, so being able to focus
on one project would be beneficial to me, assuming the virtual PTG takes
place at a different time. I could still split my time if the virtual PTG
occurs at the same time.


>
> If we do a virtual PTG
>
> - Some people already spend money to travel for kolla PTG
>

I would be going anyway.


> - PTG rooms are already reserved for kolla session
>

If the virtual PTG occurs at the same time, we could use the (oversized)
reserved room to dial into calls.

- No cross project discussion
>

Happy to attend on behalf of kolla and feed back to the team.

>
> If there are more people who is going to Denver and haven't signed up at
> the etherpad, please confirm your presence as it will probably influence on
> this topic.
>
> Here is the though question...
>
> What kind of PTG do you prefer for this one, virtual or on-site in Denver?
>

Virtual makes sense to me.

>
> CC to Kendall Nelson from the foundation if she could help us on this
> though decission, given the small time we have until the PTG both ways have
> some kind of bad consecuencies for both the project and the contributors.
>
> [0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning
> [1] http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.
> 2018-08-15-15.00.log.html#l-13
>
> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [kolla][ptg] Denver PTG on-site or virtual

[Eduardo Gonzalez]

Fellow kolleages.

In september is Denver PTG, as per the etherpad [0] only 3 contributors
confirmed their presence in the PTG, we expected more people to be there as
previous PTGs were full of contributors and operators.

In the last kolla meeting [1] with discussed if we should make a virtual
PTG rather than a on-site one as we will probably reach a bigger number of
attendance.

This set us in a bad possition as per:

If we do an on-site PTG

- Small representation for a whole cycle design, being this one larger than
usual.
- Many people whiling to attend is not able to be there.

If we do a virtual PTG

- Some people already spend money to travel for kolla PTG
- PTG rooms are already reserved for kolla session
- No cross project discussion

If there are more people who is going to Denver and haven't signed up at
the etherpad, please confirm your presence as it will probably influence on
this topic.

Here is the though question...

What kind of PTG do you prefer for this one, virtual or on-site in Denver?

CC to Kendall Nelson from the foundation if she could help us on this
though decission, given the small time we have until the PTG both ways have
some kind of bad consecuencies for both the project and the contributors.

[0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning
[1]
http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-08-15-15.00.log.html#l-13

Regards
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [puppet] migrating to storyboard

[Tobias Urdin]

Hello Kendall,

I went through the list of projects [1] and could only really see two 
things.


1) puppet-rally and puppet-openstack-guide is missing

2) We have some support projects which doesn't really need bug tracking, 
where some others do.
    You can remove puppet-openstack-specs and 
puppet-openstack-cookiecutter all others would be

    nice to still have left so we can track bugs. [2]

Best regards
Tobias

[1] https://storyboard-dev.openstack.org/#!/project_group/60 

[2] Keeping puppet-openstack-integration (integration testing) and 
puppet-openstack_spec_helper (helper for testing).
  These two usually has a lot of changes so would be good to be 
able to track them.


On 08/16/2018 09:40 PM, Kendall Nelson wrote:

Hey :)

I created all the puppet openstack repos in the storyboard-dev 
envrionment and made a project group[1]. I am struggling a bit with 
finding all of your launchpad projects to perform the migrations 
through, can you share a list of all of them?


-Kendall (diablo_rojo)

[1] https://storyboard-dev.openstack.org/#!/project_group/60 



On Wed, Aug 15, 2018 at 12:08 AM Tobias Urdin > wrote:


Hello Kendall,

Thanks for your reply, that sounds awesome!
We can then dig around and see how everything looks when all
project bugs are imported to stories.

I see no issues with being able to move to Storyboard anytime soon
if the feedback for
moving is positive.

Best regards

Tobias


On 08/14/2018 09:06 PM, Kendall Nelson wrote:

Hello!

The error you hit can be resolved by adding launchpadlib to your
tox.ini if I recall correctly..

also, if you'd like, I can run a test migration of puppet's
launchpad projects into our storyboard-dev db (where I've done a
ton of other test migrations) if you want to see how it
looks/works with a larger db. Just let me know and I can kick it
off.

As for a time to migrate, if you all are good with it, we usually
schedule for Friday's so there is even less activity. Its a small
project config change and then we just need an infra core to kick
off the script once the change merges.

-Kendall (diablo_rojo)

On Tue, Aug 14, 2018 at 9:33 AM Tobias Urdin
mailto:tobias.ur...@binero.se>> wrote:

Hello all incredible Puppeters,

I've tested setting up an Storyboard instance and test migrated
puppet-ceph and it went without any issues there using the
documentation
[1] [2]
with just one minor issue during the SB setup [3].

My goal is that we will be able to swap to Storyboard during
the Stein
cycle but considering that we have a low activity on
bugs my opinion is that we could do this swap very easily
anything soon
as long as everybody is in favor of it.

Please let me know what you think about moving to Storyboard?
If everybody is in favor of it we can request a migration to
infra
according to documentation [2].

I will continue to test the import of all our project while
people are
collecting their thoughts and feedback :)

Best regards
Tobias

[1]
https://docs.openstack.org/infra/storyboard/install/development.html
[2] https://docs.openstack.org/infra/storyboard/migration.html
[3] It failed with an error about launchpadlib not being
installed,
solved with `tox -e venv pip install launchpadlib`


__
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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators