Re: [openstack-dev] [Magnum] TLS Support in Magnum

[Madhuri Rai]

Hi,

Thanks Adrian for the quick response. Please find my response inline.

On Mon, Jun 15, 2015 at 3:09 PM, Adrian Otto 
wrote:

>  Madhuri,
>
>  On Jun 14, 2015, at 10:30 PM, Madhuri Rai 
> wrote:
>
>Hi All,
>
> This is to bring the blueprint  secure-kubernetes
> <https://blueprints.launchpad.net/magnum/+spec/secure-kubernetes> in 
> discussion.
> I have been trying to figure out what could be the possible change area
> to support this feature in Magnum. Below is just a rough idea on how to
> proceed further on it.
>
> This task can be further broken in smaller pieces.
>
> *1. Add support for TLS in python-k8sclient.*
> The current auto-generated code doesn't support TLS. So this work will be
> to add TLS support in kubernetes python APIs.
>
> *2. Add support for Barbican in Magnum.*
>  Barbican will be used to store all the keys and certificates.
>
>
>  Keep in mind that not all clouds will support Barbican yet, so this
> approach could impair adoption of Magnum until Barbican is universally
> supported. It might be worth considering a solution that would generate all
> keys on the client, and copy them to the Bay master for communication with
> other Bay nodes. This is less secure than using Barbican, but would allow
> for use of Magnum before Barbican is adopted.
>

+1, I agree. One question here, we are trying to secure the communication
between magnum-conductor and kube-apiserver. Right?


>  If both methods were supported, the Barbican method should be the
> default, and we should put warning messages in the config file so that when
> the administrator relaxes the setting to use the non-Barbican configuration
> he/she is made aware that it requires a less secure mode of operation.
>

In non-Barbican support, client will generate the keys and pass the
location of the key to the magnum services. Then again heat template will
copy and configure the kubernetes services on master node. Same as the
below step.


>  My suggestion is to completely implement the Barbican support first, and
> follow up that implementation with a non-Barbican option as a second
> iteration for the feature.
>

How about implementing the non-Barbican support first as this would be easy
to implement, so that we can first concentrate on Point 1 and 3. And then
after it, we can work on Barbican support with more insights.

>
>  Another possibility would be for Magnum to use its own private
> installation of Barbican in cases where it is not available in the service
> catalog. I dislike this option because it creates an operational burden for
> maintaining the private Barbican service, and additional complexities with
> securing it.
>

In my opinion, installation of Barbican should be independent of Magnum. My
idea here is, if user wants to store his/her keys in Barbican then he/she
will install it.
We will have a config paramter like "store_secure" when True means we have
to store the keys in Barbican or else not.
What do you think?

>
>*3. Add support of TLS in Magnum.*
>  This work mainly involves supporting the use of key and certificates in
> magnum to support TLS.
>
> The user generates the keys, certificates and store them in Barbican. Now
> there is two way to access these keys while creating a bay.
>
>
>  Rather than "the user generates the keys…", perhaps it might be better to
> word that as "the magnum client library code generates the keys for the
> user…”.
>

It is "user" here. In my opinion, there could be users who don't want to
use magnum client rather the APIs directly, in that case the user will
generate the key themselves.

In our first implementation, we can support the user generating the keys
and then later client generating the keys.

>
> 1. Heat will access Barbican directly.
> While creating bay, the user will provide this key and heat templates will
> fetch this key from Barbican.
>
>
>  I think you mean that Heat will use the Barbican key to fetch the TLS key
> for accessing the native API service running on the Bay.
>
Yes.

>
> 2. Magnum-conductor access Barbican.
> While creating bay, the user will provide this key and then
> Magnum-conductor will fetch this key from Barbican and provide this key to
> heat.
>
> Then heat will copy this files on kubernetes master node. Then bay will
> use this key to start a Kubernetes services signed with these keys.
>
>
>  Make sure that the Barbican keys used by Heat and magnum-conductor to
> store the various TLS certificates/keys are unique per tenant and per bay,
> and are not shared among multiple tenants. We don’t want it to ever be
> possible to trick Magnum into revealing secrets belonging to other tenants.
>

Yes, I will take care of it.

[openstack-dev] [Magnum] TLS Support in Magnum

[Madhuri Rai]

Hi All,

This is to bring the blueprint  secure-kubernetes
 in
discussion.
I have been trying to figure out what could be the possible change area to
support this feature in Magnum. Below is just a rough idea on how to
proceed further on it.

This task can be further broken in smaller pieces.

*1. Add support for TLS in python-k8sclient.*
The current auto-generated code doesn't support TLS. So this work will be
to add TLS support in kubernetes python APIs.

*2. Add support for Barbican in Magnum.*
Barbican will be used to store all the keys and certificates.

*3. Add support of TLS in Magnum.*
This work mainly involves supporting the use of key and certificates in
magnum to support TLS.

The user generates the keys, certificates and store them in Barbican. Now
there is two way to access these keys while creating a bay.

1. Heat will access Barbican directly.
While creating bay, the user will provide this key and heat templates will
fetch this key from Barbican.


2. Magnum-conductor access Barbican.
While creating bay, the user will provide this key and then
Magnum-conductor will fetch this key from Barbican and provide this key to
heat.

Then heat will copy this files on kubernetes master node. Then bay will use
this key to start a Kubernetes services signed with these keys.


After discussion when we all come to same point, I will create separate
blueprints for each task.
I am currently working on configuring Kubernetes services with TLS keys.

Please provide your suggestions if any.


Regards,
Madhuri
__
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] Proposal for Madhuri Kumari to join Core Team

[Madhuri Rai]

Hi All,

Thank you for adding me to this team.

It will be my pleasure to work with you all together.
Till now, everyone has helped me in many or some way.

Thank you for all the support and this honor.

Looking forward for contributing more.


Thanks & Regards
Madhuri Kumari

On Fri, May 1, 2015 at 10:25 AM, Adrian Otto 
wrote:

>  Team,
>
>  Madnuri has been added to the magnum-core group [1]. Thanks everyone for
> your votes.
>
>  Regards,
>
>  Adrian
>
>  [1] https://review.openstack.org/#/admin/groups/473,members
>
>  On Apr 30, 2015, at 8:48 PM, Hongbin Lu  wrote:
>
>  +1!
>
> On Apr 28, 2015, at 11:14 PM, "Steven Dake (stdake)" 
> wrote:
>
>  Hi folks,
>
>  I would like to nominate Madhuri Kumari  to the core team for Magnum.
> Please remember a +1 vote indicates your acceptance.  A –1 vote acts as a
> complete veto.
>
>  Why Madhuri for core?
>
>1. She participates on IRC heavily
>2. She has been heavily involved in a really difficult project  to
>remove Kubernetes kubectl and replace it with a native python language
>binding which is really close to be done (TM)
>3. She provides helpful reviews and her reviews are of good quality
>
> Some of Madhuri’s stats, where she performs in the pack with the rest of
> the core team:
>
>  reviews: http://stackalytics.com/?release=kilo&module=magnum-group
> commits:
> http://stackalytics.com/?release=kilo&module=magnum-group&metric=commits
>
>  Please feel free to vote if your a Magnum core contributor.
>
>  Regards
> -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
>
>
>
> __
> 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] New fedora 21 Atomic images available for testing

[Madhuri Rai]

Hi Steve,

I tried to boot a vm with the new image from. But it doesn't work.
The vm state was ACTIVE but I can't ping or ssh to the vm.

If anyone has tested it, please let me know.

Also I would request folks to test the image so that we can pass it as we
need this image for Kubernetes Client.

Regards,
Madhuri


On Fri, Apr 24, 2015 at 2:00 PM, Madhuri Rai 
wrote:

> Hi Steve,
>
> Thank you for working on this.
>
> It will be really good for us to remove dependency on external projects.
>
> Regards,
> Madhuri
>
> On Fri, Apr 24, 2015 at 8:27 AM, Steven Dake (stdake) 
> wrote:
>
>>  Hi folks,
>>
>>  I have spent the last couple of days trying to bring some sanity to the
>> image building process for Magnum.
>>
>>  I have found a tool which the Atomic upstream produces which allows a
>> simple repeatable building process for Fedora Atomic images using any
>> upstream repos of our choosing.
>>
>>  I put in a kubernetes 0.15 COPR repo in this build.  Please test and
>> get back to me either on irc or the ML.
>>
>>  The image is available for download from here:
>> https://fedorapeople.org/groups/magnum/fedora-21-atomic-3.qcow2.xz
>> <https://fedorapeople.org/groups/magnum/>
>>
>>  Regards,
>> -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] [magnum] New fedora 21 Atomic images available for testing

[Madhuri Rai]

Hi Steve,

Thank you for working on this.

It will be really good for us to remove dependency on external projects.

Regards,
Madhuri

On Fri, Apr 24, 2015 at 8:27 AM, Steven Dake (stdake) 
wrote:

>  Hi folks,
>
>  I have spent the last couple of days trying to bring some sanity to the
> image building process for Magnum.
>
>  I have found a tool which the Atomic upstream produces which allows a
> simple repeatable building process for Fedora Atomic images using any
> upstream repos of our choosing.
>
>  I put in a kubernetes 0.15 COPR repo in this build.  Please test and get
> back to me either on irc or the ML.
>
>  The image is available for download from here:
> https://fedorapeople.org/groups/magnum/fedora-21-atomic-3.qcow2.xz
> 
>
>  Regards,
> -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] [magnum] swagger-codegen generated code for python-k8sclient

[Madhuri Rai]

Hi All,

As we are using fedora-21-atomic-2 image and that has Kubernetes v0.11.0, I
tried to run v1beta3 APIs on it. Some of the APIs failed.
The Kubernetes developer said "v1beta3 wasn't fully supported until the
0.15.0 release". Hence this is causing some APIs to fail.

Below are the failures:

1. service-create API fail(422 status) with v1beta3 request format.
The request format has changed from v1beta1 to v1beta3.

https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/api.md#v1beta3-conversion-tips

I have logged an issue for the same at GoogleCloudPlatform/Kubernetes:
https://github.com/GoogleCloudPlatform/kubernetes/issues/7157

2. pod-create API fail(500 status) with invalid request format.
While doing negative testing, I found that pod-create API fails with
500 status. It should actually fail with 400 status.

I have logged an issue for the same at GoogleCloudPlatform/Kubernetes:
https://github.com/GoogleCloudPlatform/kubernetes/issues/7087

3. pod-update API fail(404).
While trying to update a pod*, *it failed with status 404 even if the
pod exists. This is due to duplicate replacePod API in Kubernetes Client
code.

I have logged an issue for the same at GoogleCloudPlatform/Kubernetes:
https://github.com/GoogleCloudPlatform/kubernetes/issues/7100

4. All APIs fail with json manifest.
All Kubernetes resources(pod, rc, service) now fails with json format
manifest due to issue in swagger-codegen generated Kubernetes Client code.
It doesn't support unicode string.

After all this issues, can we really switch to Kubernetes Client in this
release or should we wait for the Fedora image with Kubernetes 0.15.0
release that has full support of v1beta3?

Please provide your suggestions on this so that I can proceed further.

 Thanks & Regards
Madhuri Kumari


On Tue, Mar 24, 2015 at 10:37 AM, Madhuri Rai 
wrote:

> Hi Hongbin,
>
>
> On Tue, Mar 24, 2015 at 12:37 AM, Hongbin Lu  wrote:
>
>> Hi Madhuri,
>>
>> Amazing work! I wouldn't concern the code duplication and modularity
>> issue since the codes are generated. However, there is another concern
>> here: if we find a bug/improvement of the generated code, we probably need
>> to modify the generator. The question is if the upstream will accept the
>> modifications? If yes, how fast the patch will go through.
>>
>> I would prefer to maintain a folk of the generator. By this way, we would
>> have full control of the generated code. Thoughts?
>>
>
> I agree that's a concern. I will try to fix the pep8 error upstream to
> look how it take to push a change upstream.
>
>
>> Thanks,
>> Hongbin
>>
>> On Mon, Mar 23, 2015 at 10:11 AM, Steven Dake (stdake) 
>> wrote:
>>
>>>
>>>
>>>   From: Madhuri Rai 
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" 
>>> Date: Monday, March 23, 2015 at 1:53 AM
>>> To: "openstack-dev@lists.openstack.org" <
>>> openstack-dev@lists.openstack.org>
>>> Subject: [openstack-dev] [magnum] swagger-codegen generated code for
>>> python-k8sclient
>>>
>>>   Hi All,
>>>
>>> This is to have a discussion on the blueprint for implementing
>>> python-k8client for magnum.
>>>
>>> https://blueprints.launchpad.net/magnum/+spec/python-k8sclient
>>>
>>> I have committed the code generated by swagger-codegen at
>>> https://review.openstack.org/#/c/166720/.
>>> But I feel the quality of the code generated by swagger-codegen is not
>>> good.
>>>
>>> Some of the points:
>>> 1) There is lot of code duplication. If we want to generate code for two
>>> or more versions, same code is duplicated for each API version.
>>> 2) There is no modularity. CLI code for all the APIs are written in same
>>> file.
>>>
>>> So, I would like your opinion on this. How should we proceed further?
>>>
>>>
>>>  Madhuri,
>>>
>>>  First off, spectacular that you figured out how to do this!  Great
>>> great job!  I suspected the swagger code would be a bunch of garbage.  Just
>>> looking over the review, the output isn’t too terribly bad.  It has some
>>> serious pep8 problems.
>>>
>>>  Now that we have seen the swagger code generator works, we need to see
>>> if it produces useable output.  In other words, can the API be used by the
>>> magnum backend.  Google is “all-in” on swagger for their API model.
>>> Realistically maintaining a python binding would be a huge job.  If we
>>> could just use swagger for the sh

Re: [openstack-dev] Regarding openstack swift implementation

[Madhuri Rai]

Hi,

You can go through below link to get started.

http://docs.openstack.org/developer/swift/development_saio.html


Thanks
Madhuri Kumari

On Tue, Apr 21, 2015 at 2:09 PM, Subbulakshmi Subha <
subbulakshmisubh...@gmail.com> wrote:

> Hi,
> I am trying to simulate openstack swift.could you please help me with
> getting started.what are all the details I should be knowing to store
> objects on swift?
>
> __
> 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] swagger-codegen generated code for python-k8sclient

[Madhuri Rai]

Hi Hongbin,


On Tue, Mar 24, 2015 at 12:37 AM, Hongbin Lu  wrote:

> Hi Madhuri,
>
> Amazing work! I wouldn't concern the code duplication and modularity issue
> since the codes are generated. However, there is another concern here: if
> we find a bug/improvement of the generated code, we probably need to modify
> the generator. The question is if the upstream will accept the
> modifications? If yes, how fast the patch will go through.
>
> I would prefer to maintain a folk of the generator. By this way, we would
> have full control of the generated code. Thoughts?
>

I agree that's a concern. I will try to fix the pep8 error upstream to look
how it take to push a change upstream.


> Thanks,
> Hongbin
>
> On Mon, Mar 23, 2015 at 10:11 AM, Steven Dake (stdake) 
> wrote:
>
>>
>>
>>   From: Madhuri Rai 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Monday, March 23, 2015 at 1:53 AM
>> To: "openstack-dev@lists.openstack.org" <
>> openstack-dev@lists.openstack.org>
>> Subject: [openstack-dev] [magnum] swagger-codegen generated code for
>> python-k8sclient
>>
>>   Hi All,
>>
>> This is to have a discussion on the blueprint for implementing
>> python-k8client for magnum.
>>
>> https://blueprints.launchpad.net/magnum/+spec/python-k8sclient
>>
>> I have committed the code generated by swagger-codegen at
>> https://review.openstack.org/#/c/166720/.
>> But I feel the quality of the code generated by swagger-codegen is not
>> good.
>>
>> Some of the points:
>> 1) There is lot of code duplication. If we want to generate code for two
>> or more versions, same code is duplicated for each API version.
>> 2) There is no modularity. CLI code for all the APIs are written in same
>> file.
>>
>> So, I would like your opinion on this. How should we proceed further?
>>
>>
>>  Madhuri,
>>
>>  First off, spectacular that you figured out how to do this!  Great
>> great job!  I suspected the swagger code would be a bunch of garbage.  Just
>> looking over the review, the output isn’t too terribly bad.  It has some
>> serious pep8 problems.
>>
>>  Now that we have seen the swagger code generator works, we need to see
>> if it produces useable output.  In other words, can the API be used by the
>> magnum backend.  Google is “all-in” on swagger for their API model.
>> Realistically maintaining a python binding would be a huge job.  If we
>> could just use swagger for the short term, even though its less then ideal,
>> that would be my preference.  Even if its suboptimal.  We can put a readme
>> in the TLD saying the code was generated by a a code generator and explain
>> how to generate the API.
>>
>>  One last question.  I didn’t see immediately by looking at the api, but
>> does it support TLS auth?  We will need that.
>>
>>  Super impressed!
>>
>>  Regards
>> -steve
>>
>>
>>
>> Regards,
>> Madhuri Kumari
>>
>>
>> __
>> 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
>
> Regards,
Madhuri Kumari
__
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] swagger-codegen generated code for python-k8sclient

[Madhuri Rai]

Hi Steven,


On Mon, Mar 23, 2015 at 11:11 PM, Steven Dake (stdake) 
wrote:

>
>
>   From: Madhuri Rai 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Monday, March 23, 2015 at 1:53 AM
> To: "openstack-dev@lists.openstack.org"  >
> Subject: [openstack-dev] [magnum] swagger-codegen generated code for
> python-k8sclient
>
>   Hi All,
>
> This is to have a discussion on the blueprint for implementing
> python-k8client for magnum.
>
> https://blueprints.launchpad.net/magnum/+spec/python-k8sclient
>
> I have committed the code generated by swagger-codegen at
> https://review.openstack.org/#/c/166720/.
> But I feel the quality of the code generated by swagger-codegen is not
> good.
>
> Some of the points:
> 1) There is lot of code duplication. If we want to generate code for two
> or more versions, same code is duplicated for each API version.
> 2) There is no modularity. CLI code for all the APIs are written in same
> file.
>
> So, I would like your opinion on this. How should we proceed further?
>
>
>  Madhuri,
>
>  First off, spectacular that you figured out how to do this!  Great great
> job!  I suspected the swagger code would be a bunch of garbage.  Just
> looking over the review, the output isn’t too terribly bad.  It has some
> serious pep8 problems.
>
>  Now that we have seen the swagger code generator works, we need to see
> if it produces useable output.  In other words, can the API be used by the
> magnum backend.  Google is “all-in” on swagger for their API model.
> Realistically maintaining a python binding would be a huge job.  If we
> could just use swagger for the short term, even though its less then ideal,
> that would be my preference.  Even if its suboptimal.  We can put a readme
> in the TLD saying the code was generated by a a code generator and explain
> how to generate the API.
>

I have started working on it and will surely look whether some improvement
can be done or not. And also will try to use it magnum.


>
>  One last question.  I didn’t see immediately by looking at the api, but
> does it support TLS auth?  We will need that.
>

I am not sure about it. I will check and let you know.

>
>  Super impressed!
>
>  Regards
> -steve
>
>
>
> Regards,
> Madhuri Kumari
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
Regards,
Madhuri Kumari
__
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] [magnum] swagger-codegen generated code for python-k8sclient

[Madhuri Rai]

Hi All,

This is to have a discussion on the blueprint for implementing
python-k8client for magnum.

https://blueprints.launchpad.net/magnum/+spec/python-k8sclient

I have committed the code generated by swagger-codegen at
https://review.openstack.org/#/c/166720/.
But I feel the quality of the code generated by swagger-codegen is not good.

Some of the points:
1) There is lot of code duplication. If we want to generate code for two or
more versions, same code is duplicated for each API version.
2) There is no modularity. CLI code for all the APIs are written in same
file.

So, I would like your opinion on this. How should we proceed further?

Regards,
Madhuri Kumari
__
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