Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
Thanks for the awesome feedback :) I got the point of not using project name, thanks Dean for explaining it so well. We will move ahead as per Monty's suggestion. On Wed, Oct 14, 2015 at 3:13 PM, Sean Dague wrote: > On 10/12/2015 07:55 PM, Dean Troyer wrote: > > On Mon, Oct 12, 2015 at 5:25 PM, Victoria Martínez de la Cruz > > mailto:victo...@vmartinezdelacruz.com>> > > wrote: > > > > So, this commands would look like > > > > openstack pool-flavor create > > openstack pool-flavor get > > openstack pool-flavor delete > > openstack pool-flavor update > > openstack pool-flavor list > > > > > > I would strongly suggest leaving the dash out of the resource name: > > > > openstack pool flavor create > > etc > > > > Multiple word names have been supported for a long time and the only > > other plugin I know that has them has a bug against it to remove the > dash. > > So, this might just be me, but I find all the multi word resources to be > really confusing to use for multiple reasons. > > 1) my brain is thinking[options]. When presented > with it does a lot of thinking is a verb, oh wait > it's not, oh wait in this case is it. Is C more verby or B more verby. > etc etc. > > Basically we've removed a very simple rule for how commands look, which > means more brain power figuring out how each command independently works. > > 2) openstack pool -h is an error. That's massively surprising. openstack > help pool (no such command!). > > So while I realize this has been the pattern in the past, it's never > really worked well for me at least. > > -Sean > > -- > Sean Dague > http://dague.net > > __ > 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] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
On 10/12/2015 07:55 PM, Dean Troyer wrote: > On Mon, Oct 12, 2015 at 5:25 PM, Victoria Martínez de la Cruz > mailto:victo...@vmartinezdelacruz.com>> > wrote: > > So, this commands would look like > > openstack pool-flavor create > openstack pool-flavor get > openstack pool-flavor delete > openstack pool-flavor update > openstack pool-flavor list > > > I would strongly suggest leaving the dash out of the resource name: > > openstack pool flavor create > etc > > Multiple word names have been supported for a long time and the only > other plugin I know that has them has a bug against it to remove the dash. So, this might just be me, but I find all the multi word resources to be really confusing to use for multiple reasons. 1) my brain is thinking[options]. When presented with it does a lot of thinking is a verb, oh wait it's not, oh wait in this case is it. Is C more verby or B more verby. etc etc. Basically we've removed a very simple rule for how commands look, which means more brain power figuring out how each command independently works. 2) openstack pool -h is an error. That's massively surprising. openstack help pool (no such command!). So while I realize this has been the pattern in the past, it's never really worked well for me at least. -Sean -- Sean Dague http://dague.net __ 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] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
On 13/10/15 18:27 -0400, Monty Taylor wrote: On 10/13/2015 05:15 PM, Dean Troyer wrote: On Tue, Oct 13, 2015 at 3:58 PM, Shifali Agrawal mailto:shaifali.agrawa...@gmail.com>> wrote: All above make sense, just one thing, how about using word "zaqar" instead of messaging? That is what all other projects are doing, for example: These are the old project-specific CLIs, note that the 'keystone' command only supports v2 auth today and will be removed entirely in the keystoneclient 2.0 release. $ keystone user-create $ heat event-list This will create a separate namespace for the project and also will solve the issue of `openstack messaging message post`. One of the things I have tried very hard to do is make it so users do NOT need to know which API handles a given command. For higher-layer projects that is less of a concern I suppose, and that was done long before anyone thought that 20+ APIs would be handled in a single command set. I agree very strongly with this goal. We've done the same thing with the new ansible modules. (os_server vs. nova_compute) It becomes especially important when there are things that are the same but handled by different services. Should the user know/care that in cloud A they get a floating IP from nova but in cloud B they get it from neutron? Nope. That's a mess in our yard - the user shouldn't need to know. Namespacing has come up and is something we need to discuss further, either within the 'openstack' command itself or by using additional top-level command names. This is one of the topics for discussion in Tokyo, but has already started on the ML for those that will not be present. No matter how we end up handling the namespacing issue, I will still strongly insist that project code names not be used. I know some plugins already do this today and we can't stop anyone else from doing it, but it leads to the same sort of inconsistency for users that the original project CLIs had. It reduces the value of a single (or small set of) CLI for the user to deal with. FWIW - in the ansible modules we adopted a general naming policy of non-service names for things that end-users want to interact with (server, floating-ip) because they are not deployers and they should care. For admin things "create keystone domain" "create nova flavor" we have the service name in - partially because of the namespacing problem, but also because an _admin_ is administering a service called "nova" - they are not consuming a service that might be provided by nova ... they can be expected to know. So we have: os_nova_flavor and will soon have os_keystone_domain but os_image and os_subnet. This is great feedback and I think it actually hits the problem we're having. The problem is not really related to the user facing API but the admins one. I fully agree with the suggestion of not using project names, which is why I originally recomended to use the catalog service type. That said, I think this can be worked out better and we chould follow sometihng similar to what Monty mentioned. I guess my remaining concern here is that this standard assumes that there's just 1 messaging service that could be used and whenever someone calls `openstack message post...` is talking to Zaqar. Cheers, Flavio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature __ 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] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
On 10/13/2015 05:15 PM, Dean Troyer wrote: On Tue, Oct 13, 2015 at 3:58 PM, Shifali Agrawal mailto:shaifali.agrawa...@gmail.com>> wrote: All above make sense, just one thing, how about using word "zaqar" instead of messaging? That is what all other projects are doing, for example: These are the old project-specific CLIs, note that the 'keystone' command only supports v2 auth today and will be removed entirely in the keystoneclient 2.0 release. $ keystone user-create $ heat event-list This will create a separate namespace for the project and also will solve the issue of `openstack messaging message post`. One of the things I have tried very hard to do is make it so users do NOT need to know which API handles a given command. For higher-layer projects that is less of a concern I suppose, and that was done long before anyone thought that 20+ APIs would be handled in a single command set. I agree very strongly with this goal. We've done the same thing with the new ansible modules. (os_server vs. nova_compute) It becomes especially important when there are things that are the same but handled by different services. Should the user know/care that in cloud A they get a floating IP from nova but in cloud B they get it from neutron? Nope. That's a mess in our yard - the user shouldn't need to know. Namespacing has come up and is something we need to discuss further, either within the 'openstack' command itself or by using additional top-level command names. This is one of the topics for discussion in Tokyo, but has already started on the ML for those that will not be present. No matter how we end up handling the namespacing issue, I will still strongly insist that project code names not be used. I know some plugins already do this today and we can't stop anyone else from doing it, but it leads to the same sort of inconsistency for users that the original project CLIs had. It reduces the value of a single (or small set of) CLI for the user to deal with. FWIW - in the ansible modules we adopted a general naming policy of non-service names for things that end-users want to interact with (server, floating-ip) because they are not deployers and they should care. For admin things "create keystone domain" "create nova flavor" we have the service name in - partially because of the namespacing problem, but also because an _admin_ is administering a service called "nova" - they are not consuming a service that might be provided by nova ... they can be expected to know. So we have: os_nova_flavor and will soon have os_keystone_domain but os_image and os_subnet. __ 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] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
On 14/10/15 10:15, Dean Troyer wrote: On Tue, Oct 13, 2015 at 3:58 PM, Shifali Agrawal mailto:shaifali.agrawa...@gmail.com>> wrote: All above make sense, just one thing, how about using word "zaqar" instead of messaging? That is what all other projects are doing, for example: These are the old project-specific CLIs, note that the 'keystone' command only supports v2 auth today and will be removed entirely in the keystoneclient 2.0 release. $ keystone user-create $ heat event-list This will create a separate namespace for the project and also will solve the issue of `openstack messaging message post`. One of the things I have tried very hard to do is make it so users do NOT need to know which API handles a given command. For higher-layer projects that is less of a concern I suppose, and that was done long before anyone thought that 20+ APIs would be handled in a single command set. Namespacing has come up and is something we need to discuss further, either within the 'openstack' command itself or by using additional top-level command names. This is one of the topics for discussion in Tokyo, but has already started on the ML for those that will not be present. No matter how we end up handling the namespacing issue, I will still strongly insist that project code names not be used. I know some plugins already do this today and we can't stop anyone else from doing it, but it leads to the same sort of inconsistency for users that the original project CLIs had. It reduces the value of a single (or small set of) CLI for the user to deal with. I would agree with Dean here. "messaging" is a service, not a thing the service provides. I'd like to think that commands can be built using a list of nouns, with the first noun making it sufficiently obvious of the general family of things you're working on. "queue" seems to fit as the first noun in this case, so how about: openstack queue post openstack queue pool flavor create openstack queue pool flavor get openstack queue pool flavor delete openstack queue pool flavor update openstack queue pool flavor list openstack queue pool create __ 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] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
On Tue, Oct 13, 2015 at 3:58 PM, Shifali Agrawal < shaifali.agrawa...@gmail.com> wrote: > All above make sense, just one thing, how about using word "zaqar" > instead of messaging? That is what all other projects are doing, for > example: > These are the old project-specific CLIs, note that the 'keystone' command only supports v2 auth today and will be removed entirely in the keystoneclient 2.0 release. $ keystone user-create > $ heat event-list > > This will create a separate namespace for the project and also will solve > the issue of `openstack messaging message post`. > One of the things I have tried very hard to do is make it so users do NOT need to know which API handles a given command. For higher-layer projects that is less of a concern I suppose, and that was done long before anyone thought that 20+ APIs would be handled in a single command set. Namespacing has come up and is something we need to discuss further, either within the 'openstack' command itself or by using additional top-level command names. This is one of the topics for discussion in Tokyo, but has already started on the ML for those that will not be present. No matter how we end up handling the namespacing issue, I will still strongly insist that project code names not be used. I know some plugins already do this today and we can't stop anyone else from doing it, but it leads to the same sort of inconsistency for users that the original project CLIs had. It reduces the value of a single (or small set of) CLI for the user to deal with. dt -- Dean Troyer dtro...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
On Tue, Oct 13, 2015 at 12:05 PM, Flavio Percoco wrote: > On 12/10/15 19:25 -0300, Victoria Martínez de la Cruz wrote: > >> HI all, >> >> Thanks for your feedback. We discussed this topic in this week weekly >> meeting >> and we came to the conclusion that it would be better to use "pool-flavor" >> instead of creating a namespace for Zaqar only (by prefixing everything >> with >> the "message" key). >> >> So, this commands would look like >> >> openstack pool-flavor create >> openstack pool-flavor get >> openstack pool-flavor delete >> openstack pool-flavor update >> openstack pool-flavor list >> > > First and foremost, I'm sorry for not attending the last meeting. > > I just read the logs from the meeting and I'd like to raise my > concerns with the above. I think it's very confusing for users to have > a non-namespaced command. > > For example, what's a pool-flavor? Is it related to Nova's flavors? Is > it something related to some network pools? etc. > > I understand that one of the concerns is that things like `openstack > message message post` wouldn't look good but I think that the project > namespace could match the service catalog (will let folks for OSC > confirm/deny this). > > Some examples: > > $ openstack messaging post > $ openstack messaging flavor create > $ openstack messaging pool add > > etc > > Does the above make sense? All above make sense, just one thing, how about using word "zaqar" instead of messaging? That is what all other projects are doing, for example: $ keystone user-create $ heat event-list This will create a separate namespace for the project and also will solve the issue of `openstack messaging message post`. __ 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] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
On 13/10/15 16:46, Fox, Kevin M wrote: > lb's use the term pools too. A little more specific might be good. > > Thanks, > Kevin > > *From:* Victoria Martínez de la Cruz [victo...@vmartinezdelacruz.com] > *Sent:* Tuesday, October 13, 2015 5:28 AM > *To:* Flavio Percoco; OpenStack Development Mailing List (not for usage > questions) > *Subject:* Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in > nova flavor and zaqar flavor > > Fair enough, +1 to Flavio's suggestion > > Thanks all, > > Victoria > > 2015-10-13 3:35 GMT-03:00 Flavio Percoco <mailto:fla...@redhat.com>>: > > On 12/10/15 19:25 -0300, Victoria Martínez de la Cruz wrote: > > HI all, > > Thanks for your feedback. We discussed this topic in this week > weekly meeting > and we came to the conclusion that it would be better to use > "pool-flavor" > instead of creating a namespace for Zaqar only (by prefixing > everything with > the "message" key). > > So, this commands would look like > > openstack pool-flavor create > openstack pool-flavor get > openstack pool-flavor delete > openstack pool-flavor update > openstack pool-flavor list > > > First and foremost, I'm sorry for not attending the last meeting. > > I just read the logs from the meeting and I'd like to raise my > concerns with the above. I think it's very confusing for users to have > a non-namespaced command. > > For example, what's a pool-flavor? Is it related to Nova's flavors? Is > it something related to some network pools? etc. > > I understand that one of the concerns is that things like `openstack > message message post` wouldn't look good but I think that the project > namespace could match the service catalog (will let folks for OSC > confirm/deny this). > > Some examples: > > $ openstack messaging post > $ openstack messaging flavor create > $ openstack messaging pool add > > etc > > Does the above make sense? > Flavio > > > > Best, > > Victoria > > 2015-10-10 10:10 GMT-03:00 Shifali Agrawal > <mailto:shaifali.agrawa...@gmail.com>>: > >All right, thanks for responses, will code accordingly :) > >On Wed, Oct 7, 2015 at 9:31 PM, Doug Hellmann > mailto:d...@doughellmann.com>> >wrote: > >Excerpts from Steve Martinelli's message of 2015-10-06 > 16:09:32 -0400: >> >> Using `message flavor` works for me, and having two > words is just >fine. > >It might even be good to change "flavor" to "server > flavor" (keeping >flavor as a backwards-compatible alias, of course). > Doug > > >> I'm in the process of collecting all of the existing > "object" works >are >> putting them online, there's a lot of them. Hopefully > this will >reduce the >> collisions in the future. >> >> Thanks, >> >> Steve Martinelli >> OpenStack Keystone Core >> >> >> >> From:Shifali Agrawal <mailto:shaifali.agrawa...@gmail.com>> >> To:openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org> >> Date:2015/10/06 03:40 PM >> Subject:[openstack-dev] > [Zaqar][cli][openstack-client] conflict >in nova >> flavor and zaqar flavor >> >> >> >> Greetings, >> >> I am implementing cli commands for Zaqar flavors, the > command should >be >> like: >> >> "openstack flavor " >> >> But there is already same command present for Nova > flavors. After >> discussing with Zaqa
Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
lb's use the term pools too. A little more specific might be good. Thanks, Kevin From: Victoria Martínez de la Cruz [victo...@vmartinezdelacruz.com] Sent: Tuesday, October 13, 2015 5:28 AM To: Flavio Percoco; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor Fair enough, +1 to Flavio's suggestion Thanks all, Victoria 2015-10-13 3:35 GMT-03:00 Flavio Percoco mailto:fla...@redhat.com>>: On 12/10/15 19:25 -0300, Victoria Martínez de la Cruz wrote: HI all, Thanks for your feedback. We discussed this topic in this week weekly meeting and we came to the conclusion that it would be better to use "pool-flavor" instead of creating a namespace for Zaqar only (by prefixing everything with the "message" key). So, this commands would look like openstack pool-flavor create openstack pool-flavor get openstack pool-flavor delete openstack pool-flavor update openstack pool-flavor list First and foremost, I'm sorry for not attending the last meeting. I just read the logs from the meeting and I'd like to raise my concerns with the above. I think it's very confusing for users to have a non-namespaced command. For example, what's a pool-flavor? Is it related to Nova's flavors? Is it something related to some network pools? etc. I understand that one of the concerns is that things like `openstack message message post` wouldn't look good but I think that the project namespace could match the service catalog (will let folks for OSC confirm/deny this). Some examples: $ openstack messaging post $ openstack messaging flavor create $ openstack messaging pool add etc Does the above make sense? Flavio Best, Victoria 2015-10-10 10:10 GMT-03:00 Shifali Agrawal mailto:shaifali.agrawa...@gmail.com>>: All right, thanks for responses, will code accordingly :) On Wed, Oct 7, 2015 at 9:31 PM, Doug Hellmann mailto:d...@doughellmann.com>> wrote: Excerpts from Steve Martinelli's message of 2015-10-06 16:09:32 -0400: > > Using `message flavor` works for me, and having two words is just fine. It might even be good to change "flavor" to "server flavor" (keeping flavor as a backwards-compatible alias, of course). Doug > > I'm in the process of collecting all of the existing "object" works are > putting them online, there's a lot of them. Hopefully this will reduce the > collisions in the future. > > Thanks, > > Steve Martinelli > OpenStack Keystone Core > > > > From:Shifali Agrawal mailto:shaifali.agrawa...@gmail.com>> > To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org> > Date:2015/10/06 03:40 PM > Subject:[openstack-dev] [Zaqar][cli][openstack-client] conflict in nova > flavor and zaqar flavor > > > > Greetings, > > I am implementing cli commands for Zaqar flavors, the command should be > like: > > "openstack flavor " > > But there is already same command present for Nova flavors. After > discussing with Zaqar devs we thought to change all zaqar commands such > that they include `message` word after openstack, thus above Zaqar flavor > command will become: > > "openstack message flavor " > > Does openstack-client devs have something to say for this? Or they also > feel its good to move with adding `message` word to all Zaqar cli > commands? > > Already existing Zaqar commands will work with get a deprecation > message/warning and also I will implement them all to work with `message` > word, and all new commands will be implement so that they work only with > `message` word. __ 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 __ 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:u
Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
Fair enough, +1 to Flavio's suggestion Thanks all, Victoria 2015-10-13 3:35 GMT-03:00 Flavio Percoco : > On 12/10/15 19:25 -0300, Victoria Martínez de la Cruz wrote: > >> HI all, >> >> Thanks for your feedback. We discussed this topic in this week weekly >> meeting >> and we came to the conclusion that it would be better to use "pool-flavor" >> instead of creating a namespace for Zaqar only (by prefixing everything >> with >> the "message" key). >> >> So, this commands would look like >> >> openstack pool-flavor create >> openstack pool-flavor get >> openstack pool-flavor delete >> openstack pool-flavor update >> openstack pool-flavor list >> > > First and foremost, I'm sorry for not attending the last meeting. > > I just read the logs from the meeting and I'd like to raise my > concerns with the above. I think it's very confusing for users to have > a non-namespaced command. > > For example, what's a pool-flavor? Is it related to Nova's flavors? Is > it something related to some network pools? etc. > > I understand that one of the concerns is that things like `openstack > message message post` wouldn't look good but I think that the project > namespace could match the service catalog (will let folks for OSC > confirm/deny this). > > Some examples: > > $ openstack messaging post > $ openstack messaging flavor create > $ openstack messaging pool add > > etc > > Does the above make sense? > Flavio > > > >> Best, >> >> Victoria >> >> 2015-10-10 10:10 GMT-03:00 Shifali Agrawal > >: >> >>All right, thanks for responses, will code accordingly :) >> >>On Wed, Oct 7, 2015 at 9:31 PM, Doug Hellmann >>wrote: >> >>Excerpts from Steve Martinelli's message of 2015-10-06 16:09:32 >> -0400: >>> >>> Using `message flavor` works for me, and having two words is just >>fine. >> >>It might even be good to change "flavor" to "server flavor" >> (keeping >>flavor as a backwards-compatible alias, of course). >> Doug >> > >>> I'm in the process of collecting all of the existing "object" >> works >>are >>> putting them online, there's a lot of them. Hopefully this will >>reduce the >>> collisions in the future. >>> >>> Thanks, >>> >>> Steve Martinelli >>> OpenStack Keystone Core >>> >>> >>> >>> From:Shifali Agrawal >>> To:openstack-dev@lists.openstack.org >>> Date:2015/10/06 03:40 PM >>> Subject:[openstack-dev] [Zaqar][cli][openstack-client] >> conflict >>in nova >>> flavor and zaqar flavor >>> >>> >>> >>> Greetings, >>> >>> I am implementing cli commands for Zaqar flavors, the command >> should >>be >>> like: >>> >>> "openstack flavor " >>> >>> But there is already same command present for Nova flavors. After >>> discussing with Zaqar devs we thought to change all zaqar >> commands >>such >>> that they include `message` word after openstack, thus above >> Zaqar >>flavor >>> command will become: >>> >>> "openstack message flavor " >>> >>> Does openstack-client devs have something to say for this? Or >> they >>also >>> feel its good to move with adding `message` word to all Zaqar cli >>> commands? >>> >>> Already existing Zaqar commands will work with get a deprecation >>> message/warning and also I will implement them all to work with >>`message` >>> word, and all new commands will be implement so that they work >> only >>with >>> `message` word. >> >> >> __ >>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 >> > > > -- > @flaper87 > Flavio Percoco > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsub
Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
On 12/10/15 19:25 -0300, Victoria Martínez de la Cruz wrote: HI all, Thanks for your feedback. We discussed this topic in this week weekly meeting and we came to the conclusion that it would be better to use "pool-flavor" instead of creating a namespace for Zaqar only (by prefixing everything with the "message" key). So, this commands would look like openstack pool-flavor create openstack pool-flavor get openstack pool-flavor delete openstack pool-flavor update openstack pool-flavor list First and foremost, I'm sorry for not attending the last meeting. I just read the logs from the meeting and I'd like to raise my concerns with the above. I think it's very confusing for users to have a non-namespaced command. For example, what's a pool-flavor? Is it related to Nova's flavors? Is it something related to some network pools? etc. I understand that one of the concerns is that things like `openstack message message post` wouldn't look good but I think that the project namespace could match the service catalog (will let folks for OSC confirm/deny this). Some examples: $ openstack messaging post $ openstack messaging flavor create $ openstack messaging pool add etc Does the above make sense? Flavio Best, Victoria 2015-10-10 10:10 GMT-03:00 Shifali Agrawal : All right, thanks for responses, will code accordingly :) On Wed, Oct 7, 2015 at 9:31 PM, Doug Hellmann wrote: Excerpts from Steve Martinelli's message of 2015-10-06 16:09:32 -0400: > > Using `message flavor` works for me, and having two words is just fine. It might even be good to change "flavor" to "server flavor" (keeping flavor as a backwards-compatible alias, of course). Doug > > I'm in the process of collecting all of the existing "object" works are > putting them online, there's a lot of them. Hopefully this will reduce the > collisions in the future. > > Thanks, > > Steve Martinelli > OpenStack Keystone Core > > > > From: Shifali Agrawal > To: openstack-dev@lists.openstack.org > Date: 2015/10/06 03:40 PM > Subject: [openstack-dev] [Zaqar][cli][openstack-client] conflict in nova > flavor and zaqar flavor > > > > Greetings, > > I am implementing cli commands for Zaqar flavors, the command should be > like: > > "openstack flavor " > > But there is already same command present for Nova flavors. After > discussing with Zaqar devs we thought to change all zaqar commands such > that they include `message` word after openstack, thus above Zaqar flavor > command will become: > > "openstack message flavor " > > Does openstack-client devs have something to say for this? Or they also > feel its good to move with adding `message` word to all Zaqar cli > commands? > > Already existing Zaqar commands will work with get a deprecation > message/warning and also I will implement them all to work with `message` > word, and all new commands will be implement so that they work only with > `message` word. __ 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 -- @flaper87 Flavio Percoco signature.asc Description: PGP signature __ 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] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
On Mon, Oct 12, 2015 at 5:25 PM, Victoria Martínez de la Cruz < victo...@vmartinezdelacruz.com> wrote: > So, this commands would look like > > openstack pool-flavor create > openstack pool-flavor get > openstack pool-flavor delete > openstack pool-flavor update > openstack pool-flavor list > I would strongly suggest leaving the dash out of the resource name: openstack pool flavor create etc Multiple word names have been supported for a long time and the only other plugin I know that has them has a bug against it to remove the dash. dt -- Dean Troyer dtro...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
HI all, Thanks for your feedback. We discussed this topic in this week weekly meeting and we came to the conclusion that it would be better to use "pool-flavor" instead of creating a namespace for Zaqar only (by prefixing everything with the "message" key). So, this commands would look like openstack pool-flavor create openstack pool-flavor get openstack pool-flavor delete openstack pool-flavor update openstack pool-flavor list Best, Victoria 2015-10-10 10:10 GMT-03:00 Shifali Agrawal : > All right, thanks for responses, will code accordingly :) > > On Wed, Oct 7, 2015 at 9:31 PM, Doug Hellmann > wrote: > >> Excerpts from Steve Martinelli's message of 2015-10-06 16:09:32 -0400: >> > >> > Using `message flavor` works for me, and having two words is just fine. >> >> It might even be good to change "flavor" to "server flavor" (keeping >> flavor as a backwards-compatible alias, of course). >> >> Doug >> >> > >> > I'm in the process of collecting all of the existing "object" works are >> > putting them online, there's a lot of them. Hopefully this will reduce >> the >> > collisions in the future. >> > >> > Thanks, >> > >> > Steve Martinelli >> > OpenStack Keystone Core >> > >> > >> > >> > From:Shifali Agrawal >> > To:openstack-dev@lists.openstack.org >> > Date:2015/10/06 03:40 PM >> > Subject:[openstack-dev] [Zaqar][cli][openstack-client] conflict in >> nova >> > flavor and zaqar flavor >> > >> > >> > >> > Greetings, >> > >> > I am implementing cli commands for Zaqar flavors, the command should be >> > like: >> > >> > "openstack flavor " >> > >> > But there is already same command present for Nova flavors. After >> > discussing with Zaqar devs we thought to change all zaqar commands such >> > that they include `message` word after openstack, thus above Zaqar >> flavor >> > command will become: >> > >> > "openstack message flavor " >> > >> > Does openstack-client devs have something to say for this? Or they also >> > feel its good to move with adding `message` word to all Zaqar cli >> > commands? >> > >> > Already existing Zaqar commands will work with get a deprecation >> > message/warning and also I will implement them all to work with >> `message` >> > word, and all new commands will be implement so that they work only with >> > `message` word. >> >> __ >> 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] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
All right, thanks for responses, will code accordingly :) On Wed, Oct 7, 2015 at 9:31 PM, Doug Hellmann wrote: > Excerpts from Steve Martinelli's message of 2015-10-06 16:09:32 -0400: > > > > Using `message flavor` works for me, and having two words is just fine. > > It might even be good to change "flavor" to "server flavor" (keeping > flavor as a backwards-compatible alias, of course). > > Doug > > > > > I'm in the process of collecting all of the existing "object" works are > > putting them online, there's a lot of them. Hopefully this will reduce > the > > collisions in the future. > > > > Thanks, > > > > Steve Martinelli > > OpenStack Keystone Core > > > > > > > > From:Shifali Agrawal > > To:openstack-dev@lists.openstack.org > > Date:2015/10/06 03:40 PM > > Subject:[openstack-dev] [Zaqar][cli][openstack-client] conflict in > nova > > flavor and zaqar flavor > > > > > > > > Greetings, > > > > I am implementing cli commands for Zaqar flavors, the command should be > > like: > > > > "openstack flavor " > > > > But there is already same command present for Nova flavors. After > > discussing with Zaqar devs we thought to change all zaqar commands such > > that they include `message` word after openstack, thus above Zaqar flavor > > command will become: > > > > "openstack message flavor " > > > > Does openstack-client devs have something to say for this? Or they also > > feel its good to move with adding `message` word to all Zaqar cli > > commands? > > > > Already existing Zaqar commands will work with get a deprecation > > message/warning and also I will implement them all to work with `message` > > word, and all new commands will be implement so that they work only with > > `message` word. > > __ > 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] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
Excerpts from Steve Martinelli's message of 2015-10-06 16:09:32 -0400: > > Using `message flavor` works for me, and having two words is just fine. It might even be good to change "flavor" to "server flavor" (keeping flavor as a backwards-compatible alias, of course). Doug > > I'm in the process of collecting all of the existing "object" works are > putting them online, there's a lot of them. Hopefully this will reduce the > collisions in the future. > > Thanks, > > Steve Martinelli > OpenStack Keystone Core > > > > From:Shifali Agrawal > To:openstack-dev@lists.openstack.org > Date:2015/10/06 03:40 PM > Subject:[openstack-dev] [Zaqar][cli][openstack-client] conflict in nova > flavor and zaqar flavor > > > > Greetings, > > I am implementing cli commands for Zaqar flavors, the command should be > like: > > "openstack flavor " > > But there is already same command present for Nova flavors. After > discussing with Zaqar devs we thought to change all zaqar commands such > that they include `message` word after openstack, thus above Zaqar flavor > command will become: > > "openstack message flavor " > > Does openstack-client devs have something to say for this? Or they also > feel its good to move with adding `message` word to all Zaqar cli > commands? > > Already existing Zaqar commands will work with get a deprecation > message/warning and also I will implement them all to work with `message` > word, and all new commands will be implement so that they work only with > `message` word. __ 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] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
Using `message flavor` works for me, and having two words is just fine. I'm in the process of collecting all of the existing "object" works are putting them online, there's a lot of them. Hopefully this will reduce the collisions in the future. Thanks, Steve Martinelli OpenStack Keystone Core From: Shifali Agrawal To: openstack-dev@lists.openstack.org Date: 2015/10/06 03:40 PM Subject:[openstack-dev] [Zaqar][cli][openstack-client] conflict in nova flavor and zaqar flavor Greetings, I am implementing cli commands for Zaqar flavors, the command should be like: "openstack flavor " But there is already same command present for Nova flavors. After discussing with Zaqar devs we thought to change all zaqar commands such that they include `message` word after openstack, thus above Zaqar flavor command will become: "openstack message flavor " Does openstack-client devs have something to say for this? Or they also feel its good to move with adding `message` word to all Zaqar cli commands? Already existing Zaqar commands will work with get a deprecation message/warning and also I will implement them all to work with `message` word, and all new commands will be implement so that they work only with `message` word. __ 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
